descoubes kirjoitti:
I am very pleased to inform you that the 1995 year bug on the TS2100 has
been solved. You will have to replace the existing Trimble ACE III
> GPS receiver by our N024 with special firmware.
Does this also correct the 1 sec offset caused by upcoming leap second?
To remind,
Hello all,
I am very pleased to inform you that the 1995 year bug on the TS2100 has
been solved.
You will have to replace the existing Trimble ACE III GPS receiver by
our N024 with special firmware.
If you wish to purchase it, just inform me how many units you will need,
and also your shipping
descoubes kirjoitti:
I am working for HEOL DESIGN company, and we are currently investigating
this TS2100 1995 bug. We have developped the N024, a clone of Trimble
ACE III receiver (which is mounted inside the TS2100). They are many
issues with the TS2100-ACE III internal protocol, and we have
Esa Heikkinen writes:
>
> Andrew Cooper kirjoitti:
>
> > We also ran into the TS2100 1995 bug this weekend.
> > For us the consequences are a bit more severe...
>
> So this is happening already.. Didn't notice this because have been
> using PPS from Thunderbolt to keep the TS2100 in time. I
Hi
The only definitive statement I have seen for implementation of the 13 bit week
is
that it will be part of the Block III deployment process. Anything going on now
is
“testing only”. Block III now looks like a 2017 sort of thing.
There may be people out there with fancy simulators that are 1
Is the 13-bit week number somewhere in the L1 C/A message? I see it in
the CNAV definition for broadcast on L2C and L5 (and eventually, with
GPS III, L1C), but I don't see any indication of a 13-bit week number
in the LNAV section of IS-GPS-200H. So as far as I can tell, it is
not being and will n
Hi
As far as I can see, the 13 bit week stuff is still very much in the “testing”
phase. I’d say that counting
on it working on anything made before 2013 is a bit of a stretch. I would also
bet that roughly 90% of the
“current” timing GPS chip set designs do not yet fully support it. That migh
Brian Inglis wrote:
The next rollover is about April 2019, but this can happen any time
an older receiver's internal date representation used for GPS to UTC
conversion overflows. Looks like Tymserve 2100 picked about Sep 1995
for its date epoch so it hits now.
Newer GPS receivers support the ext
> Good, you understand my point. You need "external information" and "That
> won't solve the problem forever" and oh, well, yeah, duh, just "rebuild and
> reinstall the fixup software" anytime there's trouble in the future.
> To me this is replacing a broken GPS receiver algorithm with a broken
>
Andrew Cooper kirjoitti:
We also ran into the TS2100 1995 bug this weekend.
For us the consequences are a bit more severe...
So this is happening already.. Didn't notice this because have been
using PPS from Thunderbolt to keep the TS2100 in time. It failed with
leap second already in Februa
Hi Hal,
> Why is that so hard?
Depends if you want a quick hack (easy) or a solid solution (hard).
> If I understand things correctly, the time (UTC) is correct because the GPS
> receiver is using the current GPS-UTC offset. But the date is off by 1024
> weeks. (or some multiple of that)
Yo
On 2015-05-05 11:32, Alan Ambrose wrote:
It's not that simple. First, it's not 20 years, but 1024 weeks (19.6 years).
And not UTC weeks (which may have leap seconds) but GPS weeks (which do not,
and are always 604800 seconds long). etc
Don't think it's _that_ much code though. There's some op
t...@leapsecond.com said:
> The hard part is understanding when the GPS receiver fails and when to apply
> the 1024 week correction, or not. This is made difficult or impossible if
> the receiver does not give you internal information or if you do not already
> have external information (like an a
Hi
> On May 5, 2015, at 10:32 PM, Tom Van Baak wrote:
>
>> Don't think it's _that_ much code though. There's some open source ACM date
>> algorithms, and it would be easy enough to implement a quick and dirty fix,
>> adding a number of days offset, while the rest of the algorithm is tested.
>> W
brian.ing...@systematicsw.ab.ca said:
> GPS provides only the current UTC offset from GPS time, which could be made
> available via a custom vendor message, or derived from the difference
> between messages which provide UTC and messages (e.g. $GPZDG) which provide
> GPS time.
I think it's more c
> Don't think it's _that_ much code though. There's some open source ACM date
> algorithms, and it would be easy enough to implement a quick and dirty fix,
> adding a number of days offset, while the rest of the algorithm is tested.
> Will the next time this problem reoccurs be another 20 years?
>
Hi,
>>>
It's not that simple. First, it's not 20 years, but 1024 weeks (19.6 years).
And not UTC weeks (which may have leap seconds) but GPS weeks (which do not,
and are always 604800 seconds long). etc
<<<
Don't think it's _that_ much code though. There's some open source ACM date
algorit
On 2015-05-05 11:47, Hal Murray wrote:
cfhar...@erols.com said:
Surely the receiver is still producing correct frames that identify the
future leapsecond, and those frames could be read, and used to set a little
routine that wakes up at the appropriate second, and adjusts the overall
offset?
cfhar...@erols.com said:
> Surely the receiver is still producing correct frames that identify the
> future leapsecond, and those frames could be read, and used to set a little
> routine that wakes up at the appropriate second, and adjusts the overall
> offset?
Is there any leap-warning info in
Hi Tom,
One of the first words I taught my precocious kid when he was
less than a year old was balderdash. It seemed appropriate for
him to know that word if I was going to be his father. Hard
for me to believe that little boy graduates from CMU with his
BS in physics this month
The curren
: Tuesday, May 05, 2015 6:33 AM
Subject: Re: [time-nuts] TymServe 2100 1995 Issue - A Kludgy Fix
> Seems to me that the obvious simple answer works this way:
>
> Since the GPS must use an RS232 connection to communicate
> its information to the other devices in the telescope, all
> th
p...@heypete.com said:
> Is there a list of other common time-nut devices that are susceptible to
> similar issues? Lots of time-nuts use surplus equipment that's no longer
> supported and it'd not be fun to have them stop working.
We should make a list of good/bad units.
The Z3801A does the ri
Seems to me that the obvious simple answer works this way:
Since the GPS must use an RS232 connection to communicate
its information to the other devices in the telescope, all
that need be done is to write a fairly trivial program to
run on a PIC, or Arduino, that when presented with the date,
ad
Hi
The simple list of devices susceptible to this problem is:
Almost all of them from before 1998, many of them after that.
The issue is inherent in the design of the GPS coding and un-aided
recovery of that coding. The need to address it only was apparent to
most marketing departments after the
On Tue, May 5, 2015 at 2:42 AM, Andrew Cooper wrote:
> We also ran into the TS2100 1995 bug this weekend. For us the consequences
> are a bit more severe... The telescopes will not point to the right location
> in the sky without accurate time!
Ouch. I have some friends who work at the Subaru
We also ran into the TS2100 1995 bug this weekend. For us the consequences are
a bit more severe... The telescopes will not point to the right location in
the sky without accurate time!
For now we have configured a temporary fix... We set up two units, previously
our primary and hot spare.
26 matches
Mail list logo
