Gazell Route Communication

RE: Gazell Route Communication

ovrebekk — Fri, 02 Feb 2024 10:20:19 GMT

Hi Fly

Then it seems like the PID is indeed the issue. Unfortunately there is no way to override the PID setting in the Gazell library, the only workaround I can see is to either make sure there is some change in the payload (just a single bit change is enough), or to send two packets in succession so that the PID gets updated before you change the mode.

Most Gazell applications use static configuration of device/host and as such this behavior is not a problem.

Best regards
Torbjørn

RE: Gazell Route Communication

fly_cow — Thu, 01 Feb 2024 11:36:15 GMT

First of all, although we keep sending the same packets, a switch between DECEIVE and HOST is carried out between each packet. During the mode switch, GAZELL layers experience both disabled and enabled states.

Second, If I use two different packets sent alternately, then each packet can be received normally.

So do you have any better advice for me? Thank you very much

Best regards

fly

RE: Gazell Route Communication

ovrebekk — Thu, 01 Feb 2024 11:18:14 GMT

There is a 2 bit counter (PID) in the packet header that is used to differentiate retransmitted packets from new packets, but if you reset or reconfigure Gazell in between each packet it is possible that the PID is reset as well, which will make the new packet look like a retransmit.

Could you run a test where you include an incrementing counter in each payload to avoid sending the same exact packet twice?

If this solves the problem then it is most likely related to the PID being identical.

Best regards
Torbjørn

RE: Gazell Route Communication

fly_cow — Thu, 01 Feb 2024 11:11:49 GMT

If the application layer of A keeps sending the same packets to B, what mechanism determines that B can correctly receive each packet instead of mistakenly thinking that the repeated packets are resent by the GAZELL protocol layer of A？