diff options
-rw-r--r-- | driver_nmea0183.c | 23 | ||||
-rw-r--r-- | gpsd.h-tail | 3 | ||||
-rw-r--r-- | timebase.c | 25 |
3 files changed, 28 insertions, 23 deletions
diff --git a/driver_nmea0183.c b/driver_nmea0183.c index e81bad40..50f826d5 100644 --- a/driver_nmea0183.c +++ b/driver_nmea0183.c @@ -767,28 +767,7 @@ static gps_mask_t processGPZDA(int c UNUSED, char *field[], gpsd_report(session->context->debug, LOG_WARN, "malformed ZDA day: %s\n", field[2]); } else { - session->context->valid |= CENTURY_VALID; - if (century > session->context->century) { - /* - * This mismatch is almost certainly not due to a GPS week - * rollover, because that would throw the ZDA report backward - * into the last rollover period instead of forward. Almost - * certainly it means that a century mark has passed while - * gpsd was running, and we should trust the new ZDA year. - */ - gpsd_report(session->context->debug, LOG_WARN, - "century rollover detected.\n"); - session->context->century = century; - } else if (session->context->start_time >= GPS_EPOCH && century < session->context->century) { - /* - * This looks like a GPS week-counter rollover. - */ - gpsd_report(session->context->debug, LOG_WARN, - "ZDA year %d less than clock year, " - "probable GPS week rollover lossage\n", - year); - session->context->valid &=~ CENTURY_VALID; - } + gpsd_century_update(session, century); session->driver.nmea.date.tm_year = year - 1900; session->driver.nmea.date.tm_mon = mon - 1; session->driver.nmea.date.tm_mday = mday; diff --git a/gpsd.h-tail b/gpsd.h-tail index 2601d97c..68fb73b6 100644 --- a/gpsd.h-tail +++ b/gpsd.h-tail @@ -803,8 +803,9 @@ extern void gpsd_set_century(struct gps_device_t *); extern timestamp_t gpsd_gpstime_resolve(/*@in@ */ struct gps_device_t *, const unsigned short, const double); extern timestamp_t gpsd_utc_resolve(/*@in@*/struct gps_device_t *); +extern void gpsd_century_update(/*@in@*/struct gps_device_t *, int); -extern void gpsd_zero_satellites(/*@out@*/struct gps_data_t *sp)/*@modifies sp@*/; +extern void gpsd_zero_satellites(/*@out@*/struct gps_data_t *sp); extern gps_mask_t gpsd_interpret_subframe(struct gps_device_t *, unsigned int, uint32_t[]); extern gps_mask_t gpsd_interpret_subframe_raw(struct gps_device_t *, @@ -204,6 +204,31 @@ timestamp_t gpsd_utc_resolve(/*@in@*/struct gps_device_t *session) return t; } + +void gpsd_century_update(/*@in@*/struct gps_device_t *session, int century) +{ + session->context->valid |= CENTURY_VALID; + if (century > session->context->century) { + /* + * This mismatch is almost certainly not due to a GPS week + * rollover, because that would throw the ZDA report backward + * into the last rollover period instead of forward. Almost + * certainly it means that a century mark has passed while + * gpsd was running, and we should trust the new ZDA year. + */ + gpsd_report(session->context->debug, LOG_WARN, + "century rollover detected.\n"); + session->context->century = century; + } else if (session->context->start_time >= GPS_EPOCH && century < session->context->century) { + /* + * This looks like a GPS week-counter rollover. + */ + gpsd_report(session->context->debug, LOG_WARN, + "ZDA year less than clock year, " + "probable GPS week rollover lossage\n"); + session->context->valid &=~ CENTURY_VALID; + } +} #endif /* NMEA_ENABLE */ timestamp_t gpsd_gpstime_resolve(/*@in@*/struct gps_device_t *session, |