ESB. It is not possible to change the load of ACK on PRX.

PTX transmits data to PRX every second. The PRX should attach the payload to each ACK using nrf_esb_write_payload. In debugging on PRX, I see that the data is different every time. But the PTX receives data that was uploaded to the ASK for the first time.
That is, it turns out that after the first use of nrf_esb_write_payload on the PRX, it is impossible to change this data during subsequent transmissions.
If I do nrf_esb_flush_tx() on the PRX, it sends a normal ASK without load. As soon as I use nrf_esb_write_payload, the load that was at the very first call to nrf_esb_write_payload will be attached to the ASK.

Parents
  • Everything worked until I started disabling the transmitter again with the nrf_esb_disable() function. It looked something like this (pseudo-code):
    while(true){
    nrf_esb_init()
    nrf_esb_write_payload()
    nrf_esb_disable()
    delay(1000)
    }
    The transmitter responded only once. This was due to packet identification: "Any packet that is transmitted from a PTX to a PRX is uniquely identified by a two-bit packet ID field (PID) in the packet header along with the packet's Cyclic Redundancy Check (CRC) field. This packet ID is used to distinguish a new packet from the previous packet if it has the same payload."
    Since I completely disconnected and reinitialized the ESB, the PID was the same. The message was also the same, and so was the CRC. So, probably, PRX thought that it was the same packet from PTX.
    When I switched to nrf_esb_suspend and nrf_esb_start_tx, everything worked:
    while(true){
    nrf_esb_start_tx ()
    nrf_esb_write_payload()
    nrf_esb_suspend()
    delay(1000)
    }

  • Hi,

     

    taras789 said:
    Everything worked until I started disabling the transmitter again with the nrf_esb_disable() function. It looked something like this (pseudo-code):
    while(true){
    nrf_esb_init()
    nrf_esb_write_payload()
    nrf_esb_disable()
    delay(1000)
    }
    The transmitter responded only once. This was due to packet identification: "Any packet that is transmitted from a PTX to a PRX is uniquely identified by a two-bit packet ID field (PID) in the packet header along with the packet's Cyclic Redundancy Check (CRC) field. This packet ID is used to distinguish a new packet from the previous packet if it has the same payload."
    Since I completely disconnected and reinitialized the ESB, the PID was the same. The message was also the same, and so was the CRC. So, probably, PRX thought that it was the same packet from PTX.

    Your conclusion here is correct.

    If you always fully disable ESB, and do not change the payload in-between iterations, the payload will be exactly equal, and the receiver will look at this as a retransmit.

    Suspending ESB, as you've done, is then the correct approach.

     

    Kind regards,

    Håkon

Reply
  • Hi,

     

    taras789 said:
    Everything worked until I started disabling the transmitter again with the nrf_esb_disable() function. It looked something like this (pseudo-code):
    while(true){
    nrf_esb_init()
    nrf_esb_write_payload()
    nrf_esb_disable()
    delay(1000)
    }
    The transmitter responded only once. This was due to packet identification: "Any packet that is transmitted from a PTX to a PRX is uniquely identified by a two-bit packet ID field (PID) in the packet header along with the packet's Cyclic Redundancy Check (CRC) field. This packet ID is used to distinguish a new packet from the previous packet if it has the same payload."
    Since I completely disconnected and reinitialized the ESB, the PID was the same. The message was also the same, and so was the CRC. So, probably, PRX thought that it was the same packet from PTX.

    Your conclusion here is correct.

    If you always fully disable ESB, and do not change the payload in-between iterations, the payload will be exactly equal, and the receiver will look at this as a retransmit.

    Suspending ESB, as you've done, is then the correct approach.

     

    Kind regards,

    Håkon

Children
No Data
Related