Advertisements only seldom received/displayed #1065
Labels
3rd party issue
The issue is with the Bluetooth stack, the BLE device, or other 3rd party code not with Bleak itself
Backend: BlueZ
Issues and PRs relating to the BlueZ backend
Comments
|
What is the output with |
|
|
I'm not sure why each d-bus signal is being logged twice, but Bleak is only receiving a few update from BlueZ. So the next thing to check would be to log Bluetooth packets with Wireshark to see if the adapter is actually receiving advertisements more frequently or not. |
|
Would hcidump also work? |
|
yes |
|
It contains 4 files: I see hcidump also has only less activity, compared to fast case. |
|
Slow: Fast: Can I somehow tell bleak to not filter duplicates? |
|
Yes, you can add It looks like we need to fix the docs to show the members of |
|
Many thanks for your fast help! I must say, just using bleak for a few hours. Is it just by adding it in this way? scanner = BleakScanner(simple_callback, service_uuids, bluez=dict(filters=dict(DuplicateData=True))) Or scanner = BleakScanner(simple_callback, service_uuids, "active", bluez=dict(filters=dict(DuplicateData=True))) Or scanner = BleakScanner(simple_callback, bluez=dict(filters=dict(DuplicateData=True))) But all three variants don't seem to fix my problem. Must it be different? |
|
EDIT: nope, I read that wrong. It should be set to https://github.com/bluez/bluez/blob/master/doc/adapter-api.txt#L112 |
|
No matter if I use True or False, the parameter "filter duplicates" remains 0x01 (enabled). |
|
What is printed if you add |
|
test@test:$ grep Duplicate detection.py When I change to False, printed text also changes to False. |
|
Could this be the code on the "other" side? https://github.com/bluez/bluez/blob/61f4f2895882a19c402e93ef4ba7bb6b802015a4/client/main.c#L1520 |
|
No, that is the code for |
|
Could be related to #235 |
|
I can confirm, that the (bad) workaround from is working also on my side. I get fast advertisement messages for a short time, till it gets slow again. |
|
I found torvalds/linux@abfeea4 that indicates the behavoir was changed in Linux kernel 5.17 to not filter duplicates by default. So maybe upgrading the kernel is a possibility? |
|
We are using a Raspberry Pi. Upgrading the kernel is not so easy. We get it as binary only. I think I must sleep over it (already late evening here in Germany) and think tomorrow how it can be solved. I would like to send you a BIG THANK YOU for all your help! |
|
I tried it on a newer kernel (5.17 and 5.19) and it turns out that it only takes effect if an advertisement watcher is in place. So based on this, I was able to come up with a different workaround. If you enable experimental features in |
dlech
added
the
3rd party issue
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
bluetoothctl -v) in case of Linux: 5.55Description
I have a device which is sending a lot advertisements. I said it to do in maximum speed.
test@test:~/bleak $ sudo hcitool lescan --duplicate
LE Scan ...
E4:5F:01:BA:05:2D (unknown)
E4:5F:01:BA:05:2D
E4:5F:01:BA:05:2D (unknown)
E4:5F:01:BA:05:2D
E4:5F:01:BA:05:2D (unknown)
E4:5F:01:BA:05:2D
I can see it advertising at a high speed (around 40 advertisements per second).
Then I use (from example):
It gives the following output:
It gives only seldom data, far away from 40 per second.
I assume the checked fields remain equal, but there shall be at least a counter inside, which increases every 200ms.
So I assume at least I should see an output every 200ms?
Could I tell Bleak to display every received advertisement?
Why is stop/restart needed? Just that duplicates are reported again?
Or do I somehow need to tell BlueZ under Bleak to use something like lescan with --duplicate?
Or could it be that problem is on sender side? Advertisement data not correct? Or only sometimes correct?
The text was updated successfully, but these errors were encountered: