Empathy List Archives

MC

Mike Cook

Wed, Jan 28, 2015 10:42 AM

I have verified the Skytraq claim on my stand alone NS-T.

Tue Jan 27 06:52:06 UTC 2015 $GPGGA,065206.000,4847.3506,N,00216.3005,E,1,06,1.3,191.0,M,47.0,M,,000059
Tue Jan 27 06:52:06 UTC 2015 $GPGLL,4847.3506,N,00216.3005,E,065206.000,A,A52
Tue Jan 27 06:52:06 UTC 2015 $GPGSA,A,3,04,01,22,28,27,11,,,,,,,2.1,1.3,1.73F
Tue Jan 27 06:52:06 UTC 2015 $GPGSV,2,1,07,04,83,016,40,11,77,287,36,01,57,288,47,28,29,299,427E
Tue Jan 27 06:52:06 UTC 2015 $GPGSV,2,2,07,03,28,223,09,22,25,056,41,27,21,149,2642
Tue Jan 27 06:52:06 UTC 2015 $GPRMC,065206.000,A,4847.3506,N,00216.3005,E,000.0,000.0,270115,,,A65
Tue Jan 27 06:52:06 UTC 2015 $GPVTG,000.0,T,,M,000.0,N,000.0,K,A0D
Tue Jan 27 06:52:06 UTC 2015 $GPZDA,065206.000,27,01,2015,00,0053

Using the GNSS gui, Query Timing, get a NAK. Monitoring 1PPS gets blank.

When booting from Flash, the quantization error of +/-6ns was verifiable both with Monitor Timing on the GUI and on my scope triggered from my T-Bolt..
When booting from ROM it doesn’t seem to be any worse than +/-10ns .

I would think that the lower quantization error would enable better phase locking in a GPSDO, especially with a long time constant, which is why I bought the device in the first place. So anyone with an LTE-Lite may just prefer to not use the NMEA stream until a new firmware becomes available, rather than use the WA. It would be of interest to others to see what booting from ROM makes in practice with the LTE-Lite.

One observation that I will make is that TTFF is MUCH faster when booting from ROM, and the device is MUCH more sensitive. I can pull in twice the number of SATS when booting from ROM. I am getting HDOP figure <1…wow! The reason why my receiver is not glued to a PRS10 at the moment is that I kept losing 3D Position fix according to the GUI when booted from Flash, even though when in Static mode the 1PPS looked good.

"Ceux qui sont prêts à abandonner une liberté essentielle pour obtenir une petite et provisoire sécurité, ne méritent ni liberté ni sécurité."
Benjimin Franklin

Le 27 janv. 2015 à 02:29, Bill Beam wbeam@gci.net a écrit :

Be careful with 'eyeball data'. GPS receiver does not generate NMEA time data and the leading edge of PPS at the same time.
Programs like Tac32 (totally accurate clock) and Lady Heather increment the time display at the leading edge of PPS with a
value 1 second greater than the previous NMEA data time.

I am able to run multiple GPS receivers into multiple computers running Tac32. The LTE-lite displays one second earlier than
all the others.

Prior to the announcement of "Leap Second Pending" in the GPS data stream the LTE-lite agreed with all other units. Now it does not.

On Mon, 26 Jan 2015 22:59:36 +0100, Mike Cook wrote:

Yes there is certainly an error here:
With my timing module I was just eyeballing the output on a windows platform , comparing GUI data.
I have just linked the module up to a BeagleBone Black syncG�d with NTP and this is the NMEA msg log:

root@bb3:/home/mike/serial-ports# while read GGA; do echo date $GGA; done < /dev/ttyO4
Mon Jan 26 21:51:07 UTC 2015 $GPGGA,215106.000,4847.3526,N,00216.3005,E,1,04,2.8,192.8,M,47.0,M,,00005C
Mon Jan 26 21:51:07 UTC 2015 $GPGLL,4847.3526,N,00216.3005,E,215106.000,A,A56
Mon Jan 26 21:51:07 UTC 2015 $GPGSA,A,3,25,12,06,31,,,,,,,,,3.0,2.8,1.03A
Mon Jan 26 21:51:07 UTC 2015 $GPRMC,215106.000,A,4847.3526,N,00216.3005,E,000.0,173.5,260115,,,A60
Mon Jan 26 21:51:07 UTC 2015 $GPVTG,173.5,T,,M,000.0,N,000.0,K,A0D
Mon Jan 26 21:51:07 UTC 2015 $GPZDA,215106.000,26,01,2015,00,0054
Mon Jan 26 21:51:07 UTC 2015 $PSTI,00,2,0,4.6,,*30

