I am building an application that requires to check when is a certain device very close to another device (by very close i mean 5-10 meters). I think it could be possible using bluetooth RSSI. A lot of people suggest the use of sound analysis, but this won't be possible because i am planning to use many systems like this in the same place, so that will mess up a bit. Any suggestions?
Accuracy requirements rules GPS out - so your only option is to measure delays in signal propagation of devices. I would say that network / bluetooth is not suitable for this due to speed of light and network stack delays which are not predictable. This means that yout only option will be sound. 5-10 meter means 10-20 msec delay at speed of sound so this should be sufficient, buit will be tricky to imlpement.
To work with multiple devices you will have to implement some protocol like CSMACD and kind of time synchronisation between devices - this is possible but tricky ( you will have to look up how time is synchronized via satellites for radioastronomy )
I recommend using RSSI :-). This makes sense if you want to measure the distance b/w 5-10 meters.
Related
In my app,I use ble(Bluetooth Low Energy) to scan and connect to a nearest bluetooth device(There exists two similar bluetooth devices nearby).I use RSSI to make sure which is nearest and in most cases,it works fine.But I find it not 100% correct when the distances are short.During my test,one is 2 meters away from me and the other is 3 meters,and the RSSI of the farther one comes to be bigger,about 1 in 10 times.Is there any better idea to replace RSSI?
Your problem is very well known and it appears in any localization algorithm using ble beacons. Even if two devices are very close together, they may have different RSSI value due to the Fast fading effect.
The Fast fading originates due to effects of constructive and destructive interference patterns which is caused due to multipath.
To mitigate this problem, you can :
Compare the RSSI during a longer time. Especially if things are moving around, the radio-waves may interfere in a different way. If your receiver is a smartphone for example, the user is not static and a few more RSSI sample will give you a more accurate results.
Add spacial diversity. This can be done by adding another chip with another antenna that will also advertise. If the two antenna are not at the same place, you will have more RSSI data, coming from different path that will interfere in a different way. By doing the mean of the two value you should have better result (ideally combine with a longer acquisition time). But of course it is only possible if you are designing the hardware of the advertising device. Note that this can also allow your reciever to catch more adv for the same time-frame.
Frequency diversity. Make sure your advertiser is configured to use the 3 adv channels.
And of course if the two distances are very different the slow fading will be greater than any fast fading effect and you should not have any trouble.
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 have created an app which consuming 48 percent of battery in some device which is highest in power management task, but in some device its 5-6 %, i am running a service in background all the time which fetches the latitude and longitude and send it on server if user is logged in. but i have checked also check by logging out from app it still consumes 48 percent.
to fetch latitude and longitude o am using fused location api.
So please tell me how to resolve this issue of battery consumption in some phone and how to check which process and service is draining battery.
I agree with Lonni that the issue is the lat/long fetch. Given the scale of the power consumed, 48%, it's unlikely to be the GPS circuitry itself. I figure it's the CPU. Mobile processors are very power efficient unless they are kept active. Let me explain. An active proessor is the most power hungry device on a mobile device. So how can a processor be the biggest power hog while also being "power efficient"? By the processor being "power efficient", I mean that when the processor isn't doing anything, it goes into a very efficient lower power state where its power consumption can be over an order of magnitude less than when in the active state.
My guess is that you are keeping the processor in an active state. What you want is to keep the processor as idle as possible.
Here are my recommendations:
Use the longest interval possible between lat/long fetch. A common mistake is that more checks mean better response, but unnecessary checks generally don't improve response and just keep the processor active and consuming power for no good reason.
Never poll! Polling keeps the processor active which consumes power for no good reason. Put the processor to sleep.
Use interrupts to processes events. System libraries, such as sleep(), put the processor in an inactive state, and uses an interrupt to wake the processor back up.
Don't write your own routine if a library routine already exists. The OS/library writers are very aware of the importance of power efficiency and have written their code to be as efficient as possible.
Make your code run as fast as possible. Fast means more idle time, which drops the processor into a more efficient power state. For example, if you can get along with a lat/long check every 60 sec, and you can get your processing done in 10 sec instead of 30, you have 50 sec of idle vs 30 sec.
Use a good optimizing compiler and good optimized mobile libraries if possible. Good compilers create more efficient, faster running code. Good libraries not only run faster, they use power efficient techniques.
Use a thread pool if you are using a lot of threads. Creating and tearing down threads is costly.
Make sure you check your API specs on your devices. I can imagine that some OSs/drivers, e.g. GPS, will require the device to be explicitly turned off, while others will do so implicitly.
Here's some more information: Battery-safe coding
Aside: I already see the thought bubble: "Why are some devices using less power than others?" Some libraries are really smart, and anticipate bad programming practices and do workarounds. Others are dumb. The same with the OS, system libraries and thread scheduling.
My best guess is that the constant fetching of long and lat is draining the battery. If i remember correctly what I did a few years ago with positioning that was the case.
I would say that you should try and see the refresh-rate you want to have of your coordinates. Maybe it doesn't need to be refreshed more than 5 times per minutes. In that case you would save a lot of calls to the fetching of the coordinates and surely save your battery.
As for why it is different on some devices, I'm afraid I have no idea. Maybe the version of android used?
Edit: I don't know if Eclipse can do that and I don't think it can.
However, you may want to check this paper: http://www.usenix.org/event/usenix10/tech/full_papers/Carroll.pdf
The Google Fit app, when installed, measures the duration you are walking or running, and also the number of steps all the time. However, strangely, using it does not seem to drain the battery. Other apps like Moves which seems to record number of steps pretty accurately declares that it uses a lot of power because of it constantly monitoring the GPS and the accelerometer.
I imagine several possibilities:
Wakes up the phone every minute or so, then analyses the sensors for a few seconds and then sleeps again. However it seems that the records are pretty accurate to the minute, so the waking up must be frequent.
Actually turns on the accelerometer all the time, and analyzes it only after the accelerometer measurement data buffer is full. However I think the accelerometer has a small buffer to store the latest measurements.
Use GPS to estimate the number of steps instead of actually counting it. However this should not be the case, since it works even indoors.
The app still feels magical. Counting steps the whole time without perceptible battery drain.
Thanks for asking this question!
Battery is one of our top most concerns and we work hard to optimize Google Fit's battery usage and provide a magical experience.
Google Fit uses a mix of sensors(Accelerometer, Step counter, Significant Motion counter), Machine Learning and heuristics to get the data right. Our algorithm is pretty similar to your 1st option plus a little bit of magic.
We periodically poll accelerometer and use Machine Learning and heuristics to correctly identify the activity and duration.
For devices with hardware step counters, we use these step counters to monitor step counts. For older devices, we use the activity detected to predict the right number of steps.
Our algorithms merge these activities, steps and sometimes location to correlate and further increase accuracy.
We do not poll GPS to estimate steps or detect activities.
-- Engineer on Google Fit Team.
On some very recent phones like the Nexus 5 (released in late 2013 with Android 4.4 KitKat), there is a dedicated low-power CPU core that can serve as a pedometer. Since this core consumes very little power and can compute steps by itself without the need for the entire CPU or the GPS, overall battery use is reduced greatly. On the recent iPhones, there is a similar microcontroller called the M7 coprocessor in the iPhone 5s and the M8 in the iPhone 6.
More information here:
https://developer.android.com/about/versions/kitkat.html
http://nexus5.wonderhowto.com/how-to/your-nexus-5-has-real-pedometer-built-in-heres-you-use-0151267/
http://www.androidbeat.com/2014/01/pedometer-nexus5-hardware-count-steps-walked/
having a 3 year old HTC OneX I can say that THERE IS NO DEDICATED HARDWARE, Google Fit just uses standard sensors in a very clever way. I come from Runtastic Pedometer: there is a clear battery consume when in use, it would be impossible to keep it on all the time as it needs the full accelerometer power. On the other side, if you stand still and shake the phone Runtastic will count the shakes, while Google Fit apparently does nothing... Still it works perfectly when you actually walk or run. Magic.
Google fit try to learn use pedo step pattern and try to create its own personal walking patterns and its clusters. This eliminates the need of having huge mathematics calculations on receiving sensor data every time. This makes Google fit more power efficient compared other software pedo apps. Having said that, there is compromise on accuracy factors here. Between power-accuracy trade off, google seems to be more aligned towards power factor here.
At this moment the most power efficient detection happens Samsung flagship & its other high end models. Thanks to Samsung's dedicated hardware chip! No matter how power efficient your software pedo algorithm be but its hard to beat dedicated hardware unit advantage. I also heard about Google's bringing dedicated hardware unit for Ped upcoming nexus devices.
It would seem like the solution would be device dependent, with devices where a co-motion processor or "wimpier" core is available for low power operations, that it would default to this once the buffer is full or similar condition. With devices where a low-power core is not available, it seems like waking the device could trigger a JIT operation that would/should finish by the time the app is called.
While the Nexus 5 does have a dedicated "low-power" pedometer built in. It isn't as "low power" as you might think.
My Nexus 5 battery life was decreased by about 25% when I had Google Fit Activity Detection switched on.
Also, the pedometer doesn't show up in the battery usage stats. Presumably, because it is a hardware thing.
I don't know for the other phones out there, but Google Fit was really draining my battery life on my Nexus 5. Disabling it definitely improved my battery life.
I want to calculate distance Bluetooth Paired device from android mobile. I am new in Android Bluetooth Concept can any one suggest me it's possible or not possible in android sdk.if it's possible post any code or tutorial link!
The Bluetooth signal strength distance relation depends on the devices (built-in Bluetooth device, antenna, actual orientation of device), current way the persons hold their devices, objects in-between... You could measure this for a pair of devices for a given situation and use these information.
A larger and more general solution would incorporate an external Bluetooth network. Bluetooth triangulation is the basic concept, that will help. The link will give an insight on certainties that are achievable with such a setup. Take is as an upper limit, a device to device approach will be worse.
The EE Stack Exchange site has a more complete answer which includes a mention of Apple using 802.11v for determining if Apple Watch is close to a MacBook.
Bluetooth uses radio, and radio travels at the speed of light. A 1cm round trip will take less than 100ps. Timing something that short will be tricky, probably you'll want a 10GHz clock, though there are other options. But even then, Bluetooth isn't designed to instantly echo the radio message. If you receive, process and re-transmit the message, then the processing delay will be much longer than the time of flight, and will vary randomly by at least the period of the clock used with the Bluetooth chip.
You can't. Maybe, you can get approximate value from signal indicator but it's too much subject because of envirounment - is there something between connected devices, some reflection surfaces, etc.
There is a way you can research, is coding a response time. just calculate the bluethooth response time in nano secs, physically measure the distance between the devices and make a tree rule... is the same concept of GPS. This is a Laboratory work. I have a project that i have to develop it, in schedule i will taking it in a month.
OFC, its possible. It just requires ultra precise app, build to calculate "pings" between the two objects - kinda like ekko-location or laser distance measurement - its about how much time a specific signal travels back and forth.