Broadcasts repeated too often

[whoenig]

We see very strange behavior when using Crazyswarm2 and Crazyradio2, especially with more than one drones. One of the more obvious causes is that broadcasts are silently repeated inside the radio firmware (likely at https://github.com/bitcraze/crazyradio2-firmware/blob/068fb1b119c103a921110779d8e99001931d045f/src/esb.c#L299-L302). In other words, if we sent 100 motion capture poses per second from the host via broadcast, the Crazyflie actually receives >300. When using the Crazyradio PA, we receive exactly 100 as expected.

[knmcguire]

Hmm that is indeed odd. I've marked it for triage that we will have in 2 weeks. Until then we unfortunately have a deadline that we need to work on first.

[ataffanel]

This "functionality" rings a bell and this looks like something I made early in the development phase of the Crazyradio2: https://github.com/bitcraze/crazyradio2-firmware/blob/068fb1b119c103a921110779d8e99001931d045f/src/esb.c#L299-L302

So, this means that Crazyradio 2 sends ARC broadcasts in a row by default. I though this would actually be a nice functionality for Crazyswarm when I wrote that, but I was not expecting to make a Crazyradio PA compatible mode back then and I forgot to remove it or document it.

The question is: is that a useful functionality for Crazyswarm of shall we remove it and get back to a single broadcast packet whatever the value of ARC is?

[whoenig]

I think in the "compatibility" firmware it should behave like a Crazyradio PA. I did confirm that when setting ARC to 1, that the broadcasts are as expected, but of course this has some effect on unicast as well.

In Crazyswarm(2), we repeat the broadcasts in software with a user-defined delay. We found that just repeating the packets without delay doesn't help that much since consecutive packets are frequently "lost" (perhaps because a queue is full - not sure).

[ataffanel]

I agree with you, lets make a new version of the firmware that corrects the behavior.