BLE connection parameters
I'm experimenting with keeping simultaneous connections to multiple sensors alive. It works pretty well, actually.
One discrepancy that I've discovered is that for some of the sensors, the mbl_mw_settings_set_connection_parameters call is ignored, while for others, it's honoured. (It's easy to decide if the call was ignored or not, as the download speed changes dramatically.)
After some research, I get that the final decision regarding BLE connection parameters is made by iOS, and Mbient cannot force it.
My guess is that it depends on the number of already connected BLE devices.
Do you have any useful experience in this topic?
Does it really depend on the number of already connected BLE devices, or something else? Can we force it to use the given parameters for all sensors (say, using 6 sensors simultaneously) by watching out for something while initiating the connections to the sensors? ...
Comments
You are correct.
We experiment a lot and also look at what iOS and other companies recommend. For example, here is a link to Apple's recommendation: https://developer.apple.com/library/archive/qa/qa1931/_index.html
This is our defacto:
Also please take a look at this: https://mbientlab.com/cppdocs/latest/advanced_features.html
@kustra the ultimate decision is made either in iOS or in the BLE controller in the phone. There is a limit to the total available bandwidth for all connected devices, and they must be scheduled within time slots to achieve the desired connection parameters. If the radio is already over committed and a high performance request is made it will fail if it cannot be scheduled. Further, in iOS BLE scanning may be configured by the system and taking some available time slots.
In my unit test setup, 3 devices tended to be stable with high performance parameters, but connecting with a 4th would frequently degrade performance. This was in Linux with CSR4.0 chipset dongles.
For more devices you would want to estimate the total bus bandwidth, and choose connection settings that divide it equally (and with a little margin for overhead). If the parameter negotiation often fails or devices drop connection, the settings may be too aggressive. If you're on a Linux platform, you can add additional radio dongles.
I expect that the specific scheduling algorithm used is detailed in the bluetooth core spec, if you want to dig deeply.
@Laura thanks for the default connection parameter values. At one point, I wanted to experiment with setting them to high performance mode only for the duration of the download, then setting them back to default, and I couldn't find the default values. As for the Advanced Features link, I assume you meant the high frequency streaming feature. However, we rely on sensor fusion in our app, and unless we can compute sensor orientation from the packed accelerometer, gyroscope and magnetometer data on the iOS side, we cannot use it.
@Matt iOS bluetooth, at least on iPads, seems to be stable with more than 4 sensors. So far, the only practical issue we've found is the very different download speed of a few sensors. You've described estimating the total bus bandwidth, and using it to calculate connection settings in a way that divides it equally between sensors. This is probably what we need. Can you please elaborate a bit more on this? How does one estimate total bus bandwidth? And how to calculate the different connection parameters from this data?
Let's say, for example, that I want to record 5 seconds worth of data with 4 sensors. The sensors are all logging the same kind of data (quaternions) and they start and stop logging at roughly the same time. And one of the sensors logs data at 100Hz, while the rest at ~50Hz, i.e. one of the sensors has roughly twice as much data as the others. How can I set up connection parameters in a way that would split up total bus bandwidth between the sensors so that download times would be roughly equal if I download from all of the sensors in parallel?
Let's assume the ideal scenario: no other Bluetooth devices connected or nearby, no significant wifi traffic, etc.