i am trying to estimate network delay between two android devices connected over WiFi to synchronize clocks. but the network delay is varying a lot from 2ms to 1024ms. sometimes i gets delay value which varies between 2-10ms for continuous 100 readings. but sometimes values ranges between 2ms to 1024ms for continuous 100 readings like 2, 100, 570, 640, 2, 5, 150.
I am using socket timestamps to determine the exact receive and send time of the packet. my setup uses one laptop as wifi access point and two mobile phones. There is not much load on the network. my question is why is it varies less sometime and why it varies so much sometimes.
How to make it vary less. am i missing any configuration on android. Give me some possible reasons for this kind of behavior...
Unlike wired links, wireless links are affected from a lot of different factors. You can get stable results only in a sterile environment without electromagnetic or mechanical interferences.
Most latency fluctuations are a direct result of RF collisions. WiFi networks implement the CSMA/CA protocol to deal with the collisions. In general it detects whether there is any activity in the air and postpones the transmission if it's noisy.
You can try to minimize the external influences but still this doesn't guarantee anything:
Perform WiFi scan and see what channels are the noisiest. Choose the less occupied for our link. Remember, there are overlaps between various channels, so moving to a different channel won't necessary remove all the noises. See here about channels overlapping and how to choose a channel: http://en.wikipedia.org/wiki/List_of_WLAN_channels .
Remove mechanical obstacles from your environment.
Increase the transmission (Tx) power of your devices from their SW configuration.
Check the Quality of Service (QoS) configuration of your devices, some tweaking there might yield improvements.
Solved this problem by using WIFI_MODE_FULL_HIGH_PERF.
After acquiring this lock, i have observed constant network delays.
http://developer.android.com/reference/android/net/wifi/WifiManager.html#WIFI_MODE_FULL_HIGH_PERF
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.
If an environment has many BLE devices (200 to 500) advertising within range of a mobile device that is scanning for BLE devices, will the mobile device be able to see all of the advertising BLE devices? Does anyone know of actual testing that has been done on this scenario and can provide results of the testing?
There is no simple answer I am afraid. Assuming all advertizing devices are within a range (i.e. good RSSI), there are many factors affecting reception including: duty cycle of the scanner and broadcast interval of the beacons; you could also choose to use certain channels for groups of advertizers etc. Say the scanner is running flat out (100% duty cycle) and you start from sporadic broadcasts on all channels, gradually increasing the rate at which adverts are broadcast. At some point, you will hit a sweet spot -- increasing advert rate beyond will result in more collisions and poorer detection performance. (It's like being in a room full of people, all talking over each other, all repeating the same utterance over and over again.) The question is not so much "how many advertizers?" one can have but rather "how reliably can the advertizers be heard within a certain timeframe?" e.g. under which conditions can one detect an advertizer with 95% probability within 5 seconds.
If you can deploy multiple scanners (especially if they are spatially separated), then you will gain by collating their output. Based on one particular experiment I carried out using two scanners: 4% adverts were received only by scanner #1, 2% only by scanner #2, and 4% were not received at all. So #1 scanner alone received 94%, #2 alone 92%, but together they received 96% of the adverts.
Here is some related work I found Bluetooth beacon density maximum.
I noticed that the signal strength of Bluetooth Low Energy received on Androids is varying in cycles.
The graph below represents the RSSI values of one BLE beacon over two minutes. The receiving Android and the beacon were both static with a distance of 1 meter. I made sure that there is as low interference as possible. The Android was a Nexus 5, but I had the same phenomenon with other Android devices, all running on API 21. I could not test it on iOS yet.
RSSI Graph
You can see that there are 3 major levels for the RSSI repeating every 15 seconds, like low -> middle -> high -> low -> middle -> high etc.
My guess is that the reason lies on the android side, not sure whether it is because of hardware or software reasons.
Why is the RSSI cyclic over time? Can someone explain?
After reading a lot into the topic now, I might have come to an answer.
Bluetooth Low Energy beacons use three different channels for advertising, which is their adaption of frequency hopping to avoid interference with other 2.4GHz signals. This happens much slower than for normal Bluetooth (1600/s) - according to my measurements around every 5 seconds.
More here:
http://www.argenox.com/bluetooth-low-energy-ble-v4-0-development/library/a-ble-advertising-primer/
The received signal strength depends obviously on the frequency, so if the frequency changes to another channel, the RSSI is different. How to deal with that is now a different question.
UPDATE:
After following up on this issue, I have to update my remarks:
It is very likely that the three levels with each one around 5s are not directly due to the beacons slow frequency hopping, but to the android devices scanning seperately on the channels and switching to the next after such a time interval.
A way to overcome this behavior is starting and stopping the scan process in a loop, so that a scan lasts clearly less than 5s. When starting the scan, the device seems to begin scanning always on the same channel and the scan is restarted before it can switch to a different channel. With the restarts, the pattern is not detectable anymore - to the disadvantage that the channel is "fixed" and may suffer interference on this frequency.
Thanks to Airsource Ltd for bringing me back to this question.
As per Android AOSP - Definition of scan interval and scan window in android source code the scan interval in any scanning mode is 5000ms.
I would assume that your graph was generated via an application that used continuous scanning - i.e. scan window of 5000ms, which is basically continuous.
The scanner will rotate between channels 37,38,39 after every scan interval, which accounts for the differences you observe. Channels 37,38,39 are not contiguous in the BLE spectrum - 37 is at 2402Mz whereas 39 is at 2480Mz. The difference in wave length means that the multi path (interference from reflections) fade will be different for each channel http://www.cl.cam.ac.uk/~rmf25/papers/BLE.pdf - you say that the devices were static, so provided that nothing else was moving, the interference will also be static.
On iOS, the scan interval (foreground) is reportedly 40ms which means that you should not experience this precise effect.
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.
I'm looking for a list of all the components and their power drainage on an up-to-date smart phone.
Accelerometer, gyroscope, magnetometer, etc.
Display
WiFi
Bluetooth
GPS
CPU
Camera
Microphone
etc.
Preferably in mA so it can be easily compared to the battery's capacity (usually specified in mAh).
The Sensor's power is actually available via the SDK and can also easily figured out for most devices on AndroidFragmentation. However what I'm looking for is comparable data for the other hardware components to consider their efficency.
Bonus: Will a request for less frequent updates of a Sensor decrease energy consumption of the Sensor, as it returns only one value for getPower()?
There are a couple of detailed studies that I am able to find on this.
A study from the USENIX meeting in 2010 which studies various components of a smartphone (except the camera)
Another study from the Hotmobile mobile computing workshop 2013 that has more information on cameras and displays.
Reference 1 especially seems a great starting point.
I'm looking for a list of all the components and their power drainage on an up-to-date smart phone.
That is impossible to answer.
First, different devices will use different varieties of these components, with different power characteristics.
Second, many, if not most, of those components will have no published power statistics, or the specific components themselves may not be knowable without a complete teardown of a device.
Will a request for less frequent updates of a Sensor decrease energy consumption of the Sensor, as it returns only one value for getPower()?
That will depend on the sensor. Some sensors are effectively always "on" (e.g., ambient light sensor), courtesy of the OS, in which case the only incremental power drain for your use of that sensor will be in passing that sensor data to your process. Other sensors might not be regularly used by the OS, meaning that your request for events from that sensor might turn it "on", resulting in power drain from the sensor itself in addition to supplying you with that data.
It would be truly wonderful if all Android devices were instrumented in the way the Qualcomm MDP is, so that we could get fine-grained power detail for our apps and their usage of various components.
There was a Google I/O session on this very subject a few years ago; you can see the video here and slides pdf here.
I know it's against the rules to plug your own startup, but what you're asking sounds exactly like what we're working on.
There's an Android performance monitoring tool called "Little Eye Labs". It shows real-time power consumption of an App as it runs on a phone. It currently only supports CPU, Display, GPS, Wifi and 3G, but you'll be able to get the instantaneous power consumed (in mW) by these components.
/end of plug
Note that there's no real way to get this information directly from a device, so the best you can do is model the phone, gather device resource consumption, and model power usage.
Display is the most power consuming part of the smartphones; accounting for up to 60% of total battery life (Can draw power up to 2W). There is a book called Green IT and its Applications; you can read it online in Google books.
On any modern Android, go to Settings > Battery (sometimes Settings > About > Battery). You should see a graph of power drain over time, as well as how much was used by what component.
Although consumption varies a lot based on usage patterns, in my experience the top consumers are display, radio, and CPU. I have not seen sensors rank high in energy use on any of my devices, in the absence of bugs. The link provided by Yusuf X places game sensors above CPU.
For more information about optimizing battery use on Android, see Reducing the battery impact of apps that downloads content over a smartphone radio and Optimizing Battery Life.
There is an app called PowerTutor that it does some battery consumption measurements for every phone component and for every process. The code is open so you can pick up some ideas from there. Note that this app was optimized for Google's phone, especially for the Nexus One.