VEHPI-28: Timestamp conversion is broken

Issue Information

Issue Type: Bug
 
Priority: Major
Status: Closed

Reported By:
Ben Tasker
Assigned To:
Ben Tasker
Project: VehManPi (VEHPI)
Resolution: Won't Fix (2019-09-09 16:24:42)
Target version: 1.0,
Components: GPS ,

Created: 2013-12-26 13:14:18
Time Spent Working


Description
Not looked into why yet, but when the JourneyRecorder converts a time to epoch, the timestamp is for a date in 1994.


Issue Links

relates to VEHPI-7: Implement GPS Support
Toggle State Changes

Activity


2013-12-26 14:18:22
Appears to be working again now.

2013-12-26 20:38:07
Looking at the raw data, the GPS was reporting a date in 1994. Not entirely sure why

2013-12-26 20:38:11
btasker changed status from 'Open' to 'In Progress'

2013-12-27 00:42:16
As part of the field testing in VEHPI-30, a recurrence of this issue was found. Dates for an entire track segment covering 75 miles are in 1994.

Have a theory of the cause;

When the Pi was booted it would have been unable to contact an NTP server as no connectivity was available. No NTP servers would have been available during the drive, and so the system clock was probably used for conversion.

If this is the root cause, then the solution might simply be to take the GPS date as it's provided on the wire and use that rather than converting to Epoch. There's very little that it's likely to impact.

2013-12-27 01:47:50
A fix has been implemented in VEHPI-12, will have to wait and see whether it resolves this issue

2013-12-27 22:38:45
The fix in VEHPI-12 doesn't appear to have resolved this issue - the 1994 dates are definitely coming from the GPS. Timestamps generated by the system (such as those used in the Journeys segment) are correct, but those taken directly from the GPS are not.

2013-12-27 22:56:44
http://esr.ibiblio.org/?p=801 makes for interesting reading. Doesn't really answer the question, but interesting reading

2013-12-27 23:07:13
A temporary solution might be to use the system time for now, though it's going to lead to some inaccuracies. It also raises the question of how accurate some of the other calculations are (speed etc).

2013-12-27 23:12:24
Temporary fix introduced in commit 4a25a3b - The GPS fix data is amended to use a timestamp generated from the system time. Far from ideal, but should prevent this from happening whilst a better fix is found

2019-09-09 16:24:43
Bulk Close.

Realistically, project isn't going to see any further development so closing as Won't Fix

2019-09-09 16:24:43
btasker changed status from 'In Progress' to 'Closed'

2019-09-09 16:24:43
btasker added 'Won't Fix' to resolution