How to get accurate time stamps from Android GPS location.

[StarTraX]

I'm trying to get the GPS time for a location using location.getTime on a
location listener using GPS_PROVIDER in my requestLocationUpdates. I was
expecting the provided time to be the time from the GPS clock - accurate to
billionths of a second, but rounded to the millisecond. What I am getting
depends on the platform, but certainly doesn't seem to be what I'm
expecting.<br/>
On SGS 11 - Android 2.3.3, the returned value is always an exact second,
with the millisecond portion always .000. From my experience with GPSs, it
seems to me unlikely that every polling of the GPS will occur exactly on
the whole second interval.<br/>
On an HTC-A7275 Android 2.3.3 - I'm getting the phone's system time,
certainly not the GPS time. <br/>
I confirmed these findingsby messing with the phone's time and examining
the location time.<br/>
The time stamps in NMEA sentences on the SGS 11 are provided to 3 decimals
of a second, but on the HTC, they're all xxx.0. The problem using NMEA is
that it's really messy getting the date and time and full position from
MNEA: It is only in the GPGGA sentence that has altitude, but it has no
date stamp so it get's tricky around midnight UTC.<br/>
I am looking for precise times - preferably to the millisecond for my track
logger, so that I can reliably compare tracks from different players.
Has anyone done any more work on this?<br/>

[lbendlin]

This has nothing to do with Android. GPS chipset features are OEM
specific. Mobile phones use very cheap GPS chipsets with emphasis on power
saving, not performance. If you need better GPS accuracy then get a 10Hz
receiver. but even these are cheating, most of the time they just do
intrapolation.

Post by StarTraX
I'm trying to get the GPS time for a location using location.getTime on a
location listener using GPS_PROVIDER in my requestLocationUpdates. I was
expecting the provided time to be the time from the GPS clock - accurate to
billionths of a second, but rounded to the millisecond. What I am getting
depends on the platform, but certainly doesn't seem to be what I'm
expecting.<br/>
On SGS 11 - Android 2.3.3, the returned value is always an exact second,
with the millisecond portion always .000. From my experience with GPSs, it
seems to me unlikely that every polling of the GPS will occur exactly on
the whole second interval.<br/>
On an HTC-A7275 Android 2.3.3 - I'm getting the phone's system time,
certainly not the GPS time. <br/>
I confirmed these findingsby messing with the phone's time and examining
the location time.<br/>
The time stamps in NMEA sentences on the SGS 11 are provided to 3 decimals
of a second, but on the HTC, they're all xxx.0. The problem using NMEA is
that it's really messy getting the date and time and full position from
MNEA: It is only in the GPGGA sentence that has altitude, but it has no
date stamp so it get's tricky around midnight UTC.<br/>
I am looking for precise times - preferably to the millisecond for my
track logger, so that I can reliably compare tracks from different players.
Has anyone done any more work on this?<br/>

[RichardC]

I think that the original question is relavent to this list.
Location.getTime()<http://developer.android.com/reference/android/location/Location.html#getTime%28%29>is an Android API and it is supposed to return the time of the GPS fix in
milliseconds; this would lead me to assume that it was accurate to a few
milliseconds. That it does not on some devices is something I am interested
in knowing.

Post by lbendlin
This has nothing to do with Android. GPS chipset features are OEM
specific. Mobile phones use very cheap GPS chipsets with emphasis on power
saving, not performance. If you need better GPS accuracy then get a 10Hz
receiver. but even these are cheating, most of the time they just do
intrapolation.

Post by StarTraX
I'm trying to get the GPS time for a location using location.getTime on a
location listener using GPS_PROVIDER in my requestLocationUpdates. I was
expecting the provided time to be the time from the GPS clock - accurate to
billionths of a second, but rounded to the millisecond. What I am getting
depends on the platform, but certainly doesn't seem to be what I'm
expecting.<br/>
On SGS 11 - Android 2.3.3, the returned value is always an exact second,
with the millisecond portion always .000. From my experience with GPSs, it
seems to me unlikely that every polling of the GPS will occur exactly on
the whole second interval.<br/>
On an HTC-A7275 Android 2.3.3 - I'm getting the phone's system time,
certainly not the GPS time. <br/>
I confirmed these findingsby messing with the phone's time and examining
the location time.<br/>
The time stamps in NMEA sentences on the SGS 11 are provided to 3
decimals of a second, but on the HTC, they're all xxx.0. The problem using
NMEA is that it's really messy getting the date and time and full position
from MNEA: It is only in the GPGGA sentence that has altitude, but it has
no date stamp so it get's tricky around midnight UTC.<br/>
I am looking for precise times - preferably to the millisecond for my
track logger, so that I can reliably compare tracks from different players.
Has anyone done any more work on this?<br/>

This has nothing to do with Android. GPS chipset features are OEM
specific. Mobile phones use very cheap GPS chipsets with emphasis on power
saving, not performance. If you need better GPS accuracy then get a 10Hz
receiver. but even these are cheating, most of the time they just do
intrapolation.

Post by StarTraX
I'm trying to get the GPS time for a location using location.getTime on a
location listener using GPS_PROVIDER in my requestLocationUpdates. I was
expecting the provided time to be the time from the GPS clock - accurate to
billionths of a second, but rounded to the millisecond. What I am getting
depends on the platform, but certainly doesn't seem to be what I'm
expecting.<br/>
On SGS 11 - Android 2.3.3, the returned value is always an exact second,
with the millisecond portion always .000. From my experience with GPSs, it
seems to me unlikely that every polling of the GPS will occur exactly on
the whole second interval.<br/>
On an HTC-A7275 Android 2.3.3 - I'm getting the phone's system time,
certainly not the GPS time. <br/>
I confirmed these findingsby messing with the phone's time and examining
the location time.<br/>
The time stamps in NMEA sentences on the SGS 11 are provided to 3
decimals of a second, but on the HTC, they're all xxx.0. The problem using
NMEA is that it's really messy getting the date and time and full position
from MNEA: It is only in the GPGGA sentence that has altitude, but it has
no date stamp so it get's tricky around midnight UTC.<br/>
I am looking for precise times - preferably to the millisecond for my
track logger, so that I can reliably compare tracks from different players.
Has anyone done any more work on this?<br/>

[Panam]

Just to let you know, I am currently experimenting with GPS on a S Galaxy I
whose GPS is off about 24 hs in the future (+-some seconds) and it does not
seem to depend on the system time (adjusted the system time by some minutes
without effects). This seems to be a systematic error.
Btw. does somebody know an free app that shows the GPS time + date?

[lbendlin]

http://leapsecond.com/java/gpsclock.htm

That explains the +/- some seconds. As I mentioned already, GPS chips on
phones are cheap and cheerful. They use all kinds of dirty tricks to cut
corners (AGPS etc). You probably won't find two smartphone models (even
from the same OEM) that have the same GPS behavior .

Post by Panam
Just to let you know, I am currently experimenting with GPS on a S Galaxy
I whose GPS is off about 24 hs in the future (+-some seconds) and it does
not seem to depend on the system time (adjusted the system time by some
minutes without effects). This seems to be a systematic error.
Btw. does somebody know an free app that shows the GPS time + date?

[Alan Smith]

I can assure you that the time reported by the quoted gpsclock site is NOT
the time reported by GPS devices. It's really easy to demonstrate: Compare
what you see on your GPS with what's displayed from the web site. The
quoted time is around 15 seconds ahead of the time from the GPS device. I
wonder what that's really all about?

Post by lbendlin
http://leapsecond.com/java/gpsclock.htm
That explains the +/- some seconds. As I mentioned already, GPS chips on
phones are cheap and cheerful. They use all kinds of dirty tricks to cut
corners (AGPS etc). You probably won't find two smartphone models (even
from the same OEM) that have the same GPS behavior .

Post by Panam
Just to let you know, I am currently experimenting with GPS on a S Galaxy
I whose GPS is off about 24 hs in the future (+-some seconds) and it does
not seem to depend on the system time (adjusted the system time by some
minutes without effects). This seems to be a systematic error.
Btw. does somebody know an free app that shows the GPS time + date?

--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[lbendlin]

The OEM for your device decided to use UTC rather than GPS time.

