Where are the bluetooth messages received and processed?

Post Reply
Posts: 1
Joined: Tue Nov 06, 2018 3:23 pm

Where are the bluetooth messages received and processed?

Post by acecilia » Thu Nov 08, 2018 3:04 pm


I am looking into improving the functionality of the iOS app for flying the crazyflie 2.0. I observed that the bluetooth packets have a header (value 0x30), roll, pitch, yay and thrust declared in the file CommandPacket.h (see attached image). I have been looking in the firmware of the stm and the nrf, but I could not locate where this bluetooth packets are received and processed. Can anybody point me in which file is this happening?

Screen Shot 2018-11-08 at 16.02.54.png

Posts: 1734
Joined: Mon Jan 28, 2013 7:17 pm
Location: Sweden

Re: Where are the bluetooth messages received and processed?

Post by tobias » Mon Nov 12, 2018 12:52 pm

The commander handling you can find in the modules directory and the files containing *commander*. There is a new way and an old way. The new way can handle many types of command messages such as setpoints and are described in crtp_commander_generic.c. The old way is described in crtp_commander_rpyt.c which is used by e.g. the IOS app.

Posts: 1790
Joined: Tue Feb 06, 2007 12:36 pm

Re: Where are the bluetooth messages received and processed?

Post by arnaud » Mon Nov 12, 2018 1:05 pm

The bluetooth link is just a tunnel to regulat CRTP packets: the nRF51 will receive the bluetooth packet and transmit its data as CRTP packet to the STM32. The STM32 is not aware of the protocol used to communicate the packet, it only receive and send CRTP packets to the nRF51.

The ble protocol is documented in the wiki: https://wiki.bitcraze.io/doc:crazyflie:ble:index. Basically it behave like a tunnel so as long as the BLE protocol is implemented, you can look at the CRTP documentation and implementation as pointed by Tobias. For reference the bluetooth implementation is in the nrf firmware: https://github.com/bitcraze/crazyflie2- ... azyflies.c.

One interesting details about BLE: the bandwidth of ble is very small on ios, we can basically send and receive one packet every 20ms so if we want to transfer other data in parallel with the commander packet we need to be a bit careful to still update the commander at regular interval. The way I thought about doing it was to implement a data queue that contains all packet to send except the commander, and to implement a round-robin mechanism at low level that alternate between sending a commander packet and the next data packet.

Post Reply