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