Post by Alan Smith
I can assure you that the time reported by the quoted gpsclock site is NOT
the time reported by GPS devices. It's really easy to demonstrate: Compare
what you see on your GPS with what's displayed from the web site. The
quoted time is around 15 seconds ahead of the time from the GPS device. I
wonder what that's really all about?

Post by lbendlin
http://leapsecond.com/java/gpsclock.htm
That explains the +/- some seconds. As I mentioned already, GPS chips on
phones are cheap and cheerful. They use all kinds of dirty tricks to cut
corners (AGPS etc). You probably won't find two smartphone models (even
from the same OEM) that have the same GPS behavior .

Post by Panam
Just to let you know, I am currently experimenting with GPS on a S
Galaxy I whose GPS is off about 24 hs in the future (+-some seconds) and it
does not seem to depend on the system time (adjusted the system time by
some minutes without effects). This seems to be a systematic error.
Btw. does somebody know an free app that shows the GPS time + date?

--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[StarTraX]

Ibendin,
I think it's good practice to employ words like "perhaps", "possibly" or
"maybe" when speculating on technical subjects. It's less confusing to the
reader and makes it clear that one is not an expert on the matter.

Post by lbendlin
The OEM for your device decided to use UTC rather than GPS time.

Post by Alan Smith
I can assure you that the time reported by the quoted gpsclock site is
Compare what you see on your GPS with what's displayed from the web site.
The quoted time is around 15 seconds ahead of the time from the GPS device.
I wonder what that's really all about?

Post by lbendlin
http://leapsecond.com/java/gpsclock.htm
That explains the +/- some seconds. As I mentioned already, GPS chips
on phones are cheap and cheerful. They use all kinds of dirty tricks to cut
corners (AGPS etc). You probably won't find two smartphone models (even
from the same OEM) that have the same GPS behavior .

Post by Panam
Just to let you know, I am currently experimenting with GPS on a S
Galaxy I whose GPS is off about 24 hs in the future (+-some seconds) and it
does not seem to depend on the system time (adjusted the system time by
some minutes without effects). This seems to be a systematic error.
Btw. does somebody know an free app that shows the GPS time + date?

--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

The OEM for your device decided to use UTC rather than GPS time.

Post by Alan Smith
I can assure you that the time reported by the quoted gpsclock site is
Compare what you see on your GPS with what's displayed from the web site.
The quoted time is around 15 seconds ahead of the time from the GPS device.
I wonder what that's really all about?

Post by lbendlin
http://leapsecond.com/java/gpsclock.htm
That explains the +/- some seconds. As I mentioned already, GPS chips
on phones are cheap and cheerful. They use all kinds of dirty tricks to cut
corners (AGPS etc). You probably won't find two smartphone models (even
from the same OEM) that have the same GPS behavior .

Post by Panam
Just to let you know, I am currently experimenting with GPS on a S
Galaxy I whose GPS is off about 24 hs in the future (+-some seconds) and it
does not seem to depend on the system time (adjusted the system time by
some minutes without effects). This seems to be a systematic error.
Btw. does somebody know an free app that shows the GPS time + date?

--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[lbendlin]

"not an expert on that matter" - good one. Keep it up.

Post by StarTraX
Ibendin,
I think it's good practice to employ words like "perhaps", "possibly" or
"maybe" when speculating on technical subjects. It's less confusing to the
reader and makes it clear that one is not an expert on the matter.

Post by lbendlin
The OEM for your device decided to use UTC rather than GPS time.

Post by Alan Smith
I can assure you that the time reported by the quoted gpsclock site is
Compare what you see on your GPS with what's displayed from the web site.
The quoted time is around 15 seconds ahead of the time from the GPS device.
I wonder what that's really all about?

Post by lbendlin
http://leapsecond.com/java/gpsclock.htm
That explains the +/- some seconds. As I mentioned already, GPS chips
on phones are cheap and cheerful. They use all kinds of dirty tricks to cut
corners (AGPS etc). You probably won't find two smartphone models (even
from the same OEM) that have the same GPS behavior .

