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.griffi...@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 <hol...@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@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@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@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Reply via email to