So I did some thinking about how to synchronize to the 2*pi*f0*t phase term.
After checking the papers again and the particular GMSK example in test_cpm.py, that phase term cycles over 4 symbol periods, so it definitely adds phase ambiguity. Resetting it at every symbol is definitely the wrong thing to do. So I plugged in some real numbers from AIS to see what f0 actually was: Rb = 1/T = 9600 bits/sec h = 1/2 = f_dev / (Rb/2) => f_dev = 2400 Hz so the AIS GMSK signaling freqs are +/-2400 Hz. From Achilleas' paper, the expression for f0 is: M = 2 f0 = -h(M-1)/(2T) = -9600/4 = -2400 Hz So f0 is really the lower signaling frequency, at least for the specific case of binary MSK. (Achilleas, maybe you can comment on what f0 is in the general case?) I'm thinking that if I can pick off the phase of the lower signaling frequency during the AIS preamble (where I know there are always spots of -2400 Hz when a symbol repeats ), I can properly initialize the phase of the the frequency shift by f0. That seems kind of hokey to me, so I'm open to better ideas. I'd also like to hear if anyone thinks what I suggested will work or not. I was trying to contemplate how the t in 2*pi*f0*t could be incorporated into the FSM state, since this phase term appears to be part of the phase memory of the system, though not part of the modulation memory. I couldn't see an obvious way to do that. Regards, Andy On Thu, 2017-04-06 at 15:36 -0400, Andy Walls 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 Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
