I like to make unusual clocks. Not an unusual in how the time is displayed -- for the display I like something that people will look at and know immediately a) it's a clock and b) what time the clock says it is -- but in the underlying basis for timekeeping. I've recently been thinking about making one that uses the sun.

Sure, a sundial does this. Sort of. But I'm thinking more like local civil time that's accurate to under a minute whenever the sun is out. I'm hardly the first person to get this bug. There are some really clever shadow- or light-casting dials with no moving parts (with the exception of some way to deal with summer or daylight-savings time). These are bespoke devices built for the exact spot they're installed. I'm thinking of something a little different, a device that, given its location, orientation in space, the current date and (because it's not constrained by physics) whether summer/daylight time is in effect just works.

There are a lot of steps between here and there (including a fearsome amount I'll need to extract from Jan Meeus's Astronomical Algorithms). But I digress.

One of the first steps in deciding how to make such a clock is to decide on how it will track the sun's position in the sky over time. There are many, many choices here. Among them are heliostats, devices that, through one means or another, hold the sun's image steady with respect to the sun-sensing part of the device. The device at hand is intended to explore how well one of these can be made to work.

For this heliostat, the basic idea is to point a part of the device -- the sun sensor -- directly at the sun where it will form an image of the sun at the center of a planar image sensor when the image sensor is perpendicular to sun's position in the sky. The sun sensor is mounted in a hobby-servo-powered alt-az mount that can steer the sun sensor to point it at the sun. An Arduino Nano interprets the image and drives the servos so as to keep the sun's image in the middle of the image sensor.

Oh, and I want the whole thing -- especially sun sensor -- to be as simple and cheap as possible both conceptually and physically.

I've decided the image sensor should have four "pixels" made from 5mm red LEDs as its light sensors. Yes, LEDs make rotten light sensors, but since the target is the sun, rotten is more than good enough. Plus using an LED as a sensor is a hack, right? An image sensor with a total of four pixels doesn't make much of an image, to be sure, even with good image-forming optics. And the image forming-optics I decided on consist of 3mm Baltic birch plywood fins. Very bad, optics indeed. But the fins are arranged so that unless the device is pointed directly at the sun, at least two of the pixels will be in shadow. That's enough of an image to let the Arduino figure out which direction to turn to be more closely facing the sun. When all four pixels are equally illuminated, there's the four-pixel image; the sun sensor is pointing at the sun.

Oh, and one more thing. The LEDs don't all respond to light in exactly the same way. So calibration is needed to compensate. No biggie, just manually adjust the altitude and azimuth until the sun sensor is pointed directly at the sun and tell the Arduino, "This is what you're going for." And maybe do that several times to get a handle on how things are with different sun brightness.

That's what the device described here does. And it does it surprisingly well.

But it needs to be much better. Now in its second iteration, the pointing accuracy is about ±1°. Since the sun moves 15 degrees per hour, I'll need to get that down to less than a quarter degree. The constraint on pointing is now down to the 1° per step of the direct drive azimuth servo. As soon as I fix that, the problem will be the elevation which, on average, can track the sun to about a half degree. And in both cases, slop in the mechanism means extracting the actual altitude and azimuth from the position...