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,

 

1. What addresses are you using? A common issue is mixing up LSB/MSB: https://devzone.nordicsemi.com/f/nordic-q-a/4424/multiceiver-with-3-devices-using-nrf24l01 

2. When you mention "individual messages", do you mean that each device has it's own unique RF address?

3. If using Auto-ACKing feature, it is very important that you have individual addressing on your devices (up to 6 on each PRX), because if there's two PTX devices sending on the same RF address, you might get into a scenario where PTX #1 and PTX #2 start ACKing each other, and your PRX does not receive any of the data.

4. Could you dump the registers on your PRX and PTX so I can have a look at your configuration?

 

Kind regards,

Håkon

[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

[GonzoBe]

I added reply

[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

[GonzoBe]

Master node has configuration
PIPE_TX and PIPE_0 with CRC16 and AutoACK (AA_ON)
address 0x59 0x59 0x59 0x59 0xXX depend on to which device will be sending message

Master send a message and wait x milliseconds for reply

Slave node has configuration 
PIPE1 0x59 0x59 0x59 0x59 0x00
PIPE2 0x59 0x59 0x59 0x59 0x01
PIPE3 0x59 0x59 0x59 0x59 0x10
PIPE4 0x59 0x59 0x59 0x59 0x13
PIPE5 0x59 0x59 0x59 0x59 0x12
(In each slave the last byte is different, PIPE1 and 2 are used like broadcast so we can recive only we send on it message on which we do not want reply )

PIPE1, PIPE2 and PIPE 3 has turn off Auto Ack (AA_OFF)

PIPE4 and PIPE5 has tunr on AutoACK with 3 repetition and speed 1Mb/s, len is const and equal to 32

If Slave will recive something on PIPE4 after 5 ms send packet using PIPETX and PIPE0 (rthoses channels get for that moment address from PIPE4 and PIPE4 get adrress which is not using in normal work)

Example off problem:

MASTER AND 3 SLAVE

1. Frist iteration
MASTER -> send to 1st slave (byte in payload cnt :0)-> rec ack -> rec reply
MASTER -> send to 2nd slave(byte in payload cnt :1 -> not rec ack -> not rec reply(because dev is turn off for example)
MASTER -> send to 3rd slave (byte in payload cnt :2-> not rec ack -> not rec reply(because dev is turn off for example)

2. Second iteration
MASTER -> send to 1st slave(byte in payload cnt :3->REC ack -> NOT rec reply
MASTER -> send to 2nd slave(byte in payload cnt :4-> not rec ack -> not rec reply(because dev is turn off for example)
MASTER -> send to 3rd slave(byte in payload cnt :5-> not rec ack -> not rec reply(because dev is turn off for example)

3. Third iteration
MASTER -> send to 1st slave(byte in payload cnt :6> REC ack -> REC reply
MASTER -> send to 2nd slave(byte in payload cnt :7> not rec ack -> not rec reply(because dev is turn off for example)
MASTER -> send to 3rd slave(byte in payload cnt :8> not rec ack -> not rec reply(because dev is turn off for example)

step 2 and 3 reapet so we lose 50% of packets

If we will send after each iteration packet on broadcast channel the slave will recive it but it will not change the flow so we will still lose packet( we do not get it on slave but we got ack from slave)

But if I will add to each iterration additional device it will start work.