Raspberry Pi Zero W desk clock

In principle, the Raspberry Pi compute module is the thing you're supposed to use to embed into projects like the clock. I've done a little bit of looking at it, and in theory it is possible to design a board that would accept a compute module instead of a pi zero w. There are a couple of fairly big problems with the idea, however.

• The compute modules are very expensive compared to a zero. The CM3 is actually the same price as a Pi 3B while being far less capable (at least without breaking out a whole lot of connectors and stuff).
• The clock would need to supply 3 different voltages to the CM.
• It would need to have a USB connector and would need some special circuitry to allow the special USB bootstrapping to initialize the on-board flash (you could initialize the CM separately and not include that support on the clock, but that makes it a whole lot less maintainable by the end-users if, say, they have to replace their CM). Adding a OTG capable USB port would be necessary in any event for either wireless or wired networking.
• It remains to be seen if an equivalent 40 (or 26) pin GPIO header could be added to the clock to support traditional expansion. How that could be made to fit would be the next big question.

The nice thing about such a beast is that (with the CM3) it would have the same CPU performance as a Pi 3, but the actual benefit of that for the purpose of the clock is questionable at best.

I haven't actually done this, but I've been considering how to make a dual display variant, perhaps as a display piece for an astronomical museum - one display could show LAST, the other standard time.

To do this, you're going to probably have to come up with some new mounting / case scheme, obviously.

But electrically it's fairly straightforward. Assemble the first clock as usual, with a pi zero w. This display will be display 0.

Next, build an identical board, but leave the 40 pin GPIO header off. You'll be using 5 jumper wires to connect from this board to the GPIO header on the other board (actually, on the Pi that's connected to it). This will be display 1.

The connections required:

Thusly connected, the second board will take power from the first, and share the SPI bus. The two clocks will keep out of each other's way by using different nodes in /dev. You simply need to run two different clock daemons, with one of them using /dev/spidev0.0 (for the display connected directly to the pi), and the other using /dev/spidev0.1 (for the auxiliary display).

You do need to make sure your +5 volt power supply is beefy enough. You should count on at least supplying 500 mA.

I've got two Pi Zeros in the NTP pool, each as a GPS based stratum 1 server.

One of them is a Pi Zero connected up to the diagnostic port of one of my GPSDOs. The other is one of these Pi Zero clocks, but with a GPS breakout board hooked up as well.

Essentially, that one is a mash-up of this project and a the Pi GPS NTP project.

Since the new laser cut wood and acrylic case has a cut-out for the GPIO headers, it's easy to tack the GPS receiver on. The one downside is that you lose the serial console pins.

The next thing I'm going to do is to make a new board that's a modification of the breakout board that makes it purpose-built for the pi. It will have a 16 pin header to mate with the left-most pins on the GPIO header. It runs the GPS module from the 3.3v supply provided by the pi, and 5 volt power is applied through a blocking inductor to the antenna jack to power active antennas.

EDIT:

If you have one of my GPS Disciplined Oscillators, you can use this little board to connect to the diagnostic port. This allows you to make a mash-up of all three projects - the GPSDO, the clock display and the GPS NTP server.

The Pi Zero W clock is ideal for displaying either Greenwich Mean Sidereal Time or Local Mean Sidereal Time - you just have to change the software around a bit.

I've done just that now. In the GitHub repo there's an SPI_Sidereal.c along side the rest. If you run it without any arguments, it displays GMST, but you can specify your longitude (+ for east, - for west) with -l and you'll get LMST. AM/PM is not available - the clock only shows 24 hour mode (I can't imagine anyone wanting otherwise), but the -B, -c, -d, -b and -t options are the same as before.

I actually recommend turning the tenth digit off on the sidereal clock. The clock displays sidereal time, but the updates are still synchronized against Unix time, and the two have differing second lengths, so it's not likely to be that accurate (never mind the fact that the time is calculated with floating point math).

There are other options you can use as well - you could use the clock as a countdown timer display, or perhaps an elapsed timer display... It's all fairly straightforward changes to the existing code.

If you want to mount the clock in a chassis, here's the recommended method. Drill number 4 machine screw holes to line up with the four holes in the corner of the board. Thread 1 inch bolts through from the outside. On the top left bolt, thread a 3/16" spacer. On the other 4 bolts, thread a 5/8" spacer.

