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 > <[email protected]> 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 > > [email protected] > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
