[time-nuts] Trimble Thunderbolt no longer determines thecorrect date

[Didier Juges]

Tom,

The sticker is a good idea. I will add an electronic equivalent: a user
selectable alarm to inform the user of impending week rollover on GPS week
935, the way the Thunderbolt sets an alarm for impending leap second.
Thanks for the tip :)

I use a routine that uses 1970 as a reference but still works before, it
simply returns a negative number of days for days before 1970. It uses 32
bit variables and works well with my 8 bit microcontroller and as of this
morning it is working fine.

I should have the alarm code done today. I will post an update here and on
my web site when it's available.

Didier



On Jul 29, 2017 10:19 PM, "Tom Van Baak" <tvb at leapsecond.com> wrote:

Hi Didier,

I concur with your decision about the manual selection of epoch. That
sounds safer and simpler to me also. Pick the default so your LCD monitor
works out-of-the-box for all TBolt's starting today. Add a cute sticker
that says: press menu on 2037-03-15. I'll sign up to be your first customer
when you roll the new firmware.

I suspect you don't have to code that 936 number; all you have to do is add
N*1024 to the TBolt-reported GPS WN and let the user pick N. So that's just
three lines of code, not counting the pair of day number conversion
functions.

Mark uses JD. I use MJD. An Excel date would work. A 32-bit unsigned unix
time_t would also work since it only needs to work from 1980 (or 2017) to
maybe 2080 or 2100 at the most. If you want some fun, there are many
days-between-two-calendar-dates algorithms on the web. In fact, before
PC's, web, and mobile apps, there were lots of cool pocket calculator
algorithms for doing these day calculations.

/tvb

----- Original Message -----
From: Didier Juges
To: Tom Van Baak ; Discussion of precise time and frequency measurement
Sent: Saturday, July 29, 2017 6:20 PM
Subject: Re: [time-nuts] Trimble Thunderbolt no longer determines
thecorrect date


Tom,


Since my monitor does not mess with the TBolt data as it passes through (by
design and intentionally), the only issue is to keep the LCD display
correct.
My personal preference has always been that if I cannot come up with a very
robust method, I give the user the tools to deal with it himself.

Therefore, rather than using a routine like Mark is doing in Lady Heather
(which would seem to be fairly robust), I have added a menu selection where
the user can enter an epoch number and the kit will add the proper number
of weeks to the display accordingly.


The Thunderbolt manual indicates that for weeks before 936, they add 1024
weeks, so for the last few years and until tomorrow, they have been adding
1024 weeks and the date is OK. Then on the 31st, the week will be 936 and
they will not add 1024 so they will be behind 1024 weeks for another 19.6
years. When I wrote the previous email, I wrongly assumed they would be off
by two epochs, that does not seem to be the case after re-reading the
manual.


Anyhow, since such operation will only be required every 20 years or so,
that should be good enough, and in the mean time there will not be an issue
if the rollover detection has worked or not, or if it has been corrupted by
bad data. Seems worth it to me :) PC users have a back up time and date
source (the internet), so an error in the date would be quickly identified,
not so with a stand alone monitor. The little WiFi module I use on my
monitor is advertised as having SNTP capability, but being hard coded to
servers in China, I have decided not to take advantage of it.


I admire the decision to increase the bit count from 10 to 13 (what's wrong
with 16?) There is a very significant difference between 10 and 13 bits.
With 10 bits, whomever came up with that idea might not yet be retired when
that shortsightedness becomes apparent. With 13 bits, odds are good that he
will not only have been retired but have also passed away for a while.
That's good thinking!


Didier






On Fri, Jul 28, 2017 at 1:26 AM, Tom Van Baak <tvb at leapsecond.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.

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


_______________________________________________
time-nuts mailing list -- time-nuts at 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 at febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/
mailman/listinfo/time-nuts
and follow the instructions there.