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
Esa Heikkinen tn1ajb@... 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.
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
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
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
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
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
Hi
On May 5, 2015, at 10:32 PM, Tom Van Baak t...@leapsecond.com 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
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
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
Arduino
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)
You
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
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
algorithms,
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?
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?
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,
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
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
that need be done is to write a fairly trivial
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
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
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
On Tue, May 5, 2015 at 2:42 AM, Andrew Cooper acoo...@keck.hawaii.edu 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
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.
25 matches
Mail list logo
