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

[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.

[Hung Bui]

I think it's possible. You just need to increase the m_wait_for_ack_timeout_us so the PTX will keep the RX window open longer.

I'm not sure how much longer, some calculation needed on how many CPU cycles needed, each CPU cycle takes 15ns (at 64MHz). The peripheral clock speed is 16MHz, so it a little bit slower when you try to read/write to the peripheral.

Anyway, i guess it's easiest to actually test and see if the current timeout is actually big enough or need some increment.