snip

The time data is all a second late so they appear to have a serious issue.

Le 26 janv. 2015 +� 02:47, Bill Beam wbeam@gci.net a +�crit :

snip

Odd indeed. My LTE-lite is one second late, appears to have already added the pending leap second.
I can compare with four other GPS timeing receivers using time pulse on DCD line. The NMEA data
reports in error.

snip

Bill Beam
NL7F

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.

I have verified the Skytraq claim on my stand alone NS-T. Tue Jan 27 06:52:06 UTC 2015 $GPGGA,065206.000,4847.3506,N,00216.3005,E,1,06,1.3,191.0,M,47.0,M,,0000*59 Tue Jan 27 06:52:06 UTC 2015 $GPGLL,4847.3506,N,00216.3005,E,065206.000,A,A*52 Tue Jan 27 06:52:06 UTC 2015 $GPGSA,A,3,04,01,22,28,27,11,,,,,,,2.1,1.3,1.7*3F Tue Jan 27 06:52:06 UTC 2015 $GPGSV,2,1,07,04,83,016,40,11,77,287,36,01,57,288,47,28,29,299,42*7E Tue Jan 27 06:52:06 UTC 2015 $GPGSV,2,2,07,03,28,223,09,22,25,056,41,27,21,149,26*42 Tue Jan 27 06:52:06 UTC 2015 $GPRMC,065206.000,A,4847.3506,N,00216.3005,E,000.0,000.0,270115,,,A*65 Tue Jan 27 06:52:06 UTC 2015 $GPVTG,000.0,T,,M,000.0,N,000.0,K,A*0D Tue Jan 27 06:52:06 UTC 2015 $GPZDA,065206.000,27,01,2015,00,00*53 Using the GNSS gui, Query Timing, get a NAK. Monitoring 1PPS gets blank. When booting from Flash, the quantization error of +/-6ns was verifiable both with Monitor Timing on the GUI and on my scope triggered from my T-Bolt.. When booting from ROM it doesn’t seem to be any worse than +/-10ns . I would think that the lower quantization error would enable better phase locking in a GPSDO, especially with a long time constant, which is why I bought the device in the first place. So anyone with an LTE-Lite may just prefer to not use the NMEA stream until a new firmware becomes available, rather than use the WA. It would be of interest to others to see what booting from ROM makes in practice with the LTE-Lite. One observation that I will make is that TTFF is MUCH faster when booting from ROM, and the device is MUCH more sensitive. I can pull in twice the number of SATS when booting from ROM. I am getting HDOP figure <1…wow! The reason why my receiver is not glued to a PRS10 at the moment is that I kept losing 3D Position fix according to the GUI when booted from Flash, even though when in Static mode the 1PPS looked good. "Ceux qui sont prêts à abandonner une liberté essentielle pour obtenir une petite et provisoire sécurité, ne méritent ni liberté ni sécurité." Benjimin Franklin > Le 27 janv. 2015 à 02:29, Bill Beam <wbeam@gci.net> a écrit : > > Be careful with 'eyeball data'. GPS receiver does not generate NMEA time data and the leading edge of PPS at the same time. > Programs like Tac32 (totally accurate clock) and Lady Heather increment the time display at the leading edge of PPS with a > value 1 second greater than the previous NMEA data time. > > I am able to run multiple GPS receivers into multiple computers running Tac32. The LTE-lite displays one second earlier than > all the others. > > Prior to the announcement of "Leap Second Pending" in the GPS data stream the LTE-lite agreed with all other units. Now it does not. > > On Mon, 26 Jan 2015 22:59:36 +0100, Mike Cook wrote: > >> Yes there is certainly an error here: >> With my timing module I was just eyeballing the output on a windows platform , comparing GUI data. >> I have just linked the module up to a BeagleBone Black syncG�d with NTP and this is the NMEA msg log: > >> root@bb3:/home/mike/serial-ports# while read GGA; do echo `date` $GGA; done < /dev/ttyO4 >> Mon Jan 26 21:51:07 UTC 2015 $GPGGA,215106.000,4847.3526,N,00216.3005,E,1,04,2.8,192.8,M,47.0,M,,0000*5C >> Mon Jan 26 21:51:07 UTC 2015 $GPGLL,4847.3526,N,00216.3005,E,215106.000,A,A*56 >> Mon Jan 26 21:51:07 UTC 2015 $GPGSA,A,3,25,12,06,31,,,,,,,,,3.0,2.8,1.0*3A >> Mon Jan 26 21:51:07 UTC 2015 $GPRMC,215106.000,A,4847.3526,N,00216.3005,E,000.0,173.5,260115,,,A*60 >> Mon Jan 26 21:51:07 UTC 2015 $GPVTG,173.5,T,,M,000.0,N,000.0,K,A*0D >> Mon Jan 26 21:51:07 UTC 2015 $GPZDA,215106.000,26,01,2015,00,00*54 >> Mon Jan 26 21:51:07 UTC 2015 $PSTI,00,2,0,4.6,,*30 > > snip > >> The time data is all a second late so they appear to have a serious issue. > >>> Le 26 janv. 2015 +� 02:47, Bill Beam <wbeam@gci.net> a +�crit : > > snip > >>> Odd indeed. My LTE-lite is one second late, appears to have already added the pending leap second. >>> I can compare with four other GPS timeing receivers using time pulse on DCD line. The NMEA data >>> reports in error. > > snip > > > > Bill Beam > NL7F > > > > _______________________________________________ > 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.

