On Fri, Feb 28, 2014 at 10:21 AM, Tom Tsou <t...@tsou.cc> wrote: > On Fri, Feb 28, 2014 at 11:51 AM, Nick Foster <bistrom...@gmail.com> > wrote: > > I'm working on a generalized CPM demod based on Achilleas's previous > work in > > gr-trellis/src/examples/test_cpm.py, and I have it more or less working > > although there are plenty of little bugs to work out. Since the Viterbi > part > > was more or less worked out for me, synchronization is the hard part; my > > application isn't GSM, and I'd like the solution in Gnuradio to be > > applicable to a wide range of systems -- this means closed-loop timing > and > > freq synchronization instead of just doing data-aided estimates from the > > preamble. > > 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. --n > > -TT >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
