nrf24l01+ multiceiver fails if more than 3 pipes

[redguymi]

Hi. I just recently started using nRF24L01+. I am trying to simulate MultiCeiver using 2 mcus and 2 nrfs. PTX sends a message on all 6 pipes of the PRX. The problems start once more than 3 pipes are used on the RX side. I have found an identical post but it is very old and has no replies. I hope somebody can help. Here is the setup and some term definitions I will use to describe the problem:

• both nRFs configured for enhanced shockburst (auto ack, dynamic payload length)
• NACK(x) = transmit on pipe x using W_TX_PAYLOAD_NOACK
• ACK(x) = transmit on pipe x using W_TX_PAYLOAD
• TX always sends a different hardcoded payload to each pipe (no 2 RX pipes receive the same message from TX)
• TX always waits 5 seconds before a transmit
• RX pipe 2 always replies with an incremented value, setup using W_ACK_PAYLOAD when pipe 1 is addressed
• RX pipe 3 always replies with "test", setup using W_ACK_PAYLOAD when pipe 2 is addressed
• payloads are less than 32 bytes
• RX pipe 0 address: "12345"
• RX pipe 1 address: "abcd0"
• RX pipe 2 address: "?"
• RX pipe 3 address: "Z"

what works (3 pipes):

1. TX -> NACK(0) -> RX ok
2. TX -> ACK(1) -> RX ok, set pipe 2 reply to n++ -> TX ack
3. TX -> ACK(2) -> RX ok -> TX ack + reply (incremented value) start all over again

• using pipe 3 instead of pipe 2 also works

what doesn't work (4 pipes):

• iteration 1

1. TX -> NACK(0) -> RX ok
2. TX -> ACK(1) -> RX ok, set pipe 2 reply to n++ -> TX ack
3. TX -> ACK(2) -> RX ok, set pipe 3 reply to "test" -> TX ack + reply (incremented value)
4. TX -> ACK(3) -> RX ok -> TX ack + reply ("test")

• iteration 2

5. TX -> NACK(0) -> RX no event
6. TX -> ACK(1) -> RX no event (thus no reply setup for pipe 2) -> TX ack
7. TX -> ACK(2) -> RX no event (thus no reply setup for pipe 3) -> TX ack NO reply (NO incremented value)
8. TX -> ACK(3) -> RX no event -> TX ack + reply ("test")

• after the 1st iteration RX no longer displays incoming messages (IRQ is not detected) and TX always gets ACK
• TX no longer gets an incremented value for pipe 2. This is expected
• TX keeps receiving "test" on pipe 3? This is a BIG problem since PTX thinks everything is fine but PRX mcu is not actually in the loop

what I tried:

• pull RX mcu interrupt pin low after freeze. mcu prints: no events in STATUS reg and FIFO_STATUS shows all empty
• when RX receives on pipe 3, power down, power up and enable RX using registers. No luck. It requires a cold start for nRF to recover
• tried using RX pipe 5 instead of 3. Same problem
• switched roles of mcu + module from TX to RX and the other way around. Same problem

[ovrebekk]

Hi

Could you try to include a rolling counter in the payload to see if it solves the issue? If every 4th packet is sent to the same RX, and there is no change in the payload, the RX will assume that the packet is a retransmission, and will send an ACK without triggering the RX interrupt. The reason for this is that there is a 2-bit sequence counter in the packet header that will be identical for every 4th packet.

[redguymi]

Thank you Torbjørn. That did it. All 6 RX pipes are working!!

But this is unexpected. Going back through the datasheet again: "The PID field is incremented at the TX side for each new packet received through the SPI. The PID and CRC fields (see section 7.3.5 on page 30) are used by the PRX device to determine if a packet is retransmitted or new."

Edit: I got the order wrong so I changed this part: Iteration 1 ends by sending a message to pipe 3. PID should be 0 at this point. Iteration 2 starts by sending a new message thus PID should be 1 and CRC should be different since the message sent is different. Even if somehow PID is the same CRC would be different. Can you clarify?

Thank you.

[ovrebekk]

If the payload changes then it doesn't matter if the PID is the same, that is correct. Are you saying the problem is still present even after adding a changing payload?