[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Andy Walls
Subject: Re: [Discuss-gnuradio] Works with GR 3.6, breaks with 3.7
Date: Sat, 18 Oct 2014 09:39:55 -0400

On Fri, 2014-10-17 at 12:00 -0400, address@hidden

> 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:
>       <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

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

The major tradeoff is the length of the FFT:
1. More FFT points gives you finer resolution bins and a finer
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
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

Although, if you have a known preamble to inspect, data-aided carrier
frequency offset correction is way better than the above non-data-aided


> 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
> >>

Attachment: square_and_fft_freq_sync.grc.png
Description: PNG image

Attachment: GMSK_squared_spectrum.png
Description: PNG image

reply via email to

[Prev in Thread] Current Thread [Next in Thread]