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

[Didier Juges]

Second thoughts about inverting the UTC 1PPS. I have read in a previous 
post that for most GPS receivers, only the leading edge of the 1PPS 
pulse is tightly controlled (and intended to be synchronous with the 
satellite signal), the falling edge is not. If this is true, we want to 
make sure we keep that edge the way it is and then invert the 1PPS from 
the DUT, if this is possible.

Also, at least with my Jupiter receiver, the 1PPS is a fairly short 
pulse, not nearly 50% duty cycle, so inverting it might not give much 
improvement.

Any thoughts?

Didier

Didier Juges wrote:
> 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
>>   
>>     
>
>
> _______________________________________________
> time-nuts mailing list
> time-nuts at febo.com
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>
>