Next, separately thread a machine screw through from the top of the Pi through the right hand hole (the one not in a corner). Between the display board and the pi insert a 3/8" spacer. Top the bolt (on the display side of the display board) with a nut.

Add a 3/8" spacer between the pi and the display board and then thread everything over the 4 corner bolts. What you wind up with is a 5/8" spacer on the three corners that don't involve the Pi. On the corner where the Pi is, there's the case back, a 3/16" spacer, then the pi board, then a 3/8" spacer, then the display board then a nut. This works because the Pi board is about 1/16" thick. The remaining bolt doesn't go through the back chassis, it just holds the Pi to the display, with the two separated by a 3/8" spacer.

The 3/16" space between the Pi and the back is just enough for the board and all of the connectors to clear the back, but it's recommended that this mounting method be used only for wood or plastic cases. If you use a metal case, then you probably should add at least another 1/8", making the bottom corner spacer 5/16" and the other corners 3/4". The inter-board spacing (with the recommended GPIO male/female header pair) remains 3/8".

You metric people are on your own. :)

This hadn't occurred to me until I read more of the PiBakery source.

Another option for getting convenient console access is to configure the USB OTG port in target mode as a USB serial interface. In PiBakery, this is the "OTG serial" block.

This only works if you're not using the USB port for anything else, which means you're using a Pi W's WiFi to get network access. If you're using the OTG port for Ethernet or WiFi, then this isn't an option.

In principle, what this means is that once this is set up, you could just plug an ordinary micro-USB cable between the OTG port and a host and the host would see a USB serial interface show up. Open that port with terminal emulation software and you'll get a login prompt.

EDIT: I tested this out and, sure enough, it works great!

If you plan on using Ethernet for the clock connectivity, one issue is that the way the Pi is oriented on the back of the clock board, it's awkward to plug in a normal OTG adapter cable, since it exits down towards the bottom of the clock.

The solution is one of these I found on Amazon:

It's a right-angle OTG adapter cable. This one is particularly nice because it turns to the left, which means that it doesn't block the power port, if you need/want to use it (of course, you'd want a micro-usb cable that was right angle the opposite way for that one).

One of the problems inherent with this project is how to go from a blank SD card to getting a Pi Zero on WiFi and running the clock code.

A quick google for customizing Raspbian images led me to PiBakery. This looks like the easiest way to get the job done.

To that end, I'm going to see if I can develop a PiBakery block to fetch, compile and start the clock daemon. If I can do that, then there's also a prospect for sharing a canned PiBakery configuration that will create an SD card to just do everything required and write an SD card in one step.

I've been pretty dramatically under-promising on the accuracy of the clock, talking about the tens of milliseconds or so.

It turns out that my experimental observations suggest the clock does much better than I expected.

My means of testing is to take 240 fps slow motion video with my phone of a GPS clock and a Pi clock.

The GPS clock is architecturally similar - it's the same MAX6951 display driver chip, but it's being run by bit-banged SPI from an ATTiny841 that's listening to a GPS receiver module. The GPS clock is driven primarily by the PPS. What inaccuracy there is is due to the interrupt processing latency, plus the time it takes to update the display with SPI. My guess is that it's maybe a maximum of 100 µs slow.

When I take video of the two together, the two tenth-of-a-second digits change almost always in the same frame. For 240 FPS video, a frame is 4.16 ms, so when they switch in the same frame, they're at least that close to each other. Giving it the benefit of the doubt, if it's within 10 ms, then that's still an order of magnitude better than the granularity (100 ms), so it's definitely a win.

Oh, and this is comparing a Pi clock that's just running NTP over WiFi against 4 random hosts in the NTP pool. There's no local server involved.

I turned one of the boards I got back from OSHPark into a display for one of my stratum 1 NTP servers, so it could do double duty as an actual clock. One little gotcha with the GPS receivers I use is that sometimes they're two seconds fast for about 10 minutes. I attribute this to something to do with leap seconds - some bit of data relevant to leap seconds is only transmitted every ten minutes or so, and until the receiver gets it...

So what happened was that the clock showed time two seconds fast for a while, then the display froze for two seconds and then picked up again.

I'm pretty sure what happened was that the alarm system is set up to wake up at just the right moment to update the display. But if in the meantime the time has moved backwards, now you've got an alarm set for way in the future.

I'm going to just let that one go. In general, the clock shouldn't need to be horsed around like that too much. And if you do, and the display gets stuck, you can just restart the daemon.