False Address correlation

RE: False Address correlation

mark — Thu, 21 Jan 2016 13:59:08 GMT

Hung, thanks for your clarification on this. We will regenerate some more diverse addresses to use with our system as well as frequency hopping.

RE: False Address correlation

Hung Bui — Thu, 21 Jan 2016 13:46:07 GMT

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.

RE: False Address correlation

mark — Thu, 21 Jan 2016 10:43:27 GMT

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

RE: False Address correlation

Hung Bui — Thu, 21 Jan 2016 08:07:37 GMT

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.

RE: False Address correlation

mark — Wed, 20 Jan 2016 13:35:28 GMT

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

RE: False Address correlation

Hung Bui — Wed, 20 Jan 2016 12:58:58 GMT

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 ?