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 pro
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
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
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 ;
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 system with a Thunderb
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 whatever you
have the T-
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
> over 19.6 years
Hi
Best guess is that the “real work” on the firmware took place …errr… a bit over
19.6 years ago.
That’s a massively long time ago in terms of development tools and hardware.
Simply getting
a tool suite back up and going on the “old code” would be a big task in most
organizations. Ask
me abou
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 infrastructur
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 Spenc
> 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 pagi
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 ti
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 203
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 responsibility.
> Not th
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 device, manufacturing a
>
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 :
http://www.kksystems.com/
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 w
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 https://www.fe
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 02:
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 government changes the amou
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 time
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 an
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 m
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 y
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 over
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
over the years ….AFIK, there isn’t even a “public” firmware loader for the
TBolt.
Inde
I emailed Trimble on the off chance they might have a firmware upgrade. They
sent me an email which covered some units that rolled over in Feb. 2016 for
which they say they have no upgrade.
I sent them all the information on the label stuck to the outside of my TB (one
of the group buy set), t
fo as I sift through
> several TBolt's.
>
> /tvb
>
>
> - Original Message -
> From: "Mike Cook"
> To: "Tom Van Baak" ; "Discussion of precise time and
> frequency measurement"
> Sent: Saturday, July 29, 2017 11:47 PM
> S
ment"
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 be
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 écrit :
>
> Caught it. So
Tom Van Baak
Sent: Saturday, July 29, 2017 18:16
To: Discussion of precise time and frequency measurement
Subject: 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
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 GPS
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 report
> 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 you using? Palisade?
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 that information.
>
> I
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. :)
On
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.
T
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-
> GPS-200D.pdf describ
> 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 tha
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 1024 weeks epoch
>> unless the governme
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 i
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 ha
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 the GPS
> system. Some
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
44 matches
Mail list logo
