nRF52 ESB protocoll mac layer access and access to low level software

[florian2840]

Hello,

I am working with the Enhanced ShockBurst protocoll on a nRF52832.

1. For synchronization reasons between several nodes I need time stamps in my data packet from just before the message is sent. Have I access to this software layer?

2. Do I have access to low level drivers? My intention is: If a message from the PTX is received I want to check one bit whether it is high or low. If it is low I want to send a certain data set, if it is high a different dataset in the ACK back to the PTX.

Thanks a lot in advance,

Florian

[florian2840]

I have the following system: 1x nRF52DK as PTX and 1x nRF52DK as PRX

I wrote a little program with your examples, if I push the button a message is sent to the PRX and I expect the ACK back to the PTX.

I open a J-Link Terminal for the PTX to see whether I will get the ACK.

I set a breakpoint in this function (start_tx_transaction()) in the PRX. If there the ACK is triggered, then the PRX should go into this function in order to send out the ACK. But the PRX does not go into this function and I immediatly get the ACK back, I can see in the J-Link Terminal. It seems there is another software part which is responsible for sending the ACK?!

[Hung Bui]

@florian: Sorry I was confused with the TX mode. The handling of ACK packet in PRX mode is executed by the SHORT setup when finishing a transmission/receiving. You can find at on_radio_disabled_rx() function, we assign the address and the pointer to the ack payload at line 775 in the nrf_esb.c. And then in on_radio_disabled_rx_ack() we enable the short to enable TX when radio is disabled and send the data with the short READY-START.

You should modify the m_tx_payload_buffer if you want to send different ack payloads.

[florian2840]

maybe we have still a missunderstanding. What is the first function, which is called if a new packet is arrived at the PRX? Is it the RADIO_IRQHandler()? If yes, I set a breakpoint in this function that the program is halted at this point. That means no ACK should be send to the PTX, correct? But I receive an ACK at the PTX. So there must be a function which is responsible for the auto ACK to which I have no access to? My intention is to decide which data is send in the ACK after the message is received at the PRX. Maybe now it gets a little bit clearer?!

[Hung Bui]

@florian: The packet sending is handled by SHORT, even if you put a breakpoint, it will be executed when the radio receive. The following SHORTs are enabled:

• READY -> START
• END -> DISABLE
• DISABLED -> TXEN (This only enabled when RX is starting)
• ADDRESS -> RSSI (not important)
• DISABLED -> RSSI (not important)

As you can see, when the packet received, END event will come and it trigger DISABLE (RX) after RX disabled it will trigger TX EN, after TX READY it will trigger START and the ACK packet is sent. Full autonomous.

I think there is a challenge here that if you want to read the RX packet then decide what to send in the ACK payload packet of the same packet, there is a timing issue. ACK packet is sent immediately after the RX reception. It's handled all by the radio it self. It could be too late if you need to use CPU to read the RX payload, and then modify the Ack payload.

If you wan to have a delay so that the CPU can read the RX packet and modify the tx ack payload you may need to modify the protocol to have longer RX period on the PTX to wait for the ACK.

Or you can think of increase the packet size so you have some time between the ADDRESS event (when we start to receive the payload) and the PAYLOAD event (when we finish receiving the payload) to read the received packet (the first byte for example) and modify the ack payload accordingly.

An easier option is to modify the ack payload for the next packet base on the value received on the current packet.

[florian2840]

"ACK packet is sent immediately after the RX reception. It's handled all by the radio it self. It could be too late if you need to use CPU to read the RX payload, and then modify the Ack payload." Ah ok I understand. But there is a way to disable this feature, right? In docs is written the shortcuts can be disabled and I can manage all in my application. But of course there is a further processing delay. Can you tell me which delay i can expect? After the END Event is occured I would trigger the DISABLE-TASK of the radio manually, switch to TX-Mode and send the ACK. Is this possible? Of course I have to increase the retransmit time at the PTX.