Post by Panam
Just to let you know, I am currently experimenting with GPS on a S
Galaxy I whose GPS is off about 24 hs in the future (+-some seconds) and it
does not seem to depend on the system time (adjusted the system time by
some minutes without effects). This seems to be a systematic error.
Btw. does somebody know an free app that shows the GPS time + date?

--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

The OEM for your device decided to use UTC rather than GPS time.

Post by Alan Smith
I can assure you that the time reported by the quoted gpsclock site is
Compare what you see on your GPS with what's displayed from the web site.
The quoted time is around 15 seconds ahead of the time from the GPS device.
I wonder what that's really all about?

Post by lbendlin
http://leapsecond.com/java/gpsclock.htm
That explains the +/- some seconds. As I mentioned already, GPS chips
on phones are cheap and cheerful. They use all kinds of dirty tricks to cut
corners (AGPS etc). You probably won't find two smartphone models (even
from the same OEM) that have the same GPS behavior .

Post by Panam
Just to let you know, I am currently experimenting with GPS on a S
Galaxy I whose GPS is off about 24 hs in the future (+-some seconds) and it
does not seem to depend on the system time (adjusted the system time by
some minutes without effects). This seems to be a systematic error.
Btw. does somebody know an free app that shows the GPS time + date?

--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[Alan Smith]

I could probably knock you up one quite quickly as I'm currently spending a
lot of time in that space. Could you be more specific about your
requirements? Maybe communicate directly with me through the info {at}
gpsanimator {dot} com

Post by Panam
Just to let you know, I am currently experimenting with GPS on a S Galaxy
I whose GPS is off about 24 hs in the future (+-some seconds) and it does
not seem to depend on the system time (adjusted the system time by some
minutes without effects). This seems to be a systematic error.
Btw. does somebody know an free app that shows the GPS time + date?
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[StarTraX]

Check out my new Examine GPS times
<https://play.google.com/store/apps/details?id=com.gpsanimator.gpsTimerDisplay&feature=search_result#?t=W251bGwsMSwyLDEsImNvbS5ncHNhbmltYXRvci5ncHNUaW1lckRpc3BsYXkiXQ..>free
app that displays both GPS times and System time.

Post by Alan Smith
I could probably knock you up one quite quickly as I'm currently spending
a lot of time in that space. Could you be more specific about your
requirements? Maybe communicate directly with me through the info {at}
gpsanimator {dot} com

Post by Panam
Just to let you know, I am currently experimenting with GPS on a S Galaxy
I whose GPS is off about 24 hs in the future (+-some seconds) and it does
not seem to depend on the system time (adjusted the system time by some
minutes without effects). This seems to be a systematic error.
Btw. does somebody know an free app that shows the GPS time + date?
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[Andrew Gregory]

Some of the time confusion arises because GPS units can report a variety of
"GPS Time", "UTC" and semi-corrected GPS Time. I discovered this when
building a precision timer for an industrial corrosion monitoring device.

On startup the GPS would report UTC plus one second. Within 12.5 minutes it
would report exactly UTC, i.e. after reception of the GPS/UTC correction
factor. I could only assume that the GPS developers had pre-programmed in
the UTC/GPS clock offset that was current when the device was manufactured.
Since then a UTC leap second had been added.

Importantly, there is no way to tell which of those times the GPS is
reporting. No doubt the precise behavior varies from chipset to chipset.
For my project I was using a SiRF III receiver and could switch on the raw
50bps data steam and watch for the GPS/UTC correction to be sure when I had
UTC time.

AFAIK, there is no way of doing that on Android, so for truly accurate
times your best bet is to leave the GPS on for 12.5 minutes before reading
the time, and hope that it has successfully received the clock correction.
--
Andrew

[StarTraX]

Hey Andrew - what interesting revelations!
What's the story behind the 12.5 minutes wait - is there some time offset
update in the GPS signal? Where can I go to learn more?
I'm now getting some very interesting results from my little app (above).
When first receiving a signal, it's reporting a NMEA time with odd
milliseconds, but after a variable time - between around 3 and I5 seconds,
the NMEA time decimals go to zero and the time syncs with the
location.getTime() value.
I have discovered that my SGS 11 uses the SiRF Star IV chip.
I'm keen to understand more - please point me to some reading, I have spent
the day googling variations on GPS message syntax with no success.
Cheers

