From 119638df569a1236d14d9f232c24140d42108969 Mon Sep 17 00:00:00 2001 From: Peter Dolkens Date: Tue, 29 Dec 2020 21:54:19 +0000 Subject: [PATCH] Fix issue where RSSI is incorrectly reported as -99 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/ --- monitor.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/monitor.sh b/monitor.sh index db35f337..8e49a77f 100755 --- a/monitor.sh +++ b/monitor.sh @@ -281,7 +281,7 @@ connectable_present_devices () { do scan_result=$(hcitool rssi "$known_addr" 2>&1); \ scan_result=${scan_result//[^0-9]/}; \ scan_result=${scan_result:-99}; \ - [[ "$scan_result" == "0" ]] && scan_result=99; \ + # [[ "$scan_result" == "0" ]] && scan_result=99; \ counter=$((counter+1)); \ avg_total=$((avg_total + scan_result )); \ sleep 0.5; \