Regarding TinyGPS++:
Which parameter is best to check to obtain the same information as the LED on the GPS module gives (blink/no blink)?
Best regards,
Niels
Now that depends on the GPS, the 1PPS LED can often be set to blink when the GPS has timesync, which occurs before but is not the same as a location fix.
Often timesync and location sync do occur very close together so people just assume that the GPS light blinks when it has a fix, but that may not be the case.
What exactly are you trying to do, and what exactly do you mean by 'sufficient' satellite lock.
see this example
I'm not sure what the criteria for 1 PPS blink is. Whether it is, for example, locking on a "sufficient" number of satellites?
I have a working test setup of a GPS clock. On the display is an icon which should indicate that the time on the display is reliable. So far I have used Isvalid(). But I can see that the GPS module's LED occasionally stops blinking without the icon changing to "?". So my criterion is not sharp enough. I want the LED and the icon to agree all the time.
Thank you. Will you help me by pointing out where in the sketch I should find your point?
That normally means that the edge of the PPS pulse is synched with the GPS network and the edge is accurate to some 30nS or so.
But actual time, as in UTC is quite different.
Then that has actually not much to do with the blinking light.
GPSs, even when they have a location fix, do not actually publish UTC. They publish GPS time based which is based on the time in January 1980 and then add the current number of leap seconds that have been added since that time to arrive at UTC. The current number of leap seconds goes out to the GPS once every 12.5 minutes in a navigation message, without this update the GPS reported time could be 2 or 3 seconds out.
So if you need the clock to be accurate to the second you need to be sure the leap seconds update has taken place.
I think it’s indeed related to time synced
I see. Is that signaled anywhere in the NMEA stream? And does TinyGPS++ have any remedy for checking it?
Thank you for your interesting reply.
Time for me to learn something. See what I did there?
I found
Dec 17, 2021 — GPS time = UTC + 18s at present
which seems to say without the update the time could be 18 seconds out.
And what I have found so far is yet ambiguous. I'll keep looking.
If I make a clock and use a GPS receiver, is it up to me to add the leap seconds, or does the GPS reported time already include it, depending of course on its having received the information necessary to do?
I made a GPS based clock that reports the time uncritically. I often see differences of 10 - 20 seconds compared to clocks sometimes visible on the nightly local newscast.
I have always wondered but never bothered to run it to ground, assuming the difference was leap seconds and/or some kind of delay at the local station, like where they can quickly not broadcast something. Someone's job is to sit there and hit the big button if something happens that oughtn't go out over the air.
TIA
a7
Not in the NMEA stream, and TinyGPS++ cannot check for it.
On a Ublox GPS there is a UBX message you can poll that has the current value of leap seconds and its status.
No, most GPS have a default value of leap seconds built into the firmware they have. Often this is 16, but I have seen GPSs with it set to 15.
OK.
Just now I got page up reporting GMT, and my GPS clock is ~0.5 seconds ahead, Imma lay that off on the internet.
Then I got a page for UTC, my GPS clock is ~0.5 seconds behind.
Close enough. I don't know if one web page can do something to make the reported time more accurate that another doesn't.
I just did all that again and the differences are very smaller.
In any case, still haven't heard from my beach buddy, for whom time is relative - she is never late, never early, and cannot be kept waiting. 
THX.
a7
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.