Issue connecting 7+ sensors to a raspi
Hello ! I'm trying to use some of the Metawear C sensors in a project (basically 15 of them). I'm facing the following issue with those :
When I try to connect more than seven bluetooth sensors to a raspberry pi 3B (on differents bluetooth dongles, for example 3 sensors on 3 differents dongles -> 9 sensors), I have various problems (eg : can't connect to the 8th, the program crashes [resource busy], got some disconnections,...).
I use the MetaWear API, with the warble lib in C++ on the raspberry pi (raspbian), and some ASUS USB-BT400 dongles along with it. I tried too with the sensors shiped with the MetaHub Gateway, with worse results.
I just wanted to know if other developers have had this issue already, and if it could come from the raspi periphericals, the linux core, the bluetooth dongles, or the sensors.
Finally, I would like to know if it is better to gather data with a streaming or a polling protocol to use such an important number of sensors (and read all our data within 100ms) ; and if the MetaWear API is thread-safe.
I am from the PaulPom team, he's going to be on hollidays...
We can connect up to 3~4 devices successfully on the same dongle and in the same process and thread, but if we try more we go through connection time-out for some devices.
When lucky, we can use up to 7 devices distributed over 3 dongles (in one thread or several threads, no matter).
We have to use IMU sensor in fusion mode, we have tried stream mode but with many deconnection problems, so we have tried with polling (using a passthrough data processor and triggering it at regular interval) and found it a bit more stable.
We do not use MblMwMetawearBoard object amongst multiple threads.
It is saying on your site that it is possible to connect up to 20 sensors to a metahub (we have one)(can we connect them at same time ?), but we failed to do this. Have you any code example that allows this ?
Any idea or advice will be greatly appreciate !
Thank's a lot !
Post a minimal script that reliably replicates this issue and a log of the BT adapter activity when it happens.
What language are you using for your workflow?
We use C++.
Things have advanced a little, but many questions remain :
After some tries we can now connect up to 15 sensors through 3 usb bluetooth dongles.
It seems that it's more reliable to first configure all sensors and then to start data send for all.
Before that one sensor was configured and started, then same thing with the follower, and so on.
However, regularly, some sensors need several connection tries to successfully connect, although they are powered from usb and within one meter from usb bluetooth dongle. Is it normal ?
The code we use for the "MblMwBtleConnection" interface : see the "MblMwBtleConnection.txt" file.
The code we use for sensor connection : see the "SensorConnectionManagement.txt" file.
It seems that the "warble_gatt_connect_async" function has no time-out, and before badly fails (when it fails) it creates 3 or 4 threads that live more than 1 minute then disappear, without any call to the handler provided to "warble_gatt_connect_async", so we can't know when threads are destroyed to retry connect properly.
From HciDump, we have 2 kinds of failure (see "HciDump.txt" file) :
Also, sometimes some sensors disconnect from bluetooth, and it's very difficult to connect them again. Is it related to others that are always sending data and disturbing connection, or to the previously mentioned connection problem ?
What is the proper way for a sensor re-connection ?
We use the "mbl_mw_metawearboard_deserialize" function. Should it be called before sensor bluetooth connection or after ?
Thanks for any advice !
That would be the best way when using multiple sensors. You should not start exchanging data until the connections are setup and stable.
Yes, you are using multiple sensors per adapter after all.
Off hand, code looks fine here.
Connect times out on its own. If the callback isn't being fired, then there is some corner case in the connect implementation that was overlooked. We'll need to have a way to reliably reproduce this situation.
Hard to say. Its most likely because there is a lot of adapter activity due to having 4-5 sensors per adapter simultaneously sending data.
You do not need to destroy anything. Re-establish connection with the board, then call
Does not matter.
See my latest update on this thread for some tips: https://mbientlab.com/community/discussion/2755/inconsistent-connecting-with-python-client#latest
First thanks for your help.
Finally we have succeeded to manage connection and disconnection in a relative reliable way with 15 sensors distributed over 3 bluetooth dongles.
connection : before calling "warble_gatt_connect_async", we register to the warble instance by calling "on_disconnect" function. So we are now notified if connection is canceled, avoiding our time-out for "warble_gatt_connect_async", and we can retry to connect immediatly. We unregister by calling "on_disconnect(nullptr, nullptr)" only if connection has failed, as if connection is successful, the mbientlab sdk will overwrite the "on_disconnect" handler.
reconnection : when connecting, we configure the sensor with "mbl_mw_settings_set_connection_parameters". We use separate min and max connection interval for each bluetooth dongle, and distinct latency value for each sensor. It seems to improve reconnection reliabililty.
As we use a time data processor to reduce sensor data send rate, we have no problem of processing power with the raspberry pi 3.
However we always have connection fails when launching our soft several times consecutively, that we solve by using method from https://marc.info/?l=linux-usb&m=121459435621262&w=2 for each used bluetooth dongle before our soft launch.
Thank for the update. As per my previous thread, you should handle automatic reconnects and connection failures.
@PaulPomTeam, any chance you could share your successful code? It's the closest thing I've been able to find which shows how to connect the C++ SDK to Warble. I have a similarly challenging multi-sensor application and would love to start with known good BLE code.