Post by Andrew Gregory
Some of the time confusion arises because GPS units can report a variety
of "GPS Time", "UTC" and semi-corrected GPS Time. I discovered this when
building a precision timer for an industrial corrosion monitoring device.
On startup the GPS would report UTC plus one second. Within 12.5 minutes
it would report exactly UTC, i.e. after reception of the GPS/UTC correction
factor. I could only assume that the GPS developers had pre-programmed in
the UTC/GPS clock offset that was current when the device was manufactured.
Since then a UTC leap second had been added.
Importantly, there is no way to tell which of those times the GPS is
reporting. No doubt the precise behavior varies from chipset to chipset.
For my project I was using a SiRF III receiver and could switch on the raw
50bps data steam and watch for the GPS/UTC correction to be sure when I had
UTC time.
AFAIK, there is no way of doing that on Android, so for truly accurate
times your best bet is to leave the GPS on for 12.5 minutes before reading
the time, and hope that it has successfully received the clock correction.
--
Andrew

[Andrew Gregory]

The Wikipedia article on GPS has a lot of info. The Official source of info
would be: http://www.gps.gov/technical/

Lots of technical PDFs there! I used the Interface Control Document
IS-GPS-200 and SPS Performance Standard Specification, mostly the latter.

In short, though, the GPS comms cycle involves sending 25 pages of data at
50bps. Each page takes 30sec to be received and contains the complete
ephemeris for the satellite and 1/25th of the almanac. 25*30sec = 12.5
minutes. One of the almanac pages contains the GPS/UTC correction.

All satellites transmit the same almanac, which is good for several days.
Each satellite transmits its own ephemeris, which is good for a few hours.
Receivers will frequently store this info for faster startup. Devices with
Internet capability (say, Android smartphones :-) can download everything
from the Internet.

I should mention that all satellites appear to transmit the almanac in
sync. I never saw the GPS/UTC correction message any faster than every 12.5
minutes no matter how many satellites were visible.

The problem for timing is that there is no way to tell what GPS/UTC offset
is actually being applied by the receiver. I have not seen any comms
protocol that includes this info, not NMEA, not SiRF.

Android limits your options. There is simply no way to be *sure*. The best
I could come up with was listening to the raw data, but you can't do that
on Android.
--
Andrew

[Andrew Gregory]

I've not looked at the relevant Android API before, but I would imagine
that if you get a GpsStatus object from the LocationManager, then check
each satellite for hasAlmanac(), then you might be more likely to have the
correct GPS/UTC offset. It is still possible to have received the almanac
data for all satellites in view, but still not received the GPS/UTC offset,
so not a perfect solution.

[StarTraX]

Thanks for your input to this, it's spurred me to further study.
Re the GpsStatus object, that's a great suggestion but for the life of me,
I can't get my SGS 11 to trigger the onStatusChanged event or to get
anything from the GpsStatus object, so that's a bit annoying. But I'll
press on.
Despite monitoring for in excess of 12.5 minutes, the GPS time being
reported in the NMEA string and Location.getTime are consistently slightly
more than 1 second ahead of UTC - averages around 1300 ms. Odd eh?

Post by Andrew Gregory
I've not looked at the relevant Android API before, but I would imagine
that if you get a GpsStatus object from the LocationManager, then check
each satellite for hasAlmanac(), then you might be more likely to have the
correct GPS/UTC offset. It is still possible to have received the almanac
data for all satellites in view, but still not received the GPS/UTC offset,
so not a perfect solution.

[Andrew Gregory]

1300ms ahead sounds odd. If it was behind I'd say it was just a reporting
delay as part of the usual message processing, but ahead is weird.

It's not GPS, but if you have an Internet connection, what about querying
an NTP server?

[Simon Platten]

You need to enable RMC messages and then wait for a GPS lock, then enable
ZDA messages these give a 1PPS message with a timestamp accurate to 1ms.

Post by Andrew Gregory
1300ms ahead sounds odd. If it was behind I'd say it was just a reporting

delay as part of the usual message processing, but ahead is weird.

