Improvement: check against trend rather than discrete values

[kbridger]

I've just discovered this project and have set it up to explore it - exactly the use case I'm trying to figure out. So thank you for this!

I find that my RSSI value fluctuates too much even when sitting at my desk within 0.5m of the Bluetooth receiver. I'm using my Samsung watch to track proximity. I find that the value jumps around between 0 and 15 quite a lot. So I set my trigger value to ~12, but it still results in false triggers, which are very impactful. Locking the screen accidentally, or pausing music/unpausing based on a single discrete measurement seems too fragile.

I was reading the Bluetooth doc about proximity and they suggest to "Use the Mode of a Range When Getting the RSSI Value" which makes a lot of sense, so those 1-off spikes can be ignored.

I was going to look at the script to think about how to track the last 5 readings and ignore high/low values against the mode but wonder if anyone else has already thought of this, or has a simple way to configure the script to avoid this problem.

Thanks again for your work, I'm not a script expert, more a dabbler, but I think this would be a great improvement to this script.

[ewenchou]

Thanks for your interest in the project. It was some code I wrote to explore using Bluetooth proximity several years ago and unfortunately I haven’t made updates for a long time. I do not know of anyone who has tried what you described but I think it’s a great idea. Good luck and happy coding :)

On Mon, Jan 17, 2022 at 10:32 AM Kirk Bridger @.***> wrote:

I've just discovered this project and have set it up to explore it - exactly the use case I'm trying to figure out. So thank you for this!

I find that my RSSI value fluctuates too much even when sitting at my desk within 0.5m of the Bluetooth receiver. I'm using my Samsung watch to track proximity. I find that the value jumps around between 0 and 15 quite a lot. So I set my trigger value to ~12, but it still results in false triggers, which are very impactful. Locking the screen accidentally, or pausing music/unpausing based on a single discrete measurement seems too fragile.

I was reading the Bluetooth doc about proximity https://www.bluetooth.com/blog/proximity-and-rssi/ and they suggest to "Use the Mode of a Range When Getting the RSSI Value" which makes a lot of sense, so those 1-off spikes can be ignored.

I was going to look at the script to think about how to track the last 5 readings and ignore high/low values against the mode but wonder if anyone else has already thought of this, or has a simple way to configure the script to avoid this problem.

Thanks again for your work, I'm not a script expert, more a dabbler, but I think this would be a great improvement to this script.

— Reply to this email directly, view it on GitHub https://github.com/ewenchou/bluetooth-proximity/issues/21, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAPBUIWNEM37DKEA7TSEV3DUWROCLANCNFSM5MFK3MAQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you are subscribed to this thread.Message ID: @.***>

-- Regards, Ewen

[AbelValko]

A couple of years ago I did something similar, implementing a passive keyless entry system with bluetooth proximity instead of RFID. Can't remember exactly how I got it to work in the end, but as you say there is considerable fluctuation in the readings, especially when the devices are moving, which requires some sort of filtering or at the very least a rolling average to get under control. Good luck! /Abel