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. > 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. 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. 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. 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. > *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. > 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 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.) > 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/ Regards, Andy