From 3d64ec6442cd7a7dcdd03a4f8df6eb9c8da7c9f5 Mon Sep 17 00:00:00 2001 From: "Eric S. Raymond" Date: Wed, 1 Apr 2015 14:22:34 -0400 Subject: Remove an impossible FIXME and an ill-specified TODO. No code changes. --- TODO | 9 --------- libgpsd_core.c | 11 ++++++++--- 2 files changed, 8 insertions(+), 12 deletions(-) diff --git a/TODO b/TODO index 8773b2df..cbaea84a 100644 --- a/TODO +++ b/TODO @@ -94,15 +94,6 @@ Our goal is to be independent of the system clock. See -**** Track gpsd's confidence in the GPS time it's seeing - -This would increase when we see a leap-second offset or get GPZDA from -the device, decrease when we detect a rollover. Some devices that are -known to deliver high-quality time (notably u-blox GPSes) would peg the -confidence measure at a high level. We'd use the confidence level to -control (a) whether gpsd ships to NTP, and (b) how it sets time -uncertainty in output JSON. - *** Optionally use tag blocks in NMEA output Ed W. writes: diff --git a/libgpsd_core.c b/libgpsd_core.c index 306bca13..c6ced73d 100644 --- a/libgpsd_core.c +++ b/libgpsd_core.c @@ -899,9 +899,14 @@ static void gpsd_error_model(struct gps_device_t *session, * expected time error should be half the resolution of * the GPS clock, so we put the bound of the error * in as a constant pending getting it from each driver. - * FIXME: increase this if no leap-second has been seen - * and it's less than 750s (one almanac load cycle) - * from device powerup. + * + * In an ideal world, we'd increase this if no leap-second has + * been seen and it's less than 750s (one almanac load cycle) from + * device powerup. Alas, we have no way to know when device + * powerup occurred - depending on the receiver design it could be + * when the hardware was first powered up or when it was first + * opened. Also, some devices (notably plain NMEA0183 receivers) + * never ship an indication of when they have valid leap second. */ if (isnan(fix->time) == 0 && isnan(fix->ept) != 0) fix->ept = 0.005; -- cgit v1.2.1