802.15.4 Rx CRC error from old device

[zrivard]

Hi,

I've run into an issue when doing some compatibility testing between our client's legacy device (802.15.4 transmitter) and the current device in development (802.15.4 receiver).  

For the receiver, there is an old Legacy version (RX1) as well as the new version that we are developing here now (RX2).

For the transmitter, there is an old Legacy version (TX1) as well as the new version that we are developing here now (TX2).

The TX1/RX1 devices are built on old MSPs with a CC2420 transceiver on it. It is no longer possible to modify FW/HW on this design.

Both the TX2/RX2 devices are built on nRF5340/nRF52833 chipsets. We will be focusing on the RX2's nRF52833.

A key feature of the client's system is full compatibility between any TX and RX version. They must all work together.

• TX1 with RX1 works
• TX2 with RX2 works
• TX2 with RX1 works
• TX1 with RX2 is prone to the issue described below. 

 

The issue we are seeing is that some of the TX1s are outputting packets that are not correctly received by RX2.

A RX1 device has no issue successfully receiving those same packets put out by the same TX1 device.

Not every TX1 device is having these issues, roughly 10% of them. But it is 100% repeatable on the TX1s that do fail.

 

The error being reported by the radio on the RX2 is that the incoming 802.15.4 packet has an invalid checksum. When the payload of the invalid packet is examined, the data received is indeed not what was expected. It was close, but never quite right.

We suspected a frequency offset between what the TX1 and RX2 both believe is 2.425GHz. I measured the actual transmit frequency of these TX1s and found that it was slightly off from 2.425GHz. I was able to adjust the RX2s internal frequency reference until its 2.425GHz lined up with the TX1s 2.425GHz. This did not resolve any of the checksum issues.

 Does this sound like anything you’ve come across before? If you have any ideas on next steps for diagnosing the problem, I am all ears. We had gone through something similar with a TI chipset a few years ago and we were given direction to modify some registers that were not in any documentation that we found. Are there any fine tuning timing registers that we should be tweaking to attempt to resolve the CRC error?

Thanks,

Zach

[Kenneth]

We suspected a frequency offset between what the TX1 and RX2 both believe is 2.425GHz. I measured the actual transmit frequency of these TX1s and found that it was slightly off from 2.425GHz. I was able to adjust the RX2s internal frequency reference until its 2.425GHz lined up with the TX1s 2.425GHz. This did not resolve any of the checksum issues.

I would think this is the only viable approach, how did you do this adjustment? I would think you would need to adjust the load capacitors on the 32MHz crystal.

Kenneth

[zrivard]

That is correct, I adjusted the caps on the 32MHz xtal until I saw alignment between the two devices. 

Having eliminated the difference in reference frequencies, I wanted to next confirm that the on-air symbols are being transmitted at an equivalent rate from both devices.

Are there any registers I can fiddle with that would allow me to tweak that rate, or are they derived purely from the 32MHz xtal?

[Kenneth]

zrivard said:

or are they derived purely from the 32MHz xtal?

That is correct. So I don't have any further suggestions really, if you have access to a spectrum analyzer it's sometimes possible to measure zero span on an actual packet, then you can see the demodulated signal in real-time. I am not sure if it can help to solve the problem, but it can at least give more indication of where the problem may be caused by.

Kenneth