# Works with GR 3.6, breaks with 3.7 **URL:** \ **Category:** GNU Radio\ **Created:** [October 13, 2014, 7:39pm UTC](https://www.ruby-forum.com/t/works-with-gr-3-6-breaks-with-3-7/232512 "2014-10-13T19:39:57Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![addis\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c4cdca/32.png) [@addis\_a](https://www.ruby-forum.com/u/addis_a)\ **Post date:** [October 13, 2014, 7:39pm UTC](https://www.ruby-forum.com/t/works-with-gr-3-6-breaks-with-3-7/232512/1 "2014-10-13T19:39:57Z")
I have a GnuRadio C++ program that decodes and records a SmartNet Trunked radio system. It is running great under GnuRadio 3.6.5.1, but it doesn’t seem to be working under 3.7.6. 3.6 is installed in /usr/local and 3.7.6 was installed in my home directory using PyBombs. My updated program compiles against 3.7 with no problem and runs. It will pick up a few of the trunking commands, so it is working, but the ratios is about 1 to 100 compared to 3.6. I also tried running it in a Ubuntu VM with 3.7 installed at /usr/local and had the same results. I corrected for the change with XlatingFirFilter in 3.7, so it is the opposite offset of 3.6. It looks like it could be a tuning error though, the flow graph seems to be failing mostly at the CRC check. Did anything else change with Blocks in 3.7? I looked at gr-osmosdr but I didn’t notice huge discrepancies between the 3.6 and 3.7 branches. Are there some obvious things I could be missing? I feel like this is something small and stupid that I missing. The diff between the two versions is here, smartness.cc is the main file that decodes the control channel. As you can see, there is not that much different: [https://github.com/robotastic/smartnet-recorder/compare/master...3.7-Update#diff-73510702485a7dd2f7000285cbd5e557R40](https://github.com/robotastic/smartnet-recorder/compare/master...3.7-Update#diff-73510702485a7dd2f7000285cbd5e557R40) [https://github.com/robotastic/smartnet-recorder/compare/master...3.7-Update#diff-73510702485a7dd2f7000285cbd5e557R40](https://github.com/robotastic/smartnet-recorder/compare/master...3.7-Update#diff-73510702485a7dd2f7000285cbd5e557R40) Here is the central code block that does it. Anything obviously dumb here? float samples\_per\_second = samp\_rate; float syms\_per\_sec = 3600; float gain\_mu = 0.01; float mu=0.5; float omega\_relative\_limit = 0.3; float offset = chan\_freq - center\_freq; // have to reverse it for 3.7 because it swapped in the switch. float clockrec\_oversample = 3; int decim = int(samples\_per\_second / (syms\_per\_sec \* clockrec\_oversample)); float sps = samples\_per\_second/decim/syms\_per\_sec; const double pi = boost::math::constants::pi(); cout \<\< "Control channel offset: " \<\< offset \<\< endl; cout \<\< "Decim: " \<\< decim \<\< endl; cout \<\< "Samples per symbol: " \<\< sps \<\< endl; ``` std::vector lpf_taps; init_loggers(max_loggers, center_freq, samp_rate); gr::msg_queue::sptr queue = gr::msg_queue::make(); ``` lpf\_taps = gr::filter::firdes::low\_pass(1, samp\_rate, 10000, 12000); gr::filter::freq\_xlating\_fir\_filter\_ccf::sptr prefilter = gr::filter::freq\_xlating\_fir\_filter\_ccf::make(decim, lpf\_taps, offset, samp\_rate); gr::digital::fll\_band\_edge\_cc::sptr carriertrack = gr::digital::fll\_band\_edge\_cc::make(sps, 0.6, 64, 0.35); ``` gr::analog::pll_freqdet_cf::sptr pll_demod = ``` gr::analog::pll\_freqdet\_cf::make(2.0 / clockrec\_oversample, 2_pi/clockrec\_oversample, -2_pi/clockrec\_oversample); gr::digital::clock\_recovery\_mm\_ff::sptr softbits = gr::digital::clock\_recovery\_mm\_ff::make(sps, 0.25 \* gain\_mu \* gain\_mu, mu, gain\_mu, omega\_relative\_limit); gr::digital::binary\_slicer\_fb::sptr slicer = gr::digital::binary\_slicer\_fb::make(); gr::digital::correlate\_access\_code\_tag\_bb::sptr start\_correlator = gr::digital::correlate\_access\_code\_tag\_bb::make(“10101100”,0,“smartnet\_preamble”); smartnet\_deinterleave\_sptr deinterleave = smartnet\_make\_deinterleave(); smartnet\_crc\_sptr crc = smartnet\_make\_crc(queue); tb-\>connect(src,0,prefilter,0); tb-\>connect(prefilter,0,carriertrack,0); tb-\>connect(carriertrack, 0, pll\_demod, 0); tb-\>connect(pll\_demod, 0, softbits, 0); tb-\>connect(softbits, 0, slicer, 0); tb-\>connect(slicer, 0, start\_correlator, 0); tb-\>connect(start\_correlator, 0, deinterleave, 0); tb-\>connect(deinterleave, 0, crc, 0); tb-\>start(); ---
**Author:** ![hagus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/9de053/32.png) [@hagus](https://www.ruby-forum.com/u/hagus)\ **Post date:** [October 16, 2014, 4:20pm UTC](https://www.ruby-forum.com/t/works-with-gr-3-6-breaks-with-3-7/232512/2 "2014-10-16T16:20:39Z")
I just tried doing a complete PyBombs reinstall and that didn’t seem the help. I checked and simple GRC files run fine. I can also see the signal where I expect it to be in GQRX, so I think my tuning parameters are correct. Are there some other things I should try? Sent from my iPhone ---
**Author:** ![hagus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/9de053/32.png) [@hagus](https://www.ruby-forum.com/u/hagus)\ **Post date:** [October 17, 2014, 8:29am UTC](https://www.ruby-forum.com/t/works-with-gr-3-6-breaks-with-3-7/232512/3 "2014-10-17T08:29:38Z")
Luke, I researched this for a bit (OK, maybe it was more like staring blankly)… unfortunately on a windows machine w/out git. Nothing stands out at the momentt. I’ll give it another try tomorrow! =) Also, I’ve never used the PLL blocks for freq demod before. Can you set something up with a graphical sink and send some snapshots showing what the output of that looks like? Also also, is the Band-Edge FLL ideal for GMSK? My possibly, incorrect understanding of that block is that it was more ideal for PAM with common RRC. -John ---
**Author:** ![hagus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/9de053/32.png) [@hagus](https://www.ruby-forum.com/u/hagus)\ **Post date:** [October 17, 2014, 11:09am UTC](https://www.ruby-forum.com/t/works-with-gr-3-6-breaks-with-3-7/232512/4 "2014-10-17T11:09:42Z")
John, I use the BE FLL for auto-doppler correction in the rare case where I am not actively correcting for doppler. But, the correction is _really_ slow. I’m probably not using it correctly, but it works OK in that rare case when it’s all I’ve got. Very Respectfully, Dan CaJacob On Fri, Oct 17, 2014 at 2:28 AM, John M. \ **Author:** ![hagus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/9de053/32.png) [@hagus](https://www.ruby-forum.com/u/hagus)\ **Post date:** [October 17, 2014, 2:20pm UTC](https://www.ruby-forum.com/t/works-with-gr-3-6-breaks-with-3-7/232512/5 "2014-10-17T14:20:09Z") On 10/17/2014 08:28 AM, John M. wrote: > Also also, is the Band-Edge FLL ideal for GMSK? My possibly, incorrect > understanding of that block is that it was more ideal for PAM with > common RRC. For the record: It might work coincidentally because of the rolloff-y shape of GMSK, but it’s derived for and designed for common PAM/RRC, as John says and I wouldn’t recommend it for anything else. To look up the math, I suggest Harris’ works. Cheers, M ---
**Author:** ![hagus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/9de053/32.png) [@hagus](https://www.ruby-forum.com/u/hagus)\ **Post date:** [October 17, 2014, 4:10pm UTC](https://www.ruby-forum.com/t/works-with-gr-3-6-breaks-with-3-7/232512/6 "2014-10-17T16:10:18Z")
Thanks for looking into it! To be honest, I am not really good at RF. I based my code off the python code in gr-smartnet. The fsk-demod python file is here: > It is quite possible that it just happened to work because of an error that got patched in Gr 3.7. Are there some good examples for GMSK/FSK demodulation that I could borrow from instead? Recreating this in GRC sounds like a great idea so I can scope along the way. I will give that a try next. Thanks again for the pointers, fresh eyes are really helpful when you have been staring at it for so long. - Luke On Fri, Oct 17, 2014 at 8:18 AM, Martin B. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) ---
**Author:** ![hagus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/9de053/32.png) [@hagus](https://www.ruby-forum.com/u/hagus)\ **Post date:** [October 17, 2014, 4:38pm UTC](https://www.ruby-forum.com/t/works-with-gr-3-6-breaks-with-3-7/232512/7 "2014-10-17T16:38:17Z")
Also, my understanding for the PLL blocks were that they were ideal for “strong carrier” signals like AM. When I say strong carrier i mean a signal that has an obvious carrier which isn’t “hidden” under modulation… Anyway, the GMSK block might be a good place to start. -John On Fri, Oct 17, 2014 at 7:35 AM, John M. \ **Author:** ![hagus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/9de053/32.png) [@hagus](https://www.ruby-forum.com/u/hagus)\ **Post date:** [October 17, 2014, 4:36pm UTC](https://www.ruby-forum.com/t/works-with-gr-3-6-breaks-with-3-7/232512/8 "2014-10-17T16:36:29Z") It doesn’t have frequency correction - I can probably follow up with some ideas on how to implement that part. But the GMSK demod might do OK for you initially. It doesn’t do anything intelligent to deal with the data shaping - its just a non-coherent slicer. If you want to design in GRC but keep your top-level application as is, you can use a hier block. You can also use a command line parameter or other mechanism to select your demodulator at start-time for easy comparisons. [typed one handed… my daughter has my other and] -John ---
**Author:** ![hagus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/9de053/32.png) [@hagus](https://www.ruby-forum.com/u/hagus)\ **Post date:** [October 17, 2014, 9:34pm UTC](https://www.ruby-forum.com/t/works-with-gr-3-6-breaks-with-3-7/232512/9 "2014-10-17T21:34:46Z")
It actually looks like the control channel for Motorola SmartNet is FSK: "On the control (data) channel the base station transmits 84 bits frames at 3600 bit/s with direct frequency modulation of the carrier using Frequency Shift Keying (FSK). " I will at least see if I can get something that looks right out the other side. Would it be best to use one of the GFSK examples in gr-digital? On Fri, Oct 17, 2014 at 10:37 AM, John M. \< ---
**Author:** ![hagus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/9de053/32.png) [@hagus](https://www.ruby-forum.com/u/hagus)\ **Post date:** [October 19, 2014, 8:43am UTC](https://www.ruby-forum.com/t/works-with-gr-3-6-breaks-with-3-7/232512/10 "2014-10-19T08:43:32Z")
On Fri, 2014-10-17 at 12:00 -0400, [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > Also, my understanding for the PLL blocks were that they were ideal for > “strong carrier” signals like AM. When I say strong carrier i mean a > signal that has an obvious carrier which isn’t “hidden” under modulation.. John and Luke, Yup. GMSK doesn’t have any narrow and strong spectral feature on which one can lock a PLL. (And the band-edge FLL is the wrong thing to use too.) You can however get a spectral feature from the square of the GMSK signal. _Assuming_ you have an approximately random bit stream, squaring the GMSK signal gives you spectral peaks at f\_c +/- f\_b/2, where f\_c is the center frequency and f\_b is your bit rate. See the attached “GMSK\_squared\_spectrum.png” which shows the spectra from a random bit stream. So you can get a non-data-aided coarse frequency correction doing essentially what older versions of gr-ais did. See the attached “square\_and\_fft\_freq\_sync.grc.png”. The gr-ais “freqest” block is the only non-stock gnuradio block and it just walks the FFT looking for the spectral peaks at +/- f\_b/2 and outputs a frequency correction values based on how many FFT bins the peaks are offset from the expected center frequency. The major tradeoff is the length of the FFT: 1. More FFT points gives you finer resolution bins and a finer correction. 2. More FFT points protects against pathological data sequences (e.g. a long run of 0’s) that give different spectral peaks which screw up the correction. 3. Fewer FFT points ensures the start and end of bursts get the proper correction as the correction reacts faster to the transition from dead-air to modulated signal. 4. Fewer FFT points ensures faster reaction to changes in frequency offset. Although, if you have a known preamble to inspect, data-aided carrier frequency offset correction is way better than the above non-data-aided stuff. Regards, Andy ---
**Author:** ![hagus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/9de053/32.png) [@hagus](https://www.ruby-forum.com/u/hagus)\ **Post date:** [October 19, 2014, 10:04am UTC](https://www.ruby-forum.com/t/works-with-gr-3-6-breaks-with-3-7/232512/11 "2014-10-19T10:04:26Z")
Figured I’d chime in since I wrote the code in question. The band edge FLL is probably the wrong thing to use, but it did work surprisingly well for my local setup (at very high SNR), so I left it in. The square-and-FFT block works great for MSK, but Smartnet isn’t MSK, it’s FSK, and its lack of phase coherence (and variable deviation) mean you won’t see those nice 1/2-bitrate FFT spikes. As Andy points out, the “right” answer is to correlate against the modulated preamble and develop phase, frequency, and timing estimates from the known preamble. –n ---
**Author:** ![hagus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/9de053/32.png) [@hagus](https://www.ruby-forum.com/u/hagus)\ **Post date:** [October 19, 2014, 11:01am UTC](https://www.ruby-forum.com/t/works-with-gr-3-6-breaks-with-3-7/232512/12 "2014-10-19T11:01:32Z")
Thanks! I clearly have a lot of RF theory to read up on. The Band Edge FLL works great for me too, on 3.6. Does anyone know if there were changes to it or surrounding blocks in 3.7 that would make it stop working? I have a pretty strong, clean signal. Sent from my iPhone ---
**Author:** ![hagus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/9de053/32.png) [@hagus](https://www.ruby-forum.com/u/hagus)\ **Post date:** [October 17, 2014, 9:40pm UTC](https://www.ruby-forum.com/t/works-with-gr-3-6-breaks-with-3-7/232512/13 "2014-10-17T21:40:43Z")
The good news is. the GFSK block doesn’t do anything specific to Gaussian FSK. So I guess tha tall works out =) You’re outputs might be more illustrative if you rebuild it in from the blocks actually inside the GFSK demod block: quad demod \> clock recovery -\> slicer ---
**Author:** ![hagus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/9de053/32.png) [@hagus](https://www.ruby-forum.com/u/hagus)\ **Post date:** [October 19, 2014, 11:14am UTC](https://www.ruby-forum.com/t/works-with-gr-3-6-breaks-with-3-7/232512/14 "2014-10-19T11:14:02Z")
Tom changed it to use the fir\_filter\_with\_buffer vs. the standard fir\_filter internally, but as the taps remain the same I’d imagine it to be more or less numerically identical. First step I think is to verify that the FLL is actually the problem – get a scope on the output of the FLL and see that your FSK signal is more or less at baseband. –n ---
**Author:** ![hagus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/9de053/32.png) [@hagus](https://www.ruby-forum.com/u/hagus)\ **Post date:** [October 19, 2014, 11:38am UTC](https://www.ruby-forum.com/t/works-with-gr-3-6-breaks-with-3-7/232512/15 "2014-10-19T11:38:27Z")
On Sat, 2014-10-18 at 08:00 -0700, Nick F. wrote: > Figured I’d chime in since I wrote the code in question. The band edge > FLL is probably the wrong thing to use, but it did work surprisingly > well for my local setup (at very high SNR), so I left it in. The > square-and-FFT block works great for MSK, but Smartnet isn’t MSK, it’s > FSK, Oops, I thought the thread was about GMSK. I guess I didn’t read far enough back. 😛 Thanks Nick. -Andy ---
**Author:** ![hagus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/9de053/32.png) [@hagus](https://www.ruby-forum.com/u/hagus)\ **Post date:** [October 20, 2014, 9:36am UTC](https://www.ruby-forum.com/t/works-with-gr-3-6-breaks-with-3-7/232512/16 "2014-10-20T09:36:39Z")
On 10/18/2014 05:57 PM, Luke B. wrote: > The Band Edge FLL works great for me too, on 3.6. Does anyone know if > there were changes to it or surrounding blocks in 3.7 that would make it > stop working? None of the DSP was changed, if it worked before it should™ still work. The reason we say it’s a bad choice is that it was derived for PSK/PAM signals. The reason it still might work is that the implementation runs 2 filters at the band-edges and compares the energy content of those, and that difference might be sufficient to correct your frequency offset if you have sufficient averaging (i.e. low enough loop bandwidth). M ---
**Author:** ![hagus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/9de053/32.png) [@hagus](https://www.ruby-forum.com/u/hagus)\ **Post date:** [October 27, 2014, 4:11am UTC](https://www.ruby-forum.com/t/works-with-gr-3-6-breaks-with-3-7/232512/17 "2014-10-27T04:11:46Z")
* * * Discuss-gnuradio mailing list removed\_email\_address@domain.invalid [https://lists.gnu.org/mailman/listinfo/discuss-gnuradio](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) ---
**Author:** ![hagus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/9de053/32.png) [@hagus](https://www.ruby-forum.com/u/hagus)\ **Post date:** [October 27, 2014, 1:05am UTC](https://www.ruby-forum.com/t/works-with-gr-3-6-breaks-with-3-7/232512/18 "2014-10-27T01:05:46Z")
Thanks - Most bizarre. That probably means it is somewhere in my code. I am still trying to rebuild the demodulator just in case it helps. I have been following this guide: [http://www.inguardians.com/pubs/GRC\_signal\_analysis\_InGuardians\_v1.pdf](http://www.inguardians.com/pubs/GRC_signal_analysis_InGuardians_v1.pdf) [http://www.inguardians.com/pubs/GRC\_signal\_analysis\_InGuardians\_v1.pdf](http://www.inguardians.com/pubs/GRC_signal_analysis_InGuardians_v1.pdf) I have attached a screenshot of the graph I am using and what the output looks like in Baudline. Does the output look about right? I was having trouble finding the FSK Deviation for the Quad Demod for Moto SmartNet. Does 4500Hz seem about right? ---
**Author:** ![hagus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/9de053/32.png) [@hagus](https://www.ruby-forum.com/u/hagus)\ **Post date:** [November 3, 2014, 1:29pm UTC](https://www.ruby-forum.com/t/works-with-gr-3-6-breaks-with-3-7/232512/19 "2014-11-03T13:29:43Z")
On the off chance that someone has some free time to look into this, I have built the Smartnet trunk control channel in GRC. I have also made a capture of the signal. Everything is working the way it does on my C++ program. It is able find a lot of frames where the preamble matches, but barely any of them bas the CRC test. The expected behavior is that there would be 2-3 frames that pass the CRC test every second, and that is how it works under 3.6.5. The SmartNet stuff is rolled into 3.7 blocks. Git clone, cmake . , make, sudo make install If anyone sees some obvious mistakes let me know. I know this not the ideal way to decode an FSK signal, but it works perfectly in 3.6. Thanks for any pointers people have! Capture of the signal: [WeTransfer - Send Large Files & Share Photos Online - Up to 2GB Free](http://we.tl/ZMD8R5uQfR) [http://we.tl/ZMD8R5uQfR](http://we.tl/ZMD8R5uQfR) GRC Blocks for Smartnet > **[GitHub - robotastic/gr-smartnet](https://github.com/robotastic/gr-smartnet)** > > Contribute to robotastic/gr-smartnet development by creating an account on GitHub. [https://github.com/robotastic/gr-smartnet](https://github.com/robotastic/gr-smartnet) GRC to decode Smartnet Tunking channel ---
**Author:** ![hagus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/9de053/32.png) [@hagus](https://www.ruby-forum.com/u/hagus)\ **Post date:** [November 4, 2014, 1:41pm UTC](https://www.ruby-forum.com/t/works-with-gr-3-6-breaks-with-3-7/232512/20 "2014-11-04T13:41:36Z")
On Mon, 2014-11-03 at 12:01 -0500, [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > The SmartNet stuff is rolled into 3.7 blocks. Git clone, cmake . , > make, sudo make install > > If anyone sees some obvious mistakes let me know. I know this not the > ideal way to decode an FSK signal, but it works perfectly in 3.6. Hi Luke, I have not built the SmartNet blocks yet, but: Your low pass filter looks way too wide and you’ll get aliases when you decimate by 185. 2 Msps / 185 = 10.81 ksps, so the Nyquist frequency is 5.405 kHz. I winged this is as a low pass filter and things looked better: firdes.low\_pass\_2(1, samp\_rate, 4500, 1000, 60, firdes.WIN\_HANN, 6.76) The 60 dB down may be overkill, you can make it smaller for a filter with less delay. I found an offset slider value of -15k made things look about centered manually. You might want to put a waterfall sink before and after the FLL Band-Edge filter to observe how it is making the spectrum wobble around a little. If you change your offset slider, you can see the FLL band-edge filter centering things back up; so that looks like it is working. Regards, Andy [Next page](https://www.ruby-forum.com/t/works-with-gr-3-6-breaks-with-3-7/232512.md?page=2)