[time-nuts] TimeLab

[Magnus Danielson]

Hi Tom,

On 10/10/2016 11:49 AM, Tom Van Baak wrote:
> Hi Magnus, two questions for you:
>
>> I can shift the phase of the DUT intentionally, but if so I want to be
>> able to compensate that shift in the software. Now, such a shift should
>> be kept separate from the calibration factors which fills a different
>> purpose.
>
> If you can shift the DUT phase, you're all set. No need for most of the most of the discussion going on, right? What is the frequency error or stability of the DUT? A 500 ms shift should provide days to years of time before you'd hit the TIC zero.

Go back and read my original posting as well as fairly early follow-up 
posting.

I have a locked system, I can move the phase in this case, but I need 
the assistance of the post-processing to get the zero offset values 
presented properly, and I heavily use the real-time display.

Similarly, I propose improved processing through simple shift of sign 
and phase-unwrapping focused around zero.

Notice that there can be different offsets of different origins, and one 
want to set them independently for ease of use.

For the case at hand, any through zero sample skip is a rare case but 
the negative sample skip dominates.

>> The trick that I then apply is to use a stop signal of higher frequency,
>> but who's rising edge matches that of the PPS on the PPS occurence, and
>> then let my DUT signal PPS be the start signal, as that will then
>> defined the tau-rate. With a 100 Hz signal I now have 10 ms period and
>> then from the last stop-time I have 990 ms for the counter to re-arm the
>> start-channel, and thus hide the dead-time. This is the picket fence
>> approach rather than having alternate counters to cover up each others
>> dead-time.
>
> I've tried this. In general the picket fence method has no effect on you hitting the awkward region near 0 ns where the TIC waffles between - and +. In fact, a 100 Hz picket fence just means you will run into the TIC dead zone 100 times more often, but the effect the dead zone will be 100x less. To me this suggests that 2 Hz is all that is necessary, as PHK and I have mentioned. I almost hesitate to call 2 Hz a picket fence.

As I said, the through-zero problems are much less of an issue.
The 100 Hz was free and available, 2 Hz or 10 Hz would also do the 
trick, so don't hang up on the frequency as it is more to illustrate the 
setup I did.

> Or are we missing something? Is there some advantage to 10 Hz or 100 Hz over 2 Hz? It seems to me they all solve the problem where the counter start/stop accidentally gets turned into stop/start near the 0 ns region, which leads to sampling every 2 seconds instead of every 1 second for a while.

As long as you have an integer multiple, you're all fine. It's really 
what is handy which is important and preferably the period should be 
shorter than the dead-time, but as long as the software can compensate 
for multiple skipped periods we don't care about that either.

Remember, I'm measuring phase and trying to measure deviation from 
"absolute phase". I want my view to be as unbiased as possible.
This is different from just trying to make stability measures.

I'm trying to illustrate the measurement challenges and then propose 
some enhancements to TimeLab that will help immensely to provide good 
values. Much of this thread ended up covering gazillions of other cases, 
including "use this counter instead".

Cheers,
Magnus