Wednesday, June 24, 2015

Crazy Clock accuracy problems

I've discovered a design flaw in the Crazy Clock. The result of this flaw is that the clock fairly consistently gains time at a rate of ~120 ppm. That's around ten seconds fast per day. The clock is supposed to stay within 10 ppm - more than an order of magnitude better than that.

Fortunately, the error is consistent in the samples I've taken, and can be corrected in software.

If you've got an affected clock, there are two ways to fix it:

1. If you're very confident in your surface mount soldering skills, you can add a 12 pF capacitor between each lead of the crystal and ground. I do not recommend attempting this, as there's very little room on the board, and almost no margin for error. If you ruin your board attempting this, I won't replace it.

2. The new SW_TRIM facility can be used to trim the clock frequency to compensate for the error. To do this yourself, fetch the firmware from github, compile it with -DSW_TRIM and reflash the controller. After doing that, you'll also want to set the trim factor in EEPROM. It's located at address 4 and is a two byte, two's compliment, little endian integer representing the amount of adjustment in tenths-of-a-ppm. Positive values slow the clock. The standard correction factor for this error is 0x490, or 116.8 ppm slower. The avrdude argument to achieve this is "-U eeprom:w:0xff,0xff,0xff,0xff,0x90,0x04:m". If you do this, you'll wipe out the PRNG seed at locations 0-4, so if your clock has random behavior, you should replace each of the '0xff' in that command with four random numbers from 0-255. There's no harm in not doing this, really, but your random number generator will wind up starting from a "standard" state, resulting in repeated behavior the first time you power the clock up. Don't forget that the system clock speed is 32.768 kHz, so your programming SPI clock must be no faster than 4 kHz. Achieve this by adding either -i 125 or -B 250, depending on your programmer.

If you have an affected clock, you may ship it back to me and I will apply the fix and return the clock to you for free (including shipping to get the clock back to you). If you bought a complete movement, return just the movement - keep the hands and face and stuff. If you bought a controller only, then please return just the controller. In both cases, you'll get a replacement, not necessarily the same one you send. Please be sure to indicate which firmware style you wish. To proceed, contact me with the contact form and I'll send you the address to ship your movement or controller.

Friday, June 19, 2015

Sidereal clock movements

The Crazy Clock has been out there for a while, and one of the firmware options for it for almost as long has been the Sidereal clock. In looking around the Internet, I've found sort of a background rumble of interest in Sidereal movements for astronomers.

