UTC time (GPS)

[newguy]

My point is what happens to the GPZDA string when the receiver loses satellite lock or the number of satellites in view drops or drops below some threshold? What I'm trying to gently steer you toward is what do you see if you examine more than one NMEA sentence in order to give you a better idea regarding why the GPZDA time does what you have been seeing. Does it send two identical times in a row if something identifiable (measurable) happens like the number of satellites in view dropping below x? Does it happen at the same time as the receiver reporting the data invalid flag? Does it happen at the same time as the receiver switching to/from a WAAS augmentation signal? Would a different GPS receiver cause the same issues you're seeing?

There are so many avenues to explore regarding why you're seeing what you're seeing. .....Stupid question, but have you asked the manufacturer of the GPS receiver?

Edit: Upon flipping through the datasheet, is it possible you're seeing HW issues on your board(s)? Is it possible the modules are getting spurious noise on the ON/OFF line, or is the module seeing a momentary power supply droop which is causing it to reset/brownout? Are you using an external antenna or the built-in patch? If you're using an external antenna, did you follow the circuit layout guidelines in the data sheet? Did you observe the circuit layout guidelines regarding the RF feedpoint on the bottom of the module?

[championx]

Hi newguy, thanks for your answer.
Sorry if I don't make sense or if i made a mistake describing the problem, i speak spanish, so English its not my main language.

Regarding the GPS module:
1) it uses a integrated antenna, so no mistake on traces or impedances.
2) it doesn't have any power problem, it doesn't reboot at any time, i use a laboratory power supply, filtered.
3) The manufacturer told me that once the GPS have PPS signal, it synchronizes the NMEA sentences to it.

I am sure that when this happens it has clear view of the sky (it is a stationary equipment, the GPS it is ONLY used to synchronization purposes) and the number of satellites it is the same as the previous second (i analyzed the GPGSA sentence, the GPGGA sentence and the GPZDA to see if there where any change on some of the data fields).


It is not a random problem... it happens with all the boards.

It seems that the GPS module gets a "preliminary UTC TIME" and a few minutes later it correct itself and get the "FINAL UTC TIME", but no changes on satellite view, valid data or DOP value... it doesn't make any sense... i know.

If I power up 5 receivers... wait for the PPS pulses, the 5 pulses are EXACTLY at the same time. BUT, the UTC time may be different (+-1 sec) between the 5 boards. All with 7 satellites at least, 1.x DOP and Valid data.

If i wait, lets say 30 minutes, the 5 boards will have the same UTC time (no more difference). Thats why i think they correct itself at some time.

I have seen this just "listening" the nmea data... no processing, no pic, no program... just listening to the nmea output at the module.

It is driving me crazy....

[gpsmikey]

It almost sounds like the gps has built the string to send BEFORE the 1pps happens and then when the pps triggers the interrupt, you are sometimes getting the string that was started before the pps second "tic" happened?

[edit] I think you posted your last post while I was typing - the comment about the manufacturer indicates that the NMEA sentences ARE synch'd to the pps is what I was asking about. Very odd.

mikey
_________________
mikey
-- you can't have too many gadgets or too much disk space !
old engineering saying: 1+1 = 3 for sufficiently large values of 1 or small values of 3

[Ttelmah]

'3' is good news. A lot of units do not do this.

Obvious thing is that the basic data stream from a single satellite gives you the UTC time (but does not allow you to accurately calculate time offsets). 3 satellites allows a basic position fix, but not an accurate time fix.

Two possibilities. Look at the GGA sentence. The eighth figure is the 'number of satellites being tracked'. I'd suggest reading this eighth figure, and not accepting time, till this goes to 4 or above. A 3 satellite fix, gives you an approximate location, and the system _will_ say it has a GPS fix, and a PPS fix, but the accuracy of the time will be 'dubious' until a fourth satellite is being tracked.

Another way to check how good the fix 'is', would be to look at the GPGSA string, and check that it has switched to 3D. This also happens when enough satellites are seen for a good clock fix.

A lot of units won't allow update rates below 1 second, if 9600bps is selected. However 5Hz, or even 10Hz fix updates are used for things like multi-copters, but at (typically) 38400bps.

[championx]

This is the response from the manufacturer:

-------------------------------------------------------------------------------------

The issue is called leap time second.

There are 2 ways to address leap second jumps:

There are 2 ways to address leap second jumps (this is especially important since a new leap second is coming up at the end of next month (June 30).

1) You can wait for the complete Almanac broadcast from the satellite.
The leap second correction is provided once every 12.5mn (The parameters that apply to the current and future leap second events are contained in subframe 4, page 18 of the navigation data message)
2) You can program into your application processor the error correction and feed that information to the receiver upon start-up

That second option is a bit complex to do with the A2235-H as this device is a ROM only device and has no internal NV storage.

In such as case, can we suggest that you consider the A2135-H, which has embedded flash (The A2135-H is pin to pin compatible with the A2235-H). The flash will allow the receiver to read the appropriate offset and store it for future use. However that is only possible after the receiver has been turned on and been able to decode Nav data for at least 12.5m from a good satellite.

---------------------------------------------------------------------------------

I think we are talking about different things.... what do you think?

[Ttelmah]

Very much....

The leap second, is an adjustment applied to UTC, to keep it close to mean solar time. At the moment it happens, you could potentially see a similar problem, but not repeatedly. The last one was applied in 2012, and the next one is in June this year. Wouldn't have given you a problem yet....

Have you tried waiting for a 3D fix, or testing the number of satellites?.

It doesn't take very much position error for the time calculations to be less than accurate, I'd not trust it until a 3D fix is reported.

[championx]

Yes, i test DOP, number of satellites and 3d fix... nothing guaranties you a correct UTC time the first minutes of operation...

[Ttelmah]

Have a look at this post:

<www.asteroidoccultation.com/docs/GPSTimeProblem.pdf>

They found that their GPS returned GPS time, _not_ UTC, until a full almanac was acquired....

I suspect yours is holding a default offset, which is a second wrong.

Now one of the GPS strings gives the date of the current almanac. I'd suggest you need to read this, until the date on this becomes 'current', before accepting the time.

So the manufacturer is right the problem is the 'leap second'. The units have a default value programmed as the correction for this, and it is wrong, until the almanac is updated.