[time-nuts] Using a UBlox NEO-6 GPS module for calibrating a PIC microprocessor based timer.

[Tom Van Baak]

Hi Luke,

> Monitoring the GPS performance looked like a good start. I have the serial

For timing mechanical clocks, you'll find that microseconds, or 100 ns, or 50 meters is plenty accurate. So no worries there.

Even with 100 ns GPS receiver accuracy, you can calibrate your crystal oscillators to 0.01 ppm in under a minute.

> I've looked at Brian Mumford's Microset timer. I think it's the best one
> available. If I hadn't decided to make my own I'd have bought his. I really

Agreed, highly recommended. I use several of Bryan's sensors and timers, in addition to ones of my own design.

> I'm using a PIC 18F13K22. My code is in assembly language. The external
> clock is 10MHz. Internally it's running at 40MHz using the 4x PLL. The PIC

Yes, those larger PIC's with internal PLL allow you to overcome the Fosc/4 issue.

> I think that the PIC 18 interrupt latency is 3 instruction cycles. I'll
> have to double check the PIC 18 data sheet and verify this. There will also
> be some more latency because I have two interrupts occurring
> asynchronously. When the pic input pin is triggered an interrupt is

For a timer, the interrupt latency number is not really the issue; the key point is if the number is invariant under all conditions.

We can talk off-line about your use of multiple interrupts. In general, for precise interrupt-based timing, this is a bad idea. One alternative is using the ECCP (capture time-stamp) feature.

But, for your use with timing mechanical clocks, your design is more than adequate.

> Also, internally I think I'm doing something similar what your picpet does.

Probably not. The picPET is based on the 8-pin PIC12 series and does not use interrupts or timers for its timekeeping (which is why it can keep perfect time without the variable latency and jitter issues seen in some microprocessor-based timers).

> Finally, Here are some pictures of the timer.

Nice. Thanks for sharing.

/tvb