bluetooth: add rssi property#127
Conversation
| qint32 BluetoothDevice::signalStrength() const { | ||
| // Convert RSSI (dBm) to a normalized 0-100 scale | ||
| // Based on practical Bluetooth RSSI ranges: | ||
| // -30 to -40 dBm = 85-100 | ||
| // -40 to -55 dBm = 65-85 | ||
| // -55 to -65 dBm = 45-65 | ||
| // -65 to -75 dBm = 25-45 | ||
| // -75 to -85 dBm = 10-25 | ||
| // <= -85 dBm = 0-10 | ||
|
|
||
| auto rssiValue = this->bRssi.value(); | ||
| if (rssiValue == 0) { | ||
| return 0; | ||
| } | ||
|
|
||
| auto rssi = std::max(static_cast<qint16>(-100), std::min(static_cast<qint16>(-30), rssiValue)); | ||
| auto normalized = static_cast<qint32>(((rssi + 100) / 70.0) * 100.0); | ||
|
|
||
| return std::max(0, std::min(100, normalized)); | ||
| } |
There was a problem hiding this comment.
Tbh I'm not sure if this should be linear or not. It requires actual testing at various distances to make sure the number is useful
There was a problem hiding this comment.
I adjusted it, there's no good singular mathematical function I could find to get it as a good representation for display purposes - but I think the numbers are pretty good now.
| dBm | normalized |
|---|---|
| -30 | 100 |
| -35 | 96 |
| -40 | 92 |
| -45 | 88 |
| -50 | 83 |
| -55 | 79 |
| -60 | 75 |
| -65 | 59 |
| -70 | 42 |
| -75 | 26 |
| -80 | 9 |
| -85 | 5 |
| -90 | 0 |
Pretty much anything > -67 is a good signal, anything -80 or below is usually un-usable. 0 is driver reporting no signal data is available for the device (so treating it as effectively 0 normalized)
|
@outfoxxed can you have a look at the updates made since your last request? Some of these PR's sit for days or weeks at a time with small enhancement requests. I would say many are okay if you co-author as well to help push them along quicker. |
This one is deceptively simple looking. I'm quite busy and have not had the time to test that shown signal strength reports a logical looking value for various devices. The strength calculation function also looks suspiciously like a curve fit better solved by a single equation. Figuring that out for review takes a considerable amount of time which I don't have right now. |
|
Tbh it might be better to just report an enum with Excellent, good, fair, poor or something for the easy to consume value. And raw rssi for those who desire it. It’s hard to quantify very accurately because different BT versions and protocols and device manufacturers have some variations on the reporting and work better or worse at lower signals/different distances. But I’m good with whatever approach you wanna go with, no strong opinion. The main thing for me would be to sort, and show the excellent/good/fair/poor icon/text next to them. |
|
I don't have an issue with exposing raw RSSI, and exposing signal strength as an enum/int for general quality is acceptable as well. I would lean towards an integer, e.g. 0-4 for that "quality" value because enums are generally more annoying to deal with in QML. |
outfoxxed
force-pushed
the
master
branch
3 times, most recently
from
a92879d to
9bb2c04
Compare
outfoxxed
force-pushed
the
master
branch
2 times, most recently
from
08c7fc2 to
bcc3d42
Compare
3 participants
Add rssi to bluetooth property bindings. It's useful to see signal strength of devices during discovery (IE, for sorting by signal strength, ignoring very low signal strength devices)
Because rssi is not available when the adapter is no longer discovering I also added a condition to lower the log level on the property update callback for optional properties, it's not really necessary and can be removed - but prevents some log spam when turning off discovery (because the rssi properties become unavailable)