[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[gpsd-dev] [PATCH] Documentation on what we are trying to achieve
From: |
Sanjeev Gupta |
Subject: |
[gpsd-dev] [PATCH] Documentation on what we are trying to achieve |
Date: |
Wed, 27 Nov 2013 03:07:42 +0800 |
---
timebase.c | 23 ++++++++++++-----------
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/timebase.c b/timebase.c
index 0ad1740..87f8766 100644
--- a/timebase.c
+++ b/timebase.c
@@ -7,22 +7,23 @@ clock be accurate to within one second. It would be nice to
relax this
to "accurate within one GPS rollover period" for receivers reporting
GPS week+TOW, but isn't possible in general.
-Date and time in GPS is represented as number of weeks from the start
-of zero second of 6 January 1980 mod 1024, plus number of seconds into
-the week. GPS time is not leap-second corrected, though satellites
-also broadcast a current leap-second correction which is updated on
-(theoretically) three-month boundaries according to rotational
-bulletins issued by the International Earth Rotation and Reference
-Systems Service (IERS). Historically all corrections have been issued
-on six-month boundaries.
+Date and time in GPS is represented as number of weeks mod 1024 from
+the start of zero second of 6 January 1980, and number of seconds into
+the week. GPS time is not leap-second corrected, and has a constant
+offset from TAI. Satellites also broadcast a current leap-second
+correction which is updated on (theoretically) three-month boundaries
+according to rotational bulletins issued by the International
+Earth Rotation and Reference Systems Service (IERS).
+Historically all corrections have been issued on six-month boundaries.
The leap-second correction is only included in the satellite subframe
broadcast, roughly once ever 20 minutes. While the satellites do
notify GPSes of upcoming leap-seconds, this notification is not
necessarily processed correctly on consumer-grade devices, and will
not be available at all when a GPS receiver has just
-cold-booted. Thus, UTC time reported from NMEA devices may be slightly
-inaccurate between a cold boot or leap second and the following
+cold-booted. Thus, the time reported from NMEA devices, although
+supposed to be UTC, may be offset by an integer number of seconds
+between a cold boot or leap second and the following
subframe broadcast.
It might be best not to trust time for 20 minutes after GPSD startup
@@ -64,7 +65,7 @@ we can't know which rollover period we're in without an
external time
source.
4) Only one external time source, the host system clock, is reliably
-available.
+available, although it may not be accurate.
5) Another source *may* be available - the GPS leap second count, if we can
get the device to report it. The latter is not a given; SiRFs before
--
1.8.4.4
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [gpsd-dev] [PATCH] Documentation on what we are trying to achieve,
Sanjeev Gupta <=