Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix issue where RSSI is incorrectly reported as -99 #362

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

peter-dolkens
Copy link

Upon investigating why my RSSI kept jumping to -99, I discovered that the bluetooth spec for HCI_Read_RSSI states:

The RSSI parameter returns the difference between the measured Received Signal Strength Indication (RSSI) and the limits of the Golden Receive Power Range for a Connection Handle to another BR/EDR Controller. Any positive RSSI value returned by the Controller indicates how many dB the RSSI is above the upper limit, any negative value indicates how many dB the RSSI is below the lower limit. The value zero indicates that the RSSI is inside the Golden Receive Power Range.

Currently, monitor.sh has a rule that sets the RSSI to -99 if it is reported as 0, causing the RSSI to be instantly reported as -99. I have removed this override which should result in more accurate presence detection - if something is close enough to be in the "golden range", then it's more likely to be at 0, than it is to be at -99, which is almost out-of-range.

Sources:

Upon investigating why my RSSI kept jumping to -99, I discovered that the bluetooth spec for `HCI_Read_RSSI` states:

> The RSSI parameter returns the difference between the measured Received Signal Strength Indication (RSSI) and the limits of the Golden Receive Power Range for a Connection Handle to another BR/EDR Controller. Any positive RSSI value returned by the Controller indicates how many dB the RSSI is above the upper limit, any negative value indicates how many dB the RSSI is below the lower limit. The value zero indicates that the RSSI is inside the Golden Receive Power Range.

Currently, `monitor.sh` has a rule that sets the RSSI to -99 if it is reported as 0, causing the RSSI to be instantly reported as -99. I have removed this override which should result in more accurate presence detection - if something is close enough to be in the "golden range", then it's more likely to be at 0, than it is to be at -99, which is almost out-of-range.

Sources:

* https://stackoverflow.com/questions/30025139/bluez-bluetooth-api-and-distance-calibration-precision
* https://bluez-users.narkive.com/5nAqoY4A/hcitool-and-rssi-value-0
* https://www.cwnp.com/rssi-changing-definition/
@peter-dolkens
Copy link
Author

peter-dolkens commented Dec 30, 2020

For reference, this is what 4 hours of RSSI history looks like with these changes applied:

image

And this is similar history without these changes applies:

image

Notice the tendency to sit at -99, -66, and -33 - a result of reports returning within the "golden range"

forgenator added a commit to forgenator/monitor.sh that referenced this pull request Jan 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant