GPS epoch is January 6 1980. On cold boot, L76 returns "80" in the timestamp year field.
So, I modified the getUTCDateTime() method to return None if year is 80 to avoid false reading on cold start.
getUTCTime should probably be changed too, to grab the full date-time value from RMC so we can check if the year is 1980. Otherwise, there's no way to know if the getUTCTime is accurate or not from the result, alone.
I also added a new getUTCDateTimeTuple() method to return tuple of ints with full year that can be passed directly to the RTC for GPS time sync. It's hard-coded right now to "20"+utc_date year bits. In year 2100 this will need to be changed.
Note, this code does not account for leap seconds, or offset of GPS time from UT. As far as I can tell, the L76 receiver doesn't output any kind of offset information, the protocol specs to state the time is "UTC Time" and not "GPS Time" so perhaps it's corrected already.
Also, maybe it's better to look at the number of satellites in view to determine whether the fix is accurate, or not... Because otherwise, pulling a datetime from the GPS will definitely yield invalid results during a warm up, but you can fetch a datetime faster than doing a location fix, so it's not worth waiting for a fix just to sync the time.
GPS epoch is January 6 1980. On cold boot, L76 returns "80" in the timestamp year field.
So, I modified the getUTCDateTime() method to return None if year is 80 to avoid false reading on cold start.
getUTCTime should probably be changed too, to grab the full date-time value from RMC so we can check if the year is 1980. Otherwise, there's no way to know if the getUTCTime is accurate or not from the result, alone.
I also added a new getUTCDateTimeTuple() method to return tuple of ints with full year that can be passed directly to the RTC for GPS time sync. It's hard-coded right now to "20"+utc_date year bits. In year 2100 this will need to be changed.
Note, this code does not account for leap seconds, or offset of GPS time from UT. As far as I can tell, the L76 receiver doesn't output any kind of offset information, the protocol specs to state the time is "UTC Time" and not "GPS Time" so perhaps it's corrected already.
Also, maybe it's better to look at the number of satellites in view to determine whether the fix is accurate, or not... Because otherwise, pulling a datetime from the GPS will definitely yield invalid results during a warm up, but you can fetch a datetime faster than doing a location fix, so it's not worth waiting for a fix just to sync the time.