[time-nuts] Re: Picotest U6200A problem with measuring PPS period very second.

2022-02-27 Thread John Ackermann N8UR
On 2/27/22 6:56 PM, Bob kb8tq wrote: These are *all* compare to a reference measurements. The floor will always be set by that, one way or another. Bob just stated a great truth that explains why and how we become time-nuts -- in order to characterize an oscillator, you need another

[time-nuts] Re: Picotest U6200A problem with measuring PPS period very second.

2022-02-27 Thread Bob kb8tq
Hi > On Feb 27, 2022, at 5:20 PM, Hal Murray wrote: > > > kb...@n1k.org said: >> Since there is a quick / simple / (near) zero cost solution ( look at a delta >> to a second pps stream) crossing more sources of trouble off the list is >> normally a pretty easy decision. > > I can see how

[time-nuts] Re: Picotest U6200A problem with measuring PPS period very second.

2022-02-27 Thread Hal Murray
kb...@n1k.org said: > Since there is a quick / simple / (near) zero cost solution ( look at a delta > to a second pps stream) crossing more sources of trouble off the list is > normally a pretty easy decision. I can see how that works if the second PPS is high quality. What happens if it is

[time-nuts] Re: Picotest U6200A problem with measuring PPS period very second.

2022-02-27 Thread Bob kb8tq
Hi *Could* it be perfect in some ideal device? Sure it could. In any real world device I’ve ever used (and I think I’ve used just about everything on the market …..) , it’s been far from perfect. As you get out to even a modest tau ( say 1K sec) you are looking at something in the 10,000 to

[time-nuts] Re: Picotest U6200A problem with measuring PPS period very second.

2022-02-27 Thread Erik Kaashoek
Bob Would this rounding error be reduced if the phase is measured in a gapless way, e.g. against a continuos running phase counter that is captured at the moment of the PPS and the period is calculated as the delta between current and previous capture. Any rounding in this delta calculation can

[time-nuts] Re: Picotest U6200A problem with measuring PPS period very second.

2022-02-27 Thread Tom Van Baak
Erik, > Does anyone know if it is possible with the U6200A to measure every period of a PPS? Yes, use time interval mode instead of period or frequency mode. TI mode is a 2-channel measurement so one channel is your GPS/1PPS and the other channel is your Rb/1PPS. The resulting readings

[time-nuts] Re: Picotest U6200A problem with measuring PPS period very second.

2022-02-27 Thread Bob kb8tq
Hi If your goal is an ADEV measurement, you will need to tag the edges against a second “stable” PPS signal. A sequence of period measures can get you into issues related to round off problems. Bob > On Feb 27, 2022, at 11:27 AM, Erik Kaashoek wrote: > > But why can't you measure the 1 s

[time-nuts] Re: Picotest U6200A problem with measuring PPS period very second.

2022-02-27 Thread Erik Kaashoek
But why can't you measure the 1 s period of a PPS? If the counter would be able to do gapless measurement and you set the gate to 0.9s it should be able to measure the period of a PPS, at least my own build counter behaves that way so I was surprised the U76200A could not do that. On

[time-nuts] Re: Picotest U6200A problem with measuring PPS period very second.

2022-02-27 Thread Bob kb8tq
Hi If both signals arrive at the same time, many devices get a bit confused. Many counters run into this same basic issue. One work around is to “offset” one of the PPS signals. The cable delay feature on the typical GPS module will let you do this over at least a couple microseconds. For many

[time-nuts] Re: Picotest U6200A problem with measuring PPS period very second.

2022-02-27 Thread Azelio Boriani
Without a reference? If the same PPS acts as start and as stop then one (I suppose) rising edge is start and the next rising edge is stop, so a measurement every second is not possible. Maybe a dedicated hardware with two channels where one edge is the start for a channel and stop for the other is