Frequency offset compensation for 802.15.4 (ZigBee-MSK)

eric.jacobsen@ieee.org (Eric Jacobsen) writes:

> On Sat, 03 Oct 2015 07:54:15 -0400, Randy Yates
> <yates@digitalsignallabs.com> wrote:
>
>>"tarikkazaz" <50642@DSPRelated> writes:
>>
>>> Hi all,
>>>
>>> I am working on implementation of zigbee device on FPGA. Till now I have
>>> made Tx which is compatible with commercial devices. Also I have Rx which
>>> is working with my own Tx, but does not work with commercial devices.
>>> Major reason why my receiver can not decode signals from commercial
>>> devices is frequency offset. So far I tried to apply zero crossing
>>> approach to decode signal, but that does not help
>>> (http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=1615158&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D1615158).
>>> Previously I have been doing correlation of known chips with received
>>> signal (on that way I was able to decode signals from my own Tx). 
>>>
>>> Because now I am planning to start with implementation of frequency offset
>>> compensation for my receiver, I would like to get advice.  Which estimator
>>> do you suggest me to use? Or maybe I could use some simplified method, as
>>> zigbee has known preamble of 256 chips, which is 128 chips in I branch,
>>> and 128 chips in Q branch. Sampling rate of my ADC is 64Msps, and I was
>>> doing down sapling to 4Msps.
>>
>>Hi,
>>
>>MSK is FM, right? 
>
> No, MSK is not FM.   It is essentially OQPSK with crappy filtering.

PS: You are correct that it can be viewed as OQPSK with a sinusoidal
pulse-shape. See section 2.1.3 here:

  http://www.digitalsignallabs.com/hw.pdf
-- 
Randy Yates
Digital Signal Labs
http://www.digitalsignallabs.com

>eric.jacobsen@ieee.org (Eric Jacobsen) writes:
>
>> On Sat, 03 Oct 2015 07:54:15 -0400, Randy Yates
>> <yates@digitalsignallabs.com> wrote:
>>
>>>"tarikkazaz" <50642@DSPRelated> writes:
>>>
>>>> Hi all,
>>>>
>>>> I am working on implementation of zigbee device on FPGA. Till now I
>have
>>>> made Tx which is compatible with commercial devices. Also I have Rx
>which
>>>> is working with my own Tx, but does not work with commercial
devices.
>>>> Major reason why my receiver can not decode signals from commercial
>>>> devices is frequency offset. So far I tried to apply zero crossing
>>>> approach to decode signal, but that does not help
>>>>
>(http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber15158&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D1615158).
>>>> Previously I have been doing correlation of known chips with
received
>>>> signal (on that way I was able to decode signals from my own Tx). 
>>>>
>>>> Because now I am planning to start with implementation of frequency
>offset
>>>> compensation for my receiver, I would like to get advice.  Which
>estimator
>>>> do you suggest me to use? Or maybe I could use some simplified
method,
>as
>>>> zigbee has known preamble of 256 chips, which is 128 chips in I
branch,
>>>> and 128 chips in Q branch. Sampling rate of my ADC is 64Msps, and I
was
>>>> doing down sapling to 4Msps.
>>>
>>>Hi,
>>>
>>>MSK is FM, right? 
>>
>> No, MSK is not FM.
>
>I don't believe this is correct, Eric. MSK is a special limiting case of
>FSK (the minimum frequency separation of FSK), and FSK is
>frequency-shift keying, which is a form of FM. Thus by transitive logic,
>MSK is a form of FM.
>
>If this is not correct, point out my error.
>-- 
>Randy Yates
>Digital Signal Labs
>http://www.digitalsignallabs.com

I think either way is correct. It is matter of perspective. We better
focus on clock recovery and frequency offset solutions.

Kaz
---------------------------------------
Posted through http://www.DSPRelated.com

"kaz" <37480@DSPRelated> writes:

>>eric.jacobsen@ieee.org (Eric Jacobsen) writes:
>>
>>> On Sat, 03 Oct 2015 07:54:15 -0400, Randy Yates
>>> <yates@digitalsignallabs.com> wrote:
>>>
>>>>"tarikkazaz" <50642@DSPRelated> writes:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I am working on implementation of zigbee device on FPGA. Till now I
>>have
>>>>> made Tx which is compatible with commercial devices. Also I have Rx
>>which
>>>>> is working with my own Tx, but does not work with commercial
> devices.
>>>>> Major reason why my receiver can not decode signals from commercial
>>>>> devices is frequency offset. So far I tried to apply zero crossing
>>>>> approach to decode signal, but that does not help
>>>>>
>>(http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber15158&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D1615158).
>>>>> Previously I have been doing correlation of known chips with
> received
>>>>> signal (on that way I was able to decode signals from my own Tx). 
>>>>>
>>>>> Because now I am planning to start with implementation of frequency
>>offset
>>>>> compensation for my receiver, I would like to get advice.  Which
>>estimator
>>>>> do you suggest me to use? Or maybe I could use some simplified
> method,
>>as
>>>>> zigbee has known preamble of 256 chips, which is 128 chips in I
> branch,
>>>>> and 128 chips in Q branch. Sampling rate of my ADC is 64Msps, and I
> was
>>>>> doing down sapling to 4Msps.
>>>>
>>>>Hi,
>>>>
>>>>MSK is FM, right? 
>>>
>>> No, MSK is not FM.
>>
>>I don't believe this is correct, Eric. MSK is a special limiting case of
>>FSK (the minimum frequency separation of FSK), and FSK is
>>frequency-shift keying, which is a form of FM. Thus by transitive logic,
>>MSK is a form of FM.
>>
>>If this is not correct, point out my error.
>>-- 
>>Randy Yates
>>Digital Signal Labs
>>http://www.digitalsignallabs.com
>
> I think either way is correct. It is matter of perspective. We better
> focus on clock recovery and frequency offset solutions.

The OP didn't ask for timing, just frequency offset, hence my
suggestion. But I agree with your general sentiment, Kaz.
-- 
Randy Yates
Digital Signal Labs
http://www.digitalsignallabs.com

>eric.jacobsen@ieee.org (Eric Jacobsen) writes:
>
>> On Sat, 03 Oct 2015 07:54:15 -0400, Randy Yates
>> <yates@digitalsignallabs.com> wrote:
>>
>>>"tarikkazaz" <50642@DSPRelated> writes:
>>>
>>>> Hi all,
>>>>
>>>> I am working on implementation of zigbee device on FPGA. Till now I
>have
>>>> made Tx which is compatible with commercial devices. Also I have Rx
>which
>>>> is working with my own Tx, but does not work with commercial
devices.
>>>> Major reason why my receiver can not decode signals from commercial
>>>> devices is frequency offset. So far I tried to apply zero crossing
>>>> approach to decode signal, but that does not help
>>>>
>(http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber15158&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D1615158).
>>>> Previously I have been doing correlation of known chips with
received
>>>> signal (on that way I was able to decode signals from my own Tx). 
>>>>
>>>> Because now I am planning to start with implementation of frequency
>offset
>>>> compensation for my receiver, I would like to get advice.  Which
>estimator
>>>> do you suggest me to use? Or maybe I could use some simplified
method,
>as
>>>> zigbee has known preamble of 256 chips, which is 128 chips in I
branch,
>>>> and 128 chips in Q branch. Sampling rate of my ADC is 64Msps, and I
was
>>>> doing down sapling to 4Msps.
>>>
>>>Hi,
>>>
>>>MSK is FM, right? 
>>
>> No, MSK is not FM.
>
>I don't believe this is correct, Eric. MSK is a special limiting case of
>FSK (the minimum frequency separation of FSK), and FSK is
>frequency-shift keying, which is a form of FM. Thus by transitive logic,
>MSK is a form of FM.
>
>If this is not correct, point out my error.
>-- 
>Randy Yates
>Digital Signal Labs
>http://www.digitalsignallabs.com