GH

Gerhard Hoffmann

Wed, Jan 28, 2015 1:41 PM

Am 28.01.2015 um 00:23 schrieb Magnus Danielson:

It locks it up with a PLL. See page 9 in PDF below, smack in the
middle is the input circuit and PLL.

This page also gives you all the hints of how to wire in a better
oscillator if you wish.

2 I have seen that the manual has a parts list and references the
circuit
diagrams, but they are not included in the pdf. Are the circuits
somewhere
out there?

http://www.ko4bb.com/manuals/81.226.54.139/SR620_Universal_Time_Interval_Counter_Schematics.pdf

Simply pasting the link did not work, but it was close enough :-)

Thanks, also to Charles!

After Bob's comment, I have ordered it with the oven. Should be here in
.de in a good week.

My 5370A has become so unreliable that it needs replacement.

What issues do you see?

Erratic blinking of the display, probably column drivers, but not only,
bad switches that
seem to stick now & then.. For some time, it was enough to remove and
re-insert the
boards, but no more. I don't have the time now to look deeply into it.
All would not be lost. It has a nice 10811.

regards, Gerhard

Am 28.01.2015 um 00:23 schrieb Magnus Danielson: > > It locks it up with a PLL. See page 9 in PDF below, smack in the > middle is the input circuit and PLL. > > This page also gives you all the hints of how to wire in a better > oscillator if you wish. > >> 2 I have seen that the manual has a parts list and references the >> circuit >> diagrams, but they are not included in the pdf. Are the circuits >> somewhere >> out there? > > http://www.ko4bb.com/manuals/81.226.54.139/SR620_Universal_Time_Interval_Counter_Schematics.pdf > Simply pasting the link did not work, but it was close enough :-) Thanks, also to Charles! After Bob's comment, I have ordered it with the oven. Should be here in .de in a good week. >> My 5370A has become so unreliable that it needs replacement. > > What issues do you see? > Erratic blinking of the display, probably column drivers, but not only, bad switches that seem to stick now & then.. For some time, it was enough to remove and re-insert the boards, but no more. I don't have the time now to look deeply into it. All would not be lost. It has a nice 10811. regards, Gerhard

TV

Tom Van Baak

Wed, Jan 28, 2015 5:27 PM

I have verified the Skytraq claim on my stand alone NS-T.
Tue Jan 27 06:52:06 UTC 2015 $GPGGA,065206.000,4847.3506

Hi Mike,

Please use more precise timestamps so your results can be believed. In general it's not adequate to use one second unix time stamps to identify a possible one second NMEA error.

Instead try using something like dateu.c (www.leapsecond.com/tools/) to output microsecond timestamps.

