Re: [Discuss-gnuradio] The GMSK demodulation

[Tom Tsou]

On Fri, Feb 28, 2014 at 1:54 PM, Nick Foster <address@hidden> wrote:
> On Fri, Feb 28, 2014 at 10:21 AM, Tom Tsou <address@hidden> wrote:
>> I don't have much to add, but Nick and Sylvain touched on the largest
>> difference between the Gnuradio GMSK demod and GSM/TDMA type burst
>> processing - and it's not the Viterbi. The use of synchronization
>> loops (or lack thereof) in the demod is really the separating factor.
>
> Sample tagging in GR makes it easier to have it both ways in this case. If
> you have a correlator block that outputs timing phase estimates based on the
> preamble (or whatever), this should be used to initialize a closed-loop
> timing recovery block's phase. For bursty transmissions this lets you keep
> the loop gain pretty low and still acquire quickly. This is what Tom (R) is
> doing with the correlate_and_sync and polyphase_clock_sync blocks, and it's
> what I'm doing in my MSK timing recovery block, although I'm still dealing
> with a bug in that estimate. If you want to rely strictly on the timing
> phase estimate of the preamble as in GMSK's case you could just turn the
> loop gain of your favorite timing sync block to zero and let it act as a
> naive (and inefficient) decimator.

I wasn't implying that a combined method couldn't be done. But for
GSM, the assumption is that frequency sync is acquired separately
(with embedded tones), timing is derived from frequency, and Doppler
effects restricted (i.e. high speed train is not a supported use
case). Add in short durations before/after mid-amble and the benefits
of closed-loop timing begin to diminish.

Of course, these assumptions from GSM specification don't extend to
the generalized case and collapse when we handle continuous signals.
That was really the only point I was trying to make.

  -TT