Post by Andrew Gregory
It's not GPS, but if you have an Internet connection, what about querying

an NTP server?

Post by Andrew Gregory
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[StarTraX]

Hi Sy, Thanks for your input. If I understand you correctly, you are
suggesting I look for a $GPZDA NMEA sentence. I have just checked the SiRF
NMEA Manual and tried it. I'm getting RMC and GGA but no ZDA sentences on
either my SGS 11 or HTC , both running 2.3.3. Am I missing something here?

Post by Simon Platten
You need to enable RMC messages and then wait for a GPS lock, then enable
ZDA messages these give a 1PPS message with a timestamp accurate to 1ms.

Post by Andrew Gregory
1300ms ahead sounds odd. If it was behind I'd say it was just a

reporting delay as part of the usual message processing, but ahead is weird.

Post by Andrew Gregory
It's not GPS, but if you have an Internet connection, what about

querying an NTP server?

Post by Andrew Gregory
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[StarTraX]

Further, here are the sentence types I do get:
GPGSA, GPGGA, GPGLL, GPRMC, GPGSV, GPVTG. The SiRF manual indicates the ZDA
message is only provided to the GSW2 software versions 2.3.2 and above -
maybe that's not being implemented on the phones.

Post by StarTraX
Hi Sy, Thanks for your input. If I understand you correctly, you are
suggesting I look for a $GPZDA NMEA sentence. I have just checked the SiRF
NMEA Manual and tried it. I'm getting RMC and GGA but no ZDA sentences on
either my SGS 11 or HTC , both running 2.3.3. Am I missing something here?

Post by Simon Platten
You need to enable RMC messages and then wait for a GPS lock, then enable
ZDA messages these give a 1PPS message with a timestamp accurate to 1ms.

Post by Andrew Gregory
1300ms ahead sounds odd. If it was behind I'd say it was just a

reporting delay as part of the usual message processing, but ahead is weird.

Post by Andrew Gregory
It's not GPS, but if you have an Internet connection, what about

querying an NTP server?

Post by Andrew Gregory
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[Simon Platten]

If ZDA isn't implemented or supported then you are really out of luck as
the time from the GPS could be out significantly also add to that the lag
in sending and receiving the NMEA message.

We use the 1PPS pulse at work to synchronise remote devices in the field,
once we lock on with the RMC the 1PPS pulse is used to generate an
interrupt which ensures that devices are absolutely in sync.

Post by StarTraX
GPGSA, GPGGA, GPGLL, GPRMC, GPGSV, GPVTG. The SiRF manual indicates the
ZDA message is only provided to the GSW2 software versions 2.3.2 and above
- maybe that's not being implemented on the phones.

Post by StarTraX
Hi Sy, Thanks for your input. If I understand you correctly, you are
suggesting I look for a $GPZDA NMEA sentence. I have just checked the SiRF
NMEA Manual and tried it. I'm getting RMC and GGA but no ZDA sentences on
either my SGS 11 or HTC , both running 2.3.3. Am I missing something here?

Post by Simon Platten
You need to enable RMC messages and then wait for a GPS lock, then
enable ZDA messages these give a 1PPS message with a timestamp accurate to
1ms.

Post by Andrew Gregory
1300ms ahead sounds odd. If it was behind I'd say it was just a

reporting delay as part of the usual message processing, but ahead is weird.

Post by Andrew Gregory
It's not GPS, but if you have an Internet connection, what about

querying an NTP server?

