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 On Oct 18, 2014 6:41 AM, "Andy Walls" <a...@silverblocksystems.net> wrote: > On Fri, 2014-10-17 at 12:00 -0400, discuss-gnuradio-requ...@gnu.org > wrote: > > > Message: 33 > > Date: Fri, 17 Oct 2014 07:37:25 -0700 > > From: John Malsbury <jmalsbury.perso...@gmail.com> > > To: Luke Berndt <l...@robotastic.com> > > Cc: "Discuss-gnuradio@gnu.org List" <discuss-gnuradio@gnu.org> > > Subject: Re: [Discuss-gnuradio] Works with GR 3.6, breaks with 3.7 > > Message-ID: > > <CAK+fQffv_gbGbq7DimJM0DiD= > agfz1rxekc7nav+xzimzqv...@mail.gmail.com> > > Content-Type: text/plain; charset="utf-8" > > > > 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 > > > Anyway, the GMSK block might be a good place to start. > > > > -John > > > > On Fri, Oct 17, 2014 at 7:35 AM, John Malsbury < > jmalsbury.perso...@gmail.com > > > wrote: > > > > > 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 > > > > > > On Fri, Oct 17, 2014 at 7:08 AM, Luke Berndt <l...@robotastic.com> > wrote: > > > > > >> 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: > > >> > https://github.com/bistromath/gr-smartnet/blob/master/src/python/fsk_demod.py > > >> > > >> 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 Braun <martin.br...@ettus.com > > > > >> wrote: > > >> > > >>> On 10/17/2014 08:28 AM, John Malsbury 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. > > >>> > > >>> > > >>> > > >> > > >> _______________________________________________ > > >> Discuss-gnuradio mailing list > > >> Discuss-gnuradio@gnu.org > > >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > >> > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