/tvb

> I have verified the Skytraq claim on my stand alone NS-T. > Tue Jan 27 06:52:06 UTC 2015 $GPGGA,065206.000,4847.3506 Hi Mike, Please use more precise timestamps so your results can be believed. In general it's not adequate to use one second unix time stamps to identify a possible one second NMEA error. Instead try using something like dateu.c (www.leapsecond.com/tools/) to output microsecond timestamps. /tvb

KL

Keith Loiselle

Wed, Jan 28, 2015 6:31 PM

Skytraq has provided updated firmware that corrects the 1 second offset.
For those who have not already, please contact us off list for return
instructions to have your unit updated.

Thank you for your patience with this issue. According to Skytraq the
error was introduced when code was added based on a customer request.

Keith

On Wed, Jan 28, 2015 at 9:27 AM, Tom Van Baak tvb@leapsecond.com wrote:

I have verified the Skytraq claim on my stand alone NS-T.
Tue Jan 27 06:52:06 UTC 2015 $GPGGA,065206.000,4847.3506

Hi Mike,

Please use more precise timestamps so your results can be believed. In
general it's not adequate to use one second unix time stamps to identify a
possible one second NMEA error.

Instead try using something like dateu.c (www.leapsecond.com/tools/) to
output microsecond timestamps.

/tvb

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.

Skytraq has provided updated firmware that corrects the 1 second offset. For those who have not already, please contact us off list for return instructions to have your unit updated. Thank you for your patience with this issue. According to Skytraq the error was introduced when code was added based on a customer request. Keith Keith On Wed, Jan 28, 2015 at 9:27 AM, Tom Van Baak <tvb@leapsecond.com> wrote: > > I have verified the Skytraq claim on my stand alone NS-T. > > Tue Jan 27 06:52:06 UTC 2015 $GPGGA,065206.000,4847.3506 > > Hi Mike, > > Please use more precise timestamps so your results can be believed. In > general it's not adequate to use one second unix time stamps to identify a > possible one second NMEA error. > > Instead try using something like dateu.c (www.leapsecond.com/tools/) to > output microsecond timestamps. > > /tvb > > _______________________________________________ > 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. >

MC

Mike Cook

Wed, Jan 28, 2015 6:33 PM

Le 28 janv. 2015 à 18:27, Tom Van Baak tvb@LeapSecond.com a écrit :

I have verified the Skytraq claim on my stand alone NS-T.
Tue Jan 27 06:52:06 UTC 2015 $GPGGA,065206.000,4847.3506

Hi Mike,

Please use more precise timestamps so your results can be believed. In general it's not adequate to use one second unix time stamps to identify a possible one second NMEA error.

Thanks for the pointer Tom. I realize that it was not ideal and that some NMEA traffic can leak into the following second if there is enough or if the serial baud rate is too low , but the results with my lash up looked unambiguous. I wouldn’t use the same method for any analysis.

Bit of news from my supplier. They have said they will send me a new module with corrected firmware. All I requested was the firmware. Nice of them.

Mike

Instead try using something like dateu.c (www.leapsecond.com/tools/) to output microsecond timestamps.

/tvb

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.

> Le 28 janv. 2015 à 18:27, Tom Van Baak <tvb@LeapSecond.com> a écrit : > >> I have verified the Skytraq claim on my stand alone NS-T. >> Tue Jan 27 06:52:06 UTC 2015 $GPGGA,065206.000,4847.3506 > > Hi Mike, > > Please use more precise timestamps so your results can be believed. In general it's not adequate to use one second unix time stamps to identify a possible one second NMEA error. > Thanks for the pointer Tom. I realize that it was not ideal and that some NMEA traffic can leak into the following second if there is enough or if the serial baud rate is too low , but the results with my lash up looked unambiguous. I wouldn’t use the same method for any analysis. Bit of news from my supplier. They have said they will send me a new module with corrected firmware. All I requested was the firmware. Nice of them. Mike > Instead try using something like dateu.c (www.leapsecond.com/tools/) to output microsecond timestamps. > > /tvb > > _______________________________________________ > 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.

DJ

Didier Juges

Thu, Jan 29, 2015 11:32 AM

"Simply pasting the link did not work, but it was close enough :-)"

