Logging performance issues

[bgromov]

I am working on additional functionality of the client and so far have implemented parameter reading/writing and logging. The problem I am facing now is that the maximum rate I receive the log data, i.e. the rate the BLE callback is triggered, is around 17 Hz, although the blocks are configured at 30 Hz. I have two blocks at 30 Hz, 16 bytes each (state estimation), plus one block at 1 Hz of 6 bytes with some other states, like battery and so on.

From what I see in BluetoothLink.swift module there should be no problems with queuing etc. Though I tried to use DispatchQueue.global() for the CentralManager but it didn't help.

We are on a custom firmware (adds support for in-house built LED-deck) that is based on a bit old official version. Could that be an issue?

SYS: Crazyflie 2.1 is up and running!
SYS: Build 169:a547542462f9 (2018.01.1 +169) MODIFIED
SYS: I am 0x2039374348485017003F0022 and I have 1024KB of flash!

The phone is iPhone 7, with iOS 12.2

It seems a bit unlikely to be an issue of the Bluetooth 4.0 itself as its data rate should be at least 100kbps while all the blocks take up not more than 10kbps.

Any ideas what could be the reason for such a low performance?

Thanks.

P.S. When I additionally connect to the drone from PC via the radio dongle using cfclient, the iOS client gets flooded with messages very quickly and is barely able to receive anything back for its own requests (e.g. fetching TOCs), but the packets to the drone are going through with less issues (at least I can reset the logging).

[ataffanel]

The problem is likely coming from the BLE implementation in the nRF firmware of the Crazyflie: as far as I can remember, the Crazyflie can only send one packet per BLE connection event. This is made worst by the fact that iOS is limiting greatly the rate of the connection event (I wan not able to setup connection event every 7.5ms on iOS).

So there would be two things to test:

• Decrease the connection interval, the minimum acceptable by BLE is 7.5ms: https://github.com/bitcraze/crazyflie2-nrf-firmware/blob/master/src/ble/ble.c#L55-L56. Maybe newer iOS device can accept faster devices.
• Investigate what is happening on the air. Nordic semi has a pretty nice BLE sniffer that works with most of their dev board. My assumption is that currently there is only one packet exchange per connection interval, if that is confirmed it explains the rate limitation. This can be fixed either with changing the way we talk to Crazyflie or (worst case) by upgrading the bluetooth stack. If you do not have a nordic dev kit, you could send me the link to your dev branch and I could do some test for myself.

[bgromov]

Decrease the connection interval, the minimum acceptable by BLE is 7.5ms: https://github.com/bitcraze/crazyflie2-nrf-firmware/blob/master/src/ble/ble.c#L55-L56. Maybe newer iOS device can accept faster devices.

From what I was able to google, it seems that the minimal interval for Apple devices is 15ms (I don't know how up to date is that data), so I don't think that changing it from 20 to 15 we could gain much.

Interestingly though, I am also working with MetaWear IMU sensors, that seem to have exactly the same chip as the Crazyflie. Through the API of MetaWear I can set the connection interval to 7.5ms and I don't have any issues with receiving data from 9DoF IMU at 50Hz rate, though I tried it only on macOS, not on the iOS. Maybe indeed newer Apple devices can accept smaller intervals.

If flashing the nRF firmware is reversible I can directly try to set 7.5ms and see if that works. Will I need to do any other changes to make this value acceptable by the rest of firmware?

If you do not have a nordic dev kit, you could send me the link to your dev branch and I could do some test for myself.

Unfortunately I don't have neither the dev kit nor enough knowledge on BLE to do that, so I would really appreciate your help with this.

The code is here (clone recursively): https://github.com/bgromov/CrazyFlieTestApp.git
On the first run, once connected the app will download the TOCs for params and log, and it takes quite a bit of time (sorry, no progress bar yet). Once you see the updates of Odometry values, the frequency estimation should also appear.

You can change the log period here: https://github.com/bgromov/CrazyFlieTestApp/blob/master/CrazyFlieTestApp/ViewController.swift#L78

NB: I didn't expect to get that far in the development (quite new to Swift yet), so the code is not a fork of the official repo and large chunks were dropped, firmware updates etc., to simplify the code. I was primarily targeting position control, so it is more or less tailored to this need. Anyway, the BluetoothLink and Crazyflie classes are almost intact. Once the API is more or less stable I could attempt to contribute back to the original client.

Thanks!