Category Archives: teensy

QWERTY (and nothing else)

I built a QWERTY keyboard that types the letters Q, W, E, R, T and Y, and nothing else. No space, no return, no escape.

It’s a fully-functional USB device, you know, as long as you just want to type words that can be composed with Q, W, E, R, T and Y. (WET, WRY, YET, TRY, there’s a bunch of them!)

I wrote plenty more about this project on my blog, and if you want to read about the history of the QWERTY layout, and its connection to Milwaukee, and why the way we interact with technology is interesting and sometime ridiculous, well… I got that too.

TARDIS Pinewood Derby Car With Light and Sound!

photo 3

This January my daughter decided that she wanted to join in her brother’s cub pack’s Pinewood derby with a replica of Doctor Who’s TARDIS on wheels.


Her design was pretty straightforward – balsa wood trim, poster paint, paper cutouts for the windows and sign, and her construction was quickly nearing completion. Then came the ask – “Dad, could you help me make a blue light on top flash? Also, it should sound like the TARDIS landing – can we do that? How about only when someone touches it?”.

photo 2

Playing a wav file, blinking a LED and setting timeouts so it wouldn’t run continually led to the idea of using a Teensy 3.0 that had been generously donated to Nova Labs by PJRC. It is Arduino compatible, has decent libraries and has a ton more flash than a Nano. The space limitation was dictated by how large (small) a hole we could hack in the underside of the Pinewood car, so small factor boards were necessary – and the aptly named Teensy fit the bill.

photo 1

The hardware was cake – we used an orphaned micro speaker from a broken monitor (liberated by said daughter during a Take Apart Day at NovaLabs), a jiggle-switch motion sensor from an offshore arduino vendor, and a blue LED. Power came from a gutted $1 Harbor Freight LED flashlight (3*AAA carrier) and we were all done but the code A tiny SPDT switch was salvaged from a broken toy.

photo 4


Jiggler board took 3.3v from the teensy, gnd and returned a line to an analog input that went momentarily high when the car was moved. If I were doing it again, I’d just use a jiggler switch and dispense with the board and circuitry (opamp integrator for debouncing, needed +/gnd, two wire would have been easier).

Speaker was capacitively coupled to a PWM digital output with a .1uF cap, the idea being that varying the pulse width duty cycle from 0 to 255 at a high rate (>>>8 kHz) would drive AC to the speaker via the cap.

Power was supplied to the Teensy per it’s pinout Vin (4.5V).


The only tough part was to find a utility to turn an MP3/wav I downloaded of the Tardis landing into an array of values that my arduino code would step through. Thanks to the internet, I found that has exactly what I was looking for – input is a wav file, output is a C def file to link in that provides a representation of the wav as an array of 8 bit unsigned values samples at 8 kHz (thanks to Ino Schlaucher).

Perfect – run the program pointed at your sound from the command line and a “foobar.h” file is output for inclusion into your arduino program.

The Arduino “IDE” is an inscrutable bodge, so I had to mess around with paths before giving up and putting files where I thought it would look (instead of pointing the IDE to where I wanted them to be). Your mileage will vary. Be prepared to fight it over where your files go.

The program was really simple as well, two timers are used – one to blink the blue LED on top, the other one used to grab a new sample out of the sampled array every 125uS, set the designated PWM channel appropriately and repeat until the entire sampled array has been played. A global keeps track of # plays, and it stops and waits for a new “jiggle input” before repeating again (twice actually).


#include <avr/pgmspace.h> // needed to support defining sounddata as FLASH based
#include <sounddata.h> // this is the noise/sound to play

const int ledPin = 13; // Teensy3 has LED on 13

void TardisLightisr(void);

volatile int TardisLightStatus = 0;

IntervalTimer TardisLight;
const int speakerPin = 3; // Teensy3 has Speaker on 3
void TardisSpeakerisr(void); // we’re going to call this function at 8kHz
IntervalTimer TardisSpeaker; // interval timer construct to call TardisSpeakerisr
const int jigglerPin = 14; // I wired the jiggle switch to pin 14
int jiggle=0; // jiggle state
volatile uint32_t sample = 0; // needed 32 bit unsigned, had issues w larger (8 seconds) samples rolling over the 16 bit counter – duh
volatile uint16_t PlaybackCount = 0; // keep track of the number of plays per ISR playback loops
byte lastSample;
byte ontime;

