Bluetooth devices that send RSSI before advertisement are never found #236
Assignees
Labels
bug
Device Comm Managers
Tasks/Bugs pertaining to a Device Communication Managers (platform specific hardware access)
Comments
qdot
added
bug
Device Comm Managers
qdot
added a commit
that referenced
this issue
Jan 1, 2021
If we ignore addresses without names, we may get RSSI packets before advertisement packets and will never actually resolve the device to connect fixes #236
qdot
added a commit
that referenced
this issue
Jan 1, 2021
Same as last commit, if we don't spin the loop on DeviceUpdated events, we may never see name updates for peripherals, which means we won't connect until the next time we see a new device. Always try devices on all packets, since things were fixes with task spawning this shouldn't hurt memory in tight start/stop loops. Fixes #236
qdot
added a commit
that referenced
this issue
Jan 1, 2021
Same as last commit, if we don't spin the loop on DeviceUpdated events, we may never see name updates for peripherals, which means we won't connect until the next time we see a new device. Always try devices on all packets, since things were fixes with task spawning this shouldn't hurt memory in tight start/stop loops. Fixes #236
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
Expected behavior
KEON found every time
Actual behavior
KEON is found around 50% of the time
Additional context
Due to our caching to addresses to make sure we don't constantly reprocess unnamed devices, we miss when a device has just sent its RSSI packets before we actually see an advertisement. If we get a device with no name, we shouldn't add it to the tried addresses list, we should just ignore the advertisement.
The text was updated successfully, but these errors were encountered: