• State Not Answered
  • Replies 2 replies
  • Subscribers 86 subscribers
  • Views 367 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 354116
Options

Strange behavior with ESB driver fast ramp-up on nrf52840

Charlemagne

Hello, I have two nrf52840-dongles which I am using to test ESB. (NCS 3.1.1)

With a few modifications to the ESB prx and ptx samples:

  • Remove logs except for PTX ESB_EVENT_RX_RECEIVED printout (avoid slow logging having an impact)
  • Reduce sleep time to 10ms
  • Enable config.use_fast_ramp_up
  • Set retransmit count to 0 (don't need that complicating things)
  • Add some kind of light processing thread to PRX (doesn't seem to matter what, a busy-loop should do)

The system continues working, but the PTX begins receiving very strange "echoes" of its own transmitted packets:

I: Sending test packet
D: Packet received, len 8 : 0x01, 0x04, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08
D: Packet received, len 8 : 0x01, 0x05, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08
D: Packet received, len 8 : 0x01, 0x06, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08
D: Packet received, len 8 : 0x01, 0x06, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08
D: Packet received, len 8 : 0x01, 0x07, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08
D: Packet received, len 8 : 0x01, 0x08, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08
D: Packet received, len 8 : 0x01, 0x09, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08
D: Packet received, len 8 : 0x01, 0x0a, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08
D: Packet received, len 8 : 0x01, 0x0b, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08

These are roughly sequential, aligned to the actual transmitted packets, but some duplicates are present.
I *believe* these are actual OTA packets somehow sent by the PRX, but I will confirm this with an ESB monitor.

The frequency of these erroneous packets is correlated to the amount of work we're asking the PRX to do in its processing thread, but they start showing up infrequently even if the processing thread sleeps for an order of magnitude longer than the ESB frequency and does nothing more than assign a few integers.

If I try to run a thread on the PRX at 1khz doing some work I'll need in my application, the PTX gets blasted by these erroneous "reflected" packets, and it appears to interfere with the PTX's ability to properly receive ACK payloads when I extend the ESB sample to start including those.

I don't believe that I should be coming up against any limits to system performance at these rates?

This question is related to:
ESB anomaly when using Fast ramp-up 

In this thread, no solution is presented but it is suggested that "The ESB library hasn't been tested for use with fast mode". This was three years ago, and I assume the esb_config::use_fast_ramp_up was added since. I cannot find any Nordic documentation suggesting use_fast_ramp_up is untested or has issues/errata for two nrf52 devices.

Can anyone shed more light on this situation?


Thank you very much for any help!


Parents
  • 0
    Hi Trembley,
    Those weird “echoes” frames probably are not coming from the PTX, they seem to be coming from the PRX. it seems that the ACK stage can’t finish its cleanup fast enough. When you turn on esb_config.use_fast_ramp_up, you cut the RX-to-TX ramp time from 124 us down to 40 us.  The driver uses that exact value to set up the timers between. So, with just 40 microseconds between the radio wrapping up RX and the hardware forcing the next TX, the PRX has to finish the entire on_radio_disabled_rx() routine without a hitch. If some other thread grabs even few extra microseconds, maybe a periodic busy loop or something then the RADIO interrupt gets delayed. That means PACKETPTR still points to rx_payload_buffer when the hardware flips to TX. This might lead to the ACK sending out the same payload it just got. The PTX then sees an ESB_EVENT_RX_RECEIVED event with the same 8-byte payload it sent earlier, which gives you that “echo” pattern. That’s also why the NCS samples don’t mess with these settings on nRF52 or nRF53. In nrf/samples/esb/esb_prx/src/main.c  and the PTX sample, we only set config.use_fast_ramp_up to true if CONFIG_ESB_FAST_SWITCHING is enabled. That Kconfig option is only for the nRF54H20, where the driver actually supports direct RX-to-TX switching. On the nRF52840, we seem to leave fast ramp-up off because the ESB driver isn’t tuned or validated for such tight timing. The comment you saw on DevZone is still accurate. So honestly, what you’re seeing just lines up with how the current driver works: If you set RU to Fast, the PRX has about 40 microseconds after every packet to handle the RADIO IRQ. If anything else eats up CPU time, the ACK can end up pulling from outdated buffers, which makes it look like the PRX is echoing your own frames. The ESB library in NCS v3.1.x doesn’t promise that low of a latency on nRF52 chips. That is why the samples stick with the default ramp-up and only flip to fast mode on nRF54 with the special fast-switching support. Right now, your workarounds are: - Keep use_fast_ramp_up off on nRF52840. If you really want to try fast ramp-up, you might need to keep the PRX CPU almost completely idle while the radio’s running, no long-running threads, no logging, no busy loops. You could also try increasing up the RADIO IRQ priority so it always interrupts your code. Basically, until someone rewrites the driver to do proper double-buffering and lock down ISR scheduling, fast ramp-up seems to be supported on the nRF52840.
Reply
  • 0
    Hi Trembley,
    Those weird “echoes” frames probably are not coming from the PTX, they seem to be coming from the PRX. it seems that the ACK stage can’t finish its cleanup fast enough. When you turn on esb_config.use_fast_ramp_up, you cut the RX-to-TX ramp time from 124 us down to 40 us.  The driver uses that exact value to set up the timers between. So, with just 40 microseconds between the radio wrapping up RX and the hardware forcing the next TX, the PRX has to finish the entire on_radio_disabled_rx() routine without a hitch. If some other thread grabs even few extra microseconds, maybe a periodic busy loop or something then the RADIO interrupt gets delayed. That means PACKETPTR still points to rx_payload_buffer when the hardware flips to TX. This might lead to the ACK sending out the same payload it just got. The PTX then sees an ESB_EVENT_RX_RECEIVED event with the same 8-byte payload it sent earlier, which gives you that “echo” pattern. That’s also why the NCS samples don’t mess with these settings on nRF52 or nRF53. In nrf/samples/esb/esb_prx/src/main.c  and the PTX sample, we only set config.use_fast_ramp_up to true if CONFIG_ESB_FAST_SWITCHING is enabled. That Kconfig option is only for the nRF54H20, where the driver actually supports direct RX-to-TX switching. On the nRF52840, we seem to leave fast ramp-up off because the ESB driver isn’t tuned or validated for such tight timing. The comment you saw on DevZone is still accurate. So honestly, what you’re seeing just lines up with how the current driver works: If you set RU to Fast, the PRX has about 40 microseconds after every packet to handle the RADIO IRQ. If anything else eats up CPU time, the ACK can end up pulling from outdated buffers, which makes it look like the PRX is echoing your own frames. The ESB library in NCS v3.1.x doesn’t promise that low of a latency on nRF52 chips. That is why the samples stick with the default ramp-up and only flip to fast mode on nRF54 with the special fast-switching support. Right now, your workarounds are: - Keep use_fast_ramp_up off on nRF52840. If you really want to try fast ramp-up, you might need to keep the PRX CPU almost completely idle while the radio’s running, no long-running threads, no logging, no busy loops. You could also try increasing up the RADIO IRQ priority so it always interrupts your code. Basically, until someone rewrites the driver to do proper double-buffering and lock down ISR scheduling, fast ramp-up seems to be supported on the nRF52840.
Children
No Data
Related
Terms of service