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

Calibration of the Rx/RSSI ratio by device? #2

Open
ramsestom opened this issue Apr 10, 2020 · 10 comments
Open

Calibration of the Rx/RSSI ratio by device? #2

ramsestom opened this issue Apr 10, 2020 · 10 comments

Comments

@ramsestom
Copy link

Thank you for having open sourced your method and your data for the detection of contacts thanks to bluetoothLE.
In the approach used to estimate the distance as a function of the RSSI received, however, there seems to me to be a potentially very significant bias.
From what I understand from the bluetoothLE protocol, the RSSI reported by a device (wich is the only value reported by mobile iOS or Android platforms) is effectively directly correlated to the signal strength (Rx) received by its antenna, but this correlation coefficient can vary completely from one device to another (https://www.bluetooth.com/blog/proximity-and-rssi/). This therefore means that two devices of different make and model, virtually located in exactly the same place and therefore receiving a signal with exactly the same power can report completely different RSSI values ​​for this signal.
In your method, you try to correct the differences in emission power between models of devices by calibrating and normalizing this parameter according to the brand and model, but do you also do the same with regard to their reception capacity ? In other words, have you checked that by sending a signal of known power at a fixed distance (2m) from a device placed in reception (= in scan mode), the RSSI returned by this device was always almost identical whatever the model and brand of the device? (because I am afraid that this would not be the case, in which case an additional calibration on this parameter seems necessary to have a correct final estimate of the distance).
Thank you in advance for clarification on this point if you can.

@mkwiecinski
Copy link

mkwiecinski commented Apr 12, 2020

If I understand correctly, you would suggest a x-device data matrix, since each device differs in both receiving capabilities and transmission power?

This means that device data should be in the form of:

Transmitter Receiver dBm
Device A Device B -50
Device A Device C -45
Device B Device A -48
Device B Device C -43
Device C Device A -47
Device C Device B -44

and so on...

@ramsestom
Copy link
Author

ramsestom commented Apr 12, 2020

No. If you always take the same Transmitter to test the devices Receiver capalities and the same Receiver to test their Transmitter capalities you can normalize your data according to these references. So you don't need to test each combination.
So what I suggest is to add a column into the current Device_data.csv file that would indicate the average RSSI reported by the device at a distance of 2m of a Transmitter emitting a signal of a known power.

@jasonbay
Copy link
Collaborator

ramestom is right. Signal "losses" are multiplicative, or additive on a log-scale. Preparing the code for open-sourcing has taken away time to do more extensive testing -- in different orientations for the transmitter (and possibly for the receiver as well). We have done some testing of receiver variation. They're generally not as bad as the variation in transmitter power. Hence, that has been our focus so far. If you have any data across a range of devices, please do share them with us!

@rashedhamadin
Copy link

rashedhamadin commented Apr 17, 2020

COVID19-BT-Prblm
Hi ... I suggest that you try to protocol this idea ... it may help you to solve reversing the Ptx or (RSSI reference values) for the devices in general without needing to have a lookup table for all types of the devices, rather you can append this (three-hand-shake) protocol with some filtering for the signals using Kalman for instance (See the attached reference
An_Improved_BLE_Indoor_Localization_with_Kalman-Ba (1).pdf
).

Thank you for your great and valuable efforts and I hope my simplification for the Idea follows some sort of your standards that could help you brothers.
Rashed.

@ramsestom
Copy link
Author

ramsestom commented Apr 17, 2020

There is no way you can solve a 4 variables equation system with only two connected devices and the information provided by bluetoothLE only.

The variables that are unknown are:

  • the emitting power Tx_A of device A
  • the emitting power Tx_B of device B
  • the Rx/RSSI ratio of device A
  • the RX/RSSI ratio of device B

what we want to know is the distance d between the two devices A and B which is a function of Tx_A,Rx_B (and Tx_B,Rx_A) and all we have is RSSI_AB and RSSI_BA. So we have a system of 2 equations (d=f(Tx_A,Rx_B) and d=f(Tx_B, Rx_A)) with 5 unknown variables (or only 3 unknown variables if we approximate the Rx values with the RSSI ones, wich is what is currently done in the opentrace method; but it still can't be resolved). This is why you need calibration values for your devices Tx (and ideally Rx/RSSI) values if you want to have an idea of the distance d (the system is even more complicated by Tx power saving mode reduction, RSSI variations at small distances and possible obstables like human body between the devices).

@MecJames
Copy link

Attached you will find a publication. It describes the complete solution of the Calibration Method.

Coronavirus COVID-19 - Calibration Method and Proximity Accuracy - EN.pdf

Considering the communication between the Bluetooth Transmitter and Receiver, there are three areas, Transmitter, Radio Channel (Fading and Directivities of Smart Phones), and Receiver. In the attached Doc you can find the solution of the TR and RX problems, e.g. how to remove all the deviations between different Smart Phone Types. The remaining challenge is the Radio Channel.

If the systematic errors are not removed by the calibration method, then BLE will be completely unsuitable for the intended purpose of interrupting the infection chains.

In (https://github.com/opentrace-community/opentrace-calibration) only the TX has been considered.

@kevinjwalters
Copy link

kevinjwalters commented May 4, 2020

@MecJames When you say the radio channel, are you referring to the attenuation per frequency (Bluetooth BLE channel)?

The frequency may also have an effect on per device tx and rx power calibration, I don't know if anyone has studied that well?

@mrquincle
Copy link

Yes, it has been studied before per channel. I've just written a blog post to hopefully clarify a few things for people.

@kevinjwalters
Copy link

@mrquincle Thanks, very interesting and the polar plots are an eye-opener! BTW, two of the references 404 due to malformed links.

@mrquincle
Copy link

Check, corrected!

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

No branches or pull requests

7 participants