The links that include an IP address (like 81.226.54.139 below) only work until midnight EST, then they are cleared.

It is easy enough (but not necessarily intuitive) to go to the manuals page and search again for the document.

I am trying to come up with a scheme that will create a permanent link. Bear with me a little longer...

Didier KO4BB

On January 28, 2015 7:41:59 AM CST, Gerhard Hoffmann dk4xp@arcor.de wrote:

Am 28.01.2015 um 00:23 schrieb Magnus Danielson:

It locks it up with a PLL. See page 9 in PDF below, smack in the
middle is the input circuit and PLL.

This page also gives you all the hints of how to wire in a better
oscillator if you wish.

2 I have seen that the manual has a parts list and references the
circuit
diagrams, but they are not included in the pdf. Are the circuits
somewhere
out there?

http://www.ko4bb.com/manuals/81.226.54.139/SR620_Universal_Time_Interval_Counter_Schematics.pdf

Simply pasting the link did not work, but it was close enough :-)

Thanks, also to Charles!

After Bob's comment, I have ordered it with the oven. Should be here
in
.de in a good week.

My 5370A has become so unreliable that it needs replacement.

What issues do you see?

Erratic blinking of the display, probably column drivers, but not only,

bad switches that
seem to stick now & then.. For some time, it was enough to remove and
re-insert the
boards, but no more. I don't have the time now to look deeply into it.
All would not be lost. It has a nice 10811.

regards, Gerhard

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.

--
Sent from my Motorola Droid Razr HD 4G LTE wireless tracker while I do other things.

"Simply pasting the link did not work, but it was close enough :-)" The links that include an IP address (like 81.226.54.139 below) only work until midnight EST, then they are cleared. It is easy enough (but not necessarily intuitive) to go to the manuals page and search again for the document. I am trying to come up with a scheme that will create a permanent link. Bear with me a little longer... Didier KO4BB On January 28, 2015 7:41:59 AM CST, Gerhard Hoffmann <dk4xp@arcor.de> wrote: >Am 28.01.2015 um 00:23 schrieb Magnus Danielson: >> >> It locks it up with a PLL. See page 9 in PDF below, smack in the >> middle is the input circuit and PLL. >> >> This page also gives you all the hints of how to wire in a better >> oscillator if you wish. >> >>> 2 I have seen that the manual has a parts list and references the >>> circuit >>> diagrams, but they are not included in the pdf. Are the circuits >>> somewhere >>> out there? >> >> >http://www.ko4bb.com/manuals/81.226.54.139/SR620_Universal_Time_Interval_Counter_Schematics.pdf > >> > >Simply pasting the link did not work, but it was close enough :-) > >Thanks, also to Charles! > >After Bob's comment, I have ordered it with the oven. Should be here >in >.de in a good week. > >>> My 5370A has become so unreliable that it needs replacement. >> >> What issues do you see? >> >Erratic blinking of the display, probably column drivers, but not only, > >bad switches that >seem to stick now & then.. For some time, it was enough to remove and >re-insert the >boards, but no more. I don't have the time now to look deeply into it. >All would not be lost. It has a nice 10811. > >regards, Gerhard >_______________________________________________ >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. -- Sent from my Motorola Droid Razr HD 4G LTE wireless tracker while I do other things.

KL

Keith Loiselle

Mon, Feb 2, 2015 5:35 PM

We have received some additional information from Skytraq regarding the
leap second error:

"The faulty version firmware indicates leap seconds (17) from now to June
16th (two weeks before June 30th). During June 16th ~ June 30th, leap
second will recover to 16 and change properly to 17 on June 30th midnight.
For future leap seconds, if the leap second change is still broadcasted
ahead of time for more than 2 weeks, it'll still have this problem for
coming leap seconds."

Keith

On Wed, Jan 28, 2015 at 9:27 AM, Tom Van Baak tvb@leapsecond.com wrote:

I have verified the Skytraq claim on my stand alone NS-T.
Tue Jan 27 06:52:06 UTC 2015 $GPGGA,065206.000,4847.3506

Hi Mike,

Please use more precise timestamps so your results can be believed. In
general it's not adequate to use one second unix time stamps to identify a
possible one second NMEA error.

Instead try using something like dateu.c (www.leapsecond.com/tools/) to
output microsecond timestamps.

/tvb

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.

