I am trying to run two bluetooth dongles simultaneously for two
separate devices.
One device is communicating over classic BT while the other one is using BL=
E.
When both devices are running (approximately 250hz sampling rate), the
BLE is dropping packets (most of the samples are gone).
I am using pygatt to capture the data and it appears to happen when
the pygatt chokes and python takes 100% of a single cpu core.
bluetoothctl also shows strange behavior with two controllers. Even
when a particular controller is selected, it can not show the
paired-devices correctly, unless the other one is plugged out (the mac
is different on both dongles).
Now, the question is, in bluez is it problematic to run two dongles
simultaneously considering both of them are active and pushing data?
I am trying to get a more experienced opinion to pinpoint the
problematic part of the setup (pygatt or bluez).
bluez - 5.41
arm64 - kernel 4.4+
dongles - csr 4.0
Thanks
--=20
with best regards,
Nazmul Alam Shovon
=E0=A6=B6=E0=A7=81=E0=A6=AD=E0=A7=87=E0=A6=9A=E0=A7=8D=E0=A6=9B=E0=A6=BE=E0=
=A6=A8=E0=A7=8D=E0=A6=A4=E0=A7=87,
=E0=A6=A8=E0=A6=BE=E0=A6=9C=E0=A6=AE=E0=A7=81=E0=A6=B2 =E0=A6=86=E0=
=A6=B2=E0=A6=AE =E0=A6=B6=E0=A7=8B=E0=A6=AD=E0=A6=A8
Hi Nazmul,
Just to share my experience....
For a project using BLE for firmware upgrade transfer and configuration
of some IoT devices, I gather up to 10 USB dongles with BLE support. 1
dongle used to scan for new devices, others for performing device
upgrade and configuration in parallel pour every "device" discovered by
the scan. The whole stuff was connected to a PC.
I was only using the bluez DBUS API directly using python scripts,
standard dbus python extension (ie. import dbus) and glib mainloop for
event handling which integrates fine with python dbus (ie. dbus signals
handler).
The whole stuff works pretty well and was used in production line.
Bluez version 5.47 with experimental features enabled (which are now
integrated in most recent bluez version)
Cheap CSR USB dongle (v4.0) are working fine in BLE (which was not the
case of my integrated laptop bluetooth module...)
Regards,
Arnaud
On 20/09/2018 18:09, Nazmul Alam wrote:
> Hi Luiz and Barry,
> Thank you for the suggestions. I will try the latest bluez out.
>
> Regarding pygatt, I can double confirm they are using gatttool on the
> binary distribution provided by python package manager.
>
> Given that I used pygatt to get the data, I was evaluating the dbus
> c-api for data capture. But I don't wanted to jump into premature
> decision as I didn't know it this is an issue on the bluez side (if
> that was the case, no point using dbus api).
>
> Thank you again and I will get back once I do the testing.
> On Thu, Sep 20, 2018 at 10:06 AM Barry Byford <[email protected]> wrote:
>> Hi Luiz,
>>
>> On Thu, 20 Sep 2018 at 10:16, Luiz Augusto von Dentz
>> <[email protected]> wrote:
>>
>>> Btw, pygatt appears to be using gatttool which is deprecated, not idea
>>> why people keep using that.
>> It seems they are aware of the situation:
>> https://github.com/peplin/pygatt/issues/112
>>
>> I suspect part of the problem is that the "wrong" answers are easier
>> to find with your favorite search engine....
Hi Luiz and Barry,
Thank you for the suggestions. I will try the latest bluez out.
Regarding pygatt, I can double confirm they are using gatttool on the
binary distribution provided by python package manager.
Given that I used pygatt to get the data, I was evaluating the dbus
c-api for data capture. But I don't wanted to jump into premature
decision as I didn't know it this is an issue on the bluez side (if
that was the case, no point using dbus api).
Thank you again and I will get back once I do the testing.
On Thu, Sep 20, 2018 at 10:06 AM Barry Byford <[email protected]> wrote:
>
> Hi Luiz,
>
> On Thu, 20 Sep 2018 at 10:16, Luiz Augusto von Dentz
> <[email protected]> wrote:
>
> > Btw, pygatt appears to be using gatttool which is deprecated, not idea
> > why people keep using that.
> It seems they are aware of the situation:
> https://github.com/peplin/pygatt/issues/112
>
> I suspect part of the problem is that the "wrong" answers are easier
> to find with your favorite search engine....
Hi Luiz,
On Thu, 20 Sep 2018 at 10:16, Luiz Augusto von Dentz
<[email protected]> wrote:
> Btw, pygatt appears to be using gatttool which is deprecated, not idea
> why people keep using that.
It seems they are aware of the situation:
https://github.com/peplin/pygatt/issues/112
I suspect part of the problem is that the "wrong" answers are easier
to find with your favorite search engine....
Hi Nazmul,
On Thu, Sep 20, 2018 at 1:11 AM, Nazmul Alam <[email protected]> wrote:
> I am trying to run two bluetooth dongles simultaneously for two
> separate devices.
> One device is communicating over classic BT while the other one is using BLE.
> When both devices are running (approximately 250hz sampling rate), the
> BLE is dropping packets (most of the samples are gone).
> I am using pygatt to capture the data and it appears to happen when
> the pygatt chokes and python takes 100% of a single cpu core.
>
> bluetoothctl also shows strange behavior with two controllers. Even
> when a particular controller is selected, it can not show the
> paired-devices correctly, unless the other one is plugged out (the mac
> is different on both dongles).
Try with a more recent version, there were some improvement to handle
multiple adapters better.
> Now, the question is, in bluez is it problematic to run two dongles
> simultaneously considering both of them are active and pushing data?
>
> I am trying to get a more experienced opinion to pinpoint the
> problematic part of the setup (pygatt or bluez).
Btw, pygatt appears to be using gatttool which is deprecated, not idea
why people keep using that.
> bluez - 5.41
> arm64 - kernel 4.4+
> dongles - csr 4.0
--
Luiz Augusto von Dentz