cfs does not respond to cmdposition() after initialization

[ucaszzw]

Hi @whoenig @jpreiss , I am using 1 crazyradio PA and the cmdposition() command for the full control of 20 cfs including the take-off phase. I have a problem: sometimes (~20% probability) some of the cfs don't take off and they seem to ignore these commands.
Also there are a couple of phenomena to note.

1. cfs that do not respond to the cmdposition() take-off command will usually suddenly fly wildly out of control after 4~5s. This is obviously after the cfs that did not take off before have responded to the subsequent position control command.
2. cfs will only appear to be unresponsive for a long time during the initial take-off phase. Once the cfs can successfully take off, everything will behave normally later on.
   3, This phenomenon also seems to be related to the underlying wireless communication. When a strong 2.4G interference source is encountered, the number of cfs that do not take off becomes much higher.

[ucaszzw]

I'm trying to figure this out and figure out how to fix it.
There is a typical phenomenon with this problem: it only occurs during the take-off phase, and as long as the take-off is successful, there is not a long period of unresponsiveness that exists subsequently.
Therefore, I think that some mechanism in the initialisation phase must be responsible for this phenomenon.
I have a couple of guesses.

1. Is it because the initialisation phase requires the transfer of a large amount of transmission information, which can cause communication blocking or stack overflow. Can we somehow extend the initialization time, but reduce the data transfer rate?
2. Is there a "handshake" confirmation mechanism for nrf communication? Could a cfs that does not take off have a successful handshake?

[whoenig]

The initialization phase happens during the connection (parameters are downloaded and updated etc). If you wait after the connection before sending cmdposition commands, you should avoid any interference on that side. The cmdposition is just sending a packet to the NRF, ignoring the handshake (by default safelink is disabled and the ack flag is ignored for cmdposition).

From what I remember, the firmware has some sort of safeguard to not just fly away (one has to send a 0-command multiple times to disarm). I wonder if that is somehow related to your problem.

20 CFs with a single radio using cmdposition is very challenging, just because of bandwidth limitations (cmdpositions are not broadcast commands, so if you send it at 10 Hz, you need 10*20=200 packets/s just for that + the broadcast commands used for motion capture tracking, if you use that). I think for most computers the limit is about 500 packets/s. Does your problem go away/improve if you lower your update rate (either cmdposition of motion capture)?