gazell pros and cons (and timeslot sync threshold)

[astella]

To the kind attention of Nordic support team,

It seems gazell is a very good candidate to be used in tipical working environments, where a bunch (<= 5 devices for example) have got to coexist in a short distance range, sending a couple bytes payload to an usb dongle.

My question is related with https://devzone.nordicsemi.com/f/nordic-q-a/27227/which-is-the-best-proprietary-stack-to-pair-multiple-devices-single-fw-to-a-single-host-and-use-several-systems-e-g-host_1-with-device_1-and-host_2-with-device_2-concurrently-one-within-the-antenna-range-of-the-other-without-/107419#107419

But I would like to ask you to expand, if possible, about gazell weaknesses. I mean, I've read up that timeslot is somehow putting a throughput  limit threshold (correct me if I'm wrong). 

So it seems fascinating to use Enhanced Shock Burst as a building block. But, to get what in that scenario? I mean, in order to get the very same scenario working,

I should re-do a gazell like protocol. So, do you think does it worth? In what aspect gazell protocol could be improved? There is room for a sync schema

that is able to reach lower timeslot thresholds? Seeing ESB on air packet format, it seems about 500us timeslot is larger that two packets (a couple useful bytes payload each). But if you choose about 500us timeslot,there must be

a good compromise with overall performance. Still, radio ramps up is about 140 us : is this the main factor to determine time slot duration? I ve read up that there is a fast ramp up about 40 us.

In what conditions is it working? I would like if your experts could tell what in their opinion could be theoretically done, if any, to improve a gazell like protocol, for a scenario like the one I mentioned.

Best regards

[Kenneth]

Hi,

There is no short answer to your questions. The Gazell protocol is built on the ESB link layer. Using ESB you simply specify an address and frequency used by the receiver, then send the packet you want to transmit, next you will either get an tx success or max retransmit callback. You would need to build everything around this simplistic ESB api, for instance frequency hopping, synchronization, and how to handle max retransmit callback. It can be done, but at the end of the day I am not sure if it's worth the development time. Using Gazell, even with some of it's drawbacks, likely is the preferred solution, provided that Gazell can meet your overall requirements to throughput and latency.

Best regards,
Kenneth

[astella]

Hi Kenneth, thank you. I was thinking to evaluate a custom schema having a master with no power constraints, that is always sending a token in a round robin fashion. When devices wake up because they have got data to send, they first listen for the token.I'll try to simulate something before implementing, to be sure it is applicable in my case. 

Thank you for your kindness