Develop Reference

Bluetooth RSSI value fluctuation

I'm trying to use RSSI values to create a positioning system in my home.
I'm using the neXenio library as a base, the only changes I have made from this have been implementing logging to a database:
https://github.com/neXenio/BLE-Indoor-Positioning
I'm using 4 Minew I7's for the beacons and they are currently set to broadcast just iBeacon type adverts at 300ms. They are positioned in a square shaped room and a cross type layout and each beacon is around 2.2m apart. There are no obvious obstructions other than normal living room furntiure. For each test run I do I place my phone in the centre of the room and gather data for around 10-15 minutes at a time. Data gets sent to a database for me to look at after.
The issue I'm having is the singal strength fluctuates massively all the time, to the point the data is basically unusable.
Graphs from a typical test run.
Should there be that much difference when the phone is completely still ? I'd expect there to be some slight differences from just the nature of signal propagation but not this much.
Is this to be expected or can these be improved upon somehow ? If this is expected then I will have to look at combining some other sensor data to help improve accuracy.
Thanks
Edit:
After running some more tests, I compared values over time (I had previously only compared rssi,distance and mac address). This has led to find a consitant osscilation pattern Newest test run.
This has also led me to this overstack question:
Is there an explanation for the regular oscillation experienced in Bluetooth RSSI
If I am only advertising iBeacon type adverts then this wouldn't apply? But it seems strange how it matches me issue.

RSSI values fluctuate a lot and there is not much you can do about that. That's why the new features in Bluetooth 5.1 were created that use other techniques than signal strength for positioning. Unfortunately the adoption has been slow.

You can't do much with currently used devices. Even if you stabilize the signal statically, there will be a lot of noise during movement. You can try to:
thicken the signal to 100 ms. Urfotunately, this will affect battery consumption,
BLE transmits packets on 3 channels (37, 38, 39). The antenna probalby isn't tuned to all 3 the same. If you have the option to change the advertising channels, try to test on different settings.
if you have option of soldering or connecting an external anntena, direcational antennas may be helpful for indoor positioning system.
There are many methods to stabilize the rssi signal. If you are interested in this topic, I recommend looking at the articles:
https://scholar.google.com/scholar?hl=pl&as_sdt=0%2C5&q=stabilization+rssi+method&btnG=
In my opinion, this mothod will be most useful to you:
https://www.wouterbulten.nl/blog/tech/kalman-filters-explained-removing-noise-from-rssi-signals/
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5461075/
AoA and AoD methods may also interest you:
https://www.bluetooth.com/blog/new-aoa-aod-bluetooth-capabilities/
I hope this will be useful

