Re: [time-nuts] Ublox Neo-6M time error.

[Angus]

I noticed that in 'Messages View' window in u-center, UBX-NAV-TIMEGPS
gives Time of week, but UBX-TIM-TP gives Time of next pulse, 1 second
later. The hex in the messages also differs by 1000ms.
Putting the correction data and the time of the next pulse together
like that would suggest that it is for the next pulse, but I've not
checked it with a counter.

Angus.

On Thu, 2 Jun 2016 08:28:58 +, you wrote:

>The Ublox receivers do not have a message that outputs GPS time directly.  
>It's easiest to take the UTC time message and subtract the leapsecond offset 
>to get GPS time.   The itow value in the NAV_TIMEGPS message is milliseconds 
>past midnight of the start of the GPS week... probably not something you want 
>to be doing calculations from.  I use the TIMEUTC message.  I only use the 
>leapsecond offset from TIMEGPS.
>
>It looks like Ublox is sending the time message AFTER the 1PPS pulse ("at the 
>beep, the time was...") , and just about everybody else sends it before the 
>pulse ("at the beep, the time is ...") ... Bastards!  I wonder about the 
>thought (or lack of it) process that decided that was the way to do it.  And 
>don't get me started on the idiot receivers that send the sawtooth correction 
>message after the fact...
>--
>Despite re-checking I am still doubtful that my sums are right. I’ll do a few 
>more packets.  Is this what you are seeing Mark?   
>
>___
>time-nuts mailing list -- time-nuts@febo.com
>To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>and follow the instructions there.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Ublox Neo-6M time error.

[Hal Murray]

david-tay...@blueyonder.co.uk said:
> I think that all the GPS devices I've used sent the time /after/ the PPS
> pulse.  I've never met one which sent it before. 

That makes sense for NMEA format messages which have fractional seconds in 
some of the message formats.  Mostly they are 0, but if filled in could tell 
you when the serial message started or ended.

That is the time labels the current second which started with the previous 
PPS.


-- 
These are my opinions.  I hate spam.



___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Ublox Neo-6M time error.

[Mike Cook]

Hi Mark,

> Le 2 juin 2016 à 10:28, Mark Sims  a écrit :
> 
> The Ublox receivers do not have a message that outputs GPS time directly.  
> It's easiest to take the UTC time message and subtract the leapsecond offset 
> to get GPS time.   The itow value in the NAV_TIMEGPS message is milliseconds 
> past midnight of the start of the GPS week... probably not something you want 
> to be doing calculations from.  I use the TIMEUTC message.  I only use the 
> leapsecond offset from TIMEGPS.
> 

 Ok makes sense. BTW my calculations on other TIMEGPS messages using iTOW value 
confirm the strange finding I saw before:

09:02:08    B5 62 01 20 10 00 D0 0C 8A 16 5A 17 FD FF 6B 07  
  0010  11 07 0F 00 00 00 B3 4E  

Header  B5 62
ID  01 20
length  00 10   16
iTOW16 8A 0C D0 378146000 ms
fTOWFF FD 17 5A -ve some value
week07 6B   1:875
LeapS   11  17
flags   07  all bits valid
iAcc00 00 00 0F
CK_AB3
CK_B4E

Converting iTOW  : the above hex byte values have been changed to big endian .

4days 9h 2m 26s   from start of GPS week , that is Sunday midnight.
The seconds value make no sense in standard GPS time from the SV but as I 
saw before
can be MADE to make sense if you subtract current leap seconds.
 
4d 9h 2m 09s which is the NEXT second . 

09:02:09    24 47 50 52 4D 43 2C 30 39 30 32 30 39 2E 30 30  
$GPRMC,090209.00
  0010  2C 41 2C 34 38 34 37 2E 33 34 35 37 34 2C 4E 2C  
,A,4847.34574,N,
  0020  30 30 32 31 36 2E 32 39 37 38 32 2C 45 2C 30 2E  
00216.29782,E,0.
  0030  30 35 38 2C 2C 30 32 30 36 31 36 2C 2C 2C 41 2A  
058,,020616,,,A*
  0040  37 31 0D 0A  71

> It looks like Ublox is sending the time message AFTER the 1PPS pulse ("at the 
> beep, the time was...") , and just about everybody else sends it before the 
> pulse ("at the beep, the time is ...") ... Bastards!  I wonder about the 
> thought (or lack of it) process that decided that was the way to do it.  And 
> don't get me started on the idiot receivers that send the sawtooth correction 
> message after the fact...
> --
> Despite re-checking I am still doubtful that my sums are right. I’ll do a few 
> more packets.  Is this what you are seeing Mark?  
> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

"The power of accurate observation is commonly called cynicism by those who 
have not got it. »
George Bernard Shaw

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Ublox Neo-6M time error.

[David J Taylor]

From: Mark Sims
[]
It looks like Ublox is sending the time message AFTER the 1PPS pulse ("at 
the beep, the time was...") , and just about everybody else sends it before 
the pulse ("at the beep, the time is ...") ... Bastards!  I wonder about the 
thought (or lack of it) process that decided that was the way to do it.  And 
don't get me started on the idiot receivers that send the sawtooth 
correction message after the fact...

[]
___

I think that all the GPS devices I've used sent the time /after/ the PPS 
pulse.  I've never met one which sent it before.


David
--
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-tay...@blueyonder.co.uk
Twitter: @gm8arv 


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[time-nuts] Ublox Neo-6M time error.

[Mark Sims]

The Ublox receivers do not have a message that outputs GPS time directly.  It's 
easiest to take the UTC time message and subtract the leapsecond offset to get 
GPS time.   The itow value in the NAV_TIMEGPS message is milliseconds past 
midnight of the start of the GPS week... probably not something you want to be 
doing calculations from.  I use the TIMEUTC message.  I only use the leapsecond 
offset from TIMEGPS.

It looks like Ublox is sending the time message AFTER the 1PPS pulse ("at the 
beep, the time was...") , and just about everybody else sends it before the 
pulse ("at the beep, the time is ...") ... Bastards!  I wonder about the 
thought (or lack of it) process that decided that was the way to do it.  And 
don't get me started on the idiot receivers that send the sawtooth correction 
message after the fact...
--
Despite re-checking I am still doubtful that my sums are right. I’ll do a few 
more packets.  Is this what you are seeing Mark?

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Ublox Neo-6M time error.

[Mike Cook]

> Le 1 juin 2016 à 03:20, Mark Sims  a écrit :
> 
> I had two machines running Lady Heather with the singing chime clock mode 
> enabled (that plays a chant from the Missa Assumpta on the quarter hours).   
> 
> One machine was connected to a Ublox Neo-6M receiver and another to a Z3801A. 
>   I noticed that the two machines sang their jaunty monk tunes offset by 
> around one second.  Since a man with two singing GPS clocks never knows what 
> time it is,  I replaced the Z3801A with a Jupiter-T and the two clocks were 
> still out of sync.   Finally I tried  Motorola M12+ and UT receivers and the 
> same thing happened.  It looks like the Ublox time is ahead by a second 
> compared to all the other receivers.   I then specified a -1 second 
> "rollover" correction to the Ublox machine and the two clocks sang in perfect 
> harmony.   Has anybody noticed such behavior with other receivers?
> 
> BTW,  note that the Ublox binary time message has a "fractional nanoseconds 
> of the seconds field" (+/- 500,000 nanoseconds) correction that must be 
> applied to the hrs:min:secs values (which I am doing).  The fractional time 
> offset forms a sawtooth with around a 120 second period.  Attached is a 
> GIF... white is the nanosecond fractional time offset.  Magenta is the 
> receiver estimate of its time error (both in nanoseconds).  The Trimble 
> Resolution-T receivers report a similar "local clock bias" value, but they 
> don't seem to document what it actually is…

The manual states that all protocol messages are sent after the 1PPS time 
pulse. But it looks like the nav time message is an exception.
> 

I dumped the default data stream (just NMEA) with u-center. The first NMEA 
message being a GPRMC and the last being GPGGL.
>From your post I figured that you were referring to the NAV-TIMEGPS message so 
>I configured that in. The message showed up between the last NMEA message for 
>the second and the GPRMC at the top of the next second.

 15:42:31    24 47 50 52 4D 43 2C 31 35 34 32 33 31 2E 30 30  
$GPRMC,154231.00
  0010  2C 41 2C 34 38 34 37 2E 33 35 31 39 30 2C 4E 2C  
,A,4847.35190,N,
  0020  30 30 32 31 36 2E 33 30 34 31 38 2C 45 2C 30 2E  
00216.30418,E,0.
  0030  30 39 30 2C 2C 30 31 30 36 31 36 2C 2C 2C 41 2A  
090,,010616,,,A*
  0040  37 33 0D 0A  73
15:42:31    24 47 50 56 54 47 2C 2C 54 2C 2C 4D 2C 30 2E 30  
$GPVTG,,T,,M,0.0
  0010  39 30 2C 4E 2C 30 2E 31 36 36 2C 4B 2C 41 2A 32  
90,N,0.166,K,A*2
  0020  42 0D 0A B
15:42:31    24 47 50 47 47 41 2C 31 35 34 32 33 31 2E 30 30  
$GPGGA,154231.00
  0010  2C 34 38 34 37 2E 33 35 31 39 30 2C 4E 2C 30 30  
,4847.35190,N,00
  0020  32 31 36 2E 33 30 34 31 38 2C 45 2C 31 2C 30 39  
216.30418,E,1,09
  0030  2C 30 2E 39 31 2C 31 38 39 2E 33 2C 4D 2C 34 36  
,0.91,189.3,M,46
  0040  2E 32 2C 4D 2C 2C 2A 35 34 0D 0A .2,M,,*54
15:42:31    24 47 50 47 53 41 2C 41 2C 33 2C 32 36 2C 32 31  
$GPGSA,A,3,26,21
  0010  2C 30 35 2C 32 37 2C 31 36 2C 32 39 2C 32 35 2C  
,05,27,16,29,25,
  0020  33 31 2C 32 30 2C 2C 2C 2C 31 2E 36 34 2C 30 2E  
31,201.64,0.
  0030  39 31 2C 31 2E 33 36 2A 30 31 0D 0A  91,1.36*01
15:42:31    24 47 50 47 53 56 2C 34 2C 31 2C 31 33 2C 30 34  
$GPGSV,4,1,13,04
  0010  2C 38 35 2C 32 39 39 2C 33 33 2C 30 35 2C 31 35  
,85,299,33,05,15
  0020  2C 30 34 36 2C 33 38 2C 30 39 2C 30 34 2C 33 32  
,046,38,09,04,32
  0030  39 2C 2C 31 36 2C 33 35 2C 33 30 32 2C 33 37 2A  
9,,16,35,302,37*
  0040  37 43 0D 0A  7C
15:42:31    24 47 50 47 53 56 2C 34 2C 32 2C 31 33 2C 31 38  
$GPGSV,4,2,13,18
  0010  2C 30 36 2C 31 34 35 2C 31 34 2C 32 30 2C 32 33  
,06,145,14,20,23
  0020  2C 30 39 33 2C 31 37 2C 32 31 2C 36 33 2C 31 35  
,093,17,21,63,15
  0030  34 2C 32 30 2C 32 33 2C 30 34 2C 33 30 33 2C 2A  
4,20,23,04,303,*
  0040  37 39 0D 0A  79
15:42:31    24 47 50 47 53 56 2C 34 2C 33 2C 31 33 2C 32 35  
$GPGSV,4,3,13,25
  0010  2C 31 35 2C 31 32 34 2C 31 35 2C 32 36 2C 36 36  
,15,124,15,26,66
  0020  2C 32 39 37 2C 34 34 2C 32 37 2C 31 32 2C 32 35  
,297,44,27,12,25
  0030  38 2C 31 34 2C 32 39 2C 33 37 2C 30 36 37 2C 33  
8,14,29,37,067,3
  0040  39 2A 37 43 0D 0A9*7C
15:42:31    24 47 50 47 53 56 2C 34 2C 34 2C 31 33 2C 33 31  
$GPGSV,4,4,13,31
  0010  2C 33 39 2C 32 30 38 2C 32 30 2A 34 42 0D 0A ,39,208,20*4B
15:42:31    24 47 50 47 4C 4C 2C 34 38 34 37 2E 33 35 31 39  
$GPGLL,4847.3519
  0010  30 2C 4E 2C 30 30 32 31 36 2E 33 30 34 31 38 2C  
0,N,00216.30418,
  0020  45 2C 31 35 34 32 33 31 2E 30 30 2C 41 2C 41 2A  
E,154231.00,A,A*
  

[time-nuts] Ublox Neo-6M time error.

[Mark Sims]

Versions past 8.16 no longer run on XP.   For versions 7 (and earlier) Ublox 
only offered a Windows downloader program to download the actual program.  That 
was what I ran into earlier.   I just downloaded the 8.16 version and it does 
work under XP and does not need a net connection. 

BTW, the Neo-6M documentation on the receiver version info message is wrong.  
They say it should return a packet a least 70 bytes long (with software 
version,  firmware version,  rom version, and optional feature versions).  The 
Neo-6M only returns 40 bytes (software version, firmware version).

--
> So I don't know what problem you're having, but I don't think it's caused by 
> ublox. 
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Ublox Neo-6M time error.

[Keenan Tims]

FYI, u-center works fine in Wine. It also works (and installs)
perfectly in a Windows VM without any network access. So I don't know
what problem you're having, but I don't think it's caused by ublox.

On 1 June 2016 at 14:02, Mark Sims  wrote:
> I have no idea... I can't run Ucenter.  It requires an internet connection to 
> run (or at least register).  All my current Windoze boxes are XP,  and 
> there's no way in hell I'm connecting an XP box to the internet.  Other GPS 
> makers don't have such a requirement to use their software,  so I avoid using 
> Ublox products.
>
> I'm pretty sure the issue is the "when does the time message come out in 
> relation to the 1PPS" question.  It seems Ublox is the odd man out compared 
> to the 11 other receivers from 6 different makers that I have tested.
>
> Oh, and whoever thought sending out sawtooth corrections after the 1PPS was a 
> good idea needs to treated to a severe atomic wedgie...
>
> ---
>> What does u-center report for the NEO-6M?
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[time-nuts] Ublox Neo-6M time error.

[Mark Sims]

I have no idea... I can't run Ucenter.  It requires an internet connection to 
run (or at least register).  All my current Windoze boxes are XP,  and there's 
no way in hell I'm connecting an XP box to the internet.  Other GPS makers 
don't have such a requirement to use their software,  so I avoid using Ublox 
products.

I'm pretty sure the issue is the "when does the time message come out in 
relation to the 1PPS" question.  It seems Ublox is the odd man out compared to 
the 11 other receivers from 6 different makers that I have tested.

Oh, and whoever thought sending out sawtooth corrections after the 1PPS was a 
good idea needs to treated to a severe atomic wedgie...

---
> What does u-center report for the NEO-6M? 
>   
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Ublox Neo-6M time error.

[Bob Stewart]

Hal, thanks for reminding me of what I ran into on the LEA-6T modules.  When 
you first power them on, they are often a second off in time.  It's not until 
the NAV-TIMEUTC->valid field returns a set validUTC flag that the time can be 
counted on.  But it usually doesn't take more than a minute or two after 
power-on that the flag gets set and the time jumps to valid time.

Bob

---
GFS GPSDO list:
groups.yahoo.com/neo/groups/GFS-GPSDOs/info


On Wed, 6/1/16, Hal Murray <hmur...@megapathdsl.net> wrote:

 Subject: Re: [time-nuts] Ublox Neo-6M time error.
 To: "Discussion of precise time and frequency measurement" <time-nuts@febo.com>
 Cc: hmur...@megapathdsl.net
 Date: Wednesday, June 1, 2016, 2:09 AM
 
 
 hol...@hotmail.com
 said:
 > The receiver is reporting the correct UTC offset and
 appears to be working
 > properly... it's just that the time is one second off
 from what 7 other
 > models of receivers are reporting... 
 
 I'm pretty sure that I've seen one GPS unit that was off by
 a second.  I'm 
 pretty sure it didn't get fixed by waiting a while. 
 But I don't remember 
 which type it was so this is just a rumor.
 
 I think I was using NMEA mode rather than a vendor specific
 binary mode.
 
 
 -- 
 These are my opinions.  I hate spam.
 
 
 
 ___
 time-nuts mailing list -- time-nuts@febo.com
 To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
 and follow the instructions there.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Ublox Neo-6M time error.

[Hal Murray]

hol...@hotmail.com said:
> The receiver is reporting the correct UTC offset and appears to be working
> properly... it's just that the time is one second off from what 7 other
> models of receivers are reporting... 

I'm pretty sure that I've seen one GPS unit that was off by a second.  I'm 
pretty sure it didn't get fixed by waiting a while.  But I don't remember 
which type it was so this is just a rumor.

I think I was using NMEA mode rather than a vendor specific binary mode.


-- 
These are my opinions.  I hate spam.



___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Ublox Neo-6M time error.

[Michael Wouters]

The local clock bias value reported by the Res T is the difference between
the receiver's clock and the reference time scale ( GPS or UTC). You need
it to correct the raw pseudo ranges reported by the receiver, which are
with respect to the receiver's clock.

Cheers
Michael

On Wednesday, 1 June 2016, Mark Sims  wrote:

> I had two machines running Lady Heather with the singing chime clock mode
> enabled (that plays a chant from the Missa Assumpta on the quarter hours).
>
> One machine was connected to a Ublox Neo-6M receiver and another to a
> Z3801A.   I noticed that the two machines sang their jaunty monk tunes
> offset by around one second.  Since a man with two singing GPS clocks never
> knows what time it is,  I replaced the Z3801A with a Jupiter-T and the two
> clocks were still out of sync.   Finally I tried  Motorola M12+ and UT
> receivers and the same thing happened.  It looks like the Ublox time is
> ahead by a second compared to all the other receivers.   I then specified a
> -1 second "rollover" correction to the Ublox machine and the two clocks
> sang in perfect harmony.   Has anybody noticed such behavior with other
> receivers?
>
> BTW,  note that the Ublox binary time message has a "fractional
> nanoseconds of the seconds field" (+/- 500,000 nanoseconds) correction that
> must be applied to the hrs:min:secs values (which I am doing).  The
> fractional time offset forms a sawtooth with around a 120 second period.
> Attached is a GIF... white is the nanosecond fractional time offset.
> Magenta is the receiver estimate of its time error (both in nanoseconds).
> The Trimble Resolution-T receivers report a similar "local clock bias"
> value, but they don't seem to document what it actually is...
>
>
>
>
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[time-nuts] Ublox Neo-6M time error.

[Mark Sims]

The receiver is reporting the correct UTC offset and appears to be working 
properly... it's just that the time is one second off from what 7 other models 
of receivers are reporting...


> Yup.  Quite common when the GPS is confused about the current leap seconds.


  
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Ublox Neo-6M time error.

[Tom Van Baak]

Hi Mark,

What does u-center report for the NEO-6M? Or how about TAC32?

Check the precise alignment of the 1PPS and the NMEA/binary/SCPI message stream.

Since the messages cannot coincide with the 1PPS, firmware has two choices: the 
message can describe the time of the previous 1PPS or the time of the next 
1PPS. Vendors differ. Depending on your software or how you receive the 1PPS or 
how you interpret the packets, there are possibilities for off-by-one second 
errors due to this.

The same issue occurs with sawtooth correction: is the correction for the 1PPS 
that just occurred a fraction of a second ago, or the correction for the 1PPS 
that will occur in a fraction of a second from now? Vendors differ.

The good news is that vendors all agree on NMEA: it's the time of the current 
second, not the next second. But the bad news is that this makes it impossible 
to handle UTC leap seconds with standard NMEA. By the time you find out there 
was a leap second it's too late. At least one vendor has a custom leap second 
pending NMEA message to work-around this.

/tvb

- Original Message - 
From: "Mark Sims" <hol...@hotmail.com>
To: <time-nuts@febo.com>
Sent: Tuesday, May 31, 2016 6:20 PM
Subject: [time-nuts] Ublox Neo-6M time error.


I had two machines running Lady Heather with the singing chime clock mode 
enabled (that plays a chant from the Missa Assumpta on the quarter hours).   

One machine was connected to a Ublox Neo-6M receiver and another to a Z3801A.   
I noticed that the two machines sang their jaunty monk tunes offset by around 
one second.  Since a man with two singing GPS clocks never knows what time it 
is,  I replaced the Z3801A with a Jupiter-T and the two clocks were still out 
of sync.   Finally I tried  Motorola M12+ and UT receivers and the same thing 
happened.  It looks like the Ublox time is ahead by a second compared to all 
the other receivers.   I then specified a -1 second "rollover" correction to 
the Ublox machine and the two clocks sang in perfect harmony.   Has anybody 
noticed such behavior with other receivers?

BTW,  note that the Ublox binary time message has a "fractional nanoseconds of 
the seconds field" (+/- 500,000 nanoseconds) correction that must be applied to 
the hrs:min:secs values (which I am doing).  The fractional time offset forms a 
sawtooth with around a 120 second period.  Attached is a GIF... white is the 
nanosecond fractional time offset.  Magenta is the receiver estimate of its 
time error (both in nanoseconds).  The Trimble Resolution-T receivers report a 
similar "local clock bias" value, but they don't seem to document what it 
actually is...



 





> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Ublox Neo-6M time error.

[Gary E. Miller]

Yo Mark!

On Wed, 1 Jun 2016 01:20:27 +
Mark Sims  wrote:

> Has anybody noticed such behavior with other receivers?

Yup.  Quite common when the GPS is confused about the current leap
seconds.

Usually a GPS will download the correct offset withing 30 mins of cold
start.

RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588


pgpbcuWgOxO_C.pgp
Description: OpenPGP digital signature
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[time-nuts] Ublox Neo-6M time error.

[Mark Sims]

I had two machines running Lady Heather with the singing chime clock mode 
enabled (that plays a chant from the Missa Assumpta on the quarter hours).   

One machine was connected to a Ublox Neo-6M receiver and another to a Z3801A.   
I noticed that the two machines sang their jaunty monk tunes offset by around 
one second.  Since a man with two singing GPS clocks never knows what time it 
is,  I replaced the Z3801A with a Jupiter-T and the two clocks were still out 
of sync.   Finally I tried  Motorola M12+ and UT receivers and the same thing 
happened.  It looks like the Ublox time is ahead by a second compared to all 
the other receivers.   I then specified a -1 second "rollover" correction to 
the Ublox machine and the two clocks sang in perfect harmony.   Has anybody 
noticed such behavior with other receivers?

BTW,  note that the Ublox binary time message has a "fractional nanoseconds of 
the seconds field" (+/- 500,000 nanoseconds) correction that must be applied to 
the hrs:min:secs values (which I am doing).  The fractional time offset forms a 
sawtooth with around a 120 second period.  Attached is a GIF... white is the 
nanosecond fractional time offset.  Magenta is the receiver estimate of its 
time error (both in nanoseconds).  The Trimble Resolution-T receivers report a 
similar "local clock bias" value, but they don't seem to document what it 
actually is...



  ___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.