• State Verified Answer
  • +1 person also asked this people also asked this
  • Replies 4 replies
  • Subscribers 88 subscribers
  • Views 2534 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 217124
Options
Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

ESB Ack - queuing different payload by RX pipe

dmhummel

Hello,

    If a rf52 device running ESB in RX mode has multiple devices TXing on different pipes, is it possible to prepare a different TX response to be sent to each device on each pipe.   If I do have multiple TX devices and one RX device, how can I transmit unique data to each unique tx device?

  • 0

    to clarify, the TX responses are all being transmitted as ack payloads.

  • +1

    Hi

    The current ESB implementation in the nRF52 series is a bit limited in this regard. 

    In the original ESB implementation going back to the nRF24L series (nRF24L01+, nRF24LE1 and nRF24LU1+), you had a 3 level FIFO for ACK payloads. You could upload a packet to three different pipes at a time, and if a packet was received on any of those pipes the ACK payload would automatically be included. 

    In the nRF52 implementation you can have a much larger FIFO if you like, but when a packet is received on the radio the ESB library will only look at the oldest packet in the FIFO to see if there is a pipe match. In other words, if you have multiple packets loaded for different pipes then you need to send packets in the same pipe order from the TX as you upload packets on the RX side, which severely limits the flexibility of the ACK payload feature when using more than one pipe. 

    For more information about this please refer to lines 807-836 of nrf_esb.c in the nRF5 SDK v15.2.0 for details. 

    Ideally there should have been separate TX fifo's for each pipe, but that is not implemented in the library as of today. 

    Best regards
    Torbjørn

  • 0 in reply to ovrebekk

    Thanks for the clear answer.   This limitation does severely impact our ability to solve our problem (multiple low power sensors transmitting on an irregular basis).  Before we consider modifying the SDK or complicating our solution by switching between RX and TX modes, do you have any recommendations?

  • 0 in reply to dmhummel

    Hi 

    Sorry for the slow response. I forgot to include the verified cases in my active list...

    Did you find a solution to this, or is it still an open issue?

    I can set aside some time to look into the code and see if I can prepare a patch so that the ACK feature will work properly with multiple pipes. 

    Best regards
    Torbjørn

Related
Terms of service