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 RD and it also returns best guess
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
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.
On Wednesday, April 25, 2012 3:43:34 PM UTC+10,
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
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?
On Wednesday, April
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
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.
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to
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.
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.
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
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.
On Apr 25, 2012 6:02 AM, Andrew Gregory andrew.greg...@gmail.com wrote:
1300ms ahead sounds odd. If it was behind I'd say it was just a reporting
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?
Yes I do and will give it a go. Ta.
On Wednesday, April 25, 2012 3:01:33 PM UTC+10, andrewg_oz wrote:
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
Check out my new Examine GPS times
https://play.google.com/store/apps/details?id=com.gpsanimator.gpsTimerDisplayfeature=search_result#?t=W251bGwsMSwyLDEsImNvbS5ncHNhbmltYXRvci5ncHNUaW1lckRpc3BsYXkiXQ..free
app that displays both GPS times and System time.
On Monday, April 23, 2012 7:52:09 AM
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
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
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
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
not an expert on that matter - good one. Keep it up.
On Sunday, April 22, 2012 8:20:57 PM UTC-4, StarTraX wrote:
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
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
I think that the original question is relavent to this list.
Location.getTime()http://developer.android.com/reference/android/location/Location.html#getTime%28%29is
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
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
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
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
On Mon, Apr 23, 2012 at 12:00 AM, Panam
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
The OEM for your device decided to use UTC rather than GPS time.
On Sunday, April 22, 2012 6:05:12 PM UTC-4, StarTraX wrote:
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
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.
On Monday, April 23, 2012 9:42:50 AM UTC+10, lbendlin wrote:
The OEM for
27 matches
Mail list logo
