UTC time (GPS)

championx · Joined: 28 Feb 2006 Posts: 151

Hi! I post this question here because I'm really lost and i know some of you have worked with gps modules before. So if you have some clue about whats happening i will be veeeery happy.

I'm developing a GPS time synchronized clocks, so, i have some boards with a MAESTRO WIRELESS A2235H gps and i want them to have the same exact hour. So i use the nmea sentence "GPZDA" and the PPS signal provided by the GPS.

The thing is that when they get the position fix it starts to provide the GPZDA sentence and the PPS signal, so, i take the UTC time and PPS and establish the local clock for the board.

The problem is that SOMETIMES the gps have a 1 second difference with each other! Confused

So, i check the code 100000 times... and everything is ok... then i simulate the GPS NMEA sentences and no error... So I started SPYING the serial communication and the UTC times, and discovered that sometimes, the NMEA sentences do this after some time:

$GPZDA,172809.000...

1 second later:
$GPZDA,172810.000...

1 second later:
$GPZDA,172811.000...

1 second later:
$GPZDA,172811.000... WHATTTTT!!!??? it repeats the last UTC time!

1 second later:
$GPZDA,172812.000...

and from this point the boards have the same time...

So... i think "ok... its a matter of DOP"... so i wait for the boards to have 1.x DOP level... but they do the same... after some time... if the hour is not correct it repeat a sentence and correct the hour.

It seems that it just a matter of time... the GPS corrects the UTC time and everything is ok... but i really don't like this...

any suggestion?

Jerry I · Posted: Mon May 25, 2015 9:00 pm

Hi

Why don't you just read the GPS Time and set a RTC like DS1307 then display the time from the RTC. You can re-synchronize the RTC every hour if you like but should not be required. It may stray 10 sec a month.

As for your problem are you sure a second has passed before you display the GPS time.

Idea

newguy · Joined: 24 Jun 2004 Posts: 1903

As suggested, use the first NMEA sentence to set the RTC and keep a "local" (to the PIC) copy of the time which then updates with every PPS rising edge from the receiver. Every 24 hours re-sync the RTC chip if required.

championx · Joined: 28 Feb 2006 Posts: 151

Hi! thanks for your answer.

The thing is that i have to get the SAME exact hour on all of the boards.

Every board has an RTC which synchronizes every few minutes. But the users will use the board only a few hours.

I need to get the exact same hour on a few minutes and keep it for about 8 hours.

If i get the hour only one time and then only synchronize it with the PPS, then i could be making a mistake if one or a few boards get the "wrong" UTC time that the GPS sends for the first minutes.

It is really complicated...

Jerry I, i don't display the time, i just "spy" the nmea sentences. So, no error there, the GPS sends the nmea strings one every second. So, if two consecutive nmea sentences has the same hour, then the GPS has corrected itself...

Thanks!

newguy · Joined: 24 Jun 2004 Posts: 1903

Look for the NMEA fix stable flag. I know it's available on the GPRMC sentence and I suspect it's also available on others. I think the clocks are off if the receiver doesn't have a good satellite fix.

No fix means clock is unreliable.

Ttelmah · Joined: 11 Mar 2010 Posts: 19360

The other thing may simply be granularity.

You request the data (say) at (nominal) 1 second intervals. Asking for it from one unit, then another.

Suppose you happen to ask at exactly xxxxx.00 seconds.
You get back xxxxx, from both units.

Then one second later _by your clock_, you ask again. Actually at xxxxx.99 seconds. So you read a second xxxxx. You then ask from the second GPS. The time by it, is now xxxxx+1.00, so you receive from the second unit xxxxx+1.....

Because the two clocks are not exactly synchronised, and the read itself takes time, you can always get the possibility of a one second difference.

The way to avoid this is to repeatedly read the time, and only accept it at the moment when a 'new' reading appears.

championx · Joined: 28 Feb 2006 Posts: 151

Hi Ttelmah, thanks for your answer. The thing is im not "asking" anything, I discovered the problem by listening the nmea output from the GPS.

it actually repeat a zda sentence xxxxxxx.000

asmboy · Joined: 20 Nov 2007 Posts: 2128 Location: albany ny

.000... on every value

looks damned suspicious to me.......

championx · Joined: 28 Feb 2006 Posts: 151

Hi asmboy, i understand what you are sugesting... but that is not the solution.

If you look at the nmea sentence output from a GPS you will see for example this:

$GPGGA,112233.345...

$GPGGA,112234.345...

$GPGGA,112235.345...

Whit NO PPS signal present on the PPS output, but once you have the PPS signal on the PPS output, the NMEA output will SYNC whit tha falling edge of the PPS signal, like this:

$GPGGA,112236.000...

$GPGGA,112237.000...

$GPGGA,112238.000...

etc...

The problem, is that yo DONT know if the UTC time provided at this moment is correct, because SOMETIMES, a few minutes later, the GPS corrects the UTC time, like this:

$GPGGA,112246.000...

$GPGGA,112247.000...

$GPGGA,112247.000... time correction!

$GPGGA,112248.000...

Ttelmah · Joined: 11 Mar 2010 Posts: 19360

Sorry, my phrasing didn't make it clear what happens.

The timing is only to the second.
The ZDA message sends the time of the _last_ PPS update. It is sent 'within a few hundred mSec' of the last PPS'.
'Few hundred mSec', covers a lot of ground.
The interval is programmed by you (you can set the message update rate).
The clock used for the internal OS, is _not_ GPS time.
Data from the internal OS, is buffered for transmission.
If the internal OS is set to output a time message at 1/second, and runs a little fast of the GPS 1/second on it's output, then you can get duplicated time messages.

You are not warranted that 'this is the time'. Just that 'the time was this recently'.

championx · Joined: 28 Feb 2006 Posts: 151

ohhh... yes, i understand what you are saying now Ttelmah.

So, what do you suggest? program the GPS with a faster rate? or a lower rate?

I could program a faster rate and just use the time when it changes like some of you suggested...

Thanks!

Ttelmah · Joined: 11 Mar 2010 Posts: 19360

Yes.

Or if your board has a PPS output signal, then wait for this to trigger.

If you are using a high data rate (38400bps say), then reducing the interval between the messages and waiting for the change gives a relatively accurate result.

championx · Joined: 28 Feb 2006 Posts: 151

it seems that the max rate is 1 second...

Other thing... I'm actually doing it like you said.

first I wait for PPS to trigger (RB0 interrupt).

Once it triggered, then i LISTEN to the nmea sentence ZDA, that actually come a few milliseconds after the PPS output... but... even like this it is no solution to the problem. I make sure to fill the buffer with zeroes and disable the UART till the next PPS trigger

newguy · Joined: 24 Jun 2004 Posts: 1903

Okay so the GPZDA string doesn't have a data valid/invalid flag. GPRMC (and I'm sure others) has: http://aprs.gids.nl/nmea/#rmc (2nd parameter).

I bet your time issues would go away if you looked at a string with a data valid field.

championx · Joined: 28 Feb 2006 Posts: 151

No, it doesnt, but the GPS only starts sending the GPZDA string whe it has a FIX, so... the data is valid before that.

I even check the DOP field and only "listen" to the UTC time when the DOP value is below 2. So it is not a matter of valid data.