Post by Andrew Gregory
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/**group/android-developers?hl=en<http://groups.google.com/group/android-developers?hl=en>

--

You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

--
http://about.me/SPlatten

[StarTraX]

Sy.
Now you've got me really confused! I don't understand "..*sending*... the
NMEA message." In my code I'm just listening for the NMEA sentence in an
NMEA listener. There's no sending involved here ....is there?
On what sort of device are your receiving the ZDA sentence?

Post by Simon Platten
If ZDA isn't implemented or supported then you are really out of luck as
the time from the GPS could be out significantly also add to that the lag
in sending and receiving the NMEA message.
We use the 1PPS pulse at work to synchronise remote devices in the field,
once we lock on with the RMC the 1PPS pulse is used to generate an
interrupt which ensures that devices are absolutely in sync.

Post by StarTraX
GPGSA, GPGGA, GPGLL, GPRMC, GPGSV, GPVTG. The SiRF manual indicates the
ZDA message is only provided to the GSW2 software versions 2.3.2 and above
- maybe that's not being implemented on the phones.

Post by StarTraX
Hi Sy, Thanks for your input. If I understand you correctly, you are
suggesting I look for a $GPZDA NMEA sentence. I have just checked the SiRF
NMEA Manual and tried it. I'm getting RMC and GGA but no ZDA sentences on
either my SGS 11 or HTC , both running 2.3.3. Am I missing something here?

Post by Simon Platten
You need to enable RMC messages and then wait for a GPS lock, then
enable ZDA messages these give a 1PPS message with a timestamp accurate to
1ms.

Post by Andrew Gregory
1300ms ahead sounds odd. If it was behind I'd say it was just a

reporting delay as part of the usual message processing, but ahead is weird.

Post by Andrew Gregory
It's not GPS, but if you have an Internet connection, what about

querying an NTP server?

Post by Andrew Gregory
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/**group/android-developers?hl=en<http://groups.google.com/group/android-developers?hl=en>

--

You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

--
http://about.me/SPlatten

[Simon Platten]

Sorry, you are quite correct, I'm working with lots of protocols, a lot of
which are polled, sorry for the confusion, you do just listen for and
receive an NMEA message.

The only sending involved is to enable specific messages.

Our GPS receivers are embedded devices, I'm not absolutely sure of the part
no. but the ZDA message is well document in the NMEA specification.

Post by StarTraX
Sy.
Now you've got me really confused! I don't understand "..*sending*... the
NMEA message." In my code I'm just listening for the NMEA sentence in an
NMEA listener. There's no sending involved here ....is there?
On what sort of device are your receiving the ZDA sentence?

Post by Simon Platten
If ZDA isn't implemented or supported then you are really out of luck as
the time from the GPS could be out significantly also add to that the lag
in sending and receiving the NMEA message.
We use the 1PPS pulse at work to synchronise remote devices in the field,
once we lock on with the RMC the 1PPS pulse is used to generate an
interrupt which ensures that devices are absolutely in sync.

Post by StarTraX
GPGSA, GPGGA, GPGLL, GPRMC, GPGSV, GPVTG. The SiRF manual indicates the
ZDA message is only provided to the GSW2 software versions 2.3.2 and above
- maybe that's not being implemented on the phones.

Post by StarTraX
Hi Sy, Thanks for your input. If I understand you correctly, you are
suggesting I look for a $GPZDA NMEA sentence. I have just checked the SiRF
NMEA Manual and tried it. I'm getting RMC and GGA but no ZDA sentences on
either my SGS 11 or HTC , both running 2.3.3. Am I missing something here?

Post by Simon Platten
You need to enable RMC messages and then wait for a GPS lock, then
enable ZDA messages these give a 1PPS message with a timestamp accurate to
1ms.

Post by Andrew Gregory
1300ms ahead sounds odd. If it was behind I'd say it was just a

reporting delay as part of the usual message processing, but ahead is weird.

Post by Andrew Gregory
It's not GPS, but if you have an Internet connection, what about

querying an NTP server?

Post by Andrew Gregory
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/**group**/android-developers?hl=en<http://groups.google.com/group/android-developers?hl=en>

--

