[time-nuts] Z3801A gps week rollover

2016-09-08 Thread Mark Sims
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

Re: [time-nuts] timelab question

2016-09-08 Thread jimlux
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

Re: [time-nuts] Z3801A gps week rollover

2016-09-08 Thread Hal Murray
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

Re: [time-nuts] timelab question

2016-09-08 Thread jimlux
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,

Re: [time-nuts] timelab question

2016-09-08 Thread John Miles
> 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

Re: [time-nuts] timelab question

2016-09-08 Thread John Miles
> 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

Re: [time-nuts] timelab question

2016-09-08 Thread Bob Camp
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

Re: [time-nuts] Z3801A gps week rollover

2016-09-08 Thread Peter Vince
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"

[time-nuts] timelab question

2016-09-08 Thread jimlux
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

Re: [time-nuts] Z3801A gps week rollover

2016-09-08 Thread Hal Murray
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

Re: [time-nuts] Z3801A gps week rollover

2016-09-08 Thread Bob Camp
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

Re: [time-nuts] Z3801A gps week rollover

2016-09-08 Thread Peter Vince
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

[time-nuts] Z3801A gps week rollover

2016-09-08 Thread Mark Sims
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

Re: [time-nuts] Z3801A gps week rollover

2016-09-08 Thread paul swed
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

Re: [time-nuts] Z3801A gps week rollover

2016-09-08 Thread Tom Van Baak
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

Re: [time-nuts] Z3801A gps week rollover

2016-09-08 Thread paul swed
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