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 ?

[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.