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

Richard H McCorkle mccorkle at ptialaska.net
Sun Aug 13 02:00:36 EDT 2006


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


----- Original Message ----- 
From: "Didier Juges" <didier at cox.net>
To: "Discussion of precise time and frequency measurement"
<time-nuts at febo.com>
Sent: Saturday, August 12, 2006 3:27 PM
Subject: Re: [time-nuts] Enhancing the TIC232 code for better data


> How do you measure the averaging time? Should we 1) measure the actual
> time that the phase data is being read (as I understand, that would be
> accumulating the time that the phase comparator output is high) and stop
> when we reach a certain count/time, or should it be 2) just elapsed time
> (periodic interrupt based on independent timer)?
>
> If it's 1, we need another counter, and if it's 2, we need another timer.
>
> Should there be an overflow check on both the 24 bit phase counter and
> the 32 bit accumulator?
>
> I am concerned that clearing the phase counter may introduce more jitter
> if it's not done "at the right time". Since the counter is read from an
> ISR, there may be issues of latency.
>
> I am very interested as I am considering using a small proto Silabs PWB
> with an C8051F300 chip for the experiment.
>
> Didier KO4BB
>
> Richard H McCorkle wrote:
> >        Here is an insider tip for the Time-Nuts community:
> >
> >    Although the Simple Time Interval Counter works quite well with
> > it's present code, it was designed as a demonstration of adding
> > Simple Commands to a program. The code can be enhanced for
> > less noise in the data when being used in serious work by making
> > a few modifications to the code.
> >    As designed a 32-bit phase counter accumulates multiple samples
> > until the sample time is reached. Multiple gates of the clock to the
> > phase counter has been shown to produce higher noise in the data
> > than reading and resetting the phase counter on each sample and
> > accumulating the samples in a separate register. By taking a 24-bit
> > sample each second, adding it to a 32-bit accumulator, and clearing
> > the phase counter before the next sample, less noise is introduced
> > into the data giving improved results.
> >
> > To enhance the performance of the Simple Time Interval Counter
> > for serious use make the following changes to the code:
> >
> > 1. Change the TMR1 overflow counter in the background routine
> >     to 8-bit making a 24-bit phase counter.
> >
> > 2. Define a separate 32-bit register as a phase accumulator.
> >
> > 3. Define a 32-bit add routine to add the 24-bit phase data to the
> >     32-bit phase accumulator and clear the phase counter.
> >
> > 4. Modify the interrupt routine to read the phase counter, add the
> >     result to the 32-bit phase accumulator, and clear the phase
> >     counter on each interrupt.
> >
> > 5. Display and clear the 32-bit phase accumulator at the selected
> >     averaging time.
> >
> > By making these modifications to the Simple Time Interval Counter
> > the modified TIC can provide cleaner data capable of analysis in the
> > sub nanosecond range for use in serious timing work.
> > .
> > Enjoy!
> > Richard H McCorkle
> > _______________________________________________
> > time-nuts mailing list
> > time-nuts at febo.com
> > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> >
> >
>
>
> _______________________________________________
> time-nuts mailing list
> time-nuts at febo.com
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts




More information about the time-nuts mailing list