Re: [Discuss-gnuradio] Proper synchronization of f0T correction to use gr-trellis for a receiver (Re: gr-trellis test_cpm.py question)

[Andy Walls]

On Thu, 2017-04-06 at 20:55 +0000, Nick Foster wrote:
> Unrelated to the question at hand, but since you're on the subject:
> how are you resetting the Viterbi decoder state between packets? I
> tried the same thing some years ago and it worked well except for
> that problem.
> 
> --n

I haven't gotten that far yet. :P

I have a symbol synchronizer block (using the MSK TED that the MSK
timing recovery block uses) that will give me Q samples/symbol out,
synchronized to the symbol centers.  It also propagates tags properly,
so I'll have the center of one of the first symbols in a packet marked
with a tag (using the corr_est block).

I was planning on writing a block to inject samples, if needed, near
that marked symbol to keep the decimating matched filters and viterbi
inputs properly aligned (so they will always process fully aligned
symbols).

I had not looked into what state the metrics and viterbi decoder might
be keeping.  If they need explicit reseting, I was going to modify them
to watch for a tag.

So a lot of my design concept for feeding the gr-trellis CPM processing
methodology depends on this symbol synchronizer block:

https://github.com/awalls-cx18/gr-nwr/blob/master/grc/nwr_symbol_sync_x
x.xml

and another (to be written) custom block for injecting < Q samples to
preserve alignment, and perhaps yet another (to be written) custom
block to handle the f0T frequency correction.  (The GNURadio stock
rotator block actually drifts slightly over a great many samples due to
numerical roundoff, plus it can't be synchronously reset).

I was hoping using gr-trellis practically would have been a little bit
easier. :(  

-Andy

> On Thu, Apr 6, 2017 at 12:38 PM Andy Walls
> <address@hidden> wrote:
> > On Mon, 2017-04-03 at 09:06 -0400, Achilleas Anastasopoulos wrote:
> > > sure, feel free to look into the gr-trellis documentation and
> > provide
> > > some feedback.
> > > If you have further questions please let us know.
> > >
> > > best,
> > > Achilleas
> > 
> > Hi Achilleas:
> > 
> > My objective is to implement an AIS (GMSK, BT=0.4, L=3) receiver,
> > using
> > the Viterbi algorithm for optimal demodulation of the CPM symbols.
> > 
> > In examining gr-trellis/examples/python/test_cpm.py, I see that
> > everything is perfectly synchronized, for the purposes of
> > demonstration. (The addition of a 0.0 to the end of the 99% energy
> > orthonormal basis vectors for the matched filter correlators, to
> > have
> > the taps completely fall into the initial all-0 history of the fir
> > filter blocks, was a nice trick BTW).
> > 
> > In my design concept for a receiver, I believe I have worked out
> > carrier frequency offset correction, phase offset correction,
> > symbol
> > timing recovery at either 4 or 5 samples per symbol, and injecting
> > samples to properly realign the symbols entering the decimating
> > matched
> > filter correlators when a new burst is received.
> > 
> > What I can't quite figure out is how to properly synchronize the
> > correction of f0T carrier frequency shift introduced by the CPM
> > decomposition, without unintentionally adding an arbitrary phase
> > shift
> > to the symbol's signal in the CPM decomposition.
> > 
> > Do I restart the complex exponential frequency shift sequence with
> > a
> > phase of 0 at the start of each symbol?  I think that works for
> > Q=4.
> > But what about for Q=5?
> > 
> > The reason I ask is that it appears the phase of the complex
> > correlation output by the matched filters will affect the metric
> > for
> > which CPM decomposition signal gets selected as the best match.
> > 
> > Looking at the 16, 99% energy CPM decomposition signals generated
> > by
> > the test_cpm.py script:
> > 
> > >>> print abs(Sf.transpose())
> > [[ 1.81592306  0.83465307]
> >  [ 1.81592306  0.83465307]
> >  [ 1.90550352  0.600571  ]
> >  [ 1.90550352  0.600571  ]
> >  [ 1.96823385  0.34970555]
> >  [ 1.96823385  0.34970555]
> >  [ 1.90550352  0.600571  ]
> >  [ 1.90550352  0.600571  ]
> >  [ 1.90550352  0.600571  ]
> >  [ 1.90550352  0.600571  ]
> >  [ 1.96823385  0.34970555]
> >  [ 1.96823385  0.34970555]
> >  [ 1.90550352  0.600571  ]
> >  [ 1.90550352  0.600571  ]
> >  [ 1.81592306  0.83465307]
> >  [ 1.81592306  0.83465307]]
> > 
> > Many of the signals can only be distinguished from each other
> > properly
> > when the correlator outputs have proper phase.
> > 
> > Thank you for any advice you can provide.
> > 
> > Regards,
> > Andy
> > 
> > _______________________________________________
> > Discuss-gnuradio mailing list
> > address@hidden
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >