deadlock possibility on gazell protocol?

RE: deadlock possibility on gazell protocol?

Firek — Wed, 12 Nov 2014 15:11:08 GMT

I've found in documentation that channel_index is incremented not random generated. Can You confirm for sure that there is as You said not as documentation.

"When this counter reaches timeslots_per_channel, the timeslot_counter is reset and the channel_index is incremented (cyclically)"

RE: deadlock possibility on gazell protocol?

Firek — Wed, 12 Nov 2014 14:57:13 GMT

Ok so now everything is clear. I didn't know about picking random channel, hence my suspitions. Thanks Torbjorn.

RE: deadlock possibility on gazell protocol?

Firek — Wed, 12 Nov 2014 14:52:17 GMT

Swtching is only at host side.

RE: deadlock possibility on gazell protocol?

ovrebekk — Wed, 12 Nov 2014 14:25:33 GMT

Hi Firek

Will you be doing BLE/Gazell switching on both the device and host side, or just on the device?

The synchronization scheme in Gazell is pretty simple, and I don't think it is possible to get a dead lock as you say. If two devices will start transmitting at exactly the same time the worst thing that can happen is that they both keep retransmitting until they time out. When this happens they will pick a new random channel and try again, and sooner or later the two devices will use either a different frequency or a different time to send their data.

In other words the user might experience higher packet delay (latency) if the two devices crash, but unless you are sending a lot data from both devices I don't think it will happen regularly.