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

[Richard H McCorkle]

The inversion or delay should be introduced in the device
under test 1PPS and NOT the GPS 1PPS as most GPS
receivers output leading edge on time pulses that can have
varying pulse widths, so inverting the GPS pulse is not a
good idea. As long as there is >1us of difference between
the pulses the TIC works OK, just be aware that crossing
zero will cause errors in the TIC numbers.
The Brooks Shera controller uses a similar method of
determining the GPS offset for his GPSDO controller
and uses a setpoint to introduce a known offset of 800
counts in the OCXO output to insure the phase detector
and TIC never reach the zero crossing point in normal
operation. He uses an external counter and 24 MHz XO
in his design and reads the counter every 30 secs to get
the average offset from GPS.
The Simple Time Interval Counter is extracted from a
GPSDO controller design I regularly use based on the
16F688 and a 23-bit dac and can definitely be used
for this purpose. I up the XO to 20MHz in my GPSDO,
but this is faster than PIC spec so I can't recommend
doing so. (But it has worked very well for me.)
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: Sunday, August 13, 2006 7:28 AM
Subject: Re: [time-nuts] Enhancing the TIC232 code for better data


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