Its practice approach, I tried and implemented.I got the proper results, so that`s why writing the solution. If possible try the same.
I implemented it on one BLE router and one Beacon tag.
I need to do the calculation for up to 3 meter means 3*3.2 foot.
I minimized the fluctuation with out using the kalman filter.
For above implementation we need to go through the steps as follows,
Step 1. Keep Beacon tag at 1M of distance and take 10 [Max] number of readings of rssi & store it in one excel.
Step 2. Keep Beacon tag at 2M of distance and take 10 [Max] number of readings of rssi & store it in second excel.
Step 3. Keep Beacon tag at 3M of distance and take 10 [Max] number of readings of rssi & store it in third excel.
Now you have 3 excel.
Take one excel and observe the rssi value, compute the median for the same.
Same thing need to calculate for other two excels.
My Becon tag freq is 4 dbm.
I got the readings of RSSI from above excel as listed below:
From one excel: -58
From two excel: -64
From third excel: -70
As you see, there is difference of 6 as I change the meter.
Now I written logic by using above results like if value is fluctuating between -58 to -64 then it is represented as 1 m. same for 2m & 3m.
But this is not the proper way to do the calculation.
So I used the log for the
calculation like for the value between -58 to -64
result = log(rssi*-1,58). i.e 58 as base.
actual distance = result *1(meter)*3.2(ft)
Same for 2 meter, but for 2 m base of log is 64
result = log(rssi*-1,64). i.e 64 as base.
actual distance = result *2(meter)*3.2(ft)
Same for 3 meter, but for 3 m base of log is 70
result = log(rssi*-1,70). i.e 70 as base.
actual distance = result *3(meter)*3.2(ft)
This can be done by programming. I got the proper results with stability of rssi signal.

Difference between RunningAverageRssiFilter, ArmaRssiFilter, Kalman filter in Altbeacon SDK

I understand that we can have different implementations for RssiFilter using setRssiFilterImplClass in Altbeacon SDK. I tried out all above filters (RunningAverageRssiFilter, ArmaRssiFilter, Kalman filter) and i found that there is not much difference in distances which i got. So what is the exact difference and what is the use case where in i have to select one of these filters.

The Android Beacon Library allows different ways to filter the noise out of Bluetooth LE beacon signal strength measurements so that distance estimates are as accurate as possible.
For most users it doesn't matter which of these mechanisms you use to filter RSSI, as you have seen, they all work similarly. Variations between filters matter mostly for moving beacons. Each filter will introduce "lag" in the distance estimate when the beacon is moving.
A quick summary:
RunningAverageRssiFilter (Default): Takes the mean value of the last 20 seconds worth of RSSI measurements for a single beacon. For moving beacons, this means that the distance estimate will tell you where the beacon was (on average) over the last 20 seconds, which for beacons moving in a straight line be where it was 10 seconds ago. The default 20 second averaging interval is configurable. This is the default because it is similar to the way Apple CoreLocation works, so it is useful for cross-platform compatibility.
ArmaRssiFilter: The Autoregressive Moving Average algorithm statistically weights the more recent samples more heavily that the older samples, leading to less lag in the distance estimates. But its behavior can be a bit indeterminate and is subject to more varying performance in different radio conditions.
KalmanFilter: There is no implementation included in the library, although there is a feature request for one. In theory, a Kalman Filter uses a statistical predictive model to try to discern the difference between noise and signal, and filter out the noise. There are many variants of Kalman Filters, and different variants may be better or worse at reducing noise in specific conditions.

Room entry/exit detection using iBeacon RSSI

I'm detecting if a person enters or exits a room using iBeacon. The implementation is as follows:
1. Two beacons are placed per room. One in the door and the other is inside near the door.
2. To detect entry, the user must pass the door beacon then the one inside the room. For exit, it's the other way around.
Issue:
In case that there are rooms that are too adjacent with each other, an overlap will occur causing an error in the detection
Planned Solution:
Use RSSI to detect which one is the last nearest beacon when the inside room is detected. I'm thinking of checking the skewness of the distribution of the RSSI on a given time, say around 1 to 2 seconds since the user detected an inside beacon.
Is there other statistical analysis or any data analysis that can be used to determine or check with a probability which room the user entered?

Unless the rooms are very large (which it sounds like they are not based on the troubles you are having) I think any technique you find will have a high error rate. You might be able to get this error rate down far enough to be acceptable by recognizing cases where you simply cannot make a determination and refusing to do so in these cases to avoid false determinations.
Your best bet is to sample multiple RSSI measurements from different beacon packets (a minimum of 10 to filter out noise), then average them, perhaps throwing out the highest and lowest value before doing so. If this average RSSI is strong enough, say < -80 dB (and it is the strongest signal you have seen from all beacons) there is a high probability you are in the room indicated by the beacon.
The RSSI may drop off if you go far away from the beacon in the room so just because the criteria above are not met does not mean you are not in the room.
Keep in mind that it is impossible to determine which beacon is closest if all signals are weak -- noise becomes more important than signal. So make no conclusions unless one beacon has RSSI stronger than, say -85 dBm.
Make sure your beacons are transmitting as strongly as possible and advertising as often as possible. The latter will ensure that you get enough RSSI samples in a short time.
Finally, keep in mind that different Android phones have different Bluetooth antennas and receive the same beacon packets more or less strongly. A Huawei P9 Lite detects BLE signals at an RSSI 20 dB weaker than a similarly placed Moto G4+. Regardless of this, phones typically do not detect beacon signals weaker that -100 dBm and below -90 dBm the measurement is so weak as to become almost useless for relative distance determination.

iBeacon Accuracy While Android Device In Motion

I am testing out a positioning system using iBeacon and Altbeacon. I have found that my triangulation results are actually pretty accurate, but sometimes it takes upwards of 5 seconds to see the proper results.
For example, say I am currently standing at Point A. Altbeacon + my triangulation has me properly placed very close to Point A. However, when I move 5 meters away to Point B, I remain around Point A for around 6 seconds and all of the sudden I snap into place right near Point B. Is this an issue with Altbeacon, or possibly the communication between my iBeacons and my Android tablet?
Note: I am using a Kindle Fire 10, running FireOS 5.1.1 on top of Android. The Bluetooth iBeacon technology is BLE, and broadcasts at around 1Hz.

The issue of time lag that you describe may be caused by averaging intervals on the signal measurement. You do not say what scanning framework you are using, or if you are using raw RSSI or a distance estimate as input to your algorithm. The Android Beacon Library by default uses a 20 second averaging interval (configurable) for its distance estimates. Other framework's use similar averaging.
Reducing the averaging interval will lessen the lag, but increase the noise as an input to your algorithm.
EDIT: To reduce the distance estimate sampling interval to 3 seconds from the default 20 seconds, call:
RunningAverageRssiFilter.setSampleExpirationMilliseconds(3000l);

I have tried previously what you were trying to do. There was a lot of issues making it impossible to get correct triangulation results.
Theoretically it should work, but
Practically you will have a lot of challenges, like the fact the Bluetooth Beacon uses the 2.4GHz frequency, almost all Bluetooth Beacon has non-directional antenna, which means that you might risk not measuring the signal source but the reflection of the signal surrounded by the beacon.
The other fact is the noise from other sources or Bluetooth Beacon in your environment.
Depending on the Android phone model, the receiver antenna of Bluetooth is not necessarily mount same place in the phone, that means how you hold the phone will change the RSSI reading
Holding the phone in hand or near human body might also give different readings or no reading at all, since the human body contains water that is a signal reducer/killer for Bluetooth signal.
So even thus you improve your latency time of Bluetooth Beacon by software, you will still have these challenge make it almost impossible to get the right results.
I have seen a new directional Bluetooth Beacon I have not testing it yet, but it sounds like it solving some the mentioned issues.
It is correct what #davidgyoung wrote, but that won’t change the fact of real world scenario.
Btw, I have worked with Altbeacon a very nice and respected tool, and I used both RSSI and distance estimate with different type of Bluetooth Beacon and different phones and it did not help much, it is not Altbeacon the problem.
And regarding the university project I mentioned in my comments, we ended up using Bluetooth Beacon in different way to help us finding directions to target for visually impaired people, and we have developed scientific paper on it.
Finally for inspiration of what you are doing and what I mentioned in my answer, see this video it shows triangulation experiment, the provider of this video is btw also a user at Stackoverflow.
Note: my answer here is focusing on the context of triangulation and the challenges here make it as not a sweet solution.

Find the nearest beacon

I am developing an application, that uses iBeacons. Its main feature is to detect the nearest beacon (distance does not matter, I need simply the nearest one) and present some content according to it.
On IOS it works like a charm, there is no question.
On Android I have strange experiences. I know, it is up to the hardware, bluetooth chip vendor etc. but even if a I tried a lot of things (averaging rssi, queing...), I can't make it stable. The beacons are some 3-5 meters away from each other, there are 8 pieces of them in a ~80 square meters room.
I use Android AltBeacon library. I can not detect the nearest beacon in a stable way: sometimes a Beacon, which is some 5 meters away from the device is 'nearer' by RSSI, than a beacon, which is right next to the device and so on. (beacons use the same TX power and advertising interval, altbeacon scanperiod is 250 msec)
What should I do to make it stable? What, when and how should I average rssi? Or should I do it at all? Or...?
Thank you very much!

The RSSI value will depend on a number of things beside the TX power, among them:
Multipath reflections: The 2.4 GHz will reflect from the walls, so if the reflection helps the distant beacon and attenuates the close beacon, then the distant beacon could get at stronger RSSI.
The placement of the antenna: Holding the phone the right way can make a big difference.
I can't say why iOS should work better then Android, but it could be that they have an averaging algorithm that works well. From my two points this is not a simple thing to get right.
To learn more about these issues I recommend reading Deploying iBeacon and Common Questions and Answers in Getting Started with iBeacon.