How can I determine the GPS signal which GPS systems comes from?
How can I differentiate between Navstar, Glonass and BeiDou GPS systems when I received a signal?
As I known there is a way to differentiation, which based on the PRN number of GpsStatus if this value is greater or equals than 200, the GPS system is BeiDou, if this value in range 65 and 88 is it Glonass. (The Navstar PRN range is 1-32 maybe.)
What is the upper limit of BeiDou PRN range?
Is there another way to determinate which GPS system signal received?
Thanks in advance.
BeiDou in its final configuration will consist of 35 satellites, 5 geostationary and 30 MEO (source). Some practical measurements (though not on Android) are here, showing values in the range 201–210. I have personally seen PRN 211 reported on a co-worker's Android phone.
Apparently the PRNs start at 200 or 201, hence the upper boundary is likely to be 234 or 235. Currently only 16 satellites are up, 2 of which are not operational, hence you will never encounter most of these numbers until more satellites are launched. 201–205 seems to be the range for the geostationary satellites, thus you might not encounter any of these unless you are within their coverage range.
Edit: NMEA seems to have created a de-facto standard for satellite IDs, which pretty much matches what has been seen on Android. I have tried to put together a list of all ranges currently in use here.
Related
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 am building an application that collects the RSSI levels of APs around me and do some calculations based on that.
The problem is that the readings are unstable even if the device is still. For example, signals from an access point fluctuates between -71, -68,-75 and so on....
Is there a way to stabilize the signals?
In telecommunications, received signal strength indicator (RSSI) is a measurement of the power present in a received radio signal.
I think the best you can do is count them al together and devide them after a x amount of measssure time. (since you would never get an 100% accurate acces point because of al kinds of components).
source:
http://en.wikipedia.org/wiki/Received_signal_strength_indication
"The problem is that the readings are unstable even if the device is still. For example, signals from an access point fluctuates between -71, -68,-75 and so on...."
This is the nature of the wireless signal. Even if the device is still, the environment is "moving", so, the signal is suffering from small scale fading mostly due to the environment scatterers. So, it is normal to obtain these fluctuations in the device measurements.
The accurancy of each Android device Wi-Fi measurement is another story.
Moreover, keep in mind that the values returned are in dBm which means that is in mWatt but expressed in the log scale. So, as Thealon proposed the averaging, you have to be careful because you cannot devide dBm values.
one solution would be to convert the dBm values back to mWatt and then perform the averaging. like below
Convert dBm to mWatt: mWatt = 10^(dBm/10)
When getting the RSSI, Google recommends to:
Use calculateSignalLevel(int, int) to convert this number into an absolute signal level which can be displayed to a user.
Official Docs
I'd like to display a GPS status icon in my application to indicate whether or not there's a valid fix to the user. There seem to be a few ways to do this, including using the API directly (which seems to have poor results based on some of the questions on SO) and guessing that a GPS fix has been dropped after a certain time has elapsed (How can I check the current status of the GPS receiver?)
Android apparently lets you grab NMEA strings directly as well:
http://developer.android.com/reference/android/location/GpsStatus.NmeaListener.html
One of the NMEA Tokens ($GPGGA) gives you fix quality information:
GGA Global Positioning System Fix Data
123519 Fix taken at 12:35:19 UTC
4807.038,N Latitude 48 deg 07.038' N
01131.000,E Longitude 11 deg 31.000' E
1 Fix quality: 0 = invalid
1 = GPS fix (SPS)
2 = DGPS fix
3 = PPS fix
4 = Real Time Kinematic
5 = Float RTK
6 = estimated (dead reckoning)
7 = Manual input mode
8 = Simulation mode
08 Number of satellites being tracked
0.9 Horizontal dilution of position
545.4,M Altitude, Meters, above mean sea level
46.9,M Height of geoid (mean sea level) above WGS84
ellipsoid
(empty field) time in seconds since last DGPS update
(empty field) DGPS station ID number
*47 the checksum data, always begins with *
It seems like I can just check that my fix status isn't 0,6,7, or 8 to see if I have a fix. But I have a few questions:
Is it reasonable to expect all Android GPS receivers provide NMEA strings?
If yes to 1, will all Android GPS receivers provide NMEA strings at regular intervals?
The separate/USB GPS receivers that I've played around with just broadcast NMEA strings at regular intervals (ie, even without a fix) so its easy to check whether or not there's a fix. I don't know if this behavior is defined by any kind of standard and is something I can rely on.
I know that not all GPS receivers broadcast NMEA strings and some transmit a closed protocol... but I don't know whether or not these kinds of receivers are used in typical retail Android devices.
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.