Validity of getDateValid() & getTimeValid()

[adamgarbo]

Hi @PaulZC,

Do you have any thoughts on how reliable the .getDateValid and .getTimeValid() functions are for knowing whether the datetime from the u-blox is accurate?

In a recent test, I was attempting to use the date and time from a SparkFun u-blox SAM-M8Q receiver to synchronize the Artemis' real-time clock and calculate the observed drift. The code snippet I was using is here.

The RTC would sync only when the condition: if (gnss.getDateValid() && gnss.getTimeValid()) was met. However, it seems after a day or so, the RTC datetime was incorrectly synced to December 8, 2012. The variable I used to track the drift was only an int so I suspect the value you see is from multiple rollovers.

unixtime	drift
1610557200	0
1610560800	-1
1610571600	0
1610582400	-1
1610593200	-1
1610604000	-1
1610614800	-1
1610625600	-1
1610636400	0
1610647200	24960
1355000400	-24961

Can the u-blox receiver become confused and think it has a valid date and time when in fact it does not? I'll start reading more into the Interface Description about this but I was curious if this was an issue you'd run into in the past.

Cheers,
Adam

[adamgarbo]

After reading more about Time Validty in the datasheets, it seems like the .getDateValid() and .getTimeValid() should be looking to the confirmedDate and confirmedTime flags instead of validDate and validTime. When using the latter, it appears that having an incorrect date and time is still possible.

From the Integration Manual:

validDate means that the receiver has knowledge of the current date. However, it must be noted that this date might be wrong for various reasons. Only when the confirmedDate flag is set, the probability of the incorrect date information drops significantly.

validTime means that the receiver has knowledge of the current time. However, it must be noted that this time might be wrong for various reasons. Only when the confirmedTime flag is set, the probability of incorrect time information drops significantly.

This would be a minor change to the functions, as we'd just be pointing them to different flags in the same register.

I can do some tests and report back but would be keen to get your thoughts.

Cheers,
Adam

[PaulZC]

You can manually read those flags if you need to via:
myGNSS.packetUBXNAVPVT->data.flags2.bits.confirmedTime
and
myGNSS.packetUBXNAVPVT->data.flags2.bits.confirmedDate
But you will need to call getPVT first (either manually or via e.g. getDateValid) and will need to mark the data as stale afterwards by manually clearing
packetUBXNAVPVT->moduleQueried.moduleQueried1.bits.confirmedTime
and
packetUBXNAVPVT->moduleQueried.moduleQueried1.bits.confirmedDate
or calling flushPVT()
But, to do the job properly, I suspect I need to add getConfirmedDate and getConfirmedTime helper functions...

[adamgarbo]

Hi @PaulZC

Perhaps something like so?

//Get the confirmed current date
bool SFE_UBLOX_GNSS:: getConfirmedDate(uint16_t maxWait)
{
  if (packetUBXNAVPVT == NULL) initPacketUBXNAVPVT(); //Check that RAM has been allocated for the PVT data
  if (packetUBXNAVPVT == NULL) //Bail if the RAM allocation failed
    return (false);

  if (packetUBXNAVPVT->moduleQueried.moduleQueried1.bits.confirmedDate == false)
    getPVT(maxWait);
  packetUBXNAVPVT->moduleQueried.moduleQueried1.bits.confirmedDate = false; //Since we are about to give this to user, mark this data as stale
  packetUBXNAVPVT->moduleQueried.moduleQueried1.bits.all = false;
  return ((bool)packetUBXNAVPVT->data.flags2.bits.confirmedDate);
}

//Get the confirmed current time
bool SFE_UBLOX_GNSS:: getConfirmedTime(uint16_t maxWait)
{
  if (packetUBXNAVPVT == NULL) initPacketUBXNAVPVT(); //Check that RAM has been allocated for the PVT data
  if (packetUBXNAVPVT == NULL) //Bail if the RAM allocation failed
    return (false);

  if (packetUBXNAVPVT->moduleQueried.moduleQueried1.bits.confirmedTime == false)
    getPVT(maxWait);
  packetUBXNAVPVT->moduleQueried.moduleQueried1.bits.confirmedTime = false; //Since we are about to give this to user, mark this data as stale
  packetUBXNAVPVT->moduleQueried.moduleQueried1.bits.all = false;
  return ((bool)packetUBXNAVPVT->data.flags2.bits.confirmedTime);
}