We have received some additional information from Skytraq regarding the leap second error: "The faulty version firmware indicates leap seconds (17) from now to June 16th (two weeks before June 30th). During June 16th ~ June 30th, leap second will recover to 16 and change properly to 17 on June 30th midnight. For future leap seconds, if the leap second change is still broadcasted ahead of time for more than 2 weeks, it'll still have this problem for coming leap seconds." Keith Keith On Wed, Jan 28, 2015 at 9:27 AM, Tom Van Baak <tvb@leapsecond.com> wrote: > > I have verified the Skytraq claim on my stand alone NS-T. > > Tue Jan 27 06:52:06 UTC 2015 $GPGGA,065206.000,4847.3506 > > Hi Mike, > > Please use more precise timestamps so your results can be believed. In > general it's not adequate to use one second unix time stamps to identify a > possible one second NMEA error. > > Instead try using something like dateu.c (www.leapsecond.com/tools/) to > output microsecond timestamps. > > /tvb > > _______________________________________________ > 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. >

KL

Keith Loiselle

Tue, Feb 3, 2015 5:33 AM

NAVCEN issued an alert regarding receiver errors in handling the current
pending leap second data like has occurred with the Skytraq receiver.
Several brands/models were affected. I have not seen the original alert,
but here is an article summarizing:

http://www.insidegnss.com/node/4398

Keith

On Mon, Feb 2, 2015 at 9:35 AM, Keith Loiselle keith.loiselle@gmail.com
wrote:

We have received some additional information from Skytraq regarding the
leap second error:

"The faulty version firmware indicates leap seconds (17) from now to June
16th (two weeks before June 30th). During June 16th ~ June 30th, leap
second will recover to 16 and change properly to 17 on June 30th midnight.
For future leap seconds, if the leap second change is still broadcasted
ahead of time for more than 2 weeks, it'll still have this problem for
coming leap seconds."

Keith

On Wed, Jan 28, 2015 at 9:27 AM, Tom Van Baak tvb@leapsecond.com wrote:

I have verified the Skytraq claim on my stand alone NS-T.
Tue Jan 27 06:52:06 UTC 2015 $GPGGA,065206.000,4847.3506

Hi Mike,

Please use more precise timestamps so your results can be believed. In
general it's not adequate to use one second unix time stamps to identify a
possible one second NMEA error.

Instead try using something like dateu.c (www.leapsecond.com/tools/) to
output microsecond timestamps.

/tvb

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.

NAVCEN issued an alert regarding receiver errors in handling the current pending leap second data like has occurred with the Skytraq receiver. Several brands/models were affected. I have not seen the original alert, but here is an article summarizing: http://www.insidegnss.com/node/4398 Keith Keith On Mon, Feb 2, 2015 at 9:35 AM, Keith Loiselle <keith.loiselle@gmail.com> wrote: > We have received some additional information from Skytraq regarding the > leap second error: > > "The faulty version firmware indicates leap seconds (17) from now to June > 16th (two weeks before June 30th). During June 16th ~ June 30th, leap > second will recover to 16 and change properly to 17 on June 30th midnight. > For future leap seconds, if the leap second change is still broadcasted > ahead of time for more than 2 weeks, it'll still have this problem for > coming leap seconds." > > Keith > > > > Keith > > On Wed, Jan 28, 2015 at 9:27 AM, Tom Van Baak <tvb@leapsecond.com> wrote: > >> > I have verified the Skytraq claim on my stand alone NS-T. >> > Tue Jan 27 06:52:06 UTC 2015 $GPGGA,065206.000,4847.3506 >> >> Hi Mike, >> >> Please use more precise timestamps so your results can be believed. In >> general it's not adequate to use one second unix time stamps to identify a >> possible one second NMEA error. >> >> Instead try using something like dateu.c (www.leapsecond.com/tools/) to >> output microsecond timestamps. >> >> /tvb >> >> _______________________________________________ >> 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. >> > >

MC

Mike Cook

Tue, Feb 10, 2015 2:48 PM

Just to let you know that I received my replacement NS-T receiver and verified that that problem is fixed.

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.

Just to let you know that I received my replacement NS-T receiver and verified that that problem is fixed. >> _______________________________________________ >> 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@lists.febo.com

LTE Lite time error