PID problems with multicivier

[GonzoBe]

Hi,

we found problem with PID, we send individual messages to many nrf24 devices. When we have for example only 2 devices we have losses of around 40-50% but its not a problem with send becaouse on master we never get max transmit. Each time we got confirmation that packet came but we do not have response. on slave devices it looks like its got the message but it treat it like it is repetition of last one. We have in payload 1 byte cnt value so each packetshould be with diffrent crc. In documentation you have information that PID can be the same and than you compare the CRC with last recive packet. In my opinion it is not like that. 

Could you tell me if there is any solution for such a behave? It is not just one exapmle we found much more situation (we ask 1 dev which is working and 2 wich is not respond becouse they are not connected to power, 1  work and 6 not work) so there is many configuration that its treate last packet like repetiton. There is any dependency of time. for example if we send packet once per 200ms or one per 5 sec. 

It is important for us to resolve this problem becouse we already end developing our system on this because on each building which we will equiped with our system we will use 100-2000 nrf. The efficiency of network should be as good as its possible and with such a problem we can not achive it.

Best regards.
Daniel Bujnowski  

[GonzoBe]

Normaly it work. So for example if I will send only to one address everything is work properly if I will ask 4 devices still it will work. But In some configuration it not work. I see that on master I recived ack but on slave I dont see a message and the same device if I will ask only it I will get all packet without losses. One master can be used to communicate with 100 devices. Each slave has his own unique address. 

I will prepare register dump of PRX and PTX and will attache here. 

But problem is not with configuration I think because normally it works very well. 

1. Its not a problem with LSB/MSB becuse it work properly when we have for example 4 or 5 devices.

2. Each nrf has his own unique address

3. We use Auto-ACK, on master i see that I got ack on sent message but on slave I dont see those message (it depends on how many devices are not respond but for exapmle each 2 packet is recived). It really looks like it treat recived packet like last one without checking the CRC. We have in payload byte which is cnt to be sure that crc will be diffrent each time.

4. I will attache them soon.

Similar problem I found here; devzone.nordicsemi.com/.../nrf24l01-multiceiver-fails-if-more-than-3-pipes

[Håkon Alseth]

GonzoBe said:

One master can be used to communicate with 100 devices

GonzoBe said:

We use Auto-ACK

How does your network topology look? In your case, the master is a PTX (primary transmitter), and a slave device is a PRX?

You are then setting both P0 address + TX_ADDR equal when communicating with each device? In PTX mode, when using auto-ACK, you must always set TX_ADDR = PIPE0.

GonzoBe said:

1. Its not a problem with LSB/MSB becuse it work properly when we have for example 4 or 5 devices.

What addresses are you specifically using? Some are worse than others. Also note that you should never have two pipes with the same address. This is important for pipes 1 to 5, as these share the same 4 byte base address.

 

Each time we got confirmation that packet came but we do not have response. on slave devices it looks like its got the message but it treat it like it is repetition of last one

One thing that makes the radio logic go haywire is if you receive a corrupt packet, with matching CRC, and a corrupt length field.

What I suggest is:

1. Use 16 bit CRC

2. Always check the length of your received payload with "R_RX_PL_WID" before reading out the payload from the FIFO, and check for (payload_len == 0 || payload_len > 32).

If it is 0 or >32 bytes, flush the RX_FIFO. else; read out the payload. This is valid for both "ACK payload" and normal PRX operation.

3. Never use addresses starting with 0x00/0xFF/0xAA/0x55 (remember; byte endianess on the addressing when clocking in), as these patterns resemble demodulated noise or the preamble pattern.

Kind regards,

Håkon

[Håkon Alseth]

Hi,

 

GonzoBe said:

Master send a message and wait x milliseconds for reply

 Does this mean that you are using ACK_PAYLOAD? Ie: Do you expect the PRX device to send ACK + data back to you?

If yes; It is _very important_ that you send two payloads:

#1 to let the PRX prepare and upload the data

#2 to fetch the ACK payload.

 

Since you are using 1MBit data rate, the ARD register must be adjusted to 500 us if the ACK payload holds >= 5 bytes, per the datasheet chapter 7.4.2

 

Best regards,

Håkon

[GonzoBe]

We do not use payload with ack.

We sent message from master wait 5 ms for ack and then we start listen on master and we sending message from slave. So we change role just for send message and then we change it again.

[Håkon Alseth]

Have I understood this correctly?

1. Master sends to slave.

2. Slave receives on pipe X (X being between pipes 1 and 5)

3. Master goes into PRX mode

4. Slave goes into PTX mode

5. Slave sets TXPIPE and PIPE0 to 0xADDR_IT_RECEIVED_ON

6. Master waits for the payload.

 

The slave device in the above scenario will receive on pipe1 - 5, then send back on the unique pipe0.

Are you ensuring that pipe0 is not equal to pipe1 in this scenario? The LSByte must be unique for all 6 pipes, per the datasheet chapter 7.6.

Meaning that pipe0 LSByte cannot be equal to the LSByte on any of the other pipes.

Best regards,

Håkon

[GonzoBe]

Is exactly like you wrote. I am sure that we have unique address on each pipe all the time. When we change the address on pipe0, pipe on which we recived message get unique address. 

[Håkon Alseth]

It's not only the whole address, but the last byte must be unique, ie: pipe0 last address byte cannot be equal to pipe1 last address byte etc:

Q1: Can you please confirm that this is done?

Q2: Are you flushing the FIFOs on both ends after both slave and master has changed their address? If the master already has a payload in the FIFO, you may be sending old data.

Q3: When reconfiguring the radio addresses on both slave and master, is the radio in "Standby" state at this point?

Q4: The pin "VDD_PA" will go high approx. 80 us before a transmission occurs, and will go low again when the radio has finished its TX operation. Could you try scoping this line on both the slave and master to see if it goes high?

Kind regards,

Håkon

[GonzoBe]

A1: I'm sure that we have each byte diffrent.

A2: Yes we flushing the FIFOs each time when we change the address.

A3: Yes each time when we change something we are going to Stanby

A4: I will check on scope and send you a picture.

Best regrds,

Daniel