Add path loss distance calculation algorithm

[davidgyoung]

Adds experimental support for a new formula for calculating distance based on a path loss formula rather than a curve fitted formula. This returns better results with low power beacon transmitters and is easier to add calculations for different device models.

This alternate means of calculating distance may be enabled by calling:

ModelSpecificDistanceCalculator.setDistanceCalculatorClass(
        PathLossDistanceCalculator.class);

Correction factors for various Android models may be added by doing a 1 meter calibration with that device model, to obtain the average RSSI for that model at 1 meter, then subtracting the known iPhone 5 calibration value at 1 meter. This yields a "Receiver RSSI Offset", which indicates the relative sensitivity of the Android device's bluetooth receiver compared to an iPhone 5. For a Nexus 5, this value is -2.5 dB, indicating its receiver is only very slightly less sensitive to Bluetooth signals than an iPhone 5. For a Samsung Galaxy S5, this value is -21.5 dB, indicating its receiver is much less sensitive to Bluetooth signals than an iPhone 5.

[HappyDr0id]

Hi David,

You said that for a Nexus 5, the offset is -2.5dB, but on the model-distance-calculations-r2.json file of the path loss branch, you have set -4 on the 'receiver_rssi_offset' field.

Also, you describe that the offset must be supplied by the caller, but what about the slope value ? Is it the same value for every devices ?

Thanks a lot for your work and thanks in advance for your answer ;)

[andresteves]

Hi David,

Tried to use the path loss algorithm with no luck, even tweaking the 0.35 constant was of no good. The RSSI values from the json file I used were the ones for Moto G.

The distances came up always less than 1 meter even when the beacons were at 5m and 10m.

I will try and modify the algorithm a little bit to see if it helps but since I am in a tight schedule I might do that afterwards.

Disclose: My company provides bespoke beacon solutions.

[davidgyoung]

@andresteves. Yes, I have also gotten inconsistent results with this algorithm, which is the reason I have not merged this pull request. It just has not proven to work better (or even as well) as the exiting algorithm in the library. This is why the title includes the word "experimental." Sadly, some experiments fail!

If you manage to make any changes that improve things, I would be interested in hearing about the results.