Close

v4.0 build report

A project log for GPS Clock

A simple desk clock that gets extremely accurate time from GPS

nick-sayerNick Sayer 06/24/2017 at 02:190 Comments

The v4 board went together without any surprises. There were two bugs in the firmware that I had to fix, but in essence the ATXMega32E5 has now been swapped in for the ATTiny841 with no net change in functionality. The big difference, though, is that the update latency, as predicted, has dropped to under 50 µs.

This sets the stage for the v5 hardware, which has the XMega configured for software display multiplexing as previously described. I haven't ordered that board yet, as I want to insure that the footprints for the two new parts are correct. I'll very likely order boards just as soon as the paper test succeeds.

The downside of v5 is that the display raster is only going to be 10 kHz instead of the 600 kHz of the MAX6951. This will have some impact on the accuracy because the worst-case display update time has to take the refresh frequency into account. At 10 kHz the amount of time between adjacent "slots" for a particular digit is 100 µs. Increasing the display raster rate requires increasing the interrupt frequency, which risks starving the rest of the code. The 10 kHz refresh rate requires an interrupt rate of 320 kHz (4 brightness levels and 8 digits), which is an interrupt every 100 instructions or so. Worse, the code for the interrupt service routine takes on the order of 50 instructions, so we wind up dedicating about half of the available horsepower just to refreshing the display. Still, the current spec for the clock is a display accuracy of 200 µs, so as long as the display update can occur in less than 100 µs the spec will still be met. But if you really desire the lowest update latency, you'll want to build yourself a v4 unit (I'm not planning on selling them).

EDIT:

I've added the firmware for the v4 clock to the GitHub repository, as well as the design files and PDF schematic in the files section here.

Discussions