TICC icon indicating copy to clipboard operation
TICC copied to clipboard

No recovery from loss of 10 MHz frequency reference

Open wowczarek opened this issue 8 years ago • 3 comments
trafficstars

Currently, when 10 MHz is lost and restored, the TICC does not resume measurement and stalls until it is reset, regardless of measurement mode. I have not looked into the source code yet so I appreciate that this may not be trivial to solve, but I thought I should flag this anyhow.

wowczarek avatar Mar 16 '17 03:03 wowczarek

I am not sure anything can be done about this, short of a restart. When the 10 MHz clock goes away several timing signals disappear and on recovery the relative phase of those signals may change. And the timescale will jump in a way that's not apparent in the output. Say the clock goes away after timestamp 101.something of a PPS signal. When the clock comes back, the next timestamp will be 102.something. The data will show a 1 second step but the actual gap could be milliseconds to years.

The only practical way to recover, I fear, is to reset and start again.

n8ur avatar Oct 29 '19 14:10 n8ur

Hi John,

Understood; thank you for checking this. However can this condition be detected and (whether it is a sane thing to implement or not), the way the board is laid out, can it trigger its own reset, or will a software reset re-initialise all hardware? I suppose one of the free pins could always be wired to reset, watchdog-like. I sincerely cannot recall right now whether re-connecting to serial does resume the normal operation after loss of 10 MHz or not - my TICs run for weeks or months at a time so it has been a while since I deprived them of REF.

wowczarek avatar Nov 28 '19 16:11 wowczarek

Re detecting loss of ref clock.

I just pushed a bug fix to the multi_ticc branch that might enable what you want to do, with a bit of extra hardware.

Arduino output A11 (assigned in the software to EXT_LED__CLK) is intended to turn on an LED if the coarse counter is incrementing properly. It tests for PICcount to increment at least every 250 us and if that doesn't happen, the LED is turned off. That would result on a master board from loss of 10 MHz reference, failure of the PIC divider, or possibly other issues. On the slave board, I don't think loss of 10 MHz would do it, but loss of the external COARSE_CLK signal from the master would.

You could sense the state of A11 and if it goes low, use that to pulse the reset line low and reset the Arduino. After restart A11 will stay low for at least a couple of seconds as the board initializes, so you'll need to do something to hold off sending additional reset pulses until A11 has had a chance to go high again.

The test doesn't work in the current main branch because I forgot to set A11 to OUTPUT mode. That's fixed in what I just pushed to multi_ticc.

I haven't tried this so don't know if it would work in practice.

n8ur avatar Dec 02 '19 19:12 n8ur