Hi Randy,

MSK can be interpreted as FM, and based on papers can be demodulated with
FM demodulator. For example gnuradio implementation is using FM
demodulator in RX chain of zigbee receiver.
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.179.31&rep=rep1&type=pdf

---------------------------------------
Posted through http://www.DSPRelated.com

On Sat, 03 Oct 2015 12:28:42 -0400, Randy Yates
<yates@digitalsignallabs.com> wrote:

>eric.jacobsen@ieee.org (Eric Jacobsen) writes:
>
>> On Sat, 03 Oct 2015 07:54:15 -0400, Randy Yates
>> <yates@digitalsignallabs.com> wrote:
>>
>>>"tarikkazaz" <50642@DSPRelated> writes:
>>>
>>>> Hi all,
>>>>
>>>> I am working on implementation of zigbee device on FPGA. Till now I have
>>>> made Tx which is compatible with commercial devices. Also I have Rx which
>>>> is working with my own Tx, but does not work with commercial devices.
>>>> Major reason why my receiver can not decode signals from commercial
>>>> devices is frequency offset. So far I tried to apply zero crossing
>>>> approach to decode signal, but that does not help
>>>> (http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=1615158&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D1615158).
>>>> Previously I have been doing correlation of known chips with received
>>>> signal (on that way I was able to decode signals from my own Tx). 
>>>>
>>>> Because now I am planning to start with implementation of frequency offset
>>>> compensation for my receiver, I would like to get advice.  Which estimator
>>>> do you suggest me to use? Or maybe I could use some simplified method, as
>>>> zigbee has known preamble of 256 chips, which is 128 chips in I branch,
>>>> and 128 chips in Q branch. Sampling rate of my ADC is 64Msps, and I was
>>>> doing down sapling to 4Msps.
>>>
>>>Hi,
>>>
>>>MSK is FM, right? 
>>
>> No, MSK is not FM.
>
>I don't believe this is correct, Eric. MSK is a special limiting case of
>FSK (the minimum frequency separation of FSK), and FSK is
>frequency-shift keying, which is a form of FM. Thus by transitive logic,
>MSK is a form of FM.
>
>If this is not correct, point out my error.

It's right from that perspective, but using an FM demodulator to
receive MSK is highly suboptimal.   Emphasis on highly.


Eric Jacobsen
Anchor Hill Communications
http://www.anchorhill.com

Eric Jacobsen <eric.jacobsen@ieee.org> wrote:

>On Sat, 03 Oct 2015 07:54:15 -0400, Randy Yates

>>MSK is FM, right? 

>No, MSK is not FM.   It is essentially OQPSK with crappy filtering.

Interesting perspective.

MSK is a subcategory of FSK which is a subcategory of FM.

2-MSK is equivalent to "OQPSK", but "OQPSK" is simply language that
appears in some standards documents and the fact that they are
equivalent is more of a construction than anything else.  "OQPSK"
terminology has since back-filtered into some modern textbooks.

n-MSK for n > 2 is not equivalent to OQPSK.

MSK, unqualified, might refer to the modulation without any filtering,
or might refer to the modulation without reference to the filtering 
that has been applied.  Gaussian filtering (e.g. GMSK) is very common 
(and is not particularly bad).

I would usually say that GMSK is a subcategory of MSK.  But that
can get into arguments of the form, "That's not MSK, it's GMSK" ...
these tend to be content-free arguments.

Steve

On Sat, 3 Oct 2015 18:36:53 +0000 (UTC), spope33@speedymail.org (Steve
Pope) wrote:

>Eric Jacobsen <eric.jacobsen@ieee.org> wrote:
>
>>On Sat, 03 Oct 2015 07:54:15 -0400, Randy Yates
>
>>>MSK is FM, right? 
>
>>No, MSK is not FM.   It is essentially OQPSK with crappy filtering.
>
>Interesting perspective.
>
>MSK is a subcategory of FSK which is a subcategory of FM.
>
>2-MSK is equivalent to "OQPSK", but "OQPSK" is simply language that
>appears in some standards documents and the fact that they are
>equivalent is more of a construction than anything else.  "OQPSK"
>terminology has since back-filtered into some modern textbooks.

