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  

[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