On Thu, 27 Jul 2017 19:03:35 -0700
"Tom Van Baak" tvb@LeapSecond.com wrote:

Oops.. missed that part that this wasn't the normal NAV data.
But it is already transmitted by the IIR-M satellites. Though
only on L2CM and on L5. And L1C will have a different NAV message again...

		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

FWIW, the SkyTraq receivers have the notion of a “UTC reference date” which allows the 1024 week window to roll forward indefinitely as long as you update that value once in a while. I’ve written code in my GPS Clock to update the reference date once a year as well as update the default GPS-UTC delta whenever it’s wrong (this fixes the “off by 2 seconds for a minute or two” problem). This latter issue is an interesting one - If you supply SkyTraq modules with backup power, then on power up it will copy the GPS-UTC delta to flash, as long as the memory of what it was at shut down remains preserved.

The UTC reference date also allows the clock to workaround the Y2K issue in the NMEA sentences - you can query the reference date and use a 100 year rolling window similarly for that. As long as you power the clock up and give it reception at least once every 19 years or so, it should calculate the correct date as long as GPS remains available (this only really matters for the clock because it’s how DST decisions are made - it doesn’t actually display the date).

I haven’t done this for my GPSDOs because the controller isn’t wired to speak to the GPS receiver. But you can use the diagnostic port and SkyTraq’s GNSS viewer software to do this if you care to. The only use the GPSDO makes of the time/date is time-stamping the logs.

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@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@leapsecond.com wrote:

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

Hi,
I was running Tboltmon as the rollover occurred and did not see any phase shift. Old type Tbolt firmware 3.0
Maybe your phase offset was due to your Tbolt being in survey mode and its apparent position shifted .

Mike

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

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@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@leapsecond.com wrote:

service

the

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@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.

Hi Mike,

I'm pleased you saw no phase shift at all. Did you happen to have a TBoltmon log running?

The particular TBolt I used for the screen capture was powered up too soon before GPS midnight for the survey to complete. So I just entered the coordinates manually before the photo-op.

But if you look at the two images again, the phase shift may be due to a change in DAC value. My theory at this point is that the DAC voltage calculation includes at least one component based on slope; and slope implies elapsed time interval. A calculation like that would be upset if the underlying time frame changes by -1023 weeks instead of +1 week, or -7168 days instead of +1 day, etc. Or maybe the TBolt reset on rollover and went back to a previously saved DAC value. I don't know. But for those of you making your own GPSDO, keep subtle details like this in mind.

The duration of the recovery depends on the time constant. Notice that Mark uses a 500 s time constant and I used the default (100 s), so my TBolt recovered much quicker than his. I'll have more info as I sift through several TBolt's.

/tvb

----- Original Message -----
From: "Mike Cook" michael.cook@sfr.fr
To: "Tom Van Baak" tvb@leapsecond.com; "Discussion of precise time and frequency measurement" time-nuts@febo.com
Sent: Saturday, July 29, 2017 11:47 PM
Subject: Re: [time-nuts] Trimble Thunderbolt no longer determines the correct date

Hi,
I was running Tboltmon as the rollover occurred and did not see any phase shift. Old type Tbolt firmware 3.0
Maybe your phase offset was due to your Tbolt being in survey mode and its apparent position shifted .

Mike

Unfortunately I did not have the log activated.

Although I did not see a phase shift I think that that may be just luck as looking back at the screen print of tboltmon 1 sec after the roll, I see that the DAC voltage changed by +0,00533mV from the value 10mins prior to the roll. My antenna is not positioned optimally so I am used to seeing occasional 40-200ns phase offsets due to multi path. My phase shift before rollover (-9min) was -118ns and drifting toward 0. The Tbolt and only been powered on 4Hrs prior to rollover but was in position hold and had a good almanac.  At rollover +1s it was 50,52ns and at 41secs after rollover the offset was 127,66ns so I didn’t think it unusual. Looking at it again, I see that the 10MHz frequency offset was 0,10ppb prior to the rollover , but 2.01ppb at +1s , so it looks like I did get a glitch, but one of lesser magnitude than you reported.

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