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.

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. 

OpenEVSE II update

OpenEVSE II is for sale, and the design is more or less finalized at this point.

The most recent fiddling I've been doing has related to the pilot generator. While the old one was operating within the J1772 specification for the slew rate, it was barely doing so. One thing I learned the hard way was that resistors slow things down. But more so, in the original design, there was a tension between the primary transistor pair base bias resistors and the pull-up. In order to insure that both transistors are always in either one state or the other, the pull-up resistor has to overcome the bias path from +5 through the -12V primary transistor, to its base, through its base bias resistor, through the +12 primary transistor's base bias resistor, and then through the base-emitter junction to ground. In order to make that work, the pull-up had to be one tenth of what the base bias resistors were. The latest design was 10k base biasing and 1k pull-ups, but again, that was barely fast enough. The only improvement would have been to use 4.7k base biasing and 560 or 470 ohm pull-ups. But with that, you'd be sinking way more current through the microcontroller when it's pilot output was low. It just wasn't reasonable.

The solution was to change out at least the primary pair for MOSFETs. MOSFETs don't have a conduction path from their gate to drain, as there is in BJTs from their base to emitter. So the base bias can be 0 ohms and the pull-up can be 10k. The secondary pair can either remain a pre-biased BJT pair (47k emitter to base and 10k base to input), or can be also swapped out for a MOSFET pair, but with source-to-gate biasing of 2.4k and gate-to-input biasing of 2.4k (this is only necessary to reduce the gate voltage swings. Otherwise the -12 secondary gate will see a gate voltage of 17 volts, which is quite a bit). Either way, the slew rate is around 1 µs, which is half of the spec maximum of 2 µs.

If there is a next thing in the design to tackle, it would be to attempt to further increase the sensitivity of the GCM. Right now, it's on the order of around 50k or so, but the spec demands a trip point of 100 ohms per volt (so 12k for L1 and 24k for L2). Figuring out how to achieve that reliably is going to be a tough tuning task, but it still shouldn't result in any incompatible design changes at this point.

The next step will be to update the design of the Hydra to include all of the lessons learned. Stay tuned.

Important safety update for Toast-R-Reflow controllers

Everyone who has a Toast-R-Reflow model I or model II controller should obtain the latest firmware from GitHub and install it. The latest version for model I is 0.5, and for model II it's 1.2.

The change adds support for the AVR watchdog. The Toast-R-Reflow installed at The Hacker Dojo had some unknown event happen that wedged the controller with one of the elements switched on. This is obviously an undesirable outcome. It's unknown whether the watchdog would have been effective or not, but it certainly isn't effective if it isn't used.

If you are unsure how to update the firmware or have any questions, please feel free to contact me and I'll be happy to help. If you have no other way to apply this update, you can mail your controller back to me and I will apply it for you.

Bay Area Maker Faire 2015

Well, Bay Area Maker Faire 2015 is just wrapping up. I'd like to say a special thank you to the folks at Steamy Tech for partnering with us to make the blinky earring/pendants that we were selling. I'd also like to thank all of the people who stopped by. An awesome time was had by all.

Special thanks to the folks at OSHPark for supplying us the boards and Small Batch Assembly for their sponsorship.

If you got our business card and have landed here, then you can see our products in our Tindie store. If you need help or support with a product that you purchased there, you can contact me using the contact form on the right side of this page or at Tindie.

If you bought a blinky earring/pendant, I am going to put up a page soon with the schematics and a github link with the firmware source code - that will make it Open Hardware.

Thanks again, and hope to see you all again next year!

Lessons learned: The dangers of hidden licensing requirements

There was quite a kerfuffle this morning, and I won't say that it wasn't at least partly my fault for escalating it before the true nature of the request that was being made was made clear.

The nice folks (and there is no sarcasm there - they really are nice) at AdaFruit wrote me this morning to request that I license the use of their USB VID/PID for the USB µISP. Their request caught me quite off guard, as I was using the source code not from AdaFruit's site, but from the original developer, Dick Streefland. I could never recall any mention anywhere on either AdaFruit's site, or on Dick's that said that the USB VID/PID was anything other than free. In fact, the license for the source code is the GPL 2. It seemed to me at the time as if what was going on was that this was a hidden licensing trap, and that put me very much on the defensive.

Since then, things have become much more clear. AdaFruit has put a prominent notice on their site that while the source code for the USBTiny is open source, that does not convey a license to use their VID/PID without permission. And, at the present (and at the risk of speaking for them), it appears that their permission is relatively easy to get. And I do believe that those who have been allocated USB VIDs (and IEEE MAC address blocks, PCI vendor IDs and similar allocated identifiers) do and should have the right to govern how their identifier space is used.

For my own part, the lesson is that even code under an open source license can have licensing surprises in it. I think it's particularly incumbent on both rights holders to make their requirements clear to everyone so that there are no surprises, and on those who release open source software to insure that everything in their source code is covered by the rights their license grant implies.