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

[Brooke Clarke]

Hi Didier:

Neither.

It's my understanding that Timer 1 is gated by the output of a 4046 
phase detector and it's high time is determined by counting a 16 Mhz 
oscillator.  The PIC internal Synchronization feature is set to off.   
Since Timer 1 is used as a 16 bit counter it will rollover in about 4 
milli seconds.  So the main program loop that executes much faster than 
that just polls the Timer 1 overflow bit and increments some more bytes 
to from a 4 or 5 byte accumulator (the accumulator needs to be large 
enough to hold counts corresponding to 256 seconds where the TI is 1 
second).  The falling edge of the same 4046 output is also used to 
generate an interrupt by using another PIC pin.  This interrupt 
decrements another 1 byte counter that's set for the number of times a 
phase comparison will be made ( 1 to 256 comparisons)  and since we are 
talking about 1 PPS signals it's also about how long the test sequence 
will run in seconds.  Once the counter decrements to zero the 
measurement is finished and the 4 or 5 bytes are output.  They are then 
divided by the number of measurements to get the actual measurement value. 

Since 16 Mhz has a period of 62.5 ns a single shot measurement would 
have that resolution, but if the number of measurements is 125 the 
resolution will be 0.5 ns.

I'm not sure why it's better to zero Timer 1 after each interrupt rather 
than letting it accumulate the time intervals.

Have Fun,

Brooke
PS I really like this idea.


Didier Juges wrote:

>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
>
>  
>

-- 
w/Java http://www.PRC68.com
w/o Java http://www.pacificsites.com/~brooke/PRC68COM.shtml
http://www.precisionclock.com