I’m using the L96 in I2C mode. I notice that the module is able to obtain correct Date and Time values long before its position and also in situations where it is unable to obtain its position due to poor signal (e.g. indoors). I assume this is because in order to get Date and Time it only needs a signal from one satellite and it doesn’t need the perfect signal conditions that calculating its position requires.
My issue is that I can’t find anything in the protocol specification doc that will give me a flag to tell me that the Date and Time values are valid. I notice that on powerup for several seconds it will give me invalid Date and Time values (e.g. the year 2080), then after a few seconds I see it change to the correct values. But how can I know that the values are good from the protocol (without the position fix also having to be good)?
What command are you using to read the date-time from the modem?
If it’s a command like AT+CCLK? that’s not related to GPS, then the date, time and timezone will be coming from the cellular network by having NITZ enabled.
Read NITZ status: AT+CTZU?
I’m not at my computer currently to check, but it is the basic standard command that gives the standard gps information (position and datetime). When I look at the stream every second, the date and time is populated with valid values long before the L96 provides valid lat and long and sets it’s flag to signal good gps fix.
In that case, I suspect your theory about sniffing signal from a single satellite is correct.
Can anyone from Quectel support advise on this please?
I’m seeing $GPRMC date values of 2080-01-05, 2080-01-06, 2080-01-10 on powerup before it then changes to the correct date (2023-03-01), but with STATUS V=DataNotValid still being indicated because it hasn’t achieved GPS position (and won’t do for some time yet, or at all if I’m indoors). What flag can I obtain to tell me that it has successfully got the correct date and time before STATUS A=DataValid? I can’t see anything in any of the packets that can tell me this, but it’s getting correct date and time so it seems odd it has no way of telling us this?
For our application having correct Date and Time is valuable as we can start logging some data even if we don’t have the position yet.
My error. The L96 seems to be GNSS-only with no cellular capability. I would have corrected my earlier post if I’d realized this in time.
In the absence of other suggestions, does the $GPGSA result help you?
As I understand it, the “Satellite Used 1” field should be “-” before the first satellite is used for anything.
Thanks for the suggestion snowgum, I’ve been working on this again today.
I thought maybe the GGA packet number of satellites in use field would give me the answer, but in my testing that is giving 0 if there isn’t a position fix.
Your GSA packet idea looks to be the one, I’m testing now and it’s giving me blank satellite IDs on power up:
A,1,,,,,,,,,,,,,,,,2*00
Then after a while I get 3 satellite IDs showing like this even though there is no position fix (RMC packet lat and long are blank):
A,3,25,19,29,,,,,,,,,,1.82,1.57,0.93,1*07
It’s not perfect in that I can see the RMC packet has got the correct date and time for a while before it shows the satellite IDs in the GSA packet, but its pretty damn good in that it’s confirming that it’s getting signal without a position fix being achieved.
I had an email response from a Quectel engineer who also gave me this info that other users attempting similar things might find useful:
It is difficult to tell from the NMEA datastream that the date is set correctly. Looking into the structure of the sat data stream, each subpage contains the time of the week. This time information is repeated every 6s. So you should have the proper time after max 6s once locked to a sat. the week number is contained in subframe 1 which is repeated every 30s. So once locked to a sat, after max 30s you should have the correct date.
I take it back, sadly this has ended up being an imperfect solution. Further testing reveals lots of poor signal situations where it gets the correct date and time but GSA reports no satellite IDs 