In most (more likely all) Mediatek mtk6592 phones (and also older models), There is a bug related to GPS UTC time.
the bug causes the GPS to report WRONG UTC time by an offset of exactly 1 hour.
That means that the sky view (which is the number and position of satellites currently visible) is shifted by one hour and that means that the phone is trying to connect to satellites that aren't there and even worst, it IGNORES satellites that are there!
Fixing this small issue will improve GPS in all Mediatek phones.
BTW, I discovered this bug and informed Mediatek but got no reply to date.
The question is whether Android can be fixed to insert a 1 hour shift to the GPS UTC time a thus fixing the problem.
I doubt that your information is correct!
The GPS chip receives the time from the satellites in GPS Time base, which is some seconds differet from UTC (about 17 or 18s), then after some minutes the sattelites also send the GPS time to UTC offset, for better display to the end user.
I am very sure that the chip does his work correct, otherwise nothing would work.
The time has to be correct to about nanos seconds!
If there is realy an UTC time offset, then it is in the phone or software API.
But this has nothing to do with the quality of the location, because again:
inside the GPS chip everything will work!
Probably there is an internal API like in iOS and android that replaces the location timestamps received from the GPS chip, to match the current time zone, and to match the offset from the phone time to the real time (by GPS UTC) (if the user has manualy set the time).
And this internal time replacement might fail.
Event if there would be a bug in the chip, under no circumstances you could externaly correct that time bug! GPS chips allow to set the current time, but this feature is for faster speed up of initial time calculation. In practise this does only work if the time set is extremly precise.
Related
People! I thought to include it in original question but didn't.
WHILE VOTING, YOU ARE ALLOWED TO COMMENT WHY DID YOU VOTE?
Please use it to enable learners get theirs things done and convey their thoughts/issues to others better way. Not everyone knows what you think. Thanks
In Short:
I need to synchronize clocks of two Android Phones (placed close to each other OR not; both cases) with each other AND with up to an accuracy of a few milliseconds (10, 20 ms max).
Either sync the clocks
Or get an offset of one from the other
What I am Doing:
I have a developed app that I am using to measure different GSM network statistics. I am using telephony manager to get three states (OFF-HOOK, IDLE, RINGING). Phone A calls phone B. Both phones are running an app that is saving the time-stamps with regards to the states mentioned above. After making many calls I export the time-stamps in a data file and analyze them to get different network stats.
What is my Issue:
I have to cross-match the time-stamps to get stats. Now the problem is that if the phones' clocks are not synced then I will not be able to get exact stats (e.g. how much time it takes to get phone B in ringing state after phone A initiates a call?).
What I have Tried: So far I have tried to sync clocks with NTP, GPS or atomic clock. I have used ClockSync (Android app) to get offset of both phone clocks from atomic clock. The issue is that this offset depends on RTT of network packets from my phone to server. I gives my difference of up to 100 ms when I check offset two times (tap refresh two times consecutively). The offsets at both phones can lead to error of up to 200 ms which is unacceptable for me.
All other syncing apps/methods have same issue.
Possible way forward: (What I think). I may develop an app that
takes the time-stamp at phone A
transfers that to phone B via Bluetooth or WiFi (connected to same router),
B then compares that time-stamp with its own clock, calculates offset,
And I run my original app, run experiments and,
Use the offset to correct time-stamps before processing data
Your Comments/Suggestions: How to do it? And comments on the method described in last part..
I am writing my Master thesis atm and analyzed about 400 different GPS-Trajectories (paths consisting of a list of longitude/latitude points and an according timestamp) recorded with the MediaQ-App (probably not important) for Android (about 310 trajectories) and iOS (about 90).
When analyzing the time intervals between the timestamps, I was expecting the inaccuracies around the 1 second frequency, in which the timestamps were supposed to be recorded, since neither Android or iOs are real-Time-OS from apps point of view. Still, why are there, what appears to be local peaks in about 200ms steps? Be nice, I do not know a lot about mobile operating systems :-)
(x-axis: seconds, y-axis: the relative probability that a timestamp will be recorded at this point in time. Ignore the exact values of the y-axis...)
The usual behavior is that an App takes the timestamp direct from the location delivered by the system. Most probably this is the case in that App, otheriwse this would be a heavy programming bug. (The delay between nominal GPS time and receiving system time of about 200ms is plausible, I saw that in my app, and in ios Map app, which makes a correction in their map api to extrapolate the location into the future, to try to compensate that delay)
Under android (and ios) it is import to know whether the location are determined exclusively by GPS. On both plattforms (ios, android) an App can set whether GPS only or combined GPS + WLAN + Cell Locationing is used.
For high quality recording is is highly recomended to use GPS only.
A GPS chip once having a location usually outputs a location with a timestamp exactly at 000. Exception can happen before the location is valid.
Under ios if the location was obtained by GPS the millisecond are always 0.
I have no experience with android, but usually the GPS chip itself sets the value to millis = 0. (However, some android phones are known to use a crippled cheap GPS chips, that are not able to get an intial position without the help of an internet conection)
It is possible to determine whether the location was obtained by GPS by looking at the course (or called heading) and speed value, which are invalid for non GPS locations (cell Tower locationing)
To know whether this time variations come from the Application (not using the GPS only mode) or if it is caused by Android, you can test that with another application on the same phone. (E.g Motion-X GPS) (Or by comparing both apps on another android phone)
I implemented the new LocationClient into my app, but doing a test run I noticed the readings are incorrect.
I was driving outside without GPS. WLAN on. Thus location accuracy can only be what used to be NETWORK.
I set the LocationClient to LocationRequest.PRIORITY_BALANCED_POWER_ACCURACY; and update interval to 15 sec.
When I get the data I evaluate the Location with getAccuracy() and getTime(). Both values can not be trusted.
I get an accuracy of 25 to 50m, sometimes up to 100 meters, typical for WIFI locations. However, once I left home, the location reported (with getAccuray() < 100) had nothing much to do with my current location (actual accuracy >800m). It resembled best the cell tower location. Location was never updated in the hour I was traveling, thus always pointing to the same cell tower (incidently I always was in that area although traveling about 3 km).
Doing further tests I noticed that location and accuracy did not change for at least a minute after I turned wifi off. I was walking, so accelerator should be triggered. Again, location was way off to where I was, but accuracy still reported < 30m. After about 1-2 Minutes, the location was then reported with accuracy >800 m which was correct.
I can live with bad accuracy, but I need to know that.
Time is always updated to latest time also while the actual reading is older. This also seems a bug, someone already raised an issue at google for that.
Summarized it means I can not use that functionality. I get old readings reported as current and accuracy which does not match the reading.
Test where done on a Nexus 4. Phone was connected to an UMTS (3G) cell.
Are these known issues? Is there a way to work around it (getting the correct accuracy), or do I have to use the "old" LocationManager?
Even if I set requestLocationUpdates to 0 seconds and 0 meters, the GPS sensor data updates only about every second. I need the satellites SNR data more fequently; 10/s would be nice. Is there any possibility?
If you have direct access to the GPS chip, you can set the message interval for each message. On a smartphone you cannot set that message interval.
However for consumer GPS devices the maxmimum GPS message frequency is either 1/s or 2 messages per second.
So probably, as long as you don't use an specialized GPS chip with e.g 10/s msg frequency,
it does not make much sense, to raise from 1/s to 2/s.
No, the update frequency of the device is limited by the GPS hardware itself, usually to about 1hz. Android hardware seems to be mostly concerned with battery life being one reason. Also, most GPS hardware that produces an output frequency that is greater than 1hz is cheating somewhere in the background and interpolating points, which you can do in code if you want more points. This is because, in general, producing a higher output frequency means a sample of fewer points which means reduced accuracy. There are really no "easy" solutions around this problem. If you need more data and more accuracy you are looking at sensor fusions and and probably some sort of Bayesian filtering.
You set that when you start listening to the GPS. You pass it as a parameter.
requestLocationUpdates(Provider, TIME_INTERVAL, DISTANCE_INTERVAL, LISTENER)
TIME_INTERVAL is in milliseconds.
How would I verify/ track device location within a 5' accuracy? I've heard of people using cell towers/ gps combinations.
As far as I know, the only way to get a 5 feet accuracy figure is to use GPS, then it still isn't always that accurate depending on how good a fix of the satellites (clear view to the sky) you have.
Cell tower / Wifi triangulation methods only serve to speed up positioning and will seldom (if ever) be more accurate than satellite positioning methods.
GPS is the way to go. Cell towers won't cut it. In Android (and I believe iOS) the system will provide you with an accuracy reading in addition to the actual location. You could use this value to determine whether the value you've received should be uploaded to your server. Keep in mind using the GPS is very battery intensive and there's no guarantee of how good the accuracy will be. Depending on conditions you may not be able to achieve 5' precision.
As #CommonsWare points out, 5' is really unrealistic anyway although you can get close.
As CommonsWare says you will not get much better that 10 metters accuracy in a consummer-grade device. Even in open sky, the atmosphere characteristcs change minute by minute and thats enough to change the GPS readings.
However, it's teoreticaly possible to increase accuracy if you could get all of the following:
1-There are some stationary GPS receiver stations with fixed known locations which measure the current GPS signals deviation. You would need to have one of those close to you and have access to the data in real time.
2-You would need to have low level access to your phone GPS receiver to read the unprocessed data received from sattelites. This would be different from device to device, and as far as I know, no supplier is providing this access.
3-Finnaly, you would need to do all the calculations required to determine your location applying the deviations got from point 1 above.
good luck.
The only way you can get this type of accuracy is with WAAS. As far as I know, there are no Android handsets that can receive WAAS corrections. If this is for a specific controlled situation, you could use a bluetooth gps receiver with WAAS, and only in WAAS supported locations. However, if this was for a wider deployment, then I think you are out of luck.