void setup(){
pinMode(ledPin, OUTPUT); // duh, LED is an output
pinMode(speakerPin, OUTPUT); // the PWM speaker output is an output
pinMode(jigglerPin, INPUT); // listen for motion on the jigglerswitch input
analogWriteFrequency(speakerPin, 400000); // Teensy 3.0 lets you do 400kHz comfortably, no aliasing or high freq artifacts
analogWrite(speakerPin, 0); // pull down the speaker to 0 to reduce current consumption

void loop(){
jiggle = analogRead(jigglerPin);
while (jiggle > 128){
jiggle = analogRead(jigglerPin);

TardisLight.begin(TardisLightisr, 600000); //sets the ISR rate inmicroseconds for the TardisLight – 1.2Hz rate
TardisSpeaker.begin(TardisSpeakerisr, 125); //sets the ISR rate in microseconds for the TardisSpeaker – 8kHz rate

while(PlaybackCount < 2){} //play the tardis landing loop twice
PlaybackCount=0; //reset the play count
TardisSpeaker.end(); //turn off the ISR
TardisLight.end(); //turn off the ISR}
analogWrite(speakerPin, 0); //turn off speaker output
digitalWrite(ledPin, LOW); // turn off LED just in case

void TardisLightisr(void){ // this is the very simple ISR routine called to make the TardisLED blink
TardisLightStatus=1-TardisLightStatus; //invert the status of the LED & write it digitalWrite(ledPin, TardisLightStatus);

void TardisSpeakerisr(void){
if (sample < sounddata_length) {
lastSample = pgm_read_byte(&sounddata_data[sample]); // read the sample index into lastSample from the datastructure hard-coded into sounddata.h
analogWrite(speakerPin, lastSample); //set the PWM to the just-read sample, this will average out because of the speaker’s inertia to a position
sample = sample +1; // increment sample

else {
PlaybackCount++; // guess we’re done playing the sample, inc the count and
pause a second
sample=1; // reset sample to 1}

Included sounddata.h, created by wav2c.exe (you will make your own file from a wav):

/* sounddata.h */
// sounddata sound made by wav2c
// (wav2c modified to use unsigned samples)

const int sounddata_length=69990;
const unsigned char sounddata_data[] PROGMEM = {,48,48,0,100,97,116,97,61,17,1,0,112,123,135,141,144,143,132,119,106,103,111,120




/* SNIP — 65000 values removed for brevity */



Heart Rate Running Jacket

If you’ve ever been running at night in New York City, you know that it can be dangerous, especially if other people can’t see you. This jacket was my attempt to not get flattened by a bicycle at night. Of course, I could have just bought some plain running lights, but what fun is that? Not only does this jacket have seven awesome flashy modes, but each mode responds to my heart rate!


Since my Garmin heart rate monitor uses the ANT protocol, I could easily intercept the heart rate information for my jacket. I used a Teensy and an ANT transceiver to control two LED strips based on the current mode selection and the current heart rate. The jacket is powered by rechargeable battery packs.

Heart Rate Running Jacket

My first run with the jacket was the 2013 New Year’s Eve midnight run in Central Park. Since then, I’ve worn it to a few races and even to a tech talk. The full build out details can be found here.


Disorient Pyramid at Burning Man 2013

Party at the Disorient Pyramid
This year the Disorient Camp at Burning Man built a 7m tall pyramid with over half a kilometer of LED strips. Several artists developed patterns for the panels, including Disorient founder Leo Villareal and Jacob Joaquin from Fresno Idea Works. Every night there was a party in front of the pyramid, with bicycles blocking the entire Esplanade.

The pyramid was visible from just about everywhere on the playa and served as a great beacon for finding the camp after a long night out. Read more for the technical details of how it was constructed and links to all the source code.

One of the longer patterns shows an evolution from the double helix of DNA, to the game of life to worms wiggly snakes before transitioning back to more abstract patterns.

Pyramid ToughBook
A Toughbook ran all of the pyramidTransmitter code, which rendered the frames to 24-bit bitmaps and sent them over UDP to the network. This machine spent all night in the dust and each morning was covered in several milimeters of fresh playa dust.

LED panel controller
Driving each face of the pyramid was a BeagleBone Black running LEDscape, which sliced the images into the individual panels. It then sent the individual pieces over USB to four teensy3 microcontrollers, each which had eight WS281x 30 LED/m strips. The tall panels had 5V 40A supplies, the smaller ones used 30A.

disorient led pyramid assembly party
The project was a bi-coastal one — the large panels were soldered and wired in California and much of the low level software was developed in New York. The boards were designed by Naim and available under an OSHW license. On site a crew of volunteers assembled the panels onto the pyramid structure built by the rest of the Disorient camp.

Operating in the harsh conditions of the Black Rock desert is difficult for electronics. We had lots of trouble with the powersupplies failing due to the heat and dust; next year perhaps we’ll use more, but lower amperage, sealed DC supplies. The adhesive holding many strips to the pegboard failed. Several of the solder joints broke due to stress during mounting. Screw terminals rattled loose from the 25KW of sound system in the Disorient dome. There was late night soldering while hanging from the rafters of the pyramid. Despite all these problems, the panels and the sixteen thousand LEDs put on quite a show the entire week.


LEDscape test
Are you building a giant LED display for your hackerspace or Burning Man and need a way to control multiple kilometers of LED strips? Are you tired of running massive USB hubs of Teensys for each row? Then you might be interested in my LEDscape code for the BeagleBone Black to drive up to 500 meters of WS2811 RGB LED strips at 30fps.

On the Teensy 3, Paul’s OctoWS2811 makes very clever use of three DMA engines to generate the bit-train for the WS2811 LED strips, but only supports up to eight strips. Beth’s FadeCandy improves on Paul’s work and has a great frame rate with beautiful interpolation (and a custom USB protocol to pump pixels fast enough to keep up with the frame rate), but the temporal dithering and expanded colorspace features run into frame rate and memory limitations at strips beyond 64 pixels.

The BeagleBone Black has far more memory than the embedded AVRs (512MB versus 16KB) and the AM335x ARM Cortex-A8 has a killer feature: two built in PRU (“Programmable Realtime Units”). These are embedded real-time microcontrollers built into the ARM core with full DMA to main memory and control over all of the IO pins. This afternoon I hacked up a quick proof of concept in PRU assembly that use one of the units to drive 32 of the WS2811 strips at full speed with zero CPU load and easy double-buffering of the image. The best parts of writing for the ARM instead of the AVR is that there aren’t any issues with running out of memory for image processing and there is built-in ethernet for OSC or other visualization libraries.

The drawback to the BeagleBone is that the 3.3V signals won’t travel very far for large scale displays. Matt Mets (of Blinkiverse and Blinkitape kickstarter) and I are designing a “cape” to add 32 RS485 drivers to translate them to differential signals for longer runs. Add in art-net support and it will be part of an awesome DMX/VJ system.

Future Crew

Last month we introduced Future Crew, and at the 2013 Interactive Show we finally unveiled the fully mostly operational game stations. There were five stations in the final design, and in keeping with the show’s “Digital Archaeology” theme, each was built from repurposed ancient hardware. The brains of each console was a Raspberry Pi (to connect to the network and draw OpenGL graphics) and some number of Teensy microcontrollers to interface with the real world. Of course, the source is available for you to build your own Future Crew stations!

Future Crew Game
A discarded video edit console and RF TV became the Timeline controller. Since the Pi can turn the composite video on-and-off, one of the modes glitches out the TV occasionally with real static! This one had some of the more imaginative tasks like “disable all blinking buttons” in addition to the normal tasks like “advance the timeline!”.

Future Crew Game
A rackmount data acquisition analog-digital converter and three NTSC TVs became the Blender control unit and Technobabble patch panel. The labels were printed on our large format plotter and then the BNC holes were cut on the laser cutter. The teensy++ firmware can handle arbitrary cross connects and even multi-way connections. This was one of the harder stations to play — there are eight switches, twenty verbs and twenty nouns. We ended up disabling all the verbs except “MODULATE” since it was much too difficult to find the right ones. As a todo item we plan to ramp up the difficulty as the game goes on.

Future Crew Game
A 1930′s Model 15 Teletype and some random video switcher served as the slowest output console. It’s amazing that the teletype functioned nearly perfectly for the entire eight hour show — perhaps the fresh quart of oil during the previous servicing helped keep it working. The source for this console is one of the simpler ones — it just prints to a file descriptor to write to the teletype.

Future Crew Game
One of the hardest consoles was made from a toy piano. Even with the song book, playing “Row Row Row Your Boat” under duress is not easy.

Dial James Bond!
And a last minute entry was a rotary phone. Quick! Get the President on the line! This time the handset just had a recorded loop, but future games will incorporate text to speech.

We have a whole list of things to fix and improvements to make before Makerfaire 2013. Stop by NYCR to play it during Craft Night on Thursdays and give us your suggestions!

Space Rocks

Space Rocks on the oscillograph
Cathode ray oscillographs weren’t just used for reading tweets in the 1940′s, they were also used as vector displays for serious astronomical simulations and training systems like “Space Rocks”. You can play it at the 2013 NYC Resistor Interactive Show!

While the Delta-V of the simulator space craft was optimistic for its era, the basic acceleration, velocity and position model is reasonably accurate. If the ship passes too closely to one of the space rocks, it is destroyed and the simulation restarts. Once the ship runs out of fuel (measured in hexadecimal in the upper left corner since the CPU can’t perform a DIV/MOD operation fast enough to display decimal numbers), it is stranded and unable to continue its mission.

Space Rocks joystick interface
We were not able to locate an original controller, but the interface is similar enough to more modern analog joysticks that we could wire it in. Have your own vector display? spacerocks.c is the source for the Teensy to drive it.

1930′s Teletype USB interface

Model 15 rear view
The Teletype Corporation Model 15 “typebar page printer” is a beautiful piece of equipment from the 1930′s. While the interface has much in common with modern serial communication standards – start bits and stop bits, asynchronous clocking, idle-high conditions — in the teletype all of these are implemented purely mechanically. The mainshaft looks like something out of an automobile instead of a piece of computing. Just like a car, you have to keep it well oiled, check the gaps for proper clearances and be very wary of the spinning pieces while working on it.

The 5-bit Baudot words are clocked in synchronously with the mainshaft’s rotation rate at 45.5 baud (22 ms per bit). This slow speed is difficult to generate with modern computers and serial ports, so many users bit-bang the port with Heavy Metal, which itself requires somewhat older machines to run. The 5-bit word has only thirty two entries, which is insufficient to simultaneously represent the entirety of the twenty six letters A-Z, ten digits 0-9 and punctuation. Instead there is a reserved code to switch to Figures and another code to switch to Letters. Space, carriage return and line feed are present in both the Letter and Figure sets. The interface must track which rail is currently selected and insert the correct shift sequences on the fly.

In slow motion the holding magnet can be seen pulling the selector during one-bits and not attracting it during the zero-bits. Each bit is latched via the “sword” mechanisms onto one of the rails, which select one of the twenty-eight hammers. During the fifth bit an extra gear cocks the mechanism and a latch lets the hammer fly during the stop bit. The coils are designed for 60 mA, but have a very high inductance (on the order of 4 Henries according to John Nagel). Most approaches to interfacing with the system use a large 100 VDC power supply and a current limiting resistor (that must dissipate 6 W of power!).

Teletype Model 15 USB interface board
Both the high voltage and the custom baud rate issues are a bit cumbersome, so I thought there must be a better way. USB ports will output about 5 W, so I figured that would be close enough to drive the magnet if I could produce sufficiently high voltage. Using Adafruit’s boost converter calculator, I came up with some rough numbers and built a circuit that handles both the slow baud rate and voltage required to interface with the teletype. It shows up as a normal USB serial port and handles the 7-bit ASCII to 5-bit Baudot translation, including tracking which of the two rails is selected, outputs the bits at the correct baud rate, and runs the PWM charge pump to generate the high voltage with the inductor. A second MOSFET is used to switch the high voltage through the current loop, allowing the holding magnet to turn on and off.

It’s fully self-contained, fits in an Altoids tin and works with any software you want to run on the interface computer. If you want to run it with a Raspberry Pi, be sure to use a powered hub to avoid overloading the Pi’s weak USB power circuitry. The schematics and source code are posted to and you can see it in action as part of Future Crew at the digital archeology themed 2013 NYC Resistor Interactive Party.

Introducing “Future Crew”

Building "Future Crew" console #1
Do you enjoy playing Space Team, but find that you want tactile controls? Or like the Artemis Bridge Simulator, but think it is too serious? Do you love pushing buttons, turning knobs and shouting at each other? Then you’ll really have fun playing Future Crew at the NYCR Interactive Party!

Future Crew push button panel construction
Since the theme of the party is “Digital Archeology”, all of the control stations are being built from repurposed dead hardware. There’s a patch panel, push buttons, strobe lights, more push buttons, quadrature knobs, oscilloscopes, and maybe even a teletype to keep score.

Future Crew display console
Each console will have a Raspberry Pi with Wifi to talk to the other consoles, some number of Teensys to talk to the real world, and some sort of glitchy way to communicate to the operator (like an NTSC TV or a Minitel). If things don’t work right, that’s part of the fun. And, of course the source code will be available for you to build your own Future Crew Consoles.

Tickets for the party are on sale now!