I tested the above functions with the ZED-F9P and I can see the confirmedDate and confirmedTime flags being set. However, the SAM-M8Q, even with a 3D-fix for an extended period of time, never saw the confirmedDate and confirmedTime flags be set.

Turns out this is because the M8 uses Protocol Version 18.00. According to the M8 Receiver Description:

This flag (confirmedAvai) is only supported in Protocol Versions 19.00, 19.10, 20.10, 20.20, 20.30, 22.00, 23.00, 23.01, 27 and 28.

Do you know offhand if Protocol Versions >19.00 are for F9/M9 receivers only?

Cheers,
Adam

[adamgarbo]

To answer my own question, it looks like the M8Q will use firmware SPG 3.01 and Protocol Version 18.00 for the foreseeable future.

Still, I think the getConfirmedTime and getConfirmedDate are good additions for the newer generation of receivers. However, coming back to my initial question, I'm still curious what the most reliable method is for ensuring the validity of the date and time with the older generation u-blox receivers.

Perhaps time for a post on the u-blox forums!

[adamgarbo]

Hi @PaulZC,

Here's a good illustration of the date/time validity problem. This was achieved by powering on the SAM-M8Q indoors without a good sky view.

18:16:23.828 -> 2015-10-18 0:12:10  Time is not valid  Date is not valid
18:16:24.832 -> 2015-10-18 0:16:25  Time is valid  Date is not valid <--- Time not actually valid
18:16:25.841 -> 2015-10-19 23:16:26  Time is valid  Date is not valid
18:16:26.839 -> 2015-10-19 23:16:27  Time is valid  Date is not valid
18:16:27.870 -> 2015-10-19 23:16:28  Time is valid  Date is not valid
18:16:28.866 -> 2015-10-19 23:16:29  Time is valid  Date is not valid
18:16:29.875 -> 2015-10-19 23:16:30  Time is valid  Date is not valid
18:16:30.879 -> 2015-10-19 23:16:31  Time is valid  Date is not valid
18:16:31.875 -> 2015-10-19 23:16:32  Time is valid  Date is not valid
18:16:32.881 -> 2015-10-19 23:16:33  Time is valid  Date is not valid
18:16:33.880 -> 2015-10-19 23:16:34  Time is valid  Date is not valid
18:16:34.909 -> 2015-10-19 23:16:35  Time is valid  Date is not valid
18:16:35.916 -> 2015-10-19 23:16:36  Time is valid  Date is not valid
18:16:36.913 -> 2015-10-19 23:16:37  Time is valid  Date is not valid
18:16:37.913 -> 2015-10-19 23:16:38  Time is valid  Date is not valid
18:16:38.908 -> 2015-10-19 23:16:39  Time is valid  Date is not valid
18:16:39.920 -> 2015-10-19 23:16:40  Time is valid  Date is not valid
18:16:40.947 -> 2015-10-19 23:16:41  Time is valid  Date is not valid
18:16:41.940 -> 2015-10-19 23:16:42  Time is valid  Date is not valid
18:16:42.939 -> 2015-10-19 23:16:43  Time is valid  Date is not valid
18:16:43.948 -> 2015-10-19 23:16:44  Time is valid  Date is valid <--- Date not actually valid
18:16:44.939 -> 2021-1-18 23:16:45  Time is valid  Date is valid
18:16:45.967 -> 2021-1-18 23:16:46  Time is valid  Date is valid

The issue appears to occur on the transition from invalid to valid. Is this perhaps due to stale data?

Cheers,
Adam

[adamgarbo]

To close out this issue, a few observations from additional tests of M8-based receivers:

• The receiver frequently incorrectly believes it has a valid date and time when it does not.
  • This is most commonly observed when no fix has yet been acquired.
• When using the u-blox receiver as a time source to sync the RTC of a microcontroller, a reliable GNSS fix should first be acquired.
• It is also recommended to use counters to check the dateValid and timeValid flags multiple times, due to the observed issues with the flag not updating properly (outlined above).
• M9-based receivers should rely only on confirmedDate and confirmedTime flags to confirm time validity.
  • I believe it would be useful to add functions to query these flags (included above).

Cheers,
Adam