This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

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

Parents
  • @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.

Reply
  • @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.

Children
  • "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.

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

  • That sounds great. Is there a documentation of the following functions? static void on_radio_disabled_tx_noack(void); static void on_radio_disabled_tx(void); static void on_radio_disabled_tx_wait_for_ack(void); static void on_radio_disabled_rx(void); static void on_radio_disabled_rx_ack(void);

  • and for correct understanding. The code in the "on_radio_disabled_rx" and "on_radio_disabled_rx_ack" is executed from the shortcuts? Where are these functions assigned to the shortcuts?

  • I afraid there is no further documentation except for what we have on infocenter. We just recently open the source for ESB and it's provided "as-is". We may have better documentation in the future. For now you may need to study the source code.

    Those functions "on_radio_disabled_rx" "on_radio_disabled_rx_ack" are wraped by on_radio_disabled and on_radio_disabled() will be called in the RADIO_IRQHandler().

Related