[subexp-daq] wrtclk timestamps

[Håkan T Johansson]

On Thu, 16 May 2024, Philipp Klenze wrote:

> PPS: The wrtclk can either run with a clock of an upstream system (rataclock 
> 25MHz, Butis) or with an internal clock. One thing which I found is that when 
> the inputs get disconnected, the timestamps still increase at approximately 
> the correct rate when the internal clock is used. I think the main advantage 
> of running with the upstream clock is that it is impossible to oversee this 
> condition, while for the free-running clock it would depend on the precision 
> of the exploder oscillator how long it takes to see the drift in treeview. Or 
> do ratatime/rataclock transmit a "bad timestamp"-bit in these cases?

The free-running (internal) clock could indeed give some 'interesting' 
(i.e. possibly difficult to debug) timestamp issues.

The timestamp receivers (decoders) likely (when things are connected) are 
able to decode time, even if they would actually see things jumping and 
set their error outputs. But those I think are not carried further...

Hmmm, the rataclock decoder should have a hard time, as it also needs 
the phase to stay good, but the Schakel (butis) may be quick enough...

The rataclock protocol as such does not contain any error information. 
One could define e.g. the first aux bit to mean that upstream is locked 
and 'good', but for that to be useful it would require that one detect the 
situation well also...

The T5NS measured in a clock-based VFTX or TAMEX would detect all those 
situations immediately however.  A shift by one course counter, and any 
code checking it would scream 'jump'.

Even a good nominal oscillator (typical within +/- 100 ppm), let's say it 
is great and just 0.01 ppm off, would drift by two cycles per second.

Cheers,
Håkan