My Project Workflow

Projects can take a long time to bring to fruition. This means that I often have several on the go at the same time, which in turn can cause me to miss out some important steps. So I thought I'd gather all of the tips and tricks I've learned in one place as a reference.

The idea

• scratch an itch
• read other makers (for example on hackaday)
• that new-fangled youtube can be useful too

Prototype

• use a breadboard and dupont connectors for speed
• sketch the schematic on paper as you go
• use an llm for advice or as a search engine to find similar projects
• plagiarise other people's designs, you might find one which does everything you need

Schematic

• break out KiCad or similar and copy the paper schematic
• separate subsystems and connect with labels
• add test points (and expansion points if that makes sense)
• use the electrical rules checker
• rebuild the schematic on breadboard to test it

PCB Design

• add component footprints
• use the design rules checker
• print the PCB at 1:1 on paper and check footprints
• make holes in the paper with a pin and check footprints again!
• use a ground plane and mounting holes
• use the silk-screen for component values, labels and version information
• add your email address (you never know)
• use a plugin to send your design for fabrication (for example to PCBWay)
• save the design and its firmware in version control (for example GitHub)

Board Assembly

• don't rush!
• add low-profile components first
• socket everything you might want to reuse
• solder up each subsystem and test immediately
• clean off flux with isopropyl alcohol and a toothbrush

Post Mortem

• if it works, document it on a blog like this one
• if it doesn't, fix it immediately, update the version, and document it on a blog like this one
• don't worry about anyone caring about your successes or failures!

Heroic Failures: Voice of TicBot

A project such as Magic Mouth (spotted at Dangerous Prototypes) is a fine example of the surprising power of the ATMega chip. With the addition of a simple audio amplifier and the impressive Webbotlib, your humble 8-bit microcontroller can turn English text into speech!

My first attempt at a project with a similar setup simply read text from the serial port and converted it into speech. (You can find the amplifier circuit schematic and Webbotlib code at Github here, it differs from Magic Mouth mainly by not depending on an external Arduino to supply the text to be spoken.) Here is a picture of it in all its homebrew glory; the amplifier is the little board piggybacking the Arduino clone, the 8-pin chip in the middle is an LM386.

Around the same time, I came across an article about a piece of software which tweeted tics: TicBot. While more Eliza-with-Tourettes than major AI breakthrough, it can be very funny:

@pani_bufetowa Billy Goat Gruff Survival Afternoon, Harrison Ford speaking.
— TicBot (@TicBot) February 8, 2013

Under the influence of Xmas cheer, an idea was born... Voice of TicBot! It would be a humble Arduino connected to Twitter by Ethernet, speaking TicBot's words of wisdom in a robot voice! How hard could that be?

The first obstacle was Twitter's use of OAuth; while this solves the problem of third-party web-application authentication, it is a pain for a device without a traditional UI. Thankfully the good people at supertweet.net have solved this problem, providing an OAuth proxy for Twitter to which devices authenticate themselves using good ol' Basic Auth.

It was then quite straightforward to write a little sketch which polled api.supertweet.net every 10 minutes for TicBot's timeline (using JeeLabs' handy Ethernet driver) and grubbed through the response for the id and text fields; no space for a fancy JSON parser here!

The next problem was how to combine the two applications? One an Arduino sketch (in C++) and the other a Webbotlib application (in C). Neither the option of porting the Ethernet driver to Webbotlib nor that of porting the relevant parts of Webbotlib to Arduino was particularly appealing. Moreover the combined size of the two applications exceeded the flash memory limit of the ATMega-328!

Fortunately a solution turned up in the shape of an Arduino port of Webbotlib's text-to-speech module, TTS. (This was a lucky piece of googling --- my Romanian is non-existent.) It required some work because my amplifier expected its PWM input to come from pin 3 whereas the TTS module emitted it on pin 10, which was needed for the Ethernet SPI. Adding the required functionality for PWM on pin 3 was achieved with the help of a nice online tutorial. An Arduino library updated for version 1.0 and with this functionality and some more examples (including the sketch for VoTB) can be found here.

With these problems solved, Voice of TicBot was finally operational! Unfortunately it was also a failure: the gnomic nature of TicBot's utterances combined with the low quality of the speech rendition made it necessary to visually consult twitter.com whenever output was heard! Here's an example of its output.

(All of this reminds me of a (possibly apocryphal) story about Stephen Hawking's first speech synthesizer: his students were pressed into service as translators, due, one assumes, to their familiarity both with the subject matter and the machine's vocal stylings.)

Mock Pertelian

The last post concluded with a shopping list of requirements for a workable wireless display. The picture above shows a prototype of such a thing. In particular:

• It doesn't try to be too clever: it uses an XBee as a wireless serial port and lets an ATMega do the heavy lifting, driving the display in 8-bit mode.
• It is compatible with an existing lcdproc driver, pertelian, hence the name.
• It bites the bullet and uses an external supply rather than batteries.

The backlight is turned on by touching a metal bolt on the top of the case. This bolt is wired to one of the ATMega's analog inputs via a solder tag. The case itself is a cheap perspex box costing about £1 from eBay.

The circuit diagram and Arduino sketch are shown below.

Update: after running for a week or so at 9600 baud, the 20x4 display was messed up. Although I never got to the bottom of it, the fault lay in the transmitting XBee: unless it was power-cycled, the problem persisted through reboots of the display and the box running LCDd. A successful workaround was to run all parts of the system at 57600 baud, i.e., both serial ports and both XBees.

Heroic Failures #1

This is the first in a (hopefully short) series of posts describing things which seemed possible beforehand but which turned out unsatisfactorily. It is inspired by a quote from Fred Brooks (via Nat) "Good judgement is the result of experience ... Experience is the result of bad judgement."

The initial motivation was dissatisfaction with the fact that all current (to my knowledge) lcdproc displays must be tethered to their host by either USB or Serial and that they might be much more useful if they could be positioned where they were needed.  When this was coupled to the observation that XBees are pretty smart and have lots of I/O, it seemed that driving a 4-line LCD display directly from an XBee using a couple of AA batteries might be a runner. The circuit is shown below and shows the display being driven in 4-bit mode with a couple of extra lines for EN and RS (I could only find a Series-1 Eagle part and used a Series-2 XBee so some of the pin names are a bit off).

One hacked lcdproc driver and some low-level XBee and LCD C-programming later, it worked... but only just!

• The display wouldn't work properly with 3.3v: it required 5v and hence another regulator for the XBee, e.g., an Explorer Regulated breakout board,
• It also wouldn't work (for very long anyway) on batteries: when its backlight was on, the display drew 150mA,
• Maintaining an out-of-tree driver (for lcdproc) is painful,
• It is extremely slow (about 1 char/sec). This is because each bit is framed in an XBee packet (thus requiring ~100 bytes to get one character to the display).