OQPSK is QPSK with either the I or Q channel shifted in time by 1/2
symbol.   I'm not sure what you mean by "construction", but it's been
around for a long time, is part of many standards going back a long,
long time, and is very often implemented just as I described:  a
half-symbol shift in the modulator or demodulator.

It reduces the PAPR of QPSK significantly, and avoids transitions
through the origin, without giving up any of the performance or
spectral properties of QPSK.   It also limits spectral regrowth
(compared to QPSK) when hitting the PA hard.   This was significant
back in the days when PAs weren't as linear or efficient as they are
now, and when channel filtering wasn't as tight but channels were.

If you degrade the filtering from a typical Nyquist matched-filter to
a half-sine per symbol, you get MSK.

If you demodulate MSK as though it was OQPSK with crappy filtering, it
does a pretty good job.   Better than many other methods.


>n-MSK for n > 2 is not equivalent to OQPSK.

Just like n-PSK isnt equal to QPSK for n>2.

>MSK, unqualified, might refer to the modulation without any filtering,
>or might refer to the modulation without reference to the filtering 
>that has been applied.  Gaussian filtering (e.g. GMSK) is very common 
>(and is not particularly bad).

MSK is named so because it is, as Randy stated, the limiting case of
smooshing 2-FSK down to minimum shifts.  The optimal receiver is not
an FSK or FM receiver, though.

GMSK makes it a partial response system and tries to further control
the spectral regrowth when transmitted through a limiting amplifier.

>I would usually say that GMSK is a subcategory of MSK.  But that
>can get into arguments of the form, "That's not MSK, it's GMSK" ...
>these tend to be content-free arguments.
>
>Steve

It's MSK with even crappier filtering.


Eric Jacobsen
Anchor Hill Communications
http://www.anchorhill.com

Eric Jacobsen <eric.jacobsen@ieee.org> wrote:

>On Sat, 03 Oct 2015 12:28:42 -0400, Randy Yates

>>I don't believe this is correct, Eric. MSK is a special limiting case of
>>FSK (the minimum frequency separation of FSK), and FSK is
>>frequency-shift keying, which is a form of FM. Thus by transitive logic,
>>MSK is a form of FM.

>>If this is not correct, point out my error.

>It's right from that perspective, but using an FM demodulator to
>receive MSK is highly suboptimal.   Emphasis on highly.

Certainly suboptimal.  Depending on parameters, you can count
on about a 2 dB loss if one uses a frequency discriminator
to demodulate 2MSK, compared to maximum-likelyhood.  The loss
is worse for coded modulation.

802.15, Bluetooth, and the like have a lot of uncoded modulation
modes and using a frequency discrminator in the receiver is
commonly done for simplicity and low-power.

Whereas something like GSM, where the demodulation, decoding
and equalization (and maybe even doppler correction) are
co-designed, you would not use a simple frequency discriminator
for detection.

The OP stated he's using a zero-crossing demodulator, which is
evem more simplistic than a frequency discriminator, yet the
OP stated this is satisfactory.  

(Whether it remains satisfactory as they get deeper into
their design is TBD.)

I've "inherited" zero-crossing-detected FSK systems and they certainly 
work, but I would not set out to design a system that way.


Steve

Eric Jacobsen <eric.jacobsen@ieee.org> wrote:

>On Sat, 3 Oct 2015 18:36:53 +0000 (UTC), spope33@speedymail.org (Steve

>>MSK is a subcategory of FSK which is a subcategory of FM.

>>2-MSK is equivalent to "OQPSK", but "OQPSK" is simply language that
>>appears in some standards documents and the fact that they are
>>equivalent is more of a construction than anything else.  "OQPSK"
>>terminology has since back-filtered into some modern textbooks.

>OQPSK is QPSK with either the I or Q channel shifted in time by 1/2
>symbol.   I'm not sure what you mean by "construction", but it's been
>around for a long time, is part of many standards going back a long,
>long time, 

Thanks, you are correct.

Part of my perspective is that for a long long time before that, 2MSK 
was in the literature and in the field without anybody having performed
the "equivalent to OQPSK" construction.  I call this a construction,
in this case, because it's possible to completely analyze 2MSK behavior
without making the analogy to QPSK, and it you go far enough
back in the literature, that is how it is done.

But, if one looks at OQPSK methods that are not equivalent to
MSK (say, with different pulse shapes) then it has become 
a thing of its own rather than a construction.

(But, please don't ask me for a airtight scientific definition of
"thing of its own"...)

>and is very often implemented just as I described:  a
>half-symbol shift in the modulator or demodulator.

>It reduces the PAPR of QPSK significantly, 

Well, this is true but it's a bit of an odd angle to view it from:
fundamentally FM is constant envelope, AM is not.  

>and avoids transitions
>through the origin, without giving up any of the performance or
>spectral properties of QPSK.   It also limits spectral regrowth
>(compared to QPSK) when hitting the PA hard.   This was significant
>back in the days when PAs weren't as linear or efficient as they are
>now, and when channel filtering wasn't as tight but channels were.

Yes, you get all the advantages of FM when you use... FM.

(But we know from Shannon's theorem that a constant envelope
loses capacity, so there's the trade-off.  I'm suspecting, but
am not absolutely certain, that in this discussion "crappy filtering" 
means filtering that moves you even further from capacity.)

>If you demodulate MSK as though it was OQPSK with crappy filtering, it
>does a pretty good job.   Better than many other methods.

I'm going go out on a limb and assert that a maximum likelyhood 
demodulator for MSK gives you the same result whether or not you have 
decomposed the signal into its OQPSK components, and further that this 
is true regardless of filtering or coding so long as your ML algorithm 
is applied correctly.

(Sub-optimal demodulators often exploit the structure or chosen
form of representation of the signal to narrow things down to
a much simpler approach.)

Steve

On Sat, 3 Oct 2015 19:39:33 +0000 (UTC), spope33@speedymail.org (Steve
Pope) wrote:

>Eric Jacobsen <eric.jacobsen@ieee.org> wrote:
>
>>On Sat, 3 Oct 2015 18:36:53 +0000 (UTC), spope33@speedymail.org (Steve
>
>>>MSK is a subcategory of FSK which is a subcategory of FM.
>
>>>2-MSK is equivalent to "OQPSK", but "OQPSK" is simply language that
>>>appears in some standards documents and the fact that they are
>>>equivalent is more of a construction than anything else.  "OQPSK"
>>>terminology has since back-filtered into some modern textbooks.
>
>>OQPSK is QPSK with either the I or Q channel shifted in time by 1/2
>>symbol.   I'm not sure what you mean by "construction", but it's been
>>around for a long time, is part of many standards going back a long,
>>long time, 
>
>Thanks, you are correct.
>
>Part of my perspective is that for a long long time before that, 2MSK 
>was in the literature and in the field without anybody having performed
>the "equivalent to OQPSK" construction.  I call this a construction,
>in this case, because it's possible to completely analyze 2MSK behavior
>without making the analogy to QPSK, and it you go far enough
>back in the literature, that is how it is done.
>
>But, if one looks at OQPSK methods that are not equivalent to
>MSK (say, with different pulse shapes) then it has become 
>a thing of its own rather than a construction.
>
>(But, please don't ask me for a airtight scientific definition of
>"thing of its own"...)
>
>>and is very often implemented just as I described:  a
>>half-symbol shift in the modulator or demodulator.
>
>>It reduces the PAPR of QPSK significantly, 
>
>Well, this is true but it's a bit of an odd angle to view it from:
>fundamentally FM is constant envelope, AM is not.  

It's not odd at all, because QPSK provides a very power-efficient
modulation, but the PAPR limited transmit power in some cases.   The
slight modification to get OQPSK provided a greatly reduced PAPR to
get more Tx power in the link without sacrificing any of the power
efficiency of the modulation.   The gain comes at the cost of some
added complexity in the demodulator, but nothing terrible.

FSK and MSK allow full saturation of the transmit PA, but aren't as
power efficient as QPSK, so you still may not get as efficient of a
link as OQPSK, and may not be able to close the link in some cases.
In my experience FSK and MSK were historically used when the cost or
complexity of a full PSK system was prohibitive.

One of the motivations for GMSK in cellular systems was channel
management where carriers, even with poor frequency control, could be
jammed closer to each other while still using a cheap Class C
amplifier that didn't drain the battery of the transmitter as fast.

Most of these things are non-issues today.   Even linear(ish)
amplifiers for handsets are pretty efficient, and PAPR is not much of
a concern any more, even places where you used to expect it, like
satellite channels.


>>and avoids transitions
>>through the origin, without giving up any of the performance or
>>spectral properties of QPSK.   It also limits spectral regrowth
>>(compared to QPSK) when hitting the PA hard.   This was significant
>>back in the days when PAs weren't as linear or efficient as they are
>>now, and when channel filtering wasn't as tight but channels were.
>
>Yes, you get all the advantages of FM when you use... FM.
>
>(But we know from Shannon's theorem that a constant envelope
>loses capacity, so there's the trade-off.  I'm suspecting, but
>am not absolutely certain, that in this discussion "crappy filtering" 
>means filtering that moves you even further from capacity.)

Or that it just doesn't contain the spectrum well.   You can filter
QPSK or OQPSK with whatever pulse shape you want, and these days RRC
with 10% excess bandwidth is not uncommon.   This gives a nice, tight
channel occupation with not a lot of guard band needed.   MSK, on the
other hand...you gotta leave a lot of room for that sprectrally.   If
you're paying for bandwidth, it's not a friendly modulation scheme.

>>If you demodulate MSK as though it was OQPSK with crappy filtering, it
>>does a pretty good job.   Better than many other methods.
>
>I'm going go out on a limb and assert that a maximum likelyhood 
>demodulator for MSK gives you the same result whether or not you have 
>decomposed the signal into its OQPSK components, and further that this 
>is true regardless of filtering or coding so long as your ML algorithm 
>is applied correctly.

Not sure what you mean by decomposing the signal into its OQPSK
components.   The waveforms are the same except for the pulse shape,
and the MSK pulse shape does still allow for fully coherent
demodulation with no ISI, so from that perspective the performance
potentials for the two are essentially the same, although the spectral
occupancy can be different.   Depending on how that works into one's
cost metrics, it can make a difference.

The spectral efficiencies of the two are quite different when
different pulse shapes are used for OQPSK.   The pulse shape cannot be
changed for MSK without turning it into something that's not MSK (like
GMSK).

For whatever reason people tend to demodulate them differently, and
often think of MSK as a phase trellis, since the simplest, CPM,
modulator operates that way conceptually.   This means using a Viterbi
demodulator to track the phase trellis, rather than just coherent
synchronization and using a decoder on the detected data like you
would with PSK.  They don't perform the same.

So I don't know which demodulation style you would select for MSK when
going out on a limb to analyze an ML demodulator, or which metric you
would be maximizing.   Treat it as CPM?   Treat it as minimum-shift
2FSK?   Treat it as a special case of PSK?

The performance is different for each case, sometimes by quite a bit.


>(Sub-optimal demodulators often exploit the structure or chosen
>form of representation of the signal to narrow things down to
>a much simpler approach.)

Complexity is usually an important tradeoff when using a modulation
scheme with less capacity than other candidates.  As time goes on
complexity becomes less and less of an issue, so many of these things
you don't see as much any more, except for older standards.   Zigbee
is starting to age, but it works well enough for many applications
that it still has a large market.

>Steve

Eric Jacobsen
Anchor Hill Communications
http://www.anchorhill.com