Re: [time-nuts] Trimble Thunderbolt no longer determines the correct date  

tim...@timeok.it said: >Hal, I suppose your opinion is correct. A friend has found the same > problem with an HPZ3016A GPSDO. The solution was to resetting the internal > counter inside the Motorola GPS module. To do this , the friend has removed > the GPS module and communicate using his

Re: [time-nuts] Trimble Thunderbolt no longer determines the correct date  

e, 29 Aug 2017 22:36:59 -0700 Oggetto Re: [time-nuts] Trimble Thunderbolt no longer determines the correct date w...@arrl.net said: > So, at this time is there a viable solution that will make the LCD read the > proper date? I am less concerned about the date showing accu

Re: [time-nuts] Trimble Thunderbolt no longer determines the correct date  

w...@arrl.net said: > So, at this time is there a viable solution that will make the LCD read the > proper date? I am less concerned about the date showing accurately on the > desktop Thunderbolt Monitor program. Many thanks! It's the GPS rollover problem. There is a 10 bit field for the week

[time-nuts] Trimble Thunderbolt no longer determines the correct date  

I'm late in the discussion. I rebooted my Thunderbolt this morning and it shows a date of 1998 in Thunderbolt Monitor -- and also shows the same incorrect date on my Thunderbolt's LCD display. I purchased the large LCD unit on eBay a few years ago but I no longer recall who supplied it. A photo

Re: [time-nuts] Trimble Thunderbolt no longer determines the correct date

On 08/11/2017 06:26 PM, Tom Van Baak wrote: The E911 installation, in the news, is just one of several. Others are hospitals, fire stations, etc. using different dispatch systems. Hey, at least important things like mobile phones, ISP's, Google, Amazon, FedEx and Starbucks aren't affected

Re: [time-nuts] Trimble Thunderbolt no longer determines the correct date

Hi My guess would be that the box the TBolts connect to uses a pretty limited set of messages. Like you, I’d hope that the firmware on the “other end” is happy with the E version. Bob > On Aug 11, 2017, at 6:09 PM, Mark Sims wrote: > > I wonder if they have tested their

[time-nuts] Trimble Thunderbolt no longer determines the correct date

I wonder if they have tested their system with a Thunderbolt-E? The -E is not necessarily a drop-in replacement for the original. There are a few differences between the original Tbolt messages and the -E messages. Some messages are different or unsupported and I know of a couple that

Re: [time-nuts] Trimble Thunderbolt no longer determines the correct date

On Thu, Aug 10, 2017 at 10:24 AM, Brad Dye wrote: > > I read here on the Time Nuts messages that some are considering: "some > in-line device that re-writes the serial data as it comes out of the > Thunderbolt” > An in-line device makes sense if you don't have control of

Re: [time-nuts] Trimble Thunderbolt no longer determines the correct date

Agreed. Re-inventing stuff from twenty years ago was uneconomic and possibly impossible when I was in Silicon Valley, twenty years ago. Jeremy On Fri, Aug 11, 2017 at 9:57 AM, Bob kb8tq wrote: > Hi > > Best guess is that the “real work” on the firmware took place …errr… a bit >

Re: [time-nuts] Trimble Thunderbolt no longer determines the correct date

Hi The whole “offset frequency” simulcast thing is pretty old. It most certainly pre-dates GPS. It’s actually old enough that the first OCXO I ever designed at Motorola went into that kind of system. The “time sync” thing came along a while after that. There’s always been a lot of

Re: [time-nuts] Trimble Thunderbolt no longer determines the correct date

Nice post Tom. I was also wondering about the replacement hardware vs software patch issue. Just speculation on my part but perhaps changing the software involves an extensive QA / test process, vs swapping out a piece of hardware ? Again this is just pure speculation on my part. Mark

Re: [time-nuts] Trimble Thunderbolt no longer determines the correct date

> The E911 installation, in the news, is just one of several. Others are > hospitals, > fire stations, etc. using different dispatch systems. Hey, at least important things like mobile phones, ISP's, Google, Amazon, FedEx and Starbucks aren't affected ;-) > In a wide-area simulcast-overlap

Re: [time-nuts] Trimble Thunderbolt no longer determines the correct date

Tom, et.al. The E911 installation, in the news, is just one of several. Others are hospitals, fire stations, etc. using different dispatch systems. In a wide-area simulcast-overlap paging system, the transmitters in the same coverage area are carefully set to all transmit at exactly the same

