PTX sends packet, gets ACK as TxFIFO becomes empty but no RXpacket IRQ at PRX side

RE: PTX sends packet, gets ACK as TxFIFO becomes empty but no RXpacket IRQ at PRX side

o.hojvat — Mon, 06 Jan 2025 19:35:08 GMT

Online o.hojvat 4 months ago in reply to Kenneth

Hello Kenneth

I still don´t know why there are some packets not received at PRX

I have completed an old test board with a simple program that allows to monitor RF packets sent to 3 posibles PIPES, that my system are using.

I only need modify to disable the auto ack option in Reg 01 and gess I get not tx any ack from this monitor board

In this monitor I have seen the packets well received at PRX an also when one packet fails to be received at the usual PRX

So I am sure that all the packets are sent ok from PTX and my problem is at PRX side.

I expected that the monitor can capture all the packets sent from PTX

but in some cases there are ack-payload captured in the monitor also.

Please tell me if it is posible or if it is not normal

I find the original PTX packet or the regarding ack-payload but not both in the same capture.

When sending packets with no_ack , there are all captured ok

Best Regards, Osvaldo

RE: PTX sends packet, gets ACK as TxFIFO becomes empty but no RXpacket IRQ at PRX side

o.hojvat — Sat, 14 Sep 2024 20:29:32 GMT

Hello Kenneth

The elements of the system are

Hand controls, of which there can be several with addresses from 1 to 31
Usually there are 1 to 4 connected to a Central unit by cable, RS485
Now some controls can be connected by RF, for which there is an interface with NRF24L01+ to pass from RF to 485 cable, which is responsible for managing up to 6 controls.
The Central unit sends a coded signal to the tracks, where there are locomotives with the necessary decoder to move the motor, activate lights and sounds.
In normal use each RF control sends orders to a locomotive passing through the interface, RS485 cable and the central

The central has no modifications to use controls with RF - it sequentially sends a Call Byte with each address from 31 to 1 and waits about 120us for a response from the addressed control. The interface handles these times appropriately.
In the current version, the controls are PRX with different addresses and if any of them has an order for the central, it loads it as an ack-payload.
The central can send individual messages as a response to a request for information from a control, or Broadcast messages, for all the controls, informing them of a new state of the system. For this, the PRX have the same address in PIPE 0
Example: Emergency Stop and Service Mode

This entire introduction is to explain the messages for the case of a failure.
A control can request to enter service mode in order to read and modify the internal settings in the decoder of a locomotive. Then it requests the reading of the value of the parameter of interest in the decoder.
The central now only attends to the control that started the process and is responsible for reading it. In the meantime, it suspends communication via 485 until the reading is finished. This takes 1 second
At that moment it sends a call to the corresponding command, the RF interface receives it via 485, loads it into its NRF24L01+ and sends it expecting a message as ack payload.
The command previously loaded the message in the NRF24L01+ which is a request for information about the reading result.
The interface (PTX) passes the message to the central and this returns the read value via 485.
It is loaded into the NRF of the interface and is sent to the control, expecting an ack without payload to end the packet (it deletes the txFIFO).

Up to this point everything works surprisingly well.

The only thing that fails is that the control (PRX) sometimes does not receive the packet with the information, but the PTX always deletes its TxFIFO.
I do not find any difference in the SPI signals in the PTX
when it fails or when it works well. Neither in the previous SPI signals in the PRX
Flush of TXFIFO and RXFIFO are done quite a while before this packet

I'm going to try to add a payload in the PRX to see if the PTX is really receiving the ack.
If I find the cause of the problem I'll put it in a post

Regards, Osvaldo

RE: PTX sends packet, gets ACK as TxFIFO becomes empty but no RXpacket IRQ at PRX side

Kenneth — Sat, 14 Sep 2024 11:53:29 GMT

Hello,

Sounds strange indeed. Maybe you should look at what is occuring on the PTX shortly before transmitting this specific packet, in case the PTX is not really in standby-I mode as you expect. Alternatively look at what is happening on the PRX around the same time, is it possible that the PRX is not actively receiving, or maybe it is flushing the RX FIFO at the exact time.

Kenneth

RE: PTX sends packet, gets ACK as TxFIFO becomes empty but no RXpacket IRQ at PRX side

o.hojvat — Sat, 14 Sep 2024 02:10:11 GMT

Thank you for the reply.

PTX is not waiting for ack payload for this packet

Please confirm if this is correct
In this packet PTX expects ack without payload, then if PRX receives an ok packet, the TXFIFO is cleared at PTX.

The strange thing is that repeating the sequence that ends with this packet, sometimes PRX receives the packet correctly and other times not, but always at PTX TXFIFO is cleared after about 400us of the transmission from PTX.
All other packets of different types work fine, including those that receive ack payloads and others that are for no ack.
I will try to find out how the failure occurs by doing some tests.
For example adding a payload for the ack.
If I can't solve it, I will repeat 8 times the sequence with this packet to reduce the probability of failure to less than 1%.
Fortunately in the other modes of operation I have no problems.
Regards, Osvaldo

RE: PTX sends packet, gets ACK as TxFIFO becomes empty but no RXpacket IRQ at PRX side

Kenneth — Tue, 10 Sep 2024 18:55:54 GMT

Hello,

We are not really providing technical support for the nRF24L serier anymore.

But if you say that you experience packet is sent successfully on the PTX, but no packet received on the PRX. Then I suspect the packet may be identical, and maybe the PRX consider it a duplicate.

If you are trying to send ack payload, and the ack payload is lost, then try to adjust the timing of when you write the ack payload. The ack payload should for instance not be written while an ack is being sent.

Kenneth