Hi all,
I’ve attempted to follow the M&M optimization algorithm paper, which GNU
Radio implements, to try and select proper parameters for a O-QPSK / MSK
implementation floating around that a UCLA group wrote:
http://acert.ir.bbn.com/projects/gr-ucla/
I ask because it seems as though the PHY is not recovering from clock
drift properly, which would be the goal of the M&M block. The blue in
this graph is not important, but note the smearing on the right:
http://cyprus.cmcl.cs.cmu.edu/tmp/graphs/zigbee_sample_dump9_unit_circle_19v20.jpg
That smearing is not recovered from properly by M&M and causes loss, as
an example. This causes approximately anywhere from 5-15% frame loss
over coax.
So I was pointed to the M&M paper, to try and understand why its
recovery is not working properly, looking to set proper parameters. The
paper is here:
http://ieeexplore.ieee.org/iel1/2220/8932/00392689.pdf
But, if you read the first paragraph, it states that this algorithm is
NOT for MSK, or GMSK for that matter:
“We are assuming a system whose output comprises nom-
inally synchronised data symbols subject to additive white Gaus-
sian noise, where the transmitter and the receiver use Nyquist root
raised-cosine filters.”
So, before I go any further… I was hoping someone could shed light on
how this ends up working out for GMSK which does not use an RRC filter.
Then, why would it not work with the MSK implementation? 
I
understand that GMSK is band-limited by the Gaussian filter, is this the
significant difference?
I suppose the overall question is the implications of using a CPM signal
when the GR clock recovery block was written using an RRC filter.
Thanks!
George
I could be wrong but I believe that block can work with a complex input
or a real input. For the case of GMSK/MSK it should work on a real
signal derived from the change in phase of the IQ(use
gr_quadrature_demod_cf) not the IQ itself as is the case in regular
QPSK. I believe the GMSK demo shows this. Filtering should not really
matter in either case. If you want to recover OQPSK you might need to
destagger the IQ stream for M&M to work, right?? MSK is really just
OQPSK with sine pulse shaping in the IQ domain but since it is really a
special case of FSK you can recover using FM detector or differential
phase techniques.
Thanks for the response.
You’re correct, it can work with complex or real input. GMSK and the
MSK implementation are both using the real input, passed on from
gr_quadrature_demod_cf. Here is the MSK impl:
https://moo.cmcl.cs.cmu.edu/trac/cmu_sdrg/browser/phys/802.15.4/trunk/src/python/ieee802_15_4.py#L84
I’m not sure if I and Q are meant to be de-staggered before hand or not.
George N. wrote:
George, Jeffrey:
You are discovering by inference in the M&M research work what most
communications professionals know because someone told them (usually
Matlab) ;-).
Staggered QAM and MSK minimize envelope variation and as such, the
nonlinearity in M&M generates a much weaker clock tone. At the risk of
bringing up sore topics, Matlab uses M&M where it is appropriate. For
MSK and GMSK, they use a fourth order nonlinearity to generate the clock
tone.
I use them and their large R&D shop as “proof by intimidation” rather
than going through all of the arguments why this should be so but they
start from the small envelope variation I mentioned.
google search Matlab MSK-type signal timing recovery. They have my
favorite timing author ever (Umberto Mengali) referenced.
Long before M&M wrote, Umberto Mengali wrote a paper on the asymptotic
maximum likelihood clock recovery method. After you approximate the
hyperbolic tangent with the simplest first order approximation and use
two tap differentiator, VOILA, M&M pops out.
–
AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL,
TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair
“Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it.” - Brian W. Kernighan
In the case of MSK or GMSK they don’t need to be destaggered although
you could if you wanted to recover the MSK like it was QPSK. If you did
this you would need to build a sine pulse match filter for MSK and for
GMSK I believe you are out of luck for matched filtering.
Just recovering OQPSK (whether or not it was RRC filtered) you could
destagger and then treat it like regular QPSK. I think if you used
differential encoding on the TX side I believe you could use a
differentially coherent technique like Lindsey’s book talks about. Not
sure how the matched filtering works out in that case. You probably do
it first and then do the phase math.
It is interesting how by adding a little memory to the
modulation(flavors of CPM) you have all kinds of interesting techniques
at you disposal.
While we are on the topic of clock recovery and someone more
knowledgeable than me is reading 
I would like to pose a question to
Bob. How might one do clock recovery on a M-ary CPM signal? It sounds
like a ML sequence technique might be an option but is there a simpler
ad-hoc technique that works as well? My “superiors” tell me to just do
clock recovery on a 2-ary modulated preamble and then hold it for the
rest of the packet when it switches to your M-ary mode. I suppose this
would work but I think it might be a little too much work in GNU right
now until the meta data extra channel thing is ready, right? For
simplicity I would prefer a technique that could run on streaming data
like the M&M.
thanks
Jeff
Long, Jeffrey P. wrote:
like the M&M.
thanks
Jeff
Jeff:
The answer is between the two.
Use the 2-ary modulated symbols for timing acquisition and also for
initial carrier recovery. Then since you will be close switch to a
tracking mode: Mengali’s joint timing and recovery algorithm for CPM
signals
Search for “Joint Timing and Phase Recovery for CPM signals” by Umberto
Mengali, et. al. The joint estimator helps significantly as you can
read.
Bob
–
AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL,
TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair
“Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it.” - Brian W. Kernighan
Thanks I will take a look.
Jeff
Long, Jeffrey P. wrote:
like the M&M.
thanks
Jeff
Also, let me be judgmental for a moment. I consider it extremely poor
design practice to assume stationary channels, even for short duration
signals if you can afford to do the tracking algorithms.
Bob
–
AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL,
TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair
“Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it.” - Brian W. Kernighan