False Address correlation

[mark]

I seem to be getting correlation on addresses

I running the radio transmitter and receiver examples provided in the nRF5 v11 SDK. However, I am observing still some unexpected address correlation

Setup: nRF5_SDK_11.0.0-2.alpha_bc3f6a0

Board: PCA10036 v1.1.0

IAR: 7.40.3.8938

The radio transmit example code has been modified to transmit 10,000 times with a 5 ms delay inbetween each transmission. The PCA100036 board with the receive program address is set up to a different base0 address, however, it still picks up unexpected packets.

This happens with prefix0 set 0xc3438303

receive NRF_RADIO->BASE0 = 0x3109429E transmit NRF_RADIO->BASE0 = 0x31084258

from what I see, these addresses should be conforming to the recommend rules on address requirements. ( devzone.nordicsemi.com/.../ )

again with

receive NRF_RADIO->BASE0 = 0x23094254 transmit NRF_RADIO->BASE0 = 0x23084292

I have checked the radio PCNF1 register, the BALEN is set to 4 and the ENDIAN set to 1(big)

main_receiver.c receiver main.c

main_transmitter.c transmitter main.c

[Hung Bui]

Hi Mark,

The 2 address are only 3 bits different. There is a chance that the interference can cause the error to flip those 3 bits. However, if it's the interference, the CRC check should be able to catch it.

Have you checked the CRC match (CRCSTATUS register) when received these packets ? And would the content of the packet is the same as when sending ?

How many unexpected packet did you receive on 10000 trial ?

Could you try again with more than 3 bit difference ?

[mark]

Hi Hung, I will rerun to get the amount of unexpected packets and check the CRC match

The address have 5 bits difference

0x3109429E 0011 0001 0000 1001 0100 0010 1001 1110

0x31084258 0011 0001 0000 100[0] 0100 0010 [01]01 1[00]0

0x23094254 0010 0011 0000 1001 0100 0010 0101 0100

0x23084292 0010 0011 0000 100[0] 0100 0010 [10]01 0[01]0

[Hung Bui]

Hi Mark, You were correct, it's 5 bits. But I suggest to try with at least 8 bit difference and CRC check when receive packet.

[mark]

Performed 3 runs run 1 20 unexpected packets received run 2 32 unexpected packets received run 3 25 unexpected packets received

the NRF_RADIO->CRCSTATUS is low all the time these packets are received, which according to the data sheet meant a packet has been received with CRC error. The contents of the packet received was correct. I am able to use the CRC error to filter out the received packet.

The CRCCNF->SKIPADDR is low, so address field is included in the CRC calculation.

The modification of the radio example Nordic SDK was to try and recreate a simple case of what we were seeing elsewhere. However, we are seeing this false address matching on our own software and custom dev boards where the transmit and receive boards are directly cable coupled (for testing) together to reduce the likelyhood of bit flipping in the on-air transmit/receive. In our software the CRCCNF SKIPADDR is set high to exclude the packet field out of the CRC calculation. We can include the address to CRC to filter these false messages.

The concern is when we have multiple boards transmitting and receiving in close proximity, when a board receives and processes this differing address this is occupping a time slot whilst blocking the legitimate address board transmission.

I'll carry on some testing on more bit difference in the address

[Hung Bui]

Hi Mark,

My suggestion is to have more difference in the addresses.

You should also considering using frequency channel hopping to avoid interference. Please be noted that when there is a packet sending on the same channel you are listening to, it doesn't matter if the address match or not, the scanner will receive the packet and you will have a blocking period that the correct message can't be delivered at the same time (interference between 2 packets happens anyway). Our Gazell protocol supports channel hopping.