Migration from Gazell to static payload ESB

[Abraham Hamidi]

I am migrating to ESB from Gazell to take advantage of the static 252 byte sized payloads. However, there are two things that are very different that I would like to figure out.

First, payloads are auto acknowledged. I want to know how to piggyback on these payloads if possible instead of having the data before received, like in gazell.

Second, will I be fine to queue size 252 packets to attach in ack? Or is this only supported for dynamic payloads?

Also, optionally, I would like to know if it is theoretically possible to use Gazell but in static mode to support 252 byte packets. I enjoy using Gazell instead of ESB, but ESB is necessary for my use case because 32 byte packets are too small (~200Kbps vs 1Mbps I would get through static sized packets).

I am using the Nordic Connect SDK for the receiver and the NRF52 SDK for the transmitter.

Edit: I found recently that the wording is misleading on the Nordic ESB pages. Large max payloads work with dynamic payload length. It makes it seem like you need static to use them.

[Kenneth]

Hi,

I believe the ESB examples should show for instance how to add data on ack:
https://infocenter.nordicsemi.com/topic/sdk_nrf5_v17.1.0/examples_esb.html

In general see ESB documentation: 
https://infocenter.nordicsemi.com/topic/sdk_nrf5_v17.1.0/group__nrf__esb.html 
https://infocenter.nordicsemi.com/topic/sdk_nrf5_v17.1.0/esb_users_guide.html 

Have in mind thought, that if you want to receive for instance 252byte payload on ack, then including radio switching etc you will need to have a large retransmit delay when transmitting from the PTX to ensure there is sufficient time to receive the entire ack payload. Likely you will need a retransmit delay of 2.5ms for @1Mbps and half that for 2Mbps. 

I recommend to uset dynamic payload length yes, since you can then dynamically change the payload length when transmitting.

Kenneth

[Abraham Hamidi]

Sorry if I do not understand your answer, but I do not see an answer to whether queueing data for ack on prx is supported for static size packet payloads. It seems that it is not supported for them, and is meant only for dynamic payloads (I think it has a max of 32 bytes, see discussion in devzone.nordicsemi.com/.../esb-ack-packet-not-received, maybe this is outdated), but I am not sure.

Also, the examples that you linked admit that data is delayed by one event since they queue the state on receive, which makes them attached one ack late. This is unlike Gazell, where you can piggyback to the same ack. However, I am okay with this if it means I can get the higher throughput supported by ESB, since they support larger packet sizes in static mode.

Relating to that, for the second concern, I have found that each additional byte is 4us in 2Mbps mode. However, static payloads seem to be much better because I guess since more bytes are sent per payload before the radio has to switch modes, it can get all the way to 1.28Mbps according to  Intro to ShockBurst/Enhanced ShockBurst : "Throughput is greatly improved when larger payloads are used". Anyway, is it possible to get these large throughputs supported in Gazell? Obviously I would have to increase the timeslot period, but it seems Gazell only supports dynamic/up to 32 bytes right now.

Edit: I have done some research and found that static ESB mode uses 0 byte payloads on ACK. This answers that question. I do need payloads on ACKs though. So I guess I have to modify the source code to hardcode this.