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.

Thanks !

Comments

    • Do you have better luck if you keep it to 6 devices per process?
    • Depends on what sensore you are using. For example, IMUs stream data, temperature requires polling
    • I do not recommend concurrently using a MblMwMetawearBoard object from multiple threads
  • Hello !
    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 !

  • edited December 2018

    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?

  • Hello !

    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) :

    • HCI Event: Disconn Complete (0x05) plen 4 status 0x00 handle 65 reason 0x13 Reason: Remote User Terminated Connection
    • HCI Event: Command Complete (0x0e) plen 4 LE Create Connection Cancel (0x08|0x000e) ncmd 1

    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 ?

    • destroy the sensor instance and re-create all for it (mbl_mw_metawearboard_free, mbl_mw_metawearboard_create) ?
    • destroy the warble instance linked to a sensor and re-create it (warble_gatt_delete, warble_gatt_create_with_options) ?
    • use the "disconnect" function from the warble instance or the "warble_gatt_disconnect" to clear the connection ?
    • recall the "warble_gatt_connect_async" function ?

    We use the "mbl_mw_metawearboard_deserialize" function. Should it be called before sensor bluetooth connection or after ?

    Thanks for any advice !

  • @PaulPomTeam said:
    Hello !

    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.

    That would be the best way when using multiple sensors. You should not start exchanging data until the connections are setup and stable.

    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 ?

    Yes, you are using multiple sensors per adapter after all.

    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.

    Off hand, code looks fine here.

    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.

    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.

    From HciDump, we have 2 kinds of failure (see "HciDump.txt" file) :

    • HCI Event: Disconn Complete (0x05) plen 4 status 0x00 handle 65 reason 0x13 Reason: Remote User Terminated Connection
    • HCI Event: Command Complete (0x0e) plen 4 LE Create Connection Cancel (0x08|0x000e) ncmd 1

    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 ?

    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.

    What is the proper way for a sensor re-connection ?

    • destroy the sensor instance and re-create all for it (mbl_mw_metawearboard_free, mbl_mw_metawearboard_create) ?
    • destroy the warble instance linked to a sensor and re-create it (warble_gatt_delete, warble_gatt_create_with_options) ?
    • use the "disconnect" function from the warble instance or the "warble_gatt_disconnect" to clear the connection ?
    • recall the "warble_gatt_connect_async" function ?

    You do not need to destroy anything. Re-establish connection with the board, then call mbl_mw_metawearboard_initialize.

    We use the "mbl_mw_metawearboard_deserialize" function. Should it be called before sensor bluetooth connection or after ?

    Does not matter.

  • Hello !
    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.

  • @PaulPomTeam,
    Thank for the update. As per my previous thread, you should handle automatic reconnects and connection failures.

Sign In or Register to comment.