[time-nuts] Enhancing the TIC232 code for better data

[Didier Juges]

Hi Richard,

Thanks a lot for the very detailed explanations. I was not sure after 
looking at the PIC assembly code. I have never used PICs and even with 
my favorite micros (6805 and now 8051) I try to stay away from assembly, 
it's not as much fun as it used to be, now that I am used to C, even 
though I sometimes check the assembly produced by the compiler when I 
have a doubt or for time critical operations. The Franklin C compiler 
does a very good job with 32 bits arithmetic, so that part will make it 
much easier. Also, the 8051 having multiple sets of registers reduces 
the overhead of ISRs, you don't need to push a bunch of registers on the 
stack.

OK about the DUT leading the UTC, that's something the microcontroller 
should be able to keep track of fairly easily and drive an exclusive OR 
in series with the 1PPS to invert it when necessary. That could be done 
transparently provided the XOR  has the same delay in inverting and 
non-inverting mode, something that I should check first.

I definitely intend to give a go with the Silabs part, even though it 
may not happen immediately, my life being quite busy without that at the 
moment...

The idea would be to later use this code as a basis to actually 
implement a GPSDSO control loop.

Thanks again

Didier KO4BB

Richard H McCorkle wrote:
> I have posted a detailed operation of the TIC to help
> clear up most of the questions you asked.
>
> As far as overflow tests, a 16 MHz XO over a full
> second would not completely fill a 24-bit register
> (16777216) and 256 times that will not completely
> fill a 32-bit register so no overflow test is required.
> The counters are sized based on max count equals
> XO Speed * max sample time to prevent overflow.
>
> The phase counter is disabled, read, cleared, and
> enabled early in the ISR between phase samples
> while the 4046 output is low and the counter is not
> counting. It is re-enabled before any BCD conversion
> or printing begins so there is minimal latency concern.
> The worst case is when DUT 1PPS slightly leads UTC
> (max count) and this should be avoided by introducing
> an intentional offset in the DUT 1PPS (like inverting
> it) to keep the phase detector and TIC away from
> min/max count for best operation.
>
> I hope this clears up your questions.
> Enjoy!
> Richard
>