For those who aren't aware, the 86,400 second long "day" we know is more precisely a "tropical" day. It's the amount of time (roughly) it takes for the sun to go from the local meridian (the north-south line passing through the zenith - the highest point it reaches) on one day to return to the meridian on the next day. A sidereal day, on the other hand, is the amount of time it takes a star to go from the meridian on one day to the meridian the next day. The two are not the same amount of time, because at the same time that the earth is rotating on its axis, it is revolving around the sun. Over the course of a tropical year (the time it takes for the Earth to return to the same point in its orbit), the revolution adds an extra rotation. So a sidereal day is 1/365.2425(ish) shorter than a tropical day. That works out to 3 minutes, 56 seconds (that's not exact, but it gets us to inside of the 10ppm tolerance of the clock movement, which is enough).

If you combine a 24 hour clock movement with a sidereal controller, you wind up with a very special clock for astronomers. If you superimpose a star chart for your hemisphere, centered on the pole, the hour hand will always point to the star or constellation passing through the meridian (as long as you set the clock to local apparent sidereal time). It's this property that makes 24 hour sidereal movements valuable for building things like automatic astrolabes.

So for those looking, pre-built, ready-to-use 24 hour sidereal clock movements are available from my Tindie store. Just select the pre-built 24 hour movement with the sidereal firmware. They're in stock now!

Wednesday, June 10, 2015

AVRDUDE with linuxgpio and least privilege: don't sudo

The principle of "least privilege" is a valuable practice. Far too many people just put "sudo" in front of everything when they're using *nix - particularly on the Raspberry Pi, which is often thought of as a sort of throw-away computer.

Fortunately, the Raspberry Pi folks were thinking ahead a bit and created the "gpio" group and rules in devd to set the ownership of the GPIO nodes in /sys so that you don't have to be root to use them - you just have to belong to the correct group.

There is one "gotcha" to this, however. To understand it, we need to look at how GPIO functions on the Raspberry Pi.

In /sys, there is a GPIO class - that is, a directory - at /sys/class/gpio (that's not actually where it is, but there's a symlink there, so for our purposes, we'll just say it's there). Inside that directory, there are two nodes "export" and "unexport". To take control of a GPIO pin, you open "export" and write the pin number there. When you do, a new directory will show up named "/sys/class/gpio/gpioX/" where X is the GPIO number. Inside that directory will appear a bunch of nodes that will allow you to take control of the pin.

The gotcha, however, is that the kernel driver doesn't know anything about the "gpio" group. It sets the ownership of all GPIO nodes to "root:root" and "rw-r--r--" (0644). devd comes along at some time after the nodes are created and resets the permissions so that the nodes are writable by the gpio group. Normally this isn't a big deal because most of the nodes in /sys are created when the driver is probed, usually at boot. But in this case, avrdude attempts to export the GPIO pins, and then immediately set their direction. If it does so too quickly, it will get EACCESS attempting to open /sys/class/gpio/gpioX/direction.

People have so far worked around this by simply running avrdude as root - either by prefacing it with "sudo" every time or by making the binary suid as root. These are bad ideas. If for no other reason, if you ask avrdude to read from the chip and write to a new file, that file will be owned by root, rather than by the user running avrdude.

One quick and dirty solution to the problem is to introduce a short delay between the export operation and the rest of the initialization. But more to the point, the delay must also yield the CPU so that devd gets a chance to run. To that effect, my patch just uses "sleep(1)". It's probably too long a delay, but it works consistently.

Another way to go is to remove the export and unexport operations from avrdude and instead leave the pins permanently exported, exporting them from some sort of script possibly run at boot. This is safe to do, since the linuxgpio driver in avrdude is careful to set all the pins as input before exiting, which will return them to high impedance state. I haven't implemented this change, but it would allow avrdude to run faster since there would not be a 1 second delay every time.

To proceed, download AVRDUDE 6.1 and apply this patch. Then build as usual. Having done so, you can now either make avrdude sgid and set its group to gpio, or - probably better - add yourself to the gpio group. No more sudo!

Sunday, June 7, 2015

Crazy Clock contest!

Have you built a clock with the Geppetto Electronics Crazy Clock movement? Then here's your chance to win a free $25 gift code to OSHPark! Just tweet a picture or video of your creation to @nwsayer #CrazyClock any time before July 1st, 2015 (midnight, Pacific Daylight Time). To be eligible, the clock movement must contain a Crazy Clock controller, and you must live somewhere where it's not illegal for you to participate in the contest. Entries will be judged on creativity and humor, and the winner will be announced on July 4th, 2015. The gift code will be presented to the winner via Twitter DM.

Monday, June 1, 2015

AVR ISP Pi Cap user guide

This is the permanent home for the user guide for the AVR ISP Pi Cap.

This board provides level shifting and voltage protection (including hot-plugging) for AVR programming via the GPIO pins on a Raspberry Pi. It allows you to select the target power supplied to the target as either 3.3 volts, 5 volts or no power (meaning that the target is self-powered). The programming pins for the target will be level-shifted to whatever voltage is supplied to or by the target when programming is taking place, and will be high impedance otherwise. The buffer chip protects the Pi's GPIO pins from any invalid excursions. An AP2331 hot-plug protection chip protects the Pi from shorts and hot-plugging voltage sags.

The board comes with the stacking header (for the Pi) and the shrouded DIP header (for the target) uninstalled. It is strongly recommended that you install the stacking header first so that the shrouded DIP header doesn't get in the way of your soldering iron.

The GPIO pins selected are the MOSI/MISO/SCK pins for SPI port 0, however !RESET is connected to GPIO pin 25 rather than using one of the SPI CE pins. This allows !RESET to be asserted in a separate operation rather than being asserted and deasserted with every SPI operation performed during a single programming session. With this configuration, you have a choice of using the "linuxgpio" driver built-in to avrdude version 6.1, or the higher performance native SPI driver.

To use bit-banged GPIO, configure AVRDUDE for the "linuxgpio" programmer. Add this section to your avrdude.conf file:

programmer
    id = "pihat";
    desc = "Use the Linux sysfs interface to bitbang GPIO lines";
    type = "linuxgpio";
    reset = 25;
    miso = 9;
    mosi = 10;
    sck = 11;
;


Having done that, you should be able to use the -c pihat argument to avrdude to program a target. If it doesn't work, make sure you have an avrdude binary compiled to include the "linuxgpio" programming driver. AdaFruit has a guide that shows how to build avrdude 6.1 to include that driver. The LED will light when the !RESET gpio pin is brought low, and the bus buffer chip will bring the target !RESET pin low and assert the ISP signals on their relative pins.

Note that as of 6.1, there is an issue with the linuxgpio driver in avrdude. There is a race condition between avrdude writing to the GPIO "export" node to export the GPIO pins, and udev setting the permissions properly on the newly created nodes. The only workaround (at present) is to patch avrdude to add a delay between the export and the rest of the operations. Here's a patch.

If you are used to using -B to slow down the SPI clock, you can still do so, but the correct argument is -i instead (with the same numeric value).

To instead use the SPI driver, you'll need to apply a patch to avrdude to add the "linuxspi" driver (TBD).



Sunday, May 31, 2015

Crazy Clock: Reverse engineering the Quartex movement

The Crazy Clock is a pretty good product, but what it needs to take it to the next level is a manufacturing partner to actually make movements with the crazy clock built in in place of the boring controllers that are normally used.

So far, I have been taking Quartex Q-80 movements apart, cutting the traces on the board, and wiring the crazy clock into place. That works acceptably, but the retrofit operation is very fiddly. There has to be a better way.

So I sat down and attempted this evening to reverse engineer their enclosure and board.

The gear assembly with the original controller attached

The space in the chassis where the assembly sits

Here's what we have to work with. The metal contacts from the battery holder at the top (in this picture) of the chassis mate with the contact patches at the bottom of the board. The large "hump" at the bottom right mates with the large square cutout in the board. The hole at the bottom left mates with the pin that comes through the board at the top left. The other holes and slots in the board accommodate pins and protrusions from the gear case, and the single screw that holds the assembly together. In the upper right corner of the chassis and to the left of the board space at center, there are two small spacing pins that are meant to rest against the gear case assembly.

The board

The board can be removed from the gear train simply by removing the single screw at the bottom between the contact patches and desoldering the two coil pins. The board simply lifts off the gear case. Note that the screw holds the two halves of the gear case together. I made no attempt to open the gear case, as it's entirely likely that the gears would be difficult to reassemble if they fall out of place. Since there's no need to access the gears, there's only a downside to attempting to get in there.

Carefully measuring the location of the features of the original board led to this design (seen here as rendered by OSHPark):



Note that the space at the bottom left is dead space to accommodate the spacing pin that's in the upper right corner (as shown) of the chassis. Immediately to the right of the ISP header is the cut-out. One of the goals of the design is to make sure that the ISP header is available for programming even with the board assembled in the movement. That will make reprogramming it easy (or at least easier).

There are, at this point, still some important unknowns around the physical tolerances - particularly in terms of depth. The original board is thinner than the boards from OSHPark, and the original board had only the bonded and potted chip rather than a collection of traditional surface mount parts. I did, however, hold an original crazy clock board in place in the bottom of the chassis and it did appear to be flush with the spacing pins, which suggests that it will work. No way to know for sure until the prototypes come back in a week.

If this works, then it will make the process of retrofitting the Quartex movements much easier. The risk, however, is that if I order a ton of them and then Quartex redesigns their movements, I'll have a completely worthless inventory.

Thursday, May 21, 2015

Tiny Blinky user guide

If you were at MakerFair Bay Area 2015, you may have seen (or hopefully even purchased) a pair of little round blinking earrings from us.

I've finally gotten around to fulfilling the "open" part of "open hardware" - this page.

The circuit is simplicity itself: An Attiny84 with 8 LEDs, an SMD pushbutton and a CR1220 battery clip. The only other component is a 10k pull-up resistor on !RESET. The series resistors for the LEDs are present, but it turns out that 0 ohms is the best value to use.

Normally, it's always a good idea to add a 0.1 µF bypass cap close to the Vcc pin of any logic component. In this particular case, however, we can get away with omitting it because the ATTiny is the only load, and the battery is so physically close.

If you push the button briefly (<250 ms), it will change the pattern (remembering the selected one in EEPROM). If you push the button longer (>250 ms), it will power the blinky off. While it's powered off, the battery will last "indefinitely" (limited only by its own shelf life). While it's running, you can expect it to last for an evening or so (we had better luck at Maker Faire - they lasted the whole weekend, albeit powered off overnight).

There isn't a lot to say about how it works. The one thing of note is that the ISP programming pins should not be used for LEDs, since there are no series resistors. Programming could possibly wind up pushing too much current through them. MOSI and SCK are therefore connected only to the ISP header, and MISO is used only for the button (so don't push it while programming is in progress).

Schematic


The firmware is available on GitHub