CC1100: CC1100/CC1101 Frequency Offset Compensation

The purpose of the FOC_LIMIT is to ensure that noise prior to reception of the signal does not take the assumed carrier to far astray. If you set BW/8 the frequency offset tolerance will be smaller than if you use BW/2. This means a more accurate crystal is needed for BW/8. Since frequency compensation is done through a regulation loop a wider BW will require a longer preamble, but I cannot tell how much since I have never tested this. What we have used in our testing is 4 bytes preamble and that is sufficient for no frequency compensation and the maximum BW/2.

1 ms long packet does not really tell me much as I do not know the data rate. However, use a 4 byte preamble and the FOC will work.
I think the best approach will be to re-start RX after each packet received (RX - IDLE - RX, no calibration, approx. 75 us). In this case the compensation loop will start at 0 for the second packet and not at the one of extreme value as would be the case if the packet at t=0 is at one extremes and the one at t=1.2 ms at the other extreme.

HI Sverre,

My apologies, I should have included the data rate, or in this case rates, although the 1mS period was related to the 250kbps data rate. We use 250K and we are experimenting with 31.25K data rate. I quoted the 1mS message rate as it is much faster and I figured that if the radio could frequency compensate at that period, then it shouldn't  have any problem compensating at 31.25K.

We are using 4 preamble bytes so it looks like we have met your first criteria.

If we are to use the "RX - IDLE - RX" approach, the uC will have to get involved to put the radio back in receive mode. There is no automated way of doing this correct?

Understanding that the best approach is re-start the Rx each time, what are the potential consequences of allowing the radio to stay in receive? (This is how our radio works now)

Ultimately what we are trying to determine is how much benefit would the FOC offer our radio performance. Furthermore, I would like to understand what changes we would need to make to implement it keeping it backwards compatible to currently deployed tags and receivers.

For our 250Kbps channel we need to have the BW set at 406KHz to accommodate the signal + crystal tolerances. We could lower the BW to 325KHz if we use FOC. Using thermal noise (P=kTB) as a basis of comparison this would potentially yield about a 1dB improvement in sensitivity. This seems somewhat trivial and maybe not worth the effort of reworking the way our radios are controlled.   

For our 31.25Kbps channel we need to have the BW set at 102KHz to accommodate the signal + crystal tolerances. We could lower the BW to 58KHz if we use FOC. Using thermal noise (P=kTB) as a basis of comparison this would potentially yield about a 2.4dB improvement in sensitivity. This improvement seems worth pursuing.

I understand that man made noise will likely limit the performance of the channel before thermal noise will. It was just a simple way to calculate/compare what could happen if the bandwidth was tightened.

So does this seem reasonable, or am I missing something? 

 Chris

There is an automated way of doing "RX - IDLE - RX" approach. Use MCSM1.RXOFF_MODE = Stay in RX. This is like strobing RX again and everything will be reset; including FOC.

31.25 kbps: Changing the RX filter BW from 102 kHz to 58 kHz gives a theoretical improvement in sensitivity of 10log(102/58) = 2.5 dB. The RX filter BW needs to be wider than the signal BW + frequency tolerance. Now, I do not know the mod index in your case, but assuming this is 1 (i.e. deviation is 15.625 kHz) the signal BW (99% occupied BW) will be approx 59 kHz. In this case I would not recommend 58 kHz RX filter BW. Use 70 for instance 70 kHz (or something close).

Hi Sverre,

Well all of that seems like good news for us. We seem to be in good position to update how these radios work in our system without affecting currently deployed devices.

Your comments on 31.25kbps brings up another point that I would like to ask about. In another thread you recommended to a colleague of mine to use GFSK over MSK at the 31.25kbps data rate. I would like to understand a little bit more as to why you made that recommendation and what the consequences of not following it are for our performance.

I should start with the following. We are trying to operate our radios are per a IEEE 802.15 spec. that our Director of Engineering contributed to. In that spec. it calls for MSK modulation at 31.25kbps.

Given that you have already recommended to use GFSK over MSK, what performance consequences would we expect to see if we chose to continue with MSK?

For the result "signal BW (99% occupied BW) will be approx 59 kHz" what formula did you use for the calculation?

Thanks,

Chris