[time-nuts] Neutrinos not so fast? (defectove connector)

Magnus Danielson magnus at rubidium.dyndns.org
Thu Feb 23 14:48:45 UTC 2012


On 02/23/2012 03:36 PM, Jim Lux wrote:
> On 2/23/12 6:24 AM, Alberto di Bene wrote:
>> On 2/23/2012 1:04 AM, Poul-Henning Kamp wrote:
>>
>> I simply don't buy the story that tightening the connector makes
>> a consistent 60 nanoseconds difference on a signal.
>>
>> I spoke with a physicist of Cern, friend of the leader of the team that
>> performed the Opera experiment.
>> He told me that the badly seated connector caused the amplitude of the
>> signal to be lower, and for this reason the trigger point, which was
>> set at a specific level, was reached 60ns later.
>> 73 Alberto I2PHD
>
>
>
> Darn those finite rise times<grin>
> I've been bitten more than once by this very phenomenon (which I admit
> doesn't say a lot for me.. being bitten once is ok, but since I've had
> multiple bites...)
>
> But this brings up an interesting time-nut problem for the hive mind..
>
> If you had to design some scheme for interconnecting "boxes" and wanted
> to transmit an accurate time sync, what should it look like, so that
> you're insensitive to things like rise time.
>
> (maybe this harkens back to the discussion about 10 MHz, why sine vs
> square wave distribution)
>
> It has to be a single signal (maybe a differential pair), because
> otherwise, don't you have potential for skew between the multiple signals.
>
> Zerocrossing sort of works, if you take only one direction, but does
> asymmetry of the waveform screw you up? (e.g. what's "zero".. is it half
> way between peak values + and -?)

I think that there is a little bit different approach to all this. It 
raises the issue of fault detection, and over in the telecom world we 
spend quite a bit of time just approving the signal and monitoring it. 
It starts of with signal presence, and the Loss Of Signal defect. Then 
other qualities of the signal is monitored, different defects is 
correlated into a fault cause which then has a second level of 
persistance filtering before hitting alarms and logs.

The side effect of this is that you not only build monitoring support 
but also actively think about what is a good signal anyway, how can one 
handle variations of signal and where to you put your cut-off.

In this case, the measurement noise should have been significantly 
higher in the error state.

Cheers,
Magnus



More information about the time-nuts mailing list