Alternate distance formula proposal

[davidgyoung]

An alternate distance formula proposal has been made by @WallyHale in the AltBeacon repo: AltBeacon/spec#30 (comment)

This is similar to the technique currently used by this library but it uses a comparison to the ratio of the measured rssi vs. the calibrated rssi at a series of known points and linear interpolation to approximate distance between these points.

[ericsuhong]

Is there any reason why we are not fitting a simple logarithmic function to sampled RSSIs for distance equation? (I do not know any relevant works done in this area, so please excuse my ignorance if I am missing some necessary background knowledge).

For my school project, I implemented an app that tracks the location using beacons, and I used a simple logarithmic function to estimate the distance, and it worked quiet well.

I measured signals from beacons using Samsung Galaxy Note 3, and sampled signals from 1m to 10m many iterations.

The data I collected seems to be similar to the measurements on an iPhone.

Calibration Full Data.xlsx

I eventually used this distance function: distance = e^((RSSI+60)/-12)) for my project.
(0.5m if RSSI < 60, for my project but can use different function for RSSI < 60)

[davidgyoung]

Hi, @sukhong. It looks like you have good results. The difficult part is making a formula that will work with multiple Android devices and multiple beacon transmitter power levels. Are you interested in doing some research to help find a good distance calculation for the library? If so, I can provide you with some raw data we have collected.

[ericsuhong]

I don't think I will have time to do research on this topic further next semester.

But I believe that regardless of device types and beacon power levels, all formulas should have a similar log slope because RSSI dbM is a logarithmic unit. (this, of course, may be a wrong assumption).

In my experience, each beacon had a different y-intercept, although they all had a similar slope around ~-11.

My hypothesis was that if we can find this "universal" slope that can fit most of the devices and beacons, we can find y-intercept for distance function y = a+Cln(x) given a reference signal level at 1m and universal slope C.

[andersborgabiro]

Well, the calibrated power value (TX?) should be set correctly in the beacon. My experience is that it's not. In my beacon writer app for a certain beacon brand I set TX based on selected real power, empirically calibrated for iPhone 4S (I happened to have one). Both the device's sensitivity and the beacon type (antenna design etc) will affect the actual power, despite being set to e.g. 0 dBm, so it will still differ. In practice I only rely on far/near/immediate.

Has there been any progress on a new distance algorithm? I have been using a couple of RadBeacon Dots and ranging for them on a OnePlus 2. The transmission power is set to maximum and the reference RSSI calibrated to between -49dBm and -52dBm for the different beacons using the Locate app at one meter.

I then have the same issue as has been discussed here and elsewhere, the distance from getDistance is way too small compared to the real distance as you move away from the beacon.

[andersborgabiro]

@sukhong The 60 you mention depends directly on the beacon's transmission power, so 60 should not be used as a constant in the implementation. Rather it should use the reported Tx Power (my different beacons say -53 or -59 dBm), assuming/hoping that the beacon is set up correctly. See my previous comment.

Optimally there would also be compensation for the sensitivity of the actual device, but determining that would be never-ending, as new devices come out all the time.

In what file is the current formula?

[davidgyoung]

There has been work on this periodically, but it is a bit time consuming so we have been looking for a volunteer to help with it.

There is a PR with an alternate distance implementation here: :#251

You might try that branch and enable the alternate algorithm as described there.

[davidgyoung]

FYI, current formula is here:

distance = (mCoefficient1)*Math.pow(ratio,mCoefficient2) + mCoefficient3;

https://github.com/AltBeacon/android-beacon-library/blob/master/src/main/java/org/altbeacon/beacon/distance/CurveFittedDistanceCalculator.java

Thank you, I will try using the experimental solution and see if it gives better results.

[andersborgabiro]

I'm no math expert, but if both rssi and txPower are in dBm they should be subtracted not divided, right? dBm is logarithmic.

[davidgyoung]

Yes, the path loss formula in the branch here #251 subtracts the two values as you suggest

I must admit a bit of fault here, I tried recalibrating the beacons in a more open area and received new values for TxPower that were much larger than where I was doing the first calibration. Now I get TxPowers ranging from -41 to -45 and the distances returned from getDistance() are much more sensible. With the distances I am getting now I think getDistance using the normal algorithm may be enough for my needs. Keep up the good work with this library!

[andersborgabiro]

But has anyone gone through the math and verified whether the current algorithm is correct? Isn't the conclusion that it's not?

@zakjut You mean RSSI right? TX Power is the calibration value.

[davidgyoung]

The current algorithm is based on a curve fit, which is certainly a valid technique. But it does not predict distance well with lower power transmitters, because the data points used for the curve fitting were based on a higher power transmitter.

In theory, the path loss formula referenced in the pull request is scientifically correct. However, we have not proven that it can predict distance well across a wide variety of beacn transmitter power levels and varying receiving mobile devices.