Re: [time-nuts] Trimble Thunderbolt no longer determines the correct date

Brad, Strictly speaking, there's no problem with GPS, or Trimble, or the Thunderbolt GPSDO: each did exactly as designed and documented. Anyone working with timing systems (from astronomy to calendars to watch making to operating systems) knows there are many subtle details. Just wait until

Re: [time-nuts] Trimble Thunderbolt no longer determines the correct date

Hi Indeed, this could be a new wave of TBolts into the market. My fear is that those handling it are not going to sell off the “rejects”. They’ll just toss them in the trash. Bob > On Aug 10, 2017, at 8:00 PM, paul swed wrote: > > Just remember you are taking on E911

Re: [time-nuts] Trimble Thunderbolt no longer determines the correct date

Just remember you are taking on E911 responsibility. Not that brave. But come on all those tbolts going in the trash. Sounds like goodies. Regards Regards Paul WB8TSL On Thu, Aug 10, 2017 at 7:55 PM, Adrian Godwin wrote: > While it wouldn't be difficult to build such a

Re: [time-nuts] Trimble Thunderbolt no longer determines the correct date

While it wouldn't be difficult to build such a device, manufacturing a decent quantity in less than 2 weeks to beat Trimble would be a tall order. There are, however, programmable converters : all the hardware you need and just needs some suitable software. For example :

Re: [time-nuts] Trimble Thunderbolt no longer determines the correct date

The Trimble Thunderbolts are used in many Radio Paging Systems to synchronize their transmitters in simulcast mode. Systems that are using the models affected by the 1024 week epoch are currently off the air or functioning poorly. This is a very serious issue because many doctors and nurses as

Re: [time-nuts] Trimble Thunderbolt no longer determines the correct date

Hmm.. Just a while ago, I watched the heather display on ours go to 12:59:59 and stop... Still giving me 10 MHz though which is all I really need. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to

Re: [time-nuts] Trimble Thunderbolt no longer determines the correct date

It should only be the failure of producing the wrong "display-date". The internal time system use different gears for everything, so the display-date is a side-product. Adjust with +1024 weeks and you should be all set. Leap-second info work on internal gears. Cheers, Magnus On 07/28/2017

Re: [time-nuts] Trimble Thunderbolt no longer determines the correct date

Attila, On 07/28/2017 02:01 AM, Attila Kinali wrote: On Thu, 27 Jul 2017 17:49:14 -0500 Didier Juges 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

Re: [time-nuts] Trimble Thunderbolt no longer determines the correct date

I have updated my version of tboltd to do the following: 1) I incorporated your fix for the GPS epoch rollover, with the following change: Since I was already converting the time internally to the Unix epoch I did not use the Julian conversion, rather I simply modified the returned Unix epoch

Re: [time-nuts] Trimble Thunderbolt no longer determines the correct date

Thank you, Ralph! Indeed, I had tarred up the branch on github with your original code, not the branch with my changes...how embarrassing! I've updated the tarball and re-arranged the page to make it easier to find the latest. Also, if you make an official version I'll remove my download

Re: [time-nuts] Trimble Thunderbolt no longer determines the correct date

Thanks for doing this, I was just about to dive into this. I've been neck deep in some other things recently and just became aware of this issue. Could you check the source tarball? I just downloaded it and it appears to be the unmodified version of my code from 2010. Ralph AB4RS Sent from

Re: [time-nuts] Trimble Thunderbolt no longer determines the correct date

Based on Mark Sims updates to Heather v5.0 I've updated Ralph Smith's NTP daemon to handle the rollover. I haven't updated the gpsd. https://wa5znu.org/2011/08/tbolt/ It's not as ambitious as Mark's update; this one doesn't read system time so it will have to be recompiled again in about 20

[time-nuts] Trimble Thunderbolt no longer determines the correct date

At one time one of the Chinese sellers of Tbolts was upgrading their firmware from 2.x to 3.0 I don't know how they did that... perhaps they extracted a 3.0 image via something like JTAG or pulling a chip and dumping it. -- > Unfortunately the unit that you have does not

Re: [time-nuts] Trimble Thunderbolt no longer determines the correct date

ent Subject: Re: [time-nuts] Trimble Thunderbolt no longer determines the correct date Hi Trimble, even on supported products, is pretty firm about a service contract being in place for updates. The only exception seems to be security related patches. There have been a lot of examples of this o

Re: [time-nuts] Trimble Thunderbolt no longer determines the correct date

