Well for triangulation you need to have the direction from which your device is receiving the signal.We can calculate Angle of Arrival for that but calculating that angle requires an array of receivers. Is a cell phone capable of calculating Angle of Arrival? I am asking this because I have came across the terms like wifi/BLE triangulation, calculating position by triangulation etc but they're actually referring to Trilateration in most of the cases. I know how trilateration works for a mobile and all the details but I don't think Triangulation is possible. And if it is possible, how is it possible and which one (triangulation or trilateration) is expected to give better result if you use ibeacons to approximate positions?
Lot of people are misleading terms as you pointed out. Triangulation is not possible with standard ble beacons or WiFi (I mean without modify the standard ble 4.0 or 4.1 and WiFi) right now because the standard doesn't report useful information like the phase (if you have phase and an array of directional antennas that are powered on one per time at a predetermined frequency you can use algorithms like MUSIC and deal with angles) but we only have Rssi and TX power at one meter(if it's an iBeacon) with those information we can estimate the distance that is very imprecise and fluctuate rapidly over time because of multipath and diffraction.
In Nextome we have invented an algorithm to mitigate multipath fading that causes signal to bounce and achieve high accuracy Indoor Positioning of about 1 meter without fingerprinting.
No one has tested triangulation with standard iBeacons right now but trilateration. I would start looking at least square approximation to solve the trilateration problems, but don't expect big results without filtering out the noise.
Mobile mast triangulation usually uses the power level to estimate how far a phone is from a particular cell tower. At any given time a phone will generally be in touch with several towers, even though it is only using one at a time for calls etc.
If you have an estimate of the distance from two or more towers you can imagine drawing a circle around each tower with the radius equal to this distance.
Where the circles intersect is the 'likely' position(s) of the mobile device.
WiFi estimation works on roughly the same principles but is much more accurate as there are so many more WiFi networks.
The big data aggregators (Goggle, Apple etc and their partners) receive data from millions of phones which allows them accurately locate where a particular WiFi network is located. When you then ask your phone to check you position they are able to see what WiFi networks you are close to and vey accurately narrow down your position, especially in a built up area with many WiFi networks.
Most phone positioning systems will use a mix of technologies, GPS, cell strangulation, WiFi to help narrow down your location.
Of course if you are on top of a mountain or in desert the options are a bit more limited, and GPS becomes more important...
Related
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.
I'm using my iPhone as an iBeacon device, and on the other side I have an Android 4.4.2 device scanning for the Bluetooth LE iBeacon signal from the iPhone. I searched for a good and easy way to calculate the distance between iBeacons and my Android phone, but I couldn't find anything that can help me with this.
Could you help me on this matter?
It's impossible to measure beacon distance accurately, I'm afraid, which is why Apple's own code just says "Immediate", "Near", "Far" and "Unknown". The best you can do is set up a reconstruction of the conditions you expect then do trial and error tests to map signal strength to probable distance. Trust me: I've spent a lot of time trying to do beacon distance measurement using a range of hardware.
Remember that the LE in Bluetooth LE means "Low Energy" – this stuff really is designed to use as little power as possible. That means the signal from iBeacons gets interrupted by people, walls and other objects. So, if I'm holding a beacon in my hand and put my phone next to it, I'll get a strong signal. If I move the beacon behind my back, the signal strength will collapse. If I just turn around, that has the same effect (for the same reason).
If you want to go down the "best you can do" approach, you effectively have to recreate at least partially the environment where your app will be used. So, if your app will be used in an office, find an office and place some beacons around there. Same for being in a shop.
Then get your app out and measure beacon strength at various distances to the beacon, potentially with obstacles in the way. With some averaging, you end up with something like "at 1 metre my signal strength was X, at 5 metres it was Y, at 10 metres it was Z", etc, and you then feed that into your distance calculation. It is, effectively, an educated guess.
If you find any library that claims to do beacon distancing for you, it just means they've taken their own educated guess based on their own signal strength testing.
One tip: if you're able to, stick your beacons to the ceiling. This minimises the chance of obstacles (read: people) getting between your beacon and your app.
We built a distance estimation formula into the Android Beacon Library of the form: d=A*(r/t)^B+C, where d is the distance in meters, r is the RSSI measured by the device and t is the reference RSSI at 1 meter. A, B, and C are constants. You can read more about it here. To use it with the library, you range for a beacon and then simply call:
beacon.getDistance();
This returns a distance estimate in meters. The library code is open source, so if you don't want to use the library you can copy the formula and use it directly.
As #TwoStraws notes, distance estimates are pretty rough guesses of how far a beacon is away, and the results you get vary with lots of factors:
The gain of the antenna on the receiving device. (Every Android device model is slightly different)
The noise on the A/D converter inside the phone that measures bluetooth signal strength.
The radio noise in the room.
Any obstructions between the transmitter and receiver.
Any surfaces (especially metal) that reflect radio signals.
Just be sure you set your expectations properly. Distance estimates are good for deciding if a beacon is close or far, or whether one beacon is closer than another. But they are less useful for measuring absolute distance.
I'd like to know if iBeacons require a calibration phase (i.e, like Wi-Fi fingerprinting).
When trying to measure location based on Wi-Fi signal strength there's a need to do an arbitrary prior scan at the location you want to map.
I'd like to know if Iphone/Android already gets a fair coordinate based on ibeacons signal without a map phase.
If you want accurate distance estimates, then yes, it requires calibration.
However, it is not as temperamental as the wifi calibration. And often you can use the default calibration that comes with the particular iBeacon hardware.
For example my company, Radius Networks, makes a number of iBeacon hardware solutions and those are calibrated here in our lab. While environmental changes will effect that setting it often doesn't change things too drastically. For the most part the factory setting will be just fine for many use cases.
Obviously this is not the case if there is some drastic interference, such as installing the iBeacon behind a metal wall, or in a room that will be very crowded (people are notorious for absorbing RF). In those cases it would be best to recalibrate the beacon.
One difference to note about beacon calibration vs. something like wifi calibration, is that the beacon is configured to broadcast a calibration value. That value represents the expected RSSI that a phone will see at 1 meter away. That is then used to interpolate the distance estimate.
I was attempting to map out the signal strength of a wireless network from a very sparse set of data, and was wondering if it was even mathematically possible to do this.
Imagine that we had some application installed on mobile phones, and that each mobile phone was uploading their location and their signal strength to some central database. The goal would be to take this very sparse graph and attempt to map out the signal strength and then be able to guess at the useful range of the wireless network in two or three dimensions. I think we should also imagine that no one is standing directly next to the access point, so the center would be unknown. Very roughly what density of points would we require before we could generate a useful mesh of the wireless network from which to draw a polygon?
You can expect a wireless network strength measured in DBM to scale inversely and linearly with distance. I was wondering if this could be used to help generate additional points for a Delaunay transformation?
You can expect a wireless network strength measured in DBM to scale inversely and linearly with distance
Actually, you can't expect wireless strength to be proportional to distance in any situation outside of an RF test range. Especially indoors, with 2.4G RF you'll have multipath fading and shadow fading to deal with.
a bit of info here.
http://en.wikipedia.org/wiki/Fading
In my project, I want to detect if a user is moving or not by using either wifi rssi or accelerometer sensor.
What I should do to achieve that?
It actually all depends on what kind of movement you want to detect.
WiFi RSSIs : From a starting position and scan results (initial RSSIs for newly discovered access points), you can check through time their evolution in term of signal quality. A short displacement of the user will not be easy to find as RSSI values are tweaked by a large amount of parameters (orientation, obstacles, setup of the room, atmospheric conditions, people around). Thus you would need averaged values (scans must then be performed quickly to have enough data) and leaving an access point perimeter would make you lose the information.
Accelerometer : Depends on what quality of sensor you are using. If you're using embedded sensors within smartphones, it will be tough. Their accuracy is bad, and as you'll need to integrate its values (m/s² to get m/s) the error will grow subsequently. Plus it might be hard to discern real user movement from the device's tilt if you're using a mobile phone or tablet.
Without really knowing the details of your projet, I believe that RSSIs should be easier to use if you actually need to detect not so tiny motion. If you want something more precise, you'll need some way bigger research work.
See Android accelerometer accuracy (Inertial navigation) for RSSI-based indoor localization.