You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/**group/android-developers?hl=en<http://groups.google.com/group/android-developers?hl=en>

--
http://about.me/SPlatten
--

You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

--
http://about.me/SPlatten

[Andrew Gregory]

Yeah, I'm pretty sure you can't send commands to the Android GPS device.
You'd probably need to be root and figure out the underlying device.

[StarTraX]

Yes I do and will give it a go. Ta.

Post by Andrew Gregory
1300ms ahead sounds odd. If it was behind I'd say it was just a reporting
delay as part of the usual message processing, but ahead is weird.
It's not GPS, but if you have an Internet connection, what about querying
an NTP server?

[Simon Platten]

Hi,

The RMC message contains a status parameter, this is either V=data not
valid or A=data valid. You need to wait until you read an A in the RMC,
before this you will not get a ZDA message even if you have enabled it.

To enable RMC messages:

$PSRF103,04,00,01,01

Once you get an A in the RMC message you should then enable ZDA messages:

$PSRF103,08,00,01,01

You will need to calculate and append checksum to the enable messages which
I haven't done. The ZDA message contains a UTC time, also day, month and
year, local time offsets to UCT are also included. The time is the details
the 1PPS pulse that has just occurred.

Post by StarTraX
Yes I do and will give it a go. Ta.

Post by Andrew Gregory
1300ms ahead sounds odd. If it was behind I'd say it was just a reporting
delay as part of the usual message processing, but ahead is weird.
It's not GPS, but if you have an Internet connection, what about querying
an NTP server?

--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

--
http://about.me/SPlatten

[StarTraX]

I've been reading up on the GPS signal structure, and it's true that it
takes 12 1/2 minutes for the full sequence, but... and this is a big but...
the GPS time and GPS/UTC offset are sent with every sub frame, and they
come by every six seconds.
So you can forget about waiting 12 1/2 minutes. before being certain of the
time! It's synchronized every 6 seconds. Its all well explained
in Wikipedia http://en.wikipedia.org/wiki/GPS_signals

Post by Andrew Gregory
Some of the time confusion arises because GPS units can report a variety
of "GPS Time", "UTC" and semi-corrected GPS Time. I discovered this when
building a precision timer for an industrial corrosion monitoring device.
On startup the GPS would report UTC plus one second. Within 12.5 minutes
it would report exactly UTC, i.e. after reception of the GPS/UTC correction
factor. I could only assume that the GPS developers had pre-programmed in
the UTC/GPS clock offset that was current when the device was manufactured.
Since then a UTC leap second had been added.
Importantly, there is no way to tell which of those times the GPS is
reporting. No doubt the precise behavior varies from chipset to chipset.
For my project I was using a SiRF III receiver and could switch on the raw
50bps data steam and watch for the GPS/UTC correction to be sure when I had
UTC time.
AFAIK, there is no way of doing that on Android, so for truly accurate
times your best bet is to leave the GPS on for 12.5 minutes before reading
the time, and hope that it has successfully received the clock correction.
--
Andrew
Some of the time confusion arises because GPS units can report a variety
of "GPS Time", "UTC" and semi-corrected GPS Time. I discovered this when
building a precision timer for an industrial corrosion monitoring device.
On startup the GPS would report UTC plus one second. Within 12.5 minutes
it would report exactly UTC, i.e. after reception of the GPS/UTC correction
factor. I could only assume that the GPS developers had pre-programmed in
the UTC/GPS clock offset that was current when the device was manufactured.
Since then a UTC leap second had been added.
Importantly, there is no way to tell which of those times the GPS is
reporting. No doubt the precise behavior varies from chipset to chipset.
For my project I was using a SiRF III receiver and could switch on the raw
50bps data steam and watch for the GPS/UTC correction to be sure when I had
UTC time.
AFAIK, there is no way of doing that on Android, so for truly accurate
times your best bet is to leave the GPS on for 12.5 minutes before reading
the time, and hope that it has successfully received the clock correction.
--
Andrew

[Andrew Gregory]

Each subframe (sent every six seconds) has the *GPS Time*. The GPS/UTC
offset is only sent in subframe 4 of page 18 of the almanac data, i.e. once
every 12.5 minutes.

Also, a comment on the ZDA message mentioned previously. I had tried that
as part of my project R&D and it also returns "best guess UTC", just like
RMC. i.e. if the receiver hasn't received the GPS/UTC offset, it doesn't
actually report UTC.

Post by StarTraX
I've been reading up on the GPS signal structure, and it's true that it
takes 12 1/2 minutes for the full sequence, but... and this is a big but...
the GPS time and GPS/UTC offset are sent with every sub frame, and they
come by every six seconds.
So you can forget about waiting 12 1/2 minutes. before being certain of
the time! It's synchronized every 6 seconds. Its all well explained
in Wikipedia http://en.wikipedia.org/wiki/GPS_signals

--
Andrew