The Z3801A status page takes 3 seconds to process/send. Not surprising that
the time is a bit off. Lady Heather only requests the SYST:STAT message once
per minute (at hh:mm:33 seconds) because it blocks the unit from doing anything
else while it is handling it. The main things extracted from
On 9/8/16 5:10 PM, John Miles wrote:
I've got a file with counter values that are latched once per second,
with the count read from the latch every half second. So, generally,
there are two identical values, then two different identical values,
etc. But, of course, the routine that does the eve
hol...@hotmail.com said:
> Happy until the next power glitch... the setting does not seem to persist
> between boots. There may also be other conditions that causes it to forget
> your date.
I just power cycled mine. It came back correct without setting the date.
I've assumed there is a tin
On 9/8/16 4:41 PM, Bob Camp wrote:
Hi
I think you are stuck with writing some code. I would want to make sure that in
the odd
case two latched values were identical, they didn’t get tossed (3 or 4 identical
in a row => 2 not 1) ….
since they are latched counts from a free running counter,
> That's a pretty scary problem to have. Are these frequency counts or TI
> readings? You wouldn't normally see two identical TI readings in a row,
Actually, that's not even safe to assume for TI readings, depending on how your
triggering works. It would make sense to do whatever it takes to f
> I've got a file with counter values that are latched once per second,
> with the count read from the latch every half second. So, generally,
> there are two identical values, then two different identical values,
> etc. But, of course, the routine that does the every half second
> reading isn't
Hi
I think you are stuck with writing some code. I would want to make sure that in
the odd
case two latched values were identical, they didn’t get tossed (3 or 4
identical in a row => 2 not 1) ….
Bob
> On Sep 8, 2016, at 6:13 PM, jimlux wrote:
>
> I've got a file with counter values that ar
That makes sense - thanks guys!
Peter
On 8 September 2016 at 22:53, Hal Murray wrote:
>
> petervince1...@gmail.com said:
> > Can I just ask why the Z3801As are having week roll-over problems now -
> I
> > didn't think it was 2048 weeks since GPS "zero-hour" until late on the
> 6th
> > of
I've got a file with counter values that are latched once per second,
with the count read from the latch every half second. So, generally,
there are two identical values, then two different identical values,
etc. But, of course, the routine that does the every half second
reading isn't perfec
petervince1...@gmail.com said:
> Can I just ask why the Z3801As are having week roll-over problems now - I
> didn't think it was 2048 weeks since GPS "zero-hour" until late on the 6th
> of April 2019?
It's probably 1024 weeks since a date was built into the firmware.
It's like the year 2000 pr
Hi
After the first batch of GPS devices rolled over, the manufacturers came up
with a “fix”
for the problem. If the date came out to a number *before* the firmware was
issued,
it was corrected forward in time. This only works over a single span of GPS
dates.
Depending on when the firmware you
Can I just ask why the Z3801As are having week roll-over problems now - I
didn't think it was 2048 weeks since GPS "zero-hour" until late on the 6th
of April 2019?
Peter
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.
Yes, rollovers should not be a problem and should only affect the date display.
However, I have seen devices/software that use GPS fail to work because of what
appears to be an invalid date. It seems that they are validating the data from
the receiver and if, for instance, the date is before
Tom,
Right on the pps and frequency. I should have been far more clear date and
time.
I fired up my 3801 and it locked up just fine. Need to check its message to
see whats its putting out.
I will say that I added 2 AA batteries that seem to be lasting for several
years easily and they keep the memo
Paul,
IIRC, we've never heard reports of GPSDO pulse or frequency outputs being
affected by rollovers. In GPS there are internal rollovers every 1, 256, and
1024 weeks but the 1PPS and 10 MHz outputs are not dependent on any of these
events. The same is true for leap seconds; they may be mishan
Mark,
>From some earlier threads on rollovers. Do you even need to set the time at
all?
Granted not great if the 3801 is a time source, but if its just frequency
do you care?
Thanks
Paul
WB8TSL
On Tue, Sep 6, 2016 at 11:30 AM, Mark Sims wrote:
> Happy until the next power glitch... the setting
16 matches
Mail list logo