Gzll protocol lost connection if loss power occured

RE: Gzll protocol lost connection if loss power occured

Kenneth — Tue, 26 Jan 2016 12:10:27 GMT

As long as the device has not received an ACK it will continuously retransmit, thereby the host will also retransmit ACK packet. For this to work the host should stay in receive mode to ensure that the ACK packet is transmitted before switching address.

RE: Gzll protocol lost connection if loss power occured

chenyu — Tue, 26 Jan 2016 01:49:27 GMT

Thanks you for your answer, Do you mean host can re-transmit Ack automaticly if ACK payload send fail?

RE: Gzll protocol lost connection if loss power occured

chenyu — Sat, 23 Jan 2016 08:19:21 GMT

Please refer to my flow chart, thank you!

RE: Gzll protocol lost connection if loss power occured

chenyu — Sat, 23 Jan 2016 02:19:36 GMT

Thanks! The problem havn't happend on example"gzll_ack_payload", Since my way is different from the example, I want a Device get pair with a Host. All my Host and Device have the same BASE_ADDR0 and PIPE0_ADDR. A Device send pair requirement to a Host through pipe0, the Host generate a random number and then write it to BASE_ADDR1 & PIPE1 after it get the pair requirement from device on pipe0, and then send the random addr data as ACK to Device on pipe0. The Devcie get the new BASE_ADDR1 & PIPE1 data from ACK and write them to BASE_ADDR1 & PIPE1. After above operation, the Device and Host finish pair operation and they communicate on pipe1. The passageway can work when there is only one Device and One Host, But when the Device number increase to more than one. The problem in my question will occer. Thank you!

RE: Gzll protocol lost connection if loss power occured

Kenneth — Fri, 22 Jan 2016 10:18:56 GMT

This doesn't sound familiar. If I understand you correct, you experience that if you power cycle the devices, then they can no longer communicate.

Does it also occur with the default project in the SDK for Gazell? E.g.:

\nRF5_SDK_11.0.0-2.alpha_bc3f6a0\examples\proprietary_rf\gzll\gzll_ack_payload

If your protocol depends on device and host change addresses on the fly, always make sure that the device stay in receive mode for a period of time after receiving a packet from the host (e.g. 20ms). This to ensure that the ACK in reverse direction is successfully sent, in case of interference there might be re-transmissions required.

So something along the lines of:

Device receive packet, and add ACK payload.
Device stay in receive mode for additional 20ms to ensure ACK is sent.
Device change address.