Re: [Discuss-gnuradio] Works with GR 3.6, breaks with 3.7

[Andy Walls]

On Sat, 2014-10-18 at 08:00 -0700, Nick Foster 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. :P

Thanks Nick.

-Andy

> 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" <address@hidden>
> wrote:
>         On Fri, 2014-10-17 at 12:00 -0400,
>         address@hidden
>         wrote:
>         
>         > Message: 33
>         > Date: Fri, 17 Oct 2014 07:37:25 -0700
>         > From: John Malsbury <address@hidden>
>         > To: Luke Berndt <address@hidden>
>         > Cc: "address@hidden List"
>         <address@hidden>
>         > Subject: Re: [Discuss-gnuradio] Works with GR 3.6, breaks
>         with 3.7
>         > Message-ID:
>         >       <CAK+fQffv_gbGbq7DimJM0DiD=aGFz1RXekc7NaV
>         address@hidden>
>         > 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
>         <address@hidden
>         > > 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
>         <address@hidden> 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
>         <address@hidden>
>         > >> 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
>         > >> address@hidden
>         > >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>         > >>
>         
>         
>         _______________________________________________
>         Discuss-gnuradio mailing list
>         address@hidden
>         https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>