Experiment on the Crazyradio PA

[NageshEranki]

Hi everyone!

I was interested in quantifying the radio communication data-rate between the Crazyflie and a Crazyradio PA.

The initial experiment was designed to estimate the time interval between two successive transmissions of my custom CRTP packet. (called 'AE483Data') For the sake of simplicity, I assume this to be my round trip time taken for a packet. The firmware I used was based off of an earlier version of the crazyflie firmware link.

The python script that actually ran the test radio_test.py, runs a for-loop 100 times, sending these custom packets. Following this Bitcraze post on using Wireshark, I 'sniffed' the CRTP packets that are transmitted to and from the crazyflie.

The resulting output looks like this in Wireshark:

Every packet transmitted/received is timestamped. This allows me to determine the average time between transmissions of 'AE483Data' packets.

Result:
It seems that even when I try to communicate to only one port on the CF (port 0x0A), the Crazyradio occasionally sends packets to the parameter subsystem. Also, as I understand, the firmware is such that the Crazyradio is set in TX mode while the Crazyflie is set in RX mode. I think that the 'Link Control' packets are some sort of a default ACK response from the Crazyflie (maybe the bitcraze team can correct me on this!)

Accounting for this, the average (approximate) round trip time between custom packets is ~1.036ms

Please let me know if you have any thoughts/feedback on this experiment!

Thanks

Edit:
Turns out that the 'Link Control' packets are 'NULL packets' sent back to the client (port:15, channel:3) as a response to my AE483Data packets. I was wondering if I could customize this response to a more meaningful one (maybe some sensor data, or what not).

[ataffanel]

Very interesting experiments, thanks for sharing your results!

You are correct for the NULL packets, they are ACKs when coming back from the Crazyflie and they will contain downlink data if any are available. There is already code in the nrf firmware to embeed other data in the ack if no packet is available to send back. For example it is possible to send back RSSI values that way. This needs to be enabled at compile time though.

I have writen a couple of blog post about the communication, for example this one talks about the architecture and idea behind it: https://www.bitcraze.io/2020/08/crazyflie-radio-communication/.

To summarize, the uplink (pc->crazyflie) is implemented by Crazyradio sending a packet and Crazyflie staying in RX mode and receiving the packet. Downlink is implemented as extra data in the ACK packet sent back to Crazyradio just after Crazyflie has received a packet.

An advantage of this technique is that the PC is in full control of the communication: it decides which Crazyflie talk when. This makes low latency predictable and high bandwidth communication possible. The drawback is that since downlink is implemented in ACKs, it is required to send regular packets to all the Crazyflies to have any downlink implemented.

This scheme also problematic when it comes to P2P communication. We are thinking of implementing a more classic CSMA/CA protocol for higher-level P2P communication, this would be less predictable in terms of latency, lower bandwidth, but will allow all Crazyflie to talk to each-other.