Hi Andy,
tl;dr I've tried everything and still can't get a lock on the sync, it drifts off or not locking.
Thanks alot!
It looks like you are always the one who answers my issues (2/2 :D), so thanks again.
I only now had the time to experiment with the ideas in your response.
Screenshot from the current graph attempt:
It is visible that the clock skews on the sync pattern, but I've not been able to get it to stay on the same phase/freq of the clock.
I'm attaching an
1)updated graph for the capture
2)
a simulation graph I made for testing and works good
- (I think, please point me how to make it more realistic)
3) the sample I'm using for the (1) graph
I Really need your help / this mailing list's help.
Thanks A Lot!
HLL / Hillel if u wish :P
On Sun, Aug 16, 2020, 8:42 PM Andy Walls <andy@silverblocksystems.net> wrote:
From: HLL
Date: Sun, 16 Aug 2020 10:23:06 +0300
> Hello all,
>
> I Am in the information security industry (so I do not have a signal
> processing background) and I'm trying to properly extract symbols of
> a signal.
> The device that I have access to (and no real internal documentation,
> I'm reverse-engineering it 'from the outside') can be triggered to
> send the data, I do not have access to the internal hardware.
> Also, The product is outside the US, but I think I've managed to find
> a similar device which the data does make sense for.
>
> Measured Frequency deviation ~600hz (for +1, for +3 1800)
When I look at the difference between symbols where ISI isn't dragging
things towards 0 (i.e. the flat regions), I get levels of +/- 2100 Hz
and +/- 700 Hz, so essentially 1400 Hz between each of the nominal
signal levels.
That's a bit odd for me since I've measured 600, but I will try with it also
> FCC: Channel width: 12.5khz, I do not know how to measure it (?)
The spectrum of your input signal shows that it has been filtered to
fit into a 25 kHz channel for sure, with a very steep filter.
That's one thing I've may omitted from my initial post, the capture is after some filtering of mine.
There looks to be another narrower stage of filtering (maybe just a
Gaussian pulse filter?) At the -40 dB down points, the spectrum is
taking up about 13kHz to 14 kHz. Maybe it's supposed to fit in a
12.5kHz channel, if the specification is for the signal to be only -30
dB down in the adjacent channel.
> FCC: Symbol rate 6kb/s ; I Measured 5900~6010 Sym/s
I estimated about 17 samples/symbol at 100 ksps (~5882.4 symbols/sec)
so 6 kbaud sounds right. At 2 bits per symbol, that's 12 kbps.
> FCC: Modulation 4 Level FSK, (Seems to make sense, see capture)
!t certainly looks like 4 FSK. The preamble and first few symbols stay
at the +/-3 levels probably to facilitate CFO correction and symbol
timing synchronization.
> Googling, I've found 2 Related things:
> 1. C4FM Demodulator via gnuradio - As it seems, I have almost exact
> modulation, I've tried to change the symbol rate accordingly, but I
> did not get any proper results
> 2. I Have checked out the OOT Blocks that are referenced here, but
> they are for an ancient version of GR; In order to port it I'd have
> to somehow understand both the old and the new version.
>
> I've scoured the internet trying to understand how to perform this
> task independently while I'm no math expert.
> What I've tried:
> *I tried using various configurations of RRC (as I understood that's
> the filter I should feed into the symbol synchronizer block) I
> somehow manage to configure it in such a way as intended, I believe
> so that the value is that; but do I really need such a filter?
I tried a couple different iterations of an RRC filter with various
bandwidth factors and filter length. All of them made the ISI worse
not better. I suspect this data is not RRC filterd on Tx, as I would
expect overshoots in the pulses, that just aren't in your data.
> If I'm not mistaken, the fm-demodulated time domain looks like a
> gaussian filter, not a RRC one.
I tend to agree. It would be pretty mild though, probably a pretty
high BT
> *Tried using polyphase clock sync (the old version and the 'symbol
> sync' version) with various values, again usually the sampling
> doesn't occur at the best position and slicer can't properly tell
> between +3 and +1 etc) .
The Maximum Likelyhood, small signal approximation TED in the polyphase
clock sync block assumes 2-level pulses, not 4-level. It's the wrong
tool for the job.
The M&M TED is designed for mutli-level pulses. You'll have to use the
one is the symbol sync block, along with a 4-level constellation
object.
I have built some simulation for this and it looks awesome and simple enough, unfortunately cant seem to get it to work with the real signal.
Be warned that the GNURadio constellation object autoscales your
constellation so that the symbol levels have a mean magnitude of 1.0.
(e.g. 4FSK levels would be +/-0.5 and +/-1.5, even though you told the
constellation object +/-1 and +/-3). I don't particularly like this
"feature" but you have to deal with it. That means adjusting the gain
of your input burst of pulses so that the excursions match the
constellation object the M&M TED is using to make symbol decisions.
Thank you!! An awesome tip proved to be very useful when I built the simulation.
Also, if just used the quadrature demod block to perfom FM
demodulation, you should squelch the FM noise output between bursts.
This noise will have the symbol sync block pulled off into la-la-land
and make acquisition of symbol timing at the next burst take much
longer.
Sure, also for the testing, I manually silence out non-data arras with an editor (URH)
> *Universal radio hacker" somehow did the trick, but I guess
> "autodetect" for the 4 level does not work properly and I can't
> configure the values so that I would have consistent results.
I don't think stock GNURadio has a 4-level slicer. You'll probably
have to write your own block for that.
That's apparently easy enough with the constellation decoder? Am I using it right?
> If someone could point me out to how to properly and reliably extract
> the symbols from these kinds of signals, I would greatly appreciate
> it.
GNURadio comes with a sample flowgraph for playing around with the
symbol synch block and a two level burst signal with some ISI.
https://github.com/gnuradio/gnuradio/blob/master/gr-digital/examples/demod/symbol_sync_test_float.grc
That's pretty straightforward I guess, just maybe, how to choose relatively ok parameter values, if the values are my problem then it doesn't helps me alot :(
I recommend just playing around with it, to get a feel for how various
PLL symbol synchronizer configurations behave.
(hint there is a trade-off between rapid timing acquisition vs. stabel
tracking.)
Yeah, sure that makes sense, higher loop bandwidth makes lock faster but easier jitter, narrower denies jittering while tracking longer to catch up with the current center-phase (? or sym-rate?)
My intention was that I ALMOST ALWAYS have issues synchronizing high snr, relatively clean signal.
I know that there isn't any jocker or one trick pony for this, but the time I've spent both trying to understand what values exactly I need to punch in, and both experimenting with 'gui sliders' only both to be a total failure that does not even come close to a reliable symbol extraction, that is readable with the naked eye.
> I've attached the capture from 2 different devices (they send a few
> bursts with each trigger, this case 3 each), after I've ~centered
> them and downsampled to 100ks/s (IQ Float)
>
> I Would like to "get the fish" but I would also value that you point
> me out to learning "how to fish" as it's not the first time that I'm
> having trouble in clock recover/symbol timing and this field is just
> an online puzzle that I never seem to get right (even for clean-
> looking signals with proper reception).
I'll point you to this brief on the GNURadio symbol synch blocks. It's
not going to help you solve your problem directly, but It will give you
some background on PLL symbol synchronizers.
https://www.gnuradio.org/grcon/grcon17/presentations/symbol_clock_recovery_and_improved_symbol_synchronization_blocks/
That was somehow a bit over my level, but VERY INTERESTING, and somehow contributing to my understanding.
Regards,
Andy
