on air address handling in the nRF52 family radios

[Rob Garner]

Hi there

I have a question about the way the nRF52 radio handles on air addresses. I currently am developing custom software that uses the nRF52810 radio for a custom protocol.

I am exchanging data between two transceivers every 4ms. This works very well, except that I receive a corrupted data packet approx. every 14 seconds. The software recognizes this and resychronizes the data stream. Then everything works great again for approx. 14 seconds, and I receive the next corrupted packet. The EVENT_ADDRESS register is 0 when I receive this corrupted packet, so it looks like there was not an on air address match. The fact that this event is quite periodic would point to a logical error in the firmware, and I am in the process of finding the bug.

My understanding regarding the on air address behavior is that if the transmitter's on air address does not match the receivers on air address then I will not receive a (corrupted) data packet at the receiver end, meaning the receiver will not generate an EVENTS_END and or EVENTS_DISABLED event. Is this correct? Or is it possible that the receiver will flag that there was no EVENTS_ADDRESS event, but it will still receive the (corrupted) data packet?

Thank you for your support!

Cheers

Rob

[Rob Garner]

A quick update. EVENTS_ADDRESS is actually 1, so a valid address was received. However, the actual data packet looks scrambled. EVENTS_CRCERROR is also 1. Is it possible that there was an error during the EasyDMA transfer?

Thanks

Rob

[Håkon Alseth]

Hi Rob,

 

Rob Garner said:

A quick update. EVENTS_ADDRESS is actually 1, so a valid address was received. However, the actual data packet looks scrambled. EVENTS_CRCERROR is also 1. Is it possible that there was an error during the EasyDMA transfer?

Thanks for the update. There should not be a payload without an address match, so this makes sense.

There are some errata that also includes the radio peripheral, for instance this one:

https://docs.nordicsemi.com/bundle/errata_nRF52810_Rev3/page/ERR/nRF52810/Rev3/latest/anomaly_810_245.html

 

However, this one should present itself quite quickly, and deterministic, if you are hit by it.

 

My understanding regarding the on air address behavior is that if the transmitter's on air address does not match the receivers on air address then I will not receive a (corrupted) data packet at the receiver end, meaning the receiver will not generate an EVENTS_END and or EVENTS_DISABLED event. Is this correct? Or is it possible that the receiver will flag that there was no EVENTS_ADDRESS event, but it will still receive the (corrupted) data packet?

In all wireless applications, you can get a address match based on demodulated noise, but this will usually be handled by the CRC, and not present itself as an actual payload (with correct CRC).

Choosing the RF address, to avoid certain patters that resembles preamble and longer static bit patterns, should therefore be avoided atleast on the start of the RF address.

Ie. 0xAA / 0x55 / 0xFF / 0x00

  

Q1: Could you elaborate on how your custom protocol works? Do you use any channel hopping or similar?

if yes; how do you perform time-synchronization, especially when having an on-going payload being processed mid-sequence?

 

Q2: You mention every 14 seconds, is this a repeating pattern? Ie. is it always around 14 seconds, or can it sometimes be 1 second to 20 seconds?

 

Q3: Does the corrupted payload show signs of valid data, or is it completely random every time?

 

Kind regards,

Håkon