gt; > -Original Message- > From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Mark Sims > Sent: 30 July 2017 17:18 > To: time-nuts@febo.com > Subject: [time-nuts] Trimble Thunderbolt no longer determines the correct date > > That does not appear to b

Re: [time-nuts] Trimble Thunderbolt no longer determines the correct date

), to see if there's any hope ... I'm not optimistic, but if you don't ask, you don't get. Cheers Dave -Original Message- From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Mark Sims Sent: 30 July 2017 17:18 To: time-nuts@febo.com Subject: [time-nuts] Trimble Thunderbolt

Re: [time-nuts] Trimble Thunderbolt no longer determines the correct date

ve more info as I sift through > several TBolt's. > > /tvb > > > - Original Message - > From: "Mike Cook" <michael.c...@sfr.fr> > To: "Tom Van Baak" <t...@leapsecond.com>; "Discussion of precise time and > frequency meas

Re: [time-nuts] Trimble Thunderbolt no longer determines the correct date

ecise 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 firm

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 > Le 30 juil. 2017 à 02:16, Tom Van Baak a

Re: [time-nuts] Trimble Thunderbolt no longer determines the correct date

Of Tom Van Baak Sent: Saturday, July 29, 2017 18:16 To: Discussion of precise time and frequency measurement <time-nuts@febo.com> Subject: Re: [time-nuts] Trimble Thunderbolt no longer determines the correct date Caught it. Some Trimble Thunderbolt TBoltmon.exe screen shots attached: GPS WN 19

Re: [time-nuts] Trimble Thunderbolt no longer determines the correct date

Caught it. Some Trimble Thunderbolt TBoltmon.exe screen shots attached: GPS WN 1959 TOW 604799 (July 29, 2017 23:59:41) advanced to GPS WN 936 TOW 0 (December 13, 1997) instead of GPS WN 1960 TOW 0 (July 29, 2017 23:59:42). 1960 - 936 is 1024 weeks, as advertised for this version of the TBolt

Re: [time-nuts] Trimble Thunderbolt no longer determines the correct date

It appears there is no command to set the current time in the Thunderbolt. Too bad. I have some very old Garmin OEMs (GPS35) that work fine as long as I set the time and date to be close. I just had to do a RAM reset ( $PGRMI,,,C ) on one which had gotten corrupted and would not

Re: [time-nuts] Trimble Thunderbolt no longer determines the correct date

> Le 28 juil. 2017 à 17:36, Dave B via time-nuts a écrit : > > Interesting. > > What about NTPD implementations, when using a TB as the reference time > source? Does that handle the week count roll over as well? If that was > added, from what version? Which driver are

Re: [time-nuts] Trimble Thunderbolt no longer determines the correct date

On Thu, 27 Jul 2017 19:03:35 -0700 "Tom Van Baak" wrote: > 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

Re: [time-nuts] Trimble Thunderbolt no longer determines the correct date

Forgive my naivete, but if this is something as simple as the t'bolt adding a 10 bit number to a base date, could not the base date be changed in the PROM? (Presuming one can get to it, etc) Though I suspect that might not be all that simple of course. And I'm not taking mine apart to look. :)

Re: [time-nuts] Trimble Thunderbolt no longer determines the correct date

Interesting. What about NTPD implementations, when using a TB as the reference time source? Does that handle the week count roll over as well? If that was added, from what version? I suspect I may have some updating to do! I use a TB as a frequency ref' and local NTP/NTPD server reference.

Re: [time-nuts] Trimble Thunderbolt no longer determines the correct date

Thanks I thought it would still work as the 3801 does. On Thu, Jul 27, 2017 at 10:03 PM, Tom Van Baak 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-

Re: [time-nuts] Trimble Thunderbolt no longer determines the correct date

> 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

Re: [time-nuts] Trimble Thunderbolt no longer determines the correct date

Hi > On Jul 27, 2017, at 8:01 PM, Attila Kinali wrote: > > On Thu, 27 Jul 2017 17:49:14 -0500 > Didier Juges wrote: > >> I cannot imagine a work around since the problem stems from the GPS service >> only identifying the current date within a particular

Re: [time-nuts] Trimble Thunderbolt no longer determines the correct date

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

Re: [time-nuts] Trimble Thunderbolt no longer determines the correct 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

Re: [time-nuts] Trimble Thunderbolt no longer determines the correct date

On Thu, 27 Jul 2017 17:49:14 -0500 Didier Juges 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

Re: [time-nuts] Trimble Thunderbolt no longer determines the correct date

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