[time-nuts] TAPR TICC boxed

[Bob kb8tq]

Hi

If need it, indeed coming up with individual delays is a bit of a pain. One of the most basic decisions is to establish a reference plane. More or less - the signal at “this point” is zero. Everything else is going to be off by nanoseconds from that point (with meter long cables involved). It’s not impossible to set up, but it does take some discipline and care. The specific process is unique to the “time nut” side of things rather than the “frequency nut” side. 

We often ignore this sort of thing, but it can indeed be a very big deal. Some “cables” have very long delay numbers. Propagation from a radio beacon is one example. Packet coding / decoding delay on a digital data stream is another very common one. 

Bob

> On Apr 2, 2017, at 3:22 AM, Bruce Griffiths <bruce.griffiths at xtra.co.nz> wrote:
> 
> Its usually not possible to uniquely assign individual channel delays in this way, however swapping cables allows the cable delay mismatch to be eliminated from the measurement of the differential delay between channels.
> Eliminating the effect of cable delay mismatch can be useful when adjusting narrowband quadrature splitters ect.
> 
> Bruce
>> On 02 April 2017 at 13:38 Mark Sims <holrum at hotmail.com> wrote:
>> 
>> 
>> The new TICC support in Lady Heather has an "autotune" function that can null out the cable and channel delays.  You connect a signal (like 1PPS) to both channels through matched cables (like via a T adapter) and it averages the difference and sets the "FUDGE" factor for one of the channels to null out the net offset.  It doesn't null each channel individually.    You might be able to swap the cables and work out how to allocate the offset to each channel.    My unit has a channel offset of -305 ps (part of which could be due to mismatches in the "T" cables / connectors).
>> 
>> Autotune also calculates the FIXED TIME2 values if you want to play with that feature which can allegedly reduce the device noise by sqrt(2).  I'm not sure how well that works since the TIME2 values do drift over time and I don't know how much of an error in the TIME2 settings affects the device enough to make it perform worse than with the default automatic TIME2 mode.
>> 
>> ---------------------
>> 
>>> The whole delay difference thing does get into a “do you care?” sort of category. The 
>> testing process you are doing may well calibrate out (or ignore) an offset of this nature. 
>> _______________________________________________
>> 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.
> _______________________________________________
> 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.