[time-nuts] TimeLab

Tom Van Baak tvb at LeapSecond.com
Mon Oct 10 07:47:09 UTC 2016


Poul-Henning,

The key to your dual counter proposal is the half-period delay. Consider these variations:

1) Use the GPIB "change-flank-on-the-fly" trick I mentioned yesterday. Only one counter is necessary. The symmetrical (50.000000% duty cycle) output of the PPSDIV is useful here too.

2)  Use one counter with 2PPS instead of 1PPS as the stop channel REF. That way the TI readings will always be a number ranging from 0 to 500 ms, or depending on the counter, something more like -20 ns to 500ms-20ns. Regardless, the software that is processing the raw TI data can resolve the 0.5 s wrapping. The main feature is that every 1PPS from DUT gets measured. That is, you eliminate the case that we're all trying to avoid where the sample rate jumps from one per second to one per 2 seconds as you enter the region where the TI is too close to 0.

With a 10 MHz reference, anyone with a TADD-2 (board or mini) can set the input jumper from 10 MHz to 5 MHz. Then the "1PPS" output becomes 2PPS.

3) Looking at my various PICDIV I see there's a way to program a 5/10 MHz -> 1PPS divider so that the user can step the phase of the output by, say +/-500.000 000 ms. So the idea is that the PC program reading the TI data from the counter stays content as long as the TI readings are within a range of say 200 ms to 800 ms. If the TI values slowly drift outside that range it tells the PICDIV to advance or retard the divider once by exactly 0.500 000 000 s.

The beauty of this approach is that:
- you only need one counter,
- the counter may run in talk-only mode (no need for GPIB),
- the counter never operates anywhere near the TI = 0 point,
- no DUT readings are ever lost,
- your software (or TimeLab) can easily resolve the wrapping when it sees the 500 ms phase jumps,
- the PICDIV advance/retard pins can be driven by a PC serial port DTR/RTS lines,
- the output of the program that gets TI readings and issues the occasional step commands to the PIC can output wrapped phase, or unwrapped phase, or timestamps as the user wishes. TimeLab accepts all three.

/tvb

----- Original Message ----- 
From: "Poul-Henning Kamp" <phk at phk.freebsd.dk>
To: "Discussion of precise time and frequency measurement" <time-nuts at febo.com>; "Magnus Danielson" <magnus at rubidium.dyndns.org>
Cc: <magnus at rubidium.se>
Sent: Sunday, October 09, 2016 11:22 PM
Subject: Re: [time-nuts] TimeLab


> --------
> In message <0f6c1eb7-18cb-06e3-48dd-6cd618f19575 at rubidium.dyndns.org>, Magnus D
> anielson writes:
> 
>>This is why the two-counter setup is so messy, you have to have software 
>>that will sync up and query them alternatively.
> 
> It is not that bad messy.
> 
> Counter A  Start=DUT, Stop=REF
> 
> Counter B  Start=DUT, Stop=REF + half period [1]
> 
> Now you know that at least one counter will always measure a DUT flank.
> 
> The crucial detail is that you also know that the counters will not
> spit out their result at the same time, so timestamping the
> measurements on the computer will definitively sort them into
> order[2].
> 
> I always run separate programs/scripts for each counter outputting
> into separate files, but that's a matter of temperatment.
> 
> You end up with a reliable sequence with three possible scenarios:
> 
> {AB}* fine...
> 
> {AB}*B{AB}*  lost one from A
> 
> {AB}*A{AB}*  lost one from B
> 
> And it is trivial to insert markers for the missing measurements.
> 
> In addition you end up with two entirely separate series of
> measurements which you can compare for sanity, and if they look
> good, you combine them and reduce your noise by sqrt(2)
> 
> Poul-Henning
> 
> [1] PPSDIV gives nice symmetrical PPS, just trigger opposite flank.
> 
> [2] Obviously: Do not use a computer running a weather model for this
> 
> -- 
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk at FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe    
> Never attribute to malice what can adequately be explained by incompetence.
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.



More information about the Time-nuts_lists.febo.com mailing list