Trimble Thunderbolt no longer determines the correct date
Hi,
It came to our attention at Jackson Labs that the Trimble Thunderbolt will
fail to start with the correct date after July 30, 2017. See the clip
from the Thunderbolt manual below.
Does anyone have any updates from Trimble regarding fixes for this
problem? Does does this affect other Trimble products (i.e. Mini-T,
Resolution T) in the same way?
[image: Inline image 1]
Please note that Jackson Labs products are not affected by the up-coming
April 2019 GPS week roll over, and can determine the correct date until the
following dates:
uBlox-8 based products - 4/24/2033
uBlox-6 based products - 5/12/2030
Legacy uBlox-5 based products - 12/3/2028
Thanks,
Keith
Since the Thunderbolt is hard coded to detect a particular week to
determine if it should add 1024 to the week number, I would guess that each
product has a magic date based on the anticipated release date of the
product (week 936 for the Thunderbolt), and it will work for 1024 weeks
from that date.
I cannot imagine a work around since the problem stems from the GPS service
only identifying the current date within a particular 1024 weeks epoch
unless the government changes the amount of data that is sent over the GPS
system. Somebody has to use other method to determine the epoch and add the
corresponding offset.
On Thu, Jul 27, 2017 at 12:36 PM, Keith Loiselle keith.loiselle@gmail.com
wrote:
Hi,
It came to our attention at Jackson Labs that the Trimble Thunderbolt will
fail to start with the correct date after July 30, 2017. See the clip
from the Thunderbolt manual below.
Does anyone have any updates from Trimble regarding fixes for this
problem? Does does this affect other Trimble products (i.e. Mini-T,
Resolution T) in the same way?
[image: Inline image 1]
Please note that Jackson Labs products are not affected by the up-coming
April 2019 GPS week roll over, and can determine the correct date until the
following dates:
uBlox-8 based products - 4/24/2033
uBlox-6 based products - 5/12/2030
Legacy uBlox-5 based products - 12/3/2028
Thanks,
Keith
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.
On Thu, 27 Jul 2017 17:49:14 -0500
Didier Juges shalimr9@gmail.com wrote:
I cannot imagine a work around since the problem stems from the GPS service
only identifying the current date within a particular 1024 weeks epoch
unless the government changes the amount of data that is sent over the GPS
system. Somebody has to use other method to determine the epoch and add the
corresponding offset.
There is: There is a 13bit week number in message type 10. This gives
a 157 year span instead of the ~19 years of the 10bit week number.
This has been part of the GPS standard since IS-GPS-200D which was
released in 2004. As such I am a little bit surprised that the u-blox
receivers still don't support this message (the LEA-5 family was released
in 2007 IIRC). But you can use the UBX RXM-SFRBX messages to get the
raw GPS messages and decode them yourself.
Attila Kinali
--
You know, the very powerful and the very stupid have one thing in common.
They don't alters their views to fit the facts, they alter the facts to
fit the views, which can be uncomfortable if you happen to be one of the
facts that needs altering. -- The Doctor
Well quite an unpleasant surprise. So after the 30th do the TBolts stop
working or is it a case of just the wrong date? I know my Hp3801s been
working just fine and its old. Is the TBolt the same issue. Wrong date but
still locks thats all I care about actually.
With to respect of some sort of a hack I can see that being fairly
difficult.
Regards
Paul
WB8TSL
On Thu, Jul 27, 2017 at 8:01 PM, Attila Kinali attila@kinali.ch wrote:
On Thu, 27 Jul 2017 17:49:14 -0500
Didier Juges shalimr9@gmail.com wrote:
I cannot imagine a work around since the problem stems from the GPS
service
only identifying the current date within a particular 1024 weeks epoch
unless the government changes the amount of data that is sent over the
GPS
system. Somebody has to use other method to determine the epoch and add
the
corresponding offset.
There is: There is a 13bit week number in message type 10. This gives
a 157 year span instead of the ~19 years of the 10bit week number.
This has been part of the GPS standard since IS-GPS-200D which was
released in 2004. As such I am a little bit surprised that the u-blox
receivers still don't support this message (the LEA-5 family was released
in 2007 IIRC). But you can use the UBX RXM-SFRBX messages to get the
raw GPS messages and decode them yourself.
Attila Kinali
--
You know, the very powerful and the very stupid have one thing in common.
They don't alters their views to fit the facts, they alter the facts to
fit the views, which can be uncomfortable if you happen to be one of the
facts that needs altering. -- The Doctor
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 seem to recall several people (tvb?) doing tests and determining that
the 10 MHz and PPS outputs will continue to function as normal, since
the Thunderbolt will continue to track and lock onto the satellites.
The only difference is it'd think the date and time were N weeks in the
past, where N is whatever offset they used. This can be corrected in
software, as Lady Heather does, or perhaps with some in-line device that
re-writes the serial data as it comes out of the Thunderbolt (I've been
tempted to make such a thing myself, but real-world commitments have
gotten in the way).
Cheers!
-Pete
--
Pete Stephenson
On Fri, Jul 28, 2017, at 02:36 AM, paul swed wrote:
Well quite an unpleasant surprise. So after the 30th do the TBolts stop
working or is it a case of just the wrong date? I know my Hp3801s been
working just fine and its old. Is the TBolt the same issue. Wrong date
but
still locks thats all I care about actually.
With to respect of some sort of a hack I can see that being fairly
difficult.
Regards
Paul
WB8TSL
On Thu, Jul 27, 2017 at 8:01 PM, Attila Kinali attila@kinali.ch wrote:
On Thu, 27 Jul 2017 17:49:14 -0500
Didier Juges shalimr9@gmail.com wrote:
I cannot imagine a work around since the problem stems from the GPS
service
only identifying the current date within a particular 1024 weeks epoch
unless the government changes the amount of data that is sent over the
GPS
system. Somebody has to use other method to determine the epoch and add
the
corresponding offset.
There is: There is a 13bit week number in message type 10. This gives
a 157 year span instead of the ~19 years of the 10bit week number.
This has been part of the GPS standard since IS-GPS-200D which was
released in 2004. As such I am a little bit surprised that the u-blox
receivers still don't support this message (the LEA-5 family was released
in 2007 IIRC). But you can use the UBX RXM-SFRBX messages to get the
raw GPS messages and decode them yourself.
Attila Kinali
--
You know, the very powerful and the very stupid have one thing in common.
They don't alters their views to fit the facts, they alter the facts to
fit the views, which can be uncomfortable if you happen to be one of the
facts that needs altering. -- The Doctor
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.
Well quite an unpleasant surprise. So after the 30th do the TBolts stop
Paul,
This topic has been covered a number of times over the years. Some time-nuts have even run TBolt's under GPS simulators to verify that the 10 MHz and 1PPS outputs will be fine. So apparently the only effect is that the date & time (in binary TSIP messages) are off by 1024 weeks. This rollover-related effect is by now a "common" issue with many GPS receivers.
The current version of Mark's Lady Heather program has code to detect this and fix it so you're good to go for the next 19.6 years.
/tvb
----- Original Message -----
From: "paul swed" paulswedb@gmail.com
To: "Discussion of precise time and frequency measurement" time-nuts@febo.com
Sent: Thursday, July 27, 2017 5:36 PM
Subject: Re: [time-nuts] Trimble Thunderbolt no longer determines thecorrect date
Well quite an unpleasant surprise. So after the 30th do the TBolts stop
working or is it a case of just the wrong date? I know my Hp3801s been
working just fine and its old. Is the TBolt the same issue. Wrong date but
still locks thats all I care about actually.
With to respect of some sort of a hack I can see that being fairly
difficult.
Regards
Paul
WB8TSL
There is: There is a 13bit week number in message type 10.
Attila,
Well, yes and no.
Yes -- paragraph 30.3.3.1.1.1 in www.gps.gov/technical/icwg/IS-GPS-200D.pdf describes a 13-bit extended week number.
No -- because this is part of the new CNAV format and existing GPS SV do not transmit that information.
Interesting links and PDF's if you google: "Transmission Week Number" CNAV
https://lists.ntpsec.org/pipermail/devel/2017-April/004331.html
https://lists.nongnu.org/archive/html/gpsd-dev/2016-07/msg00002.html
The new 13-bit week number is only provided by the new "CNAV" data,
which in turn is (or will be) available only in newly added GPS signals.
Based on the carrier frequencies used, only the newest of the new
signals (L1C) will be available to common civilian receivers, even with
compatible hardware and firmware. This signal is unavailable from
satellites earlier than Block III, which are currently (July 2016) not
expected to begin to launch earlier than September 2016. Given that it
takes years to launch a full constellation of satellites, it's highly
unlikely that CNAV data with "operational" status will be available to
common civilian receivers in time for the April 2019 10-bit rollover.
/tvb
Hi
On Jul 27, 2017, at 8:01 PM, Attila Kinali attila@kinali.ch wrote:
On Thu, 27 Jul 2017 17:49:14 -0500
Didier Juges shalimr9@gmail.com wrote:
I cannot imagine a work around since the problem stems from the GPS service
only identifying the current date within a particular 1024 weeks epoch
unless the government changes the amount of data that is sent over the GPS
system. Somebody has to use other method to determine the epoch and add the
corresponding offset.
There is: There is a 13bit week number in message type 10. This gives
a 157 year span instead of the ~19 years of the 10bit week number.
This has been part of the GPS standard since IS-GPS-200D which was
released in 2004.
The magic “extra bits” only get here when they launch the next block of GPS
sat’s. That was sure to happen in 2005 … 2007 ….2011 … Last time I saw, it
was out in 2018 / 2019. The “problem” is that the old ones are not dying as fast
as they should.
One would think that a simple re-shoot of firmware would get everything up to date.
That’s not the way they make these beasts. Again good news / bad news. The same
sort of approach makes them more reliable. It’s not the direct reason they are up
there longer though.
Bob
As such I am a little bit surprised that the u-blox
receivers still don't support this message (the LEA-5 family was released
in 2007 IIRC). But you can use the UBX RXM-SFRBX messages to get the
raw GPS messages and decode them yourself.
Attila Kinali
--
You know, the very powerful and the very stupid have one thing in common.
They don't alters their views to fit the facts, they alter the facts to
fit the views, which can be uncomfortable if you happen to be one of the
facts that needs altering. -- The Doctor
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.
Thanks I thought it would still work as the 3801 does.
On Thu, Jul 27, 2017 at 10:03 PM, Tom Van Baak tvb@leapsecond.com wrote:
There is: There is a 13bit week number in message type 10.
Attila,
Well, yes and no.
Yes -- paragraph 30.3.3.1.1.1 in www.gps.gov/technical/icwg/IS-
GPS-200D.pdf describes a 13-bit extended week number.
No -- because this is part of the new CNAV format and existing GPS SV do
not transmit that information.
Interesting links and PDF's if you google: "Transmission Week Number" CNAV
https://lists.ntpsec.org/pipermail/devel/2017-April/004331.html
https://lists.nongnu.org/archive/html/gpsd-dev/2016-07/msg00002.html
The new 13-bit week number is only provided by the new "CNAV" data,
which in turn is (or will be) available only in newly added GPS signals.
Based on the carrier frequencies used, only the newest of the new
signals (L1C) will be available to common civilian receivers, even with
compatible hardware and firmware. This signal is unavailable from
satellites earlier than Block III, which are currently (July 2016) not
expected to begin to launch earlier than September 2016. Given that it
takes years to launch a full constellation of satellites, it's highly
unlikely that CNAV data with "operational" status will be available to
common civilian receivers in time for the April 2019 10-bit rollover.
/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.
I cannot imagine a work around since the problem stems from the GPS service
only identifying the current date within a particular 1024 weeks epoch
unless the government changes the amount of data that is sent over the GPS
system. Somebody has to use other method to determine the epoch and add the
corresponding offset.
Didier,
There are work-arounds but none are perfect. Vendors have different approaches to determining the 1024 week (~19.6 year) GPS cycle. You can get the cycle or the year from the user. You can hardcode some base date and then increment the cycle each time a rollover is encountered and save in EEPROM. You can run in GPS mode and not worry about UTC or Gregorian dates at all. You can try to guess the cycle by hacking on the almanac or leap second info or other unspeakable acts. None of these is as robust as just a few having more week number bits, which is what the new signal format will provide.
I'm waiting until the TBolt rollover this weekend to see what actually happens to the date fields in packet 0x8F-AB. The work-around may be as simple as adding 1024 weeks. You mentioned it might be 2048 instead. I guess we'll find out in a couple of days. Additionally, I wonder if running GPS mode vs. UTC mode will make a difference. And I wonder if leap seconds will create an issue -- since the week number factors into the leap second count which is required for UTC; not to mention that a GPS week is not quite aligned with a UTC week. I wonder if being in holdover or not will make a difference. Or cold-start vs. warm-start, etc.
So you are wise to hold-off on your updated TBolt LCD monitor f/w until we see what actually happens. Sample code to add 1024 weeks is at www.leapsecond.com/tools/tbolt1.c if that's all it takes to patch the date field in the packet.
We've had people run TBolt's under GPS signal simulators and they report no loss of lock. However, a Trimble memo says a 2 hour holdover may occur, so I wonder which is right. I'm not worried either way. Instead I'll be logging outputs and TSIP from several TBolt's just to catch what happens, if anything.
/tvb