blog.tommy.sh

Hello, F0

Thu, 04 May 2017 17:00:00 PDT

Say hello to the F0!

The F0 is a minimalist, analog, square wave synthesizer with chunky 3D-printed piano key overlays, 9V battery power, and a “Feathergrain” (from which we get the F in F0) box enclosure.

Because space inside the enclosure was tight and I wanted mostly just to validate a new button layout design, it is admittedly a very spartan Minimum Viable Product (MVP), but it sets a nice baseline for later iterations.

Quick overview

The heart of the F0 is a Voltage Controlled Oscillator (VCO) from a CD4046 chip. A VCO, as its name suggests, is a machine that creates a frequency determined by some input voltage. Here, a 9v battery feeds a 5v regulator to create a constant reference voltage, which is then dispersed across buttons, diodes, and trim potentiometers (13 of each) to make voltage dividers. The potentiometers tune each note, the diodes prevent the notes’ voltages from contaminating each other, and the button switches ensure that the voltage only passes when the user intends for the note to be played.

The F0 only has one VCO, which means it can only play one note at a time and is therefore a monophonic instrument. (In contrast, the POLY1 I made awhile ago is polyphonic and all of its notes can be played simultaneously.) While there’s only one octave of keys from C to C, the tuners support five full octaves.

(For more info on the chip and its VCO capabilities, read this Logic Noise article on Hackaday.)

Key buttons

Manually laying out and soldering a dozen to a couple dozen of those voltage divider circuits is a painstaking and error-prone endeavor, so the first task was to design a Printed Circuit Board (PCB) to make it easier.

I envisioned a modular system that would allow daisy-chaining any number of PCBs together to sum into a desired number of notes. Since each board wouldn’t know where in the musical scale it was, its layout must be agnostic to disposition; the same position should serve natural/accidental/white/black keys equally.

If that weren’t enough, I also imagined that the same system could be used for both monophonic and polyphonic instruments. As such, the buttons are on a separate PCB from the diodes and tuning potentiometers I described above.

Here are the fabrication previews of what I came up with for the tuning PCB (top) and buttons PCB (bottom):

You can see that the header pins at the top and bottom of the two boards mate, and the horizontal pins on the buttons PCB mirror to match any siblings.

The A, A#, B, C pin labels basically denote potentiometer pins. The NC (Normally Closed), CM (Common), and CO (Commonly Open) labels are for the switches themselves, though my understanding in the design was incorrect so, for now, they’re unused cruft.

The 2x6 grid of rectangles below the pins is for the note buttons; the top row is for accidental notes and the bottom is for naturals. I haphazardly decided there should be 6 columns of notes.

(While I was at it, I made another version that used a different kind of button but observes the same chaining mechanisms. I’m hoping this will be used in the F1…)

So anyway, the F0 uses two and half of these PCB combos. They’re held together and under their respective keys with a 3D-printed cradle support.

Lessons learned:

This PCB system takes up way too much space. It’s basically ⅔ of the enclosure’s floor space, which is not acceptable aesthetically (the PCBs are cool but mostly repetition -- they shouldn’t be the machine’s internal focal point) nor practically (I want more room to do other stuff!)
Too much of the impressive parts of this system like the 3D-printed supports or the ribbon cable connections aren’t visible and so can’t be admired when the enclosure is open. I am of the opinion that hard work should either be recognized or obviated.
The horizontal daisy-chaining isn’t useful at this small scale. If an MVP piano has a full octave of notes, so should each individual board.
If I ever expect anyone else to do this, I need to make the assembly much simpler and cut out as much fiddly ribbon cable soldering as possible, even if it means the boards aren’t as modular as I’d intended

Buttons, meet keys

With the buttons in place, the next step is to lay some key overlays on top to make the experience closer to that of a real piano. I explored a couple different mounting options, but, for the F0, the overlays are bolted into a rectangular window cut into the top of the enclosure. When the lid closes, they simply sit atop their respective buttons.

(Designing these key overlays was a lot of fun and something I’ve been kind of noodling on outside of software for some time. A separate writeup is in the works.)

The rest of the electronics

So the buttons provide tuned voltages to the VCO, which makes sound that’s amplified by a simple headphone amplifier, and that’s sent to the speaker. A switched potentiometer plays dual roles of setting the volume and turning the machine on and off, and a thick 10mm LED makes sure the user knows when it’s on.

The PCBs were professionally fabricated by a third-party service, but the rest of the circuitry is on perforated board. Thus the discrepancy in board color and style.

(One problem I didn’t totally figure out for this project is what I’ve learned is called “VCO frequency pulling/pushing”: changing the volume inadvertently changes voltages and consequently shifts frequencies, making the instrument subtly musically inaccurate.)

Enclosure

The store-bought box enclosure gets the job done but is a glaring concession in what would otherwise be an entirely custom piece of work.

Lessons here:

Light wood is easy to cut but is too brittle and breaks too easily. It just feels cheap.
Too many holes (most noticeably, the giant window for the key overlays) make for a lousy speaker cabinet. Even if the speaker were better, there’d still be no low end
I wanted the volume knob to have a flush exposed height with the LED, so it’s not mounted to the enclosure like I’d typically do. Instead, it’s mounted to the circuit board and the enclosure top has a knob-sized hole to fit over top. This makes the hinged lid difficult to close
Designing my own hinges really felt like reinventing the wheel, but that’s okay!

Down the line, I’d like to make my own enclosures. Not yet though.

Getting 3D

I had to model the key overlays, PCB supports, speaker grill, and enclosure hinges, so I might as well throw them all together.

A cool side effect of having the full instrument as a 3D model is that I can use it to make a stencil for cutting holes on the real enclosure.

What does it sound like?!

Here’s a video of the F0 getting tuned up and playing a haphazard blues scale.

Hello, F0

In the end, given the F0 is an MVP w ith limited musical use, I don’t think I’ll try to sell it and will instead keep it around for reference and plunking. It’s got its imperfections, but I’m pretty happy with how it came out.

Stay tuned for more!

Animation Easing in OpenSCAD

Sun, 14 May 2017 17:00:00 PDT

OpenSCAD provides a $t variable as a representation of the animation’s progress. It starts at 0, increases to 1, and immediately loops back to 0. The movement is called linear because each step is equal across the timeline.

Things in real life, however, hardly ever move exactly linearly. Consider a bouncing ball or a felled tree or your swaying arms as you walk. Gravity accelerates each, increasing its speed as it falls; if it comes back up, like the ball or a swaying arm, it decelerates to zero velocity at the apex when the cycle repeats.

Motion designers call the math of how an object moves between two states an easing function. I won't pretend to fully understand how they all work mathematically, but I luckily don't have to; because their definitions don’t change across different programming languages, porting from one to another is relatively straightforward.

Demo

Code

(Demo code available here. Based on Easing Equations by Robert Penner.)

Usage

Simply include the file and wrap $t in any of its functions.

include <easing-functions.scad>;

translate([ease_in_cubic($t) * x, 0, 0]) { ... }
rotate([0, 0, 360 * ease_in_out_cubic(undulate($t)]) { ... }

Unless the starting and finishing states are identical (like cyclically rotating from 0 to 360 degrees), you’ll want a timing variable that fully goes back and forth, from 0 to 1 and back down to 0. The demo above does this by doubling the absolute distance from the midpoint:

function undulate(t) = abs((t - .5) * 2);

In the end, it may seem like an oxymoron to fret over realism in CAD software specifically designed more for machine parts than lifelike art, but I've found that if it's a trivial amount of effort to make any artificial thing more believable as a real thing, it's worth it.

Chord Synth

Tue, 23 May 2017 17:00:00 PDT

Inspired by a chord organ I had in high school, my 'chord synth' is a lo-fi analog interpretation with twelve oscillators, sixteen chords, and a wild jungle of routing jumper wires.

Organization

The internals try to follow the principle of single responsibility. Counter-clockwise from top-left in the photo:

An oscillator board for the notes
A buttons board for user input
A router for connecting each button to its three notes
A "chassis" board for the amplifier and its volume, battery, and other components that are connected directly to the cigar box

Each board has input and output header pins and is connected to its siblings with ribbon cable.

Board 1: Oscillators

Oscillation is "movement back and forth at a regular speed". In electronic circuits, that movement is of a voltage, and tuning its timing and applying it to a speaker results in an audible frequency: a note!

So the heart of the this instrument is twelve oscillators, one for each note in a complete octave starting at C#: C#, D, D#, E, F, F#, G, G#, A, A#, B, C

Why so many, instead of just one? The answer is polyphony: with one circuit per note, each can be played at the same time. Obviously, since a chord is comprised of multiple notes, a monophonic (one note at a time) solution wouldn't do.

Oscillator circuit

Borrowed from an 80s toy called the Magical Musical Thing, each oscillator circuit is based around a CD4049 Hex Inverter.

Like its name implies, the CD4049 has six inverting logic gates. If you give it a positive voltage (aka 1), it returns ground (aka 0); give it 0 and it returns 1. If you daisy-chain an odd number of inverters, they loop forever and make what's called a ring oscillator.

The board rigs up 12 of these:

Power for each CD4049 is provided by the red wires, which are connected by ribbon cable to the router board
Three of the 6 inverters on the CD4049 make a square wave, tuned by a 5k trimming potentiometer and a fixed capacitor
The other three inverters make a simple amplifier
When any oscillator is on, its output is summed through a mixing resistor to a common output in the green wire

I/O

(from left to right)

12: discrete powers from router
2: summed oscillators, ground

Board 2: Buttons

Inside and I/O

The buttons are DPDT, Double Pole Double Throw. One pair connects power to an output pin for the router. The other connects power to a "playing" status LED.

3: power, ground, "playing status"
16: chords to router

Outside

The buttons are pressed indirectly by means of overlays: cut, sanded, and painted dowels loosely fastened to the chassis by rubber band.

Aside #1: Practicality

The twelve notes generated by the oscillator board can be exhaustively combined to play all possible chords, but for simplicity I pared the options down to just the chord progressions of the keys that I like to play in:

I	ii	iii	IV	V	vi
C Major	Dm	Em	F	G	Am
D Major	Em	F#m	G	A	Bm
E Major	F#m	G#m*	A	B	C#m*
G Major	Am	Bm	C	D	Em
A Major	Bm	Em	D	E	F#m

( Asterisks denote casualties of scarcity. :( )

That sums to 16 chords via 16 buttons: C, D, E, F, F#, G, A, B; with rows for major and minor versions.

Aside #2: Technicality

Musicians will object that each chord is not necessarily in root position -- the chord triad notes of root, third, and fifth will be arranged arbitrarily, depending on oscillator availability. For example, its C Major's notes go E (third), G (fifth), and then C (root).

Because satisfying the desire for each chord to always have its root be the lowest note would increase the oscillators required from 12 to 20, I found it was an easily allowable quirk of the instrument to not have "nice" chords and to instead enforce its own inversions.

Board 3: Router

This was a crazy thing to make and looks like spaghetti, but all it really does is connect power from the buttons to the oscillators.

The ribbon cable at the top is from the buttons board. Each of its pins represents one chord and will carry voltage if the user presses its respective button.
That pin's voltage is split across three diodes to prevent bleed and fed into a horizontal 3-pin female header.
From there, color-coded jumper wires connect one-way power...
- Black wire = root
- Green wire = third
- Red wire = fifth
...to a vertical 6-pin female header, which serves as a collecting power bus for each oscillator.
And the ribbon cable at the bottom takes that power to the oscillator board.

I/O

(from top to bottom)

16: power from button board
(internal) 3 * 16: button -> chord
(internal) 6 * 8: chord -> oscillators
12: power to oscillator board

Board 4: Chassis

Okay, so this one isn't exactly observing the single responsibility principle, but I found it helpful to lump them all together: anything that the other boards aren't doing, this one should do. This meant that this board was the arbiter for power, ground, and anything directly attached to the chassis.

On the left, a simple LM386 amplifier makes things loud for the speaker (not pictured) or the mono 1/4" jack. When a cable's plugged into the jack, it conveniently switches off the built-in speaker.

On the right, 9 volts are supplied with the built-in battery or with a "wall wart" -- 9v is the voltage of most guitar pedals so adapters are super common.

Fastened to the lid, a 10k potentiometer with switch does double duty of setting volume and toggling power and two LEDs indicate statuses for "On" and "Playing" (from the buttons board).

I/O

(clockwise from top left; direct = connected directly to board without headers)

(direct) 2: audio output and ground to jack/speaker
(direct) 2: power (via switch on volume potentiometer) and ground
(direct) 3: "on" LED power, "playing" LED power, and ground
3: power to, ground to, and "playing" status from buttons board
2: ground to and summed output from oscillator board

Final product

Chord Synth

Footnotes

0:
C# was an accident. It was just the lowest note I could get with the components I had on hand.

1:
Admittedly, because I'm amplifying the summed output later, I could have had each chip serve as two oscillators. In practice, I didn't like the layout and having one chip per oscillator was a simpler mental model for me to wire up.

Early Experiments With 3D Printed Light Pipes

Sun, 04 Jun 2017 17:00:00 PDT

One of the problems with my F0 synth was its power indicator LED. It was so bright, you basically couldn’t look at it straight on without being blinded!

(Ow, my eyes!)

There are a couple solutions to an overly bright LED, the obvious being to limit its supplied voltage, but another idea is to use a light pipe: a component that redirects light from one place to another.

Additionally and importantly, it can act as a sort of lampshade, diffusing a concentrated bright bulb over a larger surface area.

But what are the ideal dimensions for something like that?

Making the light pipe model

My light pipe test model is essentially a cube with a hole in the bottom, except:

The hole is an exact negative of the LED, including its domed top and base lip. The fidelity ensures maximum contact between the light source and the diffusion medium
I left out any tolerance or “wiggle room” that you’d normally add/remove to address natural inaccuracies from the filament extrusion process. It’s an intentionally snug fit.
An inner chamfer on the LED cutout slopes out at the bottom to make initial component insertion easier and forgives something called “elephant foot,” where the bottom layers of a 3D print flare outwards due to the weight of the print on the printer’s heated bed.

The LED I’m using is a clear 5mm RGB LED, always positioned at the bottom of the cube, regardless of the cube’s height.

Spanning the gamut

The LED measured 5mm wide by 8.7mm tall and each test model is a perfect cube with equal height/width/length, so it’s important to note that the top and side of each cube don’t have the same distance from the LED.

Cube width/length/height	Ceiling depth from LED	Side wall depth from LED
9.7	1	4.7
11.7	3	6.7
13.7	5	8.7
15.7	7	10.7
17.7	9	12.7
19.7	11	14.7
21.7	13	16.7

For easier testing, I let each cube touch its neighbor(s). This probably has some effect on light dispersion, but it’s got to be nominal.

Print settings

Most 3D prints aren’t completely solid but instead have a kind of honeycomb internal pattern, called an infill, to increase print time and minimize waste.

However, initial fit tests at the default 20% infill cast visible (albeit interesting!) inner shadows on the print’s walls. Solidifying infill to 100% removed those shadows and made distribution more even.

Here’s 20% infill on the left and 100% on the right:

The filament I’m using is 3D Solutech’s Natural Clear PLA, chosen for Amazon Prime availability and it being made in the US.

Final result

Hard to resist making a little sequencer with a 555 timer and 4017 decade counter:

All together now:

And final detail shots, adjusted for brightness:

Observations

None of the cubes had perfectly even lighting. The third (13.7mm) through fifth (17.7) presented the fairest compromises.

Other circumstance-specific observations and takeaways:

Topside LED diffusion starts to get even at a top depth around 7mm but develops a kind of radial gradient around 11mm.
- An even top needs a 7-11mm ceiling. Ceilings deeper than that result in reduced and increasingly unevenly distributed light
The LED doesn’t push much sideways light from its base, as evidenced by the dark blotches at the bottom of each cube across the series
- The LED could be brought out a couple millimeters if this part of the pipe must be well lit
There isn’t much diagonal light either, as evidenced in the darkened top side corners from the third cube (13.7mm) model and onward
Those darkened top side corners start to creep down on the 17.7 cube and onward
- If the light pipe is anything but a cylinder, its width/length shouldn’t extend farther than 17.7, especially if it needs to be tall

Further reading abounds, as do other variables I could tweak in future tests:

Filament / printer
LED selection
Fit / tolerance
Infill vs wall thicknesses
Finishing, sanding, or other finishing processes

But, for now, I feel like I know enough to be dangerous.

(Dangerous with light pipes!)

Uploading to OctoPrint by Command Line

Tue, 20 Jun 2017 17:00:00 PDT

OctoPrint is a web interface for 3D printers, letting you manage prints and monitor progress without a constant USB connection between the printer and your computer. It is a lovely piece of software and I happily support it on Patreon.

But, for reasons I don’t entirely understand and despite conversation to the contrary, uploading large files (1mb+) through the normal drag-and-drop interface routinely fails, crashing the Raspberry Pi it runs on and requiring a hard unplug-and-replug reboot.

One workaround is to manually upload the file with scp:

scp ~/path/to/your/file.gcode pi@octopi.local:~/.octoprint/uploads

Because I have to do that so often and can’t memorize the incantation, I wrote a wrapper bash script to help. It additionally limits the bandwidth speed to avoid stalling, compresses to speed things up, and temporarily stops the OctoPrint server to free up the Pi’s memory.

Usage

Those configuration variables should be fine defaults for default setups; adjust to suit your needs. Then run like so:

sh upload_to_octoprint.sh ~/path/to/your/file.gcode

Known issues

OctoPrint sanitizes filenames when uploading via GUI but doesn’t for manual uploads. As such, files with spaces in their names won’t show up. A more resilient script would do its own sanitation or, better yet, loudly fail
If any SSH connection fails, it should immediately quit instead of blindly continuing

Still, pretty handy.

Designing Potentiometer Knobs

Tue, 25 Jul 2017 17:00:00 PDT

Who needs to buy new potentiometer knobs when you can make your own? Armed with patience, calipers, and a 3D printer, this is quite doable. (Note: this advice will also apply to rotary switches and encoders!)

Different knobs for different potentiometer shafts

A well-fit knob matches a potentiometer (affectionately referred to as “pot”) and its shaft. Thankfully, there are only a handful of types:

	Splined / Knurled This type of pot has vertical grooves lining the outside of its shaft. These ensure a solid grip with whatever’s mounted to it.
	Plain / Solid No features on this type, just a clean cylinder.
	Flatted / “D Shaft” These are like the plain shafts but have a cutout. When viewed from the top, they make a “D” shape.

Why would anybody even want to "reinvent the wheel" when commercial potentiometer knobs are plentiful and readily available?

Control uniformity
A project may use different types of pots side-by-side, each with different dimensions or shaft types, and fitting store-bought knobs may not match. By making knobs that internally match different specifications but have identical outward appearances, you can abstract away the underlying technical differences and have a consistent interface for the user.
Custom position markings
I recently made an instrument with D shaft pots, all mounted at odd angles to the enclosure, and I wanted their “0” positions to point in a way that my store-bought knobs wouldn’t allow. By making my own, I was able to have a custom rotation degree that wouldn't otherwise be possible.

And, of course, there’s always “it’s fun to understand how things work by making them”, which is usually the only excuse that I need.

Basic design

The simplest theoretical potentiometer knob is 1) a body with 2) a cavity for the shaft and 3) some way to mark position.

All the following examples fit that basic archetype but improve upon it to suit their respective shaft types.

Splined

The splines on these shafts need something to hold onto. Supply that with “shims”, thin strips of sacrificial material that wedge between the splines to hold the knob in place.

With enough shims, you can effectively make a negative model of the pot shaft and its splines, but an odd handful is more than sufficient and resilient to different spline counts.

One caveat about this approach is that the shims will wear out as its moved to different pots or reapplied to new rotation degrees.

Plain

Without something to hold onto, the shims from above won’t work as well here.

Instead, loosen the inner fit but tighten externally with a machine screw and threaded insert. The inserts I used were made specifically for thermoplastic, and assembly is as simple as pushing the insert into its cavity with the clean tip of a hot soldering iron.

Unlike a typical wood screw, the machine screw has a flat end to butt against the shaft, and the insert will hold the screw without stripping the plastic, even after repeated positioning and tightening.

For a flush look, if the wall is deep enough, match the insert cutout’s depth to its height and widen the remainder of the cavity to fit and hide the screw’s head. The screw will otherwise stick out, which may be a look that you like anyway.

Shims aren’t a bad idea here but aren't absolutely necessary. The tension screw is doing most of the work.

Flatted

This one’s easy enough. You’re essentially making the negative of the "D" shaft.

The advantage of a flatted knob is that rotational force is applied directly to the shaft without fear of stripping plastic, screw, or shaft itself. Supplement tightness with shims or a tension screw.

Mounting concerns

You’ll notice two things if you try to print one of the above examples and push it onto a pot:

Even if the inner diameter perfectly matches the shaft, it will be almost impossibly tight when you first put it on. Counteract that with a 45° entrance slope called a chamfer. I used this same technique for LED light pipes.
Depending on how it’s mounted, there can about a ¼” of vertical space from the pot’s fastening washer and nut below the knob, making it look like it isn’t pushed on all the way. If the knob is wide enough, you can get rid of that vertical space by providing a recess cavity for the mounting hardware.

Marking position

With the fit snug and securely tightened, the only remaining requirement for a pot knob is to let the user know how “turned” the pot is. I do this with a simple bar in a contrasting color.

And there you have it, custom potentiometer knobs!

You can download the OpenSCAD pot_knob() module I used for this post’s examples here. Please let me know if you find it useful or have any questions or suggestions.

Updates

Update November 21, 2022

Fixed missing standard_pot_flat_cutout module in the knob.scad OpenSCAD code. Thanks for the headsup, Ross!

Quick Tip: Changing Colors on 3D Prints

Thu, 24 Aug 2017 17:00:00 PDT

Changing filament in the middle of a print is an easy way to get multi-color effects without a multi-extruder 3D printer.

One way to do it is to sit by your machine and, when the moment is right, pause and change the spool.

Another way is programmatic. The process varies across printers and slicing software, but for my Prusa, I use their ColorPrint web app. With Slic3r's layers panel open as a reference, I just put the millimeter height into ColorPrint and it injects a "filament change" command into the G-code at that specific layer.

My first experiments with the technique mirrored the model's appearance; I put a filament change as soon as the next layer was supposed to be a new color. Seems logical!

Using some slider knobs as an example, that meant going from 13mm (white) to 13.2mm (black).

The printer complies but with an unfortunate side effect: after the filament is changed, the nozzle returns to its last extruding position and then moves wherever the new layer actually starts, leaving a trail of of accidental, oozed filament in its wake. This sticks to the previous layer and needs to be scraped or finished off, marring the surface.

The solution is to change the filament one layer after where you would otherwise want it.

The one layer of difference (.2mm, in my case) isn't aesthetically noticeable and is just enough vertical room to prevent plastic bonding from the odd positioning behavior. Any stringing is easily cut or melted away.

Admittedly, this is a workaround on what has got to be a bug in ColorPrint, but it's easy and works pretty well for me.

Happy filament-changing!

Quick Tip: Avoid 3D-Printed Supports with Sacrificial Bridge

Tue, 05 Sep 2017 17:00:00 PDT

A lot of my designs have bridges with holes in them, like this post with a locking cavity for a hex nut:

If printed without supports, the material at the top of the cavity has nothing to sit on and falls inward if it does anything but go straight across. Not the end of the world, but really not ideal, especially for a part that needs to be perfectly calibrated.

And printing with supports can be counter-intuitively even messier, because the supports are hard to remove at such small dimensions and tight spaces.

A cheap way to get the best of both worlds is to make your own support: a sacrificial, solid bridge over the cavity to ground the otherwise floating layers above. Here it is highlighted in red:

After printing, drill out the excess plastic or carefully melt it back with a hot soldering iron.

This process of designing for easier manufacturing is called, you guessed it, Design For Manufacturability or DFM for short. It can be a pretty dry subject for DIYers but there are some good articles in the right places.

Easy!

OKAY Synth

Wed, 27 Sep 2017 17:00:00 PDT

Hey! Check this out

Oskitone OKAY from oskitone on Vimeo.

It's a monophonic, analog, square-wave synthesizer, and I'm calling it... OKAY!

Monophonic:
Only one note at a time can be played. This is opposed to “polyphonic,” where multiple simultaneous notes can be played.
Analog:
There are no computers, microcontrollers, sound samplers, or anything digital involved. The sound you hear is the sound of a speaker being abused by discrete electronic components like capacitors and resistors and logic chips.
Square-wave:
When its output is viewed on an oscilloscope, its wave resembles a square. It’s a “hard” sounding wave type, great for bass lines, and commonly associated with chiptune music and old video games.

With a name like "OKAY" you might guess that functionality is intentionally limited. There’s just one octave of keys, a volume/power control, and an octave rotary switch to select from six different octaves. But what the OKAY lacks in features, it makes up for in accessibility; it uses standard, off-the-shelf electrical components and can be put together in about an afternoon.

How it's made

3D Printed

Unlike the F0 which had a store-bought box, the OKAY is entirely 3D-printed beyond its electronics. The enclosure, keys, speaker grill, and everything else were all designed in OpenSCAD and lovingly printed on a Prusa i3 MK2.

The 3D models are available on Thingiverse and MyMiniFactory.

Electronics

Under the hood, it’s powered by an LM555 timer (astable mutlivabratory), CD4040 ripple-carry binary counter/divider (frequency divider), and an LM386 power amplifier. All are the standard circuits you'll see diagramed in their datasheets.

The 555 timer chip is the heart of the OKAY and was chosen for its ubiquity. It’s well documented, well loved, and has been around forever. It’s so omnipresent that it’s hard to talk about any kind of timer circuit without somebody saying “Just use a 555!”

Modular PCBs

The OKAY employs a modular approach to its PCBs. Instead of one monolithic board, the instrument’s tasks are split into four smaller boards, each with their own responsibility. (I’ve used this approach in my other instruments too: F0, Chord Synth, POLY1.)

Power bus (bus 0.1.1)
Switches and distributes power from the 9v battery to the other boards and LED
Timer and divider (555_4040 0.1.1)
Oscillator and frequency divider, provides 12 octave output
Keybed (SPST_VR 0.2.2 15)
Trimming potentiometers and pushbuttons set the 555's frequency
Amp (386 0.1.1)
Standard headphone amplifier circuit

What that modularity loses us in assembly speed it gains us in clarity, extension, reuse, and hacking.

It’s obvious what each chip is doing, with clear input and output across the boards.
Adding another octave of keys, amplifier + speaker, octave changer, or some other effect will just be adding a new PCB into the pipeline and altering the 3D model to fit. That kind of customization would be impossible if everything were on one PCB.
All of the boards can be repurposed for other roles like standalone amps, metronomes, and other noise machines
All boards also expose the full functionality of their circuit instead of just what’s required for the OKAY. The amp, for example, has pads to make it distort; the oscillator outputs 12 octaves even though you’ll only use 6. If you're making your own OKAY, you can hack it to do whatever you want.

Development

The OKAY isn't just its electronics. I put a lot of thought into its design:

Made to be opened
Why pour your heart into something just to hide it away? The enclosure has beefy hinges and buckle clasps that are designed to stand heavy use. Once it's opened, the electronics are displayed with pride.
Gratuitous color-changes
I don’t have a 3D printer that can print in multiple colors, but I was able to get multiple colors on the keys, OKAY text, speaker, knobs, and control labels by carefully changing the filament at defined places.
Dovetail joints, but maybe not where you’d expect
I tried various key mounting strategies, like fixing them directly above the keybed PCB or screwing into threaded inserts, but I ended up mounting them to the enclosure's top with a dovetail joint. A similar dovetailed tab holds the OKAY text in place. This minimizes gluing and speeds assembly.
Screwed-in PCBs
Early versions of the OKAY tried to glue or snap the PCBs into place, but they’d quickly come undone when I wanted to run wires under them. My solution was to hollow a nut locking cavity into each of the PCB posts and screw the PCBs into place.
Key cantilever redesign
The keys are basically the same as the ones I used for the F0, but I rewrote their cantilevers (the springy part between where it’s fixed to the enclosure and where you press down) to make them feel more stable and have a consistent resistance
Peg key plungers
The keybed PCB's trim potentiometers are taller than its pushbuttons, so the keys can't lay directly on top like they could with the F0. Instead, "plungers" (the black cylinders you see in the photos above) descend from the keys and make up for the height difference. They're held in place by snap-in pegs .
Custom knobs
Even though the two control knobs look the same, they’re individually fitted to their components; one fits a knurled shaft rotary switch and the other uses a tension screw on a shorter shaft potentiometer. Both mimic guitar knobs and hide their component's mounting hardware with a recessed cavity on the bottom
Speaker mounting grill
To keep the enclosure as small as possible, the speaker is actually mounted to the outside and held in place by its grill. Under the enclosure’s top, the nuts are locked in place by hex cavities, which reduced the required length of the screw and allowed me to use the same size throughout the whole kit.
Battery holder
Early iterations taped the battery in place, but, by substituting for a shallower speaker, I was able to make room for a dedicated snap-in holder for the 9v battery.

Get it now!

You can purchase the OKAY right now at oskitone.com. It comes in three flavors:

Fully assembled
Ready to go! Lovingly put together and tuned by yours truly.
DIY Kit, Complete Edition
With all electronics components, enclosure, keys, and manual included.
DIY Kit, BYOP Edition
Only the electronics components.

What’s next?

I hope folks like the OKAY, because there's plenty more planned:

More keys please
Oh, this will happen! The SPST_VR PCB has mirrored output headers for daisy-chaining, and it can be trimmed to make arbitrary key counts.
Polyphony
I'm no stranger to making polyphonic instruments and the OKAY won't be immune. I've made some progress on a 6*556 12 oscillator PCB, but the board itself is big enough to require a completely different enclosure design. Expect the polyphonic to be the OKAY's older sibling!
Different colors?
The new ones are in yellow, and I've got a couple older models in blue and black. Contact me if you want to buy one in a different color. Of course, if you print it yourself, you can make it any color you like.
Different wave types
This is easier said than done without greatly increasing the complexity and number of circuits, but I do have something planned. Stay tuned.
Effects
Remember how the PCBs are modular? That will make it easy (well, not prohibitively difficult) to add effects like high-pass or low-pass filters, portamento pitch gliding, octave doubling, etc, without completely remaking the entire instrument
Different text
I don't have a way to automate this yet, but, just like the having a different color, it's of course very possible. If you're interested in getting an OKAY with different text (most 3-5 character words work just fine), contact me and we'll work it out.

Follow along via Instagram, Twitter, or email to learn when the OKAY updates. As a token of gratitude, please enjoy a video of two early model OKAYs having a duet:

OKAY Duet from oskitone on Vimeo

Making Time-lapse Videos with an iPhone by Command Line

Mon, 01 Jan 2018 16:00:00 PST

Here’s how I make the time-lapse videos for my Oskitone projects. It’s certainly not for everybody, but if your phone is the best camera you own and you’re not shy of the command line, maybe it could work for you!

Code: https://github.com/rocktronica/timelapse

How it works

IPCamera app turns iPhone into a webcam, accessible on local network.
capture.sh script repeatedly downloads its image. (It’s basically three lines of shell but with some nice help info.) You stop this process when you’re done capturing.
A followup compile.sh script uses ffmpeg to convert those images into an MP4 video for Twitter and Instagram and gifsicle for various GIF sizes.

Notes on cameras

Phone cameras

The IPCamera app starts a little server on the phone, providing a live video feed and basic camera controls with a web GUI as long as the app stays open. Inspecting its GUI from a computer’s browser, you’ll find its live video endpoint is “/live”. I emailed the author of the app and learned there’s a hidden “/photo” endpoint which returns a static JPG instead of a video stream.

While I haven’t tried other apps or other phones, they ought to be similar. As long as it can provide a JPG URL, it will work.

Other options

Camcamcam: this is a wrapper I wrote around iSight and Raspberry Pi camera to take GIFs of my cat eating her food when I'm away
Live public feeds: I'll let you find these!

Other thoughts

Rigging
I use a gooseneck clamping phone holder, which I bolted onto a woodworking clamp when the original cheap one broke. It's scrappy but works great.
Lighting, lighting, lighting
My desk faces a large window, which makes this an easy step in non-winter months.
Use the right framing
For clearer, instructional type shots, try a high eye-level angle. For moodier shots, go tight and/or to an angle.
Editorialize
Unless you want the output to be accurate to time, remove unnecessary shots of blurry movement or when you’ve stepped away from the work. No one will be the wiser.
Removing photos
If the delay wasn’t long enough and you want to, say, only use every other photo, you can remove them before running compile.sh. In the capture folder, try ls | awk 'NR%2==0' | xargs echo rm | sh, where 2 is n.

Examples

Let's make a synth together. OKAY DIY Kits are coming soon! pic.twitter.com/GsQWnPtfb2
— Oskitone (@oskitone) September 24, 2017

Sequencer PCB assembly timelapse from oskitone on Vimeo.

Trying out some time-lapse PCB soldering pic.twitter.com/IPlRFFsaEI
— Tommy (@rocktronica) April 11, 2017

SPST_VR 0.2.2 Assembly from oskitone on Vimeo.

Making an instructional soldering timelapse gif and found this dumb meta timelapse gif I apparently made and kept pic.twitter.com/oGFjz4fIYf
— Tommy (@rocktronica) December 21, 2017

Code

Everything is on Github and MIT licensed. Enjoy!

https://github.com/rocktronica/timelapse

OKAY 2 Synth

Thu, 18 Jan 2018 16:00:00 PST

The long awaited Oskitone OKAY 2 Synth is finally done and ready to share! It looks like this:

And it sounds like this:

Oskitone OKAY 2 from oskitone on Vimeo

Just like the first OKAY Synth, the OKAY 2 is an analog, monophonic, square wave synthesizer. It uses the very same modular PCBs, octave and volume controls, and speaker as the OKAY 1, and all of it was designed by me in OpenSCAD and EAGLE as usual.

The biggest noticeable difference is that it now has two octaves of keys instead of just one!

New features

Of course, there are less noticeable but still important changes:

Completely redesigned key mounting

The OKAY 1's keys are mounted to the enclosure top, and its buttons are separately mounted to the enclosure bottom.

More keys, however, means a wider keybed, which naturally starts to lose structural integrity as it grows -- plastic alone can only be so rigid. In the center of the instrument, the enclosure top and anything mounted to it want to bow up and away from the enclosure bottom and anything mounted to it. Because piano keys effectively act as levers, that bowing unfixed the lever's fulcrum (the fixed point at the back of the keys) and made playing unreliable.

So how could I design it in such a way as to be both mechanically reliable and aesthetically/functionally accessible?

The answer is to mount the keys and buttons together onto a separate "cradle" piece that nestles into the enclosure bottom. (Here's an instagram video of the proof of concept.)

With the removable key cradle, the tuning trimpots can be soldered to the bottom side of the PCB, which would otherwise be unreachable, obviating the OKAY 1's actuator pegs.
Key travel distance improvements

The OKAY 2's keys now have a front lip that gets held down when the enclosure is latched closed; this ensures they're as close the buttons as possible, minimizing vertical travel distance on key press. The key's back clearance has also been minimized so the keys are held down there too, especially the unlipped accidentals.
Audio out jack

I teased a prototype Oskitone amp on Instagram, but it's an awkward product to have when the flagship OKAY 1 can't hook up to it. The OKAY 2 has a dedicated 1/4" audio out jack, which will automatically mute the built-in speaker when something's plugged into it.

After tuning a couple OKAY 2s, my ears were happier with this upgrade!
Built-in display stands

I wanted an easy way to display this thing on a shelf or on my desk. I considered making a separate stand and even spent a day designing an integrated "kickstand" hinge, but instead I went even simpler: prop up the OKAY 2 by sticking a writing utensil into one of three angled holes on the enclosure bottom.

This idea, as well as the "OSKITONE" brand engraving, were borrowed from the prototype amp linked above.

And un-features

Prototype builds: draft print with longer/broken(!) keys and two speakers, the same design assembled and not totally broken, and the aaalllmost final design

Dieter Rams said "Less, but better." It wasn't always an easy decision, but here's what the OKAY 2 doesn't have:

Power jack

I built a prototype unit with a 9v input power jack, the same ones I had for the prototype amp and that guitarists use with guitar pedals. It was nice to have but not imperative and increased cost, so I removed it.
Stereo

I also played with the idea of having two amplifiers or two separate octaves with individual amps and speakers. It was interesting and didn't require any new PCBs, but I still scrapped it for simplicity's sake. I even scrapped having two speakers wired together.
Longer keys, different action, or other playability changes

Remember how I said piano keys act as levers? I learned about something called mechanical advantage, which is a measure of how easy a lever's load is to move relative to the effort required to move it. Musicians might call this "action" or even "playability".

On one early design, I calculated and animated the keys' mechanical advantage as their underlying buttons moved on the Y axis.

Pretty interesting! ... but I abandoned it when I switched to the cradle key mounting design, deciding to to fix one real problem rather than optimize a non-problem. The OKAY 2 has the same size keys and playability of the OKAY 1 -- just more of them.

Making the OKAY 2

After writing about how I make time-lapse videos, I made a time-lapse video of soldering and assembling a hot pink OKAY 2. It's cool; check it out!

Making an OKAY 2 Synth from oskitone on Vimeo

Availability

Now available at Oskitone.com, fully assembled or as a DIY soldering kit, available with and without the 3D printed parts.

The STL model files are on Thingiverse.

Oskitone IRL!!

On the day I put the OKAY 2 on the store, I gave my first ever real life elevator pitch at a meetup called the Hardware Developers Didactic Galactic!. I wore my most confident shirt and was really nervous but I think people liked it. There's no video of my 2min talk but I did get a nice video on Twitter from just after the main talks.

this is OKAY 2 available on @tindie #HDDG https://t.co/8We1GVoToQ
— Supplyframe Hardware (@SupplyframeHW) January 12, 2018

Thanks for reading

I put a lot of time into the OKAY 2, I'm proud of it, and I like it a lot.

I hope you like it too.

Build-A-Build-A-Synth

Mon, 05 Feb 2018 16:00:00 PST

Here’s a web app I’ve been fiddling with recently to help visualize (and, ahem, sell!) custom synthesizer based on the OKAY Synth and the OKAY 2.

It’s built in React with Next.js, uses Bootstrap styling via Reactstrap, and renders its preview onto canvas with Konva. It’s also the first time I’ve used any of that stack, so I expect to be thoroughly embarrassed by my code if/when I revisit it in six months.

Try it out: build.oskitone.com

Tinker tinker

For now, the parameters are mostly fixed to those used for the real life OKAYs:

The vanity text is always in the Open Sans font, matching the OSKITONE wordmark
There’s only one speaker size, but I made “None” an option for anybody who only wants audio out jack
Functionality is assumed to match the OKAY and OKAY 2, so there are always two knobs for the Octave and Volume controls
Key dimensions are fixed to match preexisting builds
Enclosure dimensions similarly adapt to key, text, and component dimensions based on fixed gutter and spacing parameters

You can even do things that I can’t physically do, like use colors I don’t have or effect dimensions bigger than I can 3D-print. If you do either, you’ll get a warning when you try to purchase.

Speaking of which…

How to sell a thing that doesn’t exist?

There are two legit caveats worth talking about:

The first is that the preview isn’t as accurate as I’d like. It’s an abstraction of a theory of a thing, a twice removed and two-dimensional reimplementation of a three-dimensional model of an eventual physical good. (Woof, that’s a mouthful. See below.)

The second is that my store wasn’t made to do stuff like this. The platform I’m using, Big Cartel, is more for selling goods (ex: clothing) than services (ex: tailoring). I could get around that by having one product with all N permutations as options, but that’d be a rat’s nest to implement without a programmatic way to create them on the site. (Hacks abound, no doubt, but I’ll spare you the details.)

So the workaround for now is to pass the design off to the contact form on the main Oskitone site for the user to submit. I can then follow up over email with a real 3D render and price. It’s a kludge, for sure, but it should work well enough to test the idea.

Could be better

Obviously missing details on speaker grill, knob labels, and enclosure hinges
Text has looser kerning, is missing stroke, and isn’t maximized to its available space
Dimensions may or may not be exactly accurate

What’s next

Real 3D model previews (There will be a LOT that will go into this, worthy of a new blog post. Hopefully I can get to it. Stay tuned.)
More color options on different parts
New instrument designs?!?!

URL: http://build.oskitone.com/
Code: https://github.com/rocktronica/build-oskitone

Prototype Post-Mortem: Four-Step Octaved Sequencer

Mon, 19 Mar 2018 17:00:00 PDT

Four-Step Octaved Sequencer from oskitone on Vimeo

Background

The first version of this sequencer idea was a collaboration with an artist named Rasterstache. It displayed at Maker Faire and eventually made its way to the popular Chicago band OK Go:

pic.twitter.com/NmKWoNfnOg
— OK Go (@okgo) November 4, 2017

A look inside

Inside that robot figure is a really pretty, one-off, hand-wired circuit I made on perfboard.

(IIRC, blue wires are IO (in/out) between chips, red/black are power/ground, and all IO to/from the board connected with those black headers. I was apparently big into headers at the time; I think I'd do that differently if I did it now.)

Here's its description that I sent to the artist:

I'm calling it a "4-Step Octaved Sequencer", and it's some kind of musical instrument or noise art machine or even a crude analog synthesizer. There are similar instruments, but I haven't seen one exactly like it -- It is definitely an original, one-off piece of DIY engineering.

In music, a sequencer is a piece of equipment that repeats through a series of notes to make a melodic, looping riff. You're hearing sequencers all the time if you listen to electronic music. Anyway, this one has four steps.

It's "octaved" because its output is actually two square waves mixed together; the main frequency is divided to make an octave lower, and the two are added together for a thicker, richer sound.

An extra neat thing is that, like the rest of my work, this is a fully analog (ie, NOT digital) machine. There are no computers, microcontrollers, sound samplers, or any technology basically from after the 1970s involved. The sound you hear is the sound of a speaker being abused by electricity which has been manipulated by discrete electronic components like capacitors and resistors and logic chips. It is super old school (and unnecessarily complicated) stuff.

For the curious, the IC chips are:

a 4017 counter to count and iterate through each sequencer step

a 556, which has two 555 timers to 1) set the tempo for the 4017 and 2) make the main (high) pitch

a 4040 divider to make the aforementioned octave below the main pitch

and a 386 amplifier to take the summed octaves' output and drive the speaker

The two octaves I mentioned are easier to see on an oscilloscope. This was the breadboard proof-of-concept before soldering:

Four-Step Octaved Sequencer breadboard from oskitone on Vimeo

Besides the 4017 counter to count through the steps, the circuit is identical to the OKAY Synth's: potentiometer(s) set frequency on a 555 timer, which is divided by a 4040 to make octaves, and then sent to a 386 amp.

From perfboard to PCB

A couple months later, I designed a PCB version (my second PCB design ever) and had a handful fabricated. The only difference in the PCB from the original perfboard is that I increased its octave outputs from 2 to 4 and made them switchable.

Check out the "tommy.sh" branding in the corner. This was before I before I'd decided on "Oskitone" and bought the domain name.

And PCB to product idea

Then I designed it into a 3D model, the subject of my post on bringing realistic animations to OpenSCAD.

Fast forward to today, where the subject of this post is the 3D-printed and assembled version of that model, which sat unfinished for months while I worked on the OKAY Synths.

In review

Signs of things to come

When making the OKAYs, I'd make a bunch of fit tests and prototypes before getting to a "finished" build. What's interesting to me about this sequencer prototype is that, because I spent too long designing it without printing any fit tests and then abruptly stopped working on it, it's a fully formed snapshot of what I was thinking about (warts and all) at the time.

And there are some fun parts about it that I really do like, a lot of which would make its way into my other work.

Labels
The tempo, volume, and octave controls have corresponding cute, little, 3D-printed label pieces. I've always liked this approach more than embossing/engraving text into the enclosure itself or using some sticky label tape. It's a physical, tactile thing that just makes me feel good. If you're working and printing in 3D, then I say go all out.
Multi-color print
Here's where I perfected the technique of changing filament midway through a print to get those sharp color changes, which I now use gratuitously. It's an easy hack that any printer can do.
LED light pipes
Each step has an LED pressed into a 3D-printed semi-transparent cube called a light pipe. Its dimensions are based on my experiments in designing light pipes. I'm sure I'll find another project to use this idea on.
Custom potentiometer knobs
These are the first time I made custom potentiometer knobs to fit D or smooth shaft pots.
Slider potentiometers
The original robot collaboration had a slider for tempo, and I liked it so much I made the four step pitches use them instead of knobs. Sliding is funner than turning, I think. Of course, I put custom caps on them.
Pushbuttons
The OKAY synths use a rotary switch to select just one octave, but it's technically possible to select multiple and mix them together. The sequencer does this with latching pushbuttons. Press once to add the octave to the mix; press again to remove it. They're capped with ABCD letter caps.

Hard lessons learned hard

Connections, glue, parts count

I wanted the enclosure to be able to be either 3D-printed or laser cut from plastic or plywood, so I designed it to have discrete top, sides, and bottom. That necessitated all internal supports to also be separate pieces.

And all of these things had to be glued into place with heavy duty industrial strength glue. This was a literal headache.

Labels and speaker grill glue onto enclosure top's top
The enclosure top's bottom glues to the enclosure sides
The black slider base, speaker wall, octave switches platform, and knobs bases glue into the enclosure top
Light pipes glue into slider base
PCB glues into enclosure bottom
Octave button caps glue onto buttons

Lesson 1: When designing for easy assembly, the priority of connection types should go snaps, then screws, then glue. Glue is the worst and should be a last resort. There is no glue in the OKAY 2.

Lesson 2: If you must use glue, have the pieces self-locate for effortless, perfect positioning without an external jig.

Lesson 3: Design with one type of manufacturing in mind. The enclosure would have been so much simpler as two pieces instead of three, and all of the supports could have been baked into it as well. Keep parts count low!

Enclosure closure

So the enclosure's top glues to its sides, but how does the bottom attach? With screws. And not very well.

The sides, which are one solid piece of four walls, have pocket wells for threaded inserts, which get melted into the plastic with a hot soldering iron. These take screws through matching holes in the enclosure bottom corners. I unfortunately got a trace amounts of melted plastic in the inserts' threads during installation, making them hard to screw into.

I also thought I could make a better fit by nestling a tiny lip on the sides to a tiny grooved cavity on the bottom, but it was too small to print well and basically just resulted in a tiny gap.

The end result is an enclosure that's hard to open and can't even close properly anyway.

Lesson 1: Make sure threaded inserts stay clean of foreign material. A good way for the design to help this is to have both ends of the insert's containing walls be open. If there's plastic at the opposite end, the soldering iron will pierce it and draw it back up into the threads.

Lesson 2: Integral features like the fitting lip grooves shouldn't be at a scale so small they're within the tolerance limits of the manufacturing machine.

Lesson 3: Make fit tests before making the whole thing!

Lesson 4: Users shouldn't have to disassemble a device to do routine work like change its battery. Make it easy to open and admire.

Space and size

The dimensions of the instrument were derived from the dimensions of the components. Four pushbuttons set the width of the side control panel, which set the knobs's diameters and speaker size. To make it worse, I also didn’t factor in vertical room for cables, so the whole thing is jam packed and can hardly close.

It is a needlessly tight and finicky fit. Seemed like any time I touched it during final assembly a new thing would break.

Oh, also, the small knob diameter meant that the volume's tightening screw sticks out. I hadn't considered that before printing the whole thing.

Lesson: Make room! Make room!

"Musicality" (aka "musical utility")

Potentiometers have some natural variance in their resistance, just because of the way that they work. For most typical uses, like, say, a volume or pan control, that ~5% variance is an unnoticeable non-issue. It is, however, very noticeable when they're used for something that requires high precision like frequencies for musical notes and even more noticeable when used adjacently -- controls that seem to be in identical positions should have identical effects.

The sequencer's pitch oscillator uses resistance supplied by slider potentiometers to determine frequency. It's fun but imperfect, making the instrument more about noise than music.

Lesson: Musical instruments need to keep tune and be consistent.

Sound

Ugh, why is this little speaker so pitiful? Even if I boosted the amp, you can hardly hear any bass.

And at volumes higher than 50% the octaves don't mix evenly. The low octaves basically override the higher ones. My naive mixer of resistors was, indeed, naive.

Lesson 1: Bigger speakers are better speakers.

Lesson 2: Multiple sounds want multiple amplifiers.

What's next?

Someday I'll clean it all up and have some kind of sequencer project on the Oskitone store, but it won't be this one. This one will go on my shelf as a reminder of how far I've come.

~~In the meantime, I've got a couple of the "tommy.sh" branded PCBs left. Holler if you want one.~~

Update April 5, 2018

I put the remaining handful of prototype PCBs on the store, promptly sold all of them, and am ordering more.

If you want the STLs to 3D-print your own just like the prototype, that's not a great idea! As this blog post attempted to explain, the design has way too many problems for me to feel good about putting my name on it and telling other people to make it.

Stay tuned!

Update January 17, 2021

Open-sourced the PCB: https://github.com/oskitone/four-step-octaved-sequencer

Update March 12, 2026

...and made its OshPark project public so you can buy the PCB direct from them with my blessing: https://oshpark.com/shared_projects/xo5nRkSm

Adventures in Self-Watering Planters (Part 1)

Fri, 10 Apr 2020 17:00:00 PDT

Well folks, I never could have guessed it, but I (apparently!) have opinions about plant planters and made a variation of a self-watering planter that fits into household glass jars.

Keep reading to learn how I made it or to make your own!

Whyyyyy

I’m not much of a green thumb, but I like plants. They make me feel good. When the world is scary and unknown, growing a cute little plant in a cute little planter is a very welcome distraction.

I also like low-maintenance, which is why I’m interested in self-watering planters. Unlike typical planters that take water at the top and drain at the bottom, self-watering planters keep a reservoir of water at the bottom and draw it up into the soil automatically as the soil dries out.

Notice the string in the water. It defies gravity and pulls water up via capillary action. Later, as the plant grows, its roots will extend into the water and help out too.

(You might be asking, if the plant’s so thirsty, why not submerge the whole thing in water? Because that will cause the soil to grow mold and the roots to rot, harming the plant!)

Why I made my own

There are two problems in a lot of the designs I’ve seen:

The lower reservoir container is opaque and prevents easily seeing the water level, causing more regular checking and maintenance
The reservoir is too small, requiring more refilling

Glass jars as reservoirs remedy both issues. They’re clear so it’s easy to gauge water level, and they come in sizes big enough to hold a lot of agua.

Nailing the Design

Reverse-Engineering a Jar Lid

Fortunately or unfortunately, my house is filled with jars that fit lids like this, so that's what my design uses:

Getting a good fit on a jar meant making a lid, from scratch. Luckily, for a simple part like this, it’s relatively straightforward:

Measure
I broke out the digital calipers and measured everything that seemed crucial: inner diameter of lid, outer diameter of jar mouth, lid lug length/height (see more on the naming here in the appendix below)
Recreate minimum test
With those dimensions, I made a simple ring with six small lugs evenly distributed inside. I didn’t need to make the whole design yet, because I’m only testing the fit. Pro tip: the smaller the test, the tighter the feedback loop, and the faster you can iterate.
Repeat
First it was too tight, then it was too loose, then the lugs would jam up, etc, so I just kept updating the design until I got it right. The trick here is patience. (Good variable names and a log of the iterations and their outcomes helped too!)

What else does it need?

After the lid was fit and snug, I added other features, all of which are accessible as variables:

Adjustable height pot
The pot’s height is variable and can tower over the jar and/or plunge into it
Drainage holes at bottom of pot
Holes at the bottom of the pot let water drain out and hold the capillary string in place.
Skirts at bottom
These are purely aesthetic walls that extend over the exposed jar threads for a flush, tidy look.

Design for Manufacturing

In a nutshell, Design For Manufacturing (or DFM) means making a product easy to be made. For 3D-printing, that mostly means eliminating supports: the non-model scaffolding that gets torn away after a print is done.

Here's how it gets 3D-printed:

It’s upside down! Printing it rightside up would need supports all around the lid and skirt
The lid lugs are just wide enough for its ends to rest on the rim
The drainage holes use a sacrificial bridge
The diameter differences between the outer tower and inner pot are transitioned with a 45 degree funnel

Next steps

Other stuff and followup ideas to think about:

The filament I used is made out of corn and is technically compostable, so it very probably isn’t the best choice for something around water? Something for me to keep an eye on!
Making it work with mason jars and their threads… or no threads at all and let it rest on top of any container!
What does it need to be a plant hanger? Simplest version is quick holes for hooks to latch into, but it’d need to be strong enough to not break under the weight...
Could multiple pots share one jar? Or vice versa?
The taller the tower, the higher the center of balance. And the tower could be made to be much wider than the jar. Both require thinking about legs or other supports to make sure the thing doesn’t tip over.
Terrariums?!

Make Your Own!

3D models are available on Thingiverse: https://www.thingiverse.com/thing:4276363.
OpenSCAD code: https://gist.github.com/rocktronica/9ee5183306b35a14765a4ea627cf7887

Appendix: Types of lids

I’ve learned that there are two styles of jar closures: “continuous thread” (abbreviated as “CT”) and “lug”. The easiest way to differentiate them is by their lids: CT lids have threads that directly match the threads on the mouth of the jar, and lug lids simply have a number of lugs or little ridges extending inwards from the bottom of the lid.

Unlike the lids, the respective jars themselves from these two types may be indistinguishable.

Anyway, it turns out that the technical name for the lid I made is “82 lug lid” and it is very common for the brands of jelly and salsa that we apparently go through a lot of in my house. :)

Unfocus

Thu, 23 Apr 2020 17:00:00 PDT

I wrote a script called Unfocus to prevent me from wasting too much time reading the news and Twitter. I wish that weren't necessary, but wataryagonnado, huh?

Example:

~/.unfocus.sh 15

Which lets me bum around for 15 minutes. After that, I'm greeted by:

Nice! 😅

How's it work

A popular trick to prevent visiting a website is to convince your computer that its domain resolves to localhost. This can be done by manually editing the /etc/hosts file:

127.0.0.1    site-you-do-not-want-to-visit.com

The problem is that, if you ever want a little taste of what you're missing, you have to manually edit again to unblock and remember to edit again when you're ready to re-block...

Anyway, this tool tries to do that for you.

Give it a go

For now, the default blocked sites are: twitter, netflix, google news, and HN; but it's configurable.

Code: https://github.com/rocktronica/unfocus

Quick Tip: Hone In On the Perfect Fit with a "Goldilocks Array"

Mon, 11 May 2020 17:00:00 PDT

Designing 3D-printed parts that need to perfectly match the dimensions of something else can be arduous, because it'll often mean meticulously designing-then-printing-then-trying each individual iteration, ad infinitum.

A trick I like (and I'm sure this is old news to many folks) is to combine an array of those tests into one big combo test. Then, just like Goldilocks, all you have to do is move your part around the array until you find the best fit.

The time gained in skipping the back-and-forth from your printer more than makes up for the extra time it spends being printed.

Example

In the picture above, I'm designing a horn to for a servo shaft, and my "goldilocks array" has two axes: cavity diameter on the horizontal X axis and shim count (borrowed from my adventures in making potentiometer knobs) on the vertical Y axis.

Model

OpenSCAD Code

The concept is agnostic to implementation but I think is eloquent in code.

buttonpusher: a Machine that Pushes Buttons

Thu, 11 Jun 2020 17:00:00 PDT

I made a machine to automate some of the boring parts of Animal Crossing, and it is very satisfying to me.

Like my other projects, "buttonpusher" was designed in OpenSCAD and 3D-printed. The code controlling it is CircuitPython, running on an Adafruit Metro M0 Express.

Code, circuit, and 3D models to make your own: https://github.com/rocktronica/buttonpusher

How it works, briefly

The Nintendo Switch's Joy-Con slides into a matching rail.
A servo rotates a hammer arm that swings over to press the "A" button.
Menu and progress are displayed on a 16x2 character LCD.
A rotary encoder allows for sequence and count menu selection.
A small tactile switch lets the user halt any running sequence or navigate back in the menu.

The sequences on it are hardcoded for Animal Crossing, but it could be easily extended for other games or usages, as long as the only button required to push is "A" and the timings are fixed.

Lessons abound

Yes, this is "Yet Another Unnecessary Thing," but it was a good excuse to get familiar with some unfamiliar tech like rotary encoders and LCD character displays. Per usual, I got some nice takeaways too.

Lesson 1: Don't lose force

The first version was made out of foamcore board, masking tape, and craft wood. It didn't have a menu or display and needed to have its code updated to switch the sequence or count. Still, it worked pretty well!

It used a wooden lever to push the button, and I think that made me think the servo was underpowered and not strong enough to push the button all the way down.

But I was wrong! The servo was indeed strong enough -- it was just losing torque through various design flaws that were fixed in the eventual 3D-printed version:

The Joy-Con controller mount is extra tight fit so there's no room to wiggle
A stool under the Joy-Con provides an opposing force when the hammer fully descends
And walls on opposite side of the servo prevent it from rocking back and away from the Joy-Con
The hammer arm first connects to a stock servo horn before its axle -- this avoids fine wear-and-tear and eventual slipping from the 3D-printed plastic

We basically want to keep the connections between the servo, its horn/arm, and the Joy-Con as fixed and rigid as possible. Any looseness is a loss of force that would otherwise be used to push the button.

Lesson 2: Use what ya got

Speaking of that hammer arm...

I'd intended for the arm to attach directly to the servo axle (and even spent a good amount of time dialing in the exact fit for its cavity) but it ultimately didn't work because the "teeth" on my 3D-printed part quickly wore out and lost their grip on the axle.

Instead, I modeled one of the injection-molded propeller horns that came with the servo and used it as the cavity for the arm. With cheap plastic, bigger is better.

Alternative 1: Screw the arm horn tight into the servo, but I was worried about stripping it out while iterating on the design
Alternative 2: Upgrade the plastic, which I just wasn't jazzed about

Lesson 3: Save your memory

With all that CircuitPython code, I found myself quickly running out of memory on the Metro M0 Express and needed to compile all the .py Python files into .mpy MicroPython bytecode files that consume less memory when deployed.

To make that easier, I wrote circuitpython_tools, a work-in-progress shell script that watches for local changes then automatically compiles and deploys to the board, saving me LOTS of time.

(The novelty of automating things while making a thing that automates things was not lost on me!)

Lesson 4: Consider footprint when choosing a microcontroller board

When I added menu controls and the LCD display, I had to upgrade the board to something with more IO pins.

And the only board I had around and fit the bill was a Metro M0 Express. It has a pin layout like the Arduino Uno: two rows of pin headers and (I learned the hard way) irregularly spaced pins on one side that don't match standard .1" perfboard spacing.

The electronic components connect to that board by a one-off PCB (a "shield" in Arduino parlance) that I hand-soldered. Because I 1) wanted to solder to both sides of the shield, 2) didn't have a double-sided perfboard big enough, and 3) had to work around the Arduino's unfortunate pin spacing, my shield uses right-angle headers and ribbon cable to connect to the character LCD. It's then supported by crude 3D-printed standoffs where the headers should have been.

Here's the shield stacked on top, without the character LCD:

For future projects like this, I'll save some headaches and go for a smaller board with a standard pin spacing. Good lesson.

Et cetera

Other stuff I'm proud of

The math to calculate percent completed and timing is, I think!, pretty cool. It tries to honor the prescribed sequence timing by automatically making up for variances in servo/LCD update times, while updating the display in realtime.
Design For Manufacturing, or ways the models avoid supports when printing:
- The cavity in the Joy-Con mount has super small columns distributed across its length. These easily break away when assembling.
- The hammer head has a flat side so it can print laying down without supports.
The servo clicks into a cavity of its negative and doesn't need screws. Not that I'm opposed to that, it just wasn't necessary...
The Python code is blackened.

Open questions

Are there uses for this outside of novelty hacking? Assistive technology?
How could it work with different controllers or game systems?
Can it push more buttons?
The servo could probably be replaced with a solenoid and lever. (Not a question, I guess.)
What would an enclosure look like? Could the arm retract into it somehow? How about a battery pack to work without the USB cable?
What if it had Joy-Con mounts on both sides? Or if it mounted in between the Switch's screen and controller?

Appendices

Appendix A: Visualizing progress

While procrastinating on writing this blog post, I hacked out some quick scripts to visualize the design's evolution from its git commits. You can see the Joy-Con mount getting fine-tuned, iterations on how the servo attaches and is supported, its horns and arms, its abandoned lever idea when I thought the servo was too weak, and tweaks on the final screw mounts.

Appendix B: Is this a hack?

While showing this project to friends, an interesting topic came up: Is this hacking?

I'd argue that it's not. There're no modifications to the original Nintendo hardware nor its software. The machine is physically doing a job no different from my thumb, and it's not even smart about it: the sequence timings are programmed beforehand, and it has no feedback loop to know if they're completed successfully.

But it's easy to imagine versions of this "machine that pushes buttons" idea that creep closer to something Nintendo would disapprove of, where, in each step, the human interaction is abstracted futher away from its consequences:

What if the button pushes weren't mechanical? The button's pins could be soldered to relays or maybe a 4066 chip, allowing its circuit to be closed electronically without any physical movement.
Another version skips soldering entirely and has the code directly interface with the console to emulate button presses.
The Switch's video output could be analyzed in realtime, and OCR could be used to read the dialog text. Instead of it being programmed beforehand with the sequence's timings, it could adapt automatically just like a human would.
Soon enough, the game has an API and a bot could be trained to play it.

(Beyond #1, I have no idea how to do any of that.)

If those ideas are laid out in a spectrum with buttonpusher at the front, it seems to me that the definition of hacking is an arbitrary line that we all draw somewhere. "This is okay and this is not."

Just some thoughts!

POLY555 Synth

Sun, 27 Dec 2020 16:00:00 PST

I made a new Oskitone synth: the POLY555!

It's an analog, 20 note polyphonic, square wave synthesizer based on the 555 timer chip. The enclosure and keys are 3D-printed, its models were programmed in OpenSCAD, and its PCB was designed in Kicad.

A little history

The monophonic (one note at a time) OKAY synths I made a couple years ago also used the 555 timer as their oscillator, as a sort of homage to the ubiquitous chip's long history within the electronics community. When I showed one to folks in the scene, "the best 555 synth ever" was an easy, understandable pitch.

But the first question I always got was "How can it play more than one note?". To that I'd pop the hood and explain that since it has only one 555 to make one oscillator to make one note, to have more notes and still use the 555 I'd need... more 555s!

And while there are more economical ways to get analog polyphony (at the least, the 556 immediately comes to mind), I kept with discrete 555s because I thought it'd be fun to take this train of thought to its logical, if inconvenient!, extreme.

(I consider the POLY555 to be a spiritual successor to the OKAYs, which I haven't abandoned yet but absolutely need to give some TLC...)

Features

	Exposed circuitry Obviously, right?! The 20 555 timer circuits are lovingly displayed in all their glory beneath a piece of plexiglass to protect them from dust. Each circuit also has an LED that lights up when it's supplied power. BTW, I chose 20 and picked their notes so they'd line up nicely in a grid!
	Thumbwheel volume control Just like an old Walkman, volume is controlled by a small wheel on the side. Instead of using a thumbwheel potentiometer, the wheel is 3D-printed and mounts to a pot identical to the timers’ tuners.
	Power switch on bottom The power switch is similarly hidden away in a recessed cavity on the bottom of the enclosure with engraved binary labels.
	Pencil stand Jam a writing utensil in there to prop it up like a picture frame. Admire it! It's cool!

How does it work

Schematic

From left to right:

A sliding power switch connects the 9v battery's power to an on/off indicator LED, a 7805 voltage regulator, and a 386 amplifier.
Regulated 5v is distributed across 20 tactile switch buttons, each of which is connected to a corresponding timer circuit, seen below.
Those timers' outputs bus to a standard linear trimmer pot tricked into having a logarithm sweep, before going to the 386 amp's input.
The 386 drives our speaker!

Timer circuit

All 20 555 circuits share the same circuit but have unique component IDs.

Again, from left to right:

An LED puts on a little light show
C1 is a bypass cap for stability
This 555 circuit is called an astable multivibrator (oscillator) and is modified to have a 50/50 duty cycle... in other words, a square wave!
The oscillator's frequency is determined by the C2 cap and the resistors R3 and RV1. RV1 is the 1k trimmer potentiometer for tuning.
The chip's output passes through a "mixing" 10k resistor before leaving. This prevents the 555s from "sinking" each other, which would sound more like modulation (like, a lower frequency superseding a higher one) than mixing together harmoniously.

3D-printed parts

Outside of the electronics and plexiglass, the rest of the POLY555 is 3D-printed.

Enclosure bottom
Mounting rail for the keys to rest on
Keys
Volume wheel
Enclosure top

Design for Manufacturing

Per usual with 3D-printed stuff, there are various tricks to get it to print nicely:

Floating screw holes don’t have supports or the sacrificial bridge technique I previously wrote about. Instead, the cavity is first laid out as short, increasingly tighter rectangles, and the final cylinder cavity sits on that. Cool trick: it's an OpenSCAD module.
Wherever possible, 45 degree angles are used to obviate supports: the key endstop, on/off switch exposure, volume wheel brace.
And where right angles won't work and supports can’t be avoided, they're baked into the models themselves so folks at home don’t have to have their slicer do it: plexiglass window pane supports, enclosure hitches
Exported STLs are oriented on the bed how they ought to be printed, with help from a shell script.
The engraved "OSKITONE" and "POLY555" enclosure texts are 3D-printed with the text side down. A chamfer helps to alleviate some of the "elephant foot" that happens on the a print's first few layers.

Lessons learned from the OKAY

Better tuning

The POLY555 is both easier to tune and stays in tune longer than the OKAYs. Here're the OKAY 2's tuners on the key's flip side:

That PCB is a resistor ladder. The further left on the keyboard the user plays, the more the resistance from the ladder, and the lower the note. So if one pot strayed out of tune, all the notes below it would too.
The pots have 20 turns, which is great for high precision but painful on the wrist
Should any of the buttons start to fail and introduce their own resistance, that gets added, causing an accidental vibrato.
The 555s are sensitive to voltage changes. As the battery runs low, so do the frequencies.

All of that is fixed with the POLY555, where the tuning pots are independant and need less turning, the power buttons are separate from the tuning paths, and a regulator ensures constant voltage.

Hopefully easier to put together

Believe it or not, I think the POLY555 is easier (or at least more straightforward) to solder than the OKAY. Here's the inside of the OKAY 2 again for reference:

Multiple PCBs connected with ribbon cable
"Floating" components that don't mount to the PCB and also require wiring
Some component footprints aren't actually the right size and require bending leads... yikes!
Optional or multi-purpose pads that were intended to engender hacking but were mostly ignored

The POLY555 suffers from none of that, and the end result is that its assembly should hopefully feel a lot closer to the Paint-By-Number kind of thing that, for better or wose, folks expect from an electronics kit.

Narrowing the gap between expected and actual complexity

The OKAYs were so adorable that they were cursed with looking much simpler than they actually were, which was good because I got sales but bad because (I'm almost certain) fewer folks got them assembled successfully in the end (which, IMHO, is the true heuristic for a product's success. I've no interest in being a "shelfware" designer).

So in addition to hopefully making the POLY555 easier to assemble, I'm also intentionally making it look difficult by showcasing its circuitry. By celebrating the complexity instead of abstracting it away, I'm hopeful the kind of folks who are able to will self-select into purchasing and get to the finish line.

We'll see!

Assembly guide

The OKAY kits shipped with their assembly guides printed out and folded into zines, and some even had makeshift-letterpressed covers. There's no doubt a lot of old school charm to that, but it was hard to ensure folks got the best instructions with black ink on dead trees.

So the POLY555's assembly guide is all online, complete with schematics and hacking ideas: https://oskitone.github.io/poly555/

Key endstop

Exhibiting at Maker Faire a couple years ago was like a whirlwind tour of stress testing. If enough force is applied to the keys (Thanks, kids! 😬), they’ll push beyond their buttons and break at the the cantilevers where they mount.

So the POLY555's enclosure has an endstop that fits into a matching cavity on the keys, preventing them from both being pushed too far down and from being pulled up. The endstop cavity on the keys is just tall enough for the travel distance required to actuate the switches before hitting the endstop.

Time will tell if that'll suffice, but it's definitely a step in the right direction.

Prototyping

Prototypes in various stages of scrapping:

^ Dig the cutesy 13 note version!

Abandoned ideas

A recurring theme you'll see in these is that the idea showed promise but just wasn't worth how much effort it required. I'm sure I'll revisit one or two in a future project, where the work-to-reward ratio is better.

	Course and fine tuners The first PCB used two pots summed together for each timer circuit: one with a 3/4 turn for big, "coarse" changes and another with 20 turns for more precise, "fine" control. In practice, I found I was only using one of them while tuning and the other could just be a fixed resistor.
	Speaker on bottom The first prototype tried a wide, flat speaker under the PCB, exposed through the enclosure's bottom. I didn't like that it required the instrument to be raised to prevent muting, nor that the sound was, at best, misdirected.
	Keys as speaker grill After the speaker on the bottom, I tried hiding it under the keys and using them as a grill. I do still kind of like this idea, but, like the one above, it requires that the speaker is flat and dinky. I decided if you’re going to spend a long time making something, it should have a bigger sound than what a flat speaker can give, so I moved the speaker out from under the keys and into a sidepanel to the right of the window.
	Hinges and clasps The OKAYs used hinges and clasps to make them easy to pop open and display the internals — not nearly as important when there’s a big window built right in.
	Lightpipe branding With the speaker in a sidepanel, I tried to showcase the on/off LED indicator with a 3D-printed lightpipe. As much as I would’ve liked to have drawn more attention to the POLY555’s branding, the results weren't worth the effort.
	Lit, engraved branding Another idea was to use a super bright LED to light the engraved branding text from underneath. I tried a handful of different LED diffusions, brightnesses, and dispersion angles without satisfaction. Probably needs a lightpipe that 3D-printing alone can't make.
	Dovetailed, hitch endstop You can see in some of the pics above that I was trying a key endstop that'd extend up from the enclosure bottom and hitch into both natural and accidental keys. I even briefly had this piece connect to the enclosure with dovetail joints. Abandoned for unnecessary complexity.
	Tongue-and-groove enclosure lips The enclosure’s top and bottom were briefly held together by matching tongues and grooves. They were abandoned for not being strong enough.
	Handle Ha!

Get (or make!) your own

Like the OKAYs, the POLY555 is available for purchase assembled or as a DIY electronics kit:

Buy the POLY555 Synth
Buy the POLY555 Synth DIY Kit

For the DIY kits, the 3D models are shared on Thingiverse for folks with ~20 hours and access to a 3D printer.

Open-Source

Unlike the OKAYs, I'm also open-sourcing all the OpenSCAD code used to generate the 3D models, as well as the Kicad PCB project, which I wasn't doing before: https://github.com/oskitone/poly_555

The code is generously licensed. Please reach out to me if you do anything interesting with it or have any questions!

What's next?

Um, probably nothing to do with 555 timers. 😅

Oskitone Makes an Atari Punk Console

Sun, 28 Feb 2021 16:00:00 PST

A decapitated robot head? An extraterrestrial communicator? A specter summoner?

Nope (and yep!), it's an APC!

Just like the other Oskitone projects, it's a 3D-printed electronic musical ~instrument, designed in Kicad and and OpenSCAD, Open-Source, and just plain ol' annoying fun.

Here it is in action:

As usual, this blog post details all the nooks and crannies that can't fit on the store's product page!

Byproducts

Byproducts are secondary, unintended goods from the production of some primary good. You know a couple already:

Bran from flour, molasses from sugar
Gasoline and plastic shopping bags from oil
Leather, gelatin, and lots of surprising stuff from meat
Duraflame logs from pencils

And the APC is kind of a byproduct of the POLY555!

How PCBs are priced

When you send a Printed Circuit Boards (PCB) design off to a manufacturer, you're billed by the square inch of the smallest rectangle it can fit on. A 4" circle is priced as a 4"x4" square, etc.

Now. to make room for the speaker and battery, the POLY555's PCB design is shaped like an "L". Flashback to this early version and feign shock at all of the empty space in the top right!

Getting small batches of big PCBs like this made domestically for the prototype phase isn't cheap, and my wallet is sensitive. Leaving that top right corner vacant means I'm literally paying for nothing; the factory drills it out and throws it away.

So what am I to do? I reach for my well worn copy of Timer, OpAmp & Optoelectronic Circuits & Projects, turn to its most dog-eared page, hastily Kicad the circuit, and throw together an untested board design with some jelly bean components I have before sending the design off for fabrication.

Nice, it (mostly!) worked! Now I'm fully utilizing the area that I'm paying for: the POLY555 "L"s will go to their kits, which I was feverishly trying to bring to market at the time, and the smaller APC corner rectangles will break off and eventually, hopefully be made into something cool.

Fun fact: Connecting multiple board designs into one bigger board is called "panelizing". Here I've done it with little tabs that snap apart when bent, which is fun to do!

Yet another Atari Punk Console

The circuit in question was originally described as a "Sound Synthesizer" or "Stepped Tone Generator" by Forrest M. Mims III in Radio Shack books in the early 1980s and later came to be known as the "Atari Punk Console" (aka APC). People liked it enough that they kept making it, and now it's some kind of classic. For many folks, author included!, an APC is one of their first forays into electronics.

If you google it, you'll find countless varieties of this circuit. It's small enough to fit into any kind of makeshift enclosure, and its simplicity and flexibility make it an ideal subject for modifications.

In case it's not obvious, the market differentiation for the Oskitone APC is its design.

How does it work?

In short, it uses two 555 timers (like what I've used in the POLY555, the OKAY 2, and the original OKAY Synth) but often housed together in one chip called a 556. One timer is an astable oscillator making a square-ish wave; its output feeds into the other 555, wired up as a monostable "one-shot" (a circuit that, when triggered, outputs one pulse of arbitrary length).

Atari Punk Consoles are "played" (term used generously) with two potentiometers. One on the astable controls its frequency, and another on the monostable controls its length.

The schematic for the Oskitone APC is pretty much lifted straight from the original Mims diagram with minor pot value changes, a switch, and an LED for on/off indication.

PCB

The final PCB design looks like this:

The corner holes are for mounting screws, which are a good bet on any PCB but I ended up not using.

Picking the right components

The little 1k trim potentiometer on the right is for volume. The first version of the PCB (see above) also used it for the playing pots, but I swapped them for much sturdier pots that'll do a better job standing up to aggressive playing.
The speaker isn't great for bass, but it is self-enclosed and easy to solder because it requires no hookup wire. Tidy! (I also had 100 of them from overzealous parts sourcing, just waiting for a project...)
The 5mm LED, toggle switch, 1k trimpot, and battery snap are all used in the POLY555. The fewer unique components needed, the more economical to make -- sometimes the best things to use are the things you already have!

Product design

Believe it or not, because of the APC-PCB-as-byproduct-of-POLY555 thing, the rest of the APC was designed months later. I probably had 100 "final" APC PCBs on hand before sitting down to really think about what it would look like as a finished object.

Working around that fixed PCB constraint was an interesting "freedom in constraint" design challenge. I'm sure, if given the opportunity for revision, I'd nudge things around and delay the release, but would it have been worth it? Who knows?!

Wheel knobs

The APC's knobs are more like little K'Nex wheels than traditional potentiometer knobs. Without the enclosure, here's how they fit onto the pots:

And with the enclosure, with a closeup of the switch clutch:

On top, raised spheres act as combination position markers and brodie knobs, so the user can manipulate each pot using just their thumb. With the other fingers naturally wrapping to the back of the APC, it feels a lot like holding a joystick game controller.
The wheels are exposed out of the enclosure's sides too, so you can roll it against your palms as another way to play. The exact amount of exposure and the friction ridges match the switch clutch.
The pots I'm shipping with the kits have knurled shafts that are locked onto with little shims in the wheel's inner cavity, as described in my old blog post about designing custom potentiometer knobs. There are no heat-set inserts to apply or screws to tighten.

Design for Manufacturing: the pot cavities are generously chamfered for easier assembly and to make up for "elephant's foot" during printing, where the plastic expands on the first few layers due to weight and heat and can negatively impact fit tolerances.

Switch clutch

The APC has a plain, stock switch to toggle its power. Instead of letting it poke out through the enclosure's top, it's abstracted by a piece I'm calling a "switch clutch" that sits next to the switch, clutches its actuator, and is activated through the enclosure's side.

Here it is in detail without the enclosure:

(That chipped corner is Artifact 1 of the PCB design. When the switch is in the off position, the clutch juts into the inner wall of the wheel's cavity, and that little cavity prevents obstruction to make it all work.)

A piece like this seems superfluous, but it frees up the enclosure top to show off the speaker grill, makes it much easier for the user to toggle the switch, and ties it together with the wheels. I like it!

Design for Manufacturing: Two narrow walls with a one-layer-height gap of air before contact support the piece while 3D-printing and break off clean when done.

Enclosure

The enclosure's outer dimensions are derived from the PCB, its components, and battery, including the battery's orientation. Here are some early iterations with the battery rotated a different way and shallower speaker grills:

Design for Manufacturing: See the sort of quilty aperture pattern in those wheel well cavities? Those are me trying to perfect floating holes that can print without supports. As evidenced by the inconsistencies you might also see in them, they were tricky to get right because of 1) the required wheel diameter to have them expose out the enclosure's sides and 2) the super tight clearance between the speaker and internal wheel well walls. That difficulty is Artifact 2 of designing the PCB in isolation before the rest of the APC.

I really like the final design and its asymmetrical cocked eyebrows. It's a weird, darling little thing with a lot of personality.

The enclosure's top and bottom slide together with tongue and groove joints, which were originally written for the POLY555 before being abandoned for not being strong enough.
The PCB nestles perfectly into the enclosure top, and rails on the enclosure bottom hold it into place. Again, no screws needed.
The pot wheels sit in two, deep wells that extend over the sides for additional wheel access.
A false grill covers 2/3 of the enclosure's top, entirely for aesthetics (the self-enclosed speaker doesn't need it), and wraps around the wheels. It obscures the speaker below by being extra deep and having two layers of grills at different angles. (Look close at the pic above and see if you can see the speaker cavity. Then compare to the yellow prototypes above. Huge difference!)
The grill also wraps around the power LED cavity and an access hole for the volume potentiometer. (I'd considered using the POLY555's thumbwheel but decided it wasn't worth it.)
The non-grill space on the top is engraved with make and model text, and the bottom has a big "OSKITONE" vanity wordmark, similar to previous Oskitone synths.
Engravings on the sides mark on/off switch positions and a "V" for "Volume" access.

Get or Make Your Own

Lots of folks have asked me to make something for younger makers or those new to electronics. While I'm sure an annoying noise toy isn't, uh, exactly what they wanted, I'm hopeful this gets at least a little bit closer.

It takes less than thirty minutes to put together:

The Oskitone APC is available fully assembled or as a DIY electronics kit. Like the POLY555 before it, it's fully Open-Source, from the PCB to the OpenSCAD code for the 3D models, to the documentation.

What's Next?

Hopefully nothing to do with 555 timers. I mean it this time!

Appendices

Appendix A: Making STLs in the command line, in parallel

In the OpenSCAD code, there's one top-level apc module that encapsulates its children. Toggling different parts of the APC is done with arguments:

apc(
  (show_enclosure_top = true),
  (show_enclosure_bottom = true),
  (show_pcb = true),
  (show_wheels = true),
  (show_switch_clutch = true),
  (show_battery = true),
  (show_dfm = true)
);

That works fine but is super laborious if you want to export an STL of each part individually, especially when you're making a lot of iterations during development. The APC's code borrows again from the POLY555 with its make_stls.sh shell script to automate that.

Here's how it works:

Using the OpenSCAD CLI -D flag to override variables for each show_... argument, iterates through a list of the model parts, setting each flag to false except for the part in question and exporting it as an STL.
The STL's filename is prefixed with the timestamp and hash of the last relevant git commit. This way, there's never any confusion about which exact version of the code the STL is from, and the timestamp ensures they're sorted. (I think we're all familiar with terrible filenames like xyz-final, xyz-final2, xyz-for_real_this_time_please. This is a million times better than that.)
The STLs also render out in parallel to save time and in binary format to save space.
When all are done, it zips them up into one file. Convenient!

It's also got a lot of neat things useful for development, like the ability to query for a subset of models to export, customizable folders and prefixes (as shown above), etc.

Appendix B: Self-hosting STLs

Update (Aug 2024): Abandoned. It was a good idea but I wanted to use the GitHub Pages spot for documentation. Changed in commit ce413f2974.

I'm trying a new thing with the APC where I'm hosting the STL files of the 3D models myself instead of using Thingiverse like I'd normally do. To do that, there's also a downloads/deploy.sh script that:

Optionally runs make_stls.sh to make new STL files and zip
Runs a Python script that generates a utilitarian "Downloads" web page for them using a Mustache template.
Deploys to GitHub Pages for hosting by committing and pushing to a special gh-pages branch.
After a couple minutes, oskitone.github.io/apc is automatically updated with all the latest files for download.

What's great is that because the binary STL files are 75% smaller than their ASCII counterparts and the ZIP collects them and compresses even more, the final download sizes aren't much different from a typical blog post's images (haha woops sry) and should be well within the bandwidth limits.

What's also great is that I can deploy new 3D models with one command, using code I wrote that works as expected and is pleasant for me to use.

Appendix C: Parametric wheel knobs

I liked writing the wheel module, and it's adaptable to a lot more than how it's currently being used for the APC.

In addition to all the different dimensions and grips and brodie knob counts, eagle-eyed viewers may also see the little ridge inside the pot cavity from when I was thinking about using D-shaft pots. Minutiae!

Scout

Sun, 15 Aug 2021 17:00:00 PDT

It's time for a new Oskitone synth... the Scout!

It's called the "Scout" because it's the first Oskitone synth to use a microcontroller, specifically the ATmega328 -- just like the Arduino Uno.

From the readme:

scout (/skout/):

One sent to obtain information

Jean Louise “Scout” Finch, of Atticus Finch

The first synth from Oskitone to venture into the big ol' world of microcontrollers

The Scout is:

Beginner-friendly: All components are through-hole (instead of surface mount) for easier soldering, and full assembly takes about 45min. Standalone, battery-powered, doesn't need a computer or external speakers to work. Fun!

3D-Printable: Besides the electronics and nuts and bolts, all parts are 3D-printed. And with a total width of ~160mm (about 6.3"), the Scout can fit on smaller, "Mini" (18x18x18cm) size print beds.

Hackable: Arduino-compatible and fully open source! Hook up an FTDI Serial TTL-232 cable (sold separately) to update its code using the Arduino IDE.

Minimally featured: 1.5 octaves of keys, a volume knob, on/off switch, speaker, headphone jack. Monophonic square wave with fixed glide and octave.

In addition to it being the first microcontroller-controlled instrument from Oskitone, the Scout would also make a fine introductory DIY instrument for the budding electronics hobbyist. (Some experience soldering and a general familiarity with how electricity works are recommended though!)

Like my previous work, I designed the Scout's PCB in Kicad and everything else in OpenSCAD, specifically for 3D-printing. The Scout is available assembled or as a DIY kit, with and without the 3D-printed parts; and it's fully Open Source!

This blog post is a semi-deep dive into why I made it, how it works, and its features and how they were decided.

Chasing product/market fit

Where the POLY555 looked complex and was complex to put together, the Scout tries to do the same but at the other end of the spectrum: look simple and be simple to put together. Its target demographics are folks new to electronics, parents looking for a fun project to do with their kids, and STEAM class educators and workshoppers — all demos that I'm not currently serving well for piano-like instruments. (Which takes the APC out of the running. Sorry, APC!)

Defining that target upfront meant gleefully stripping away requirements wherever I could:

Instead of 555 timers or complicated analog circuits for the oscillators, it's all software. There're way fewer discrete components to solder, no byzantine schematics to scratch your head over, and absolutely no manual tuning of notes like on Oskitone instruments of yore.
More piano notes is great but it necessitates both more stuff to solder and a bigger 3D-printer to fit all of them! I narrowed the key count to the max that would fit on very common 18cm wide printer beds.
I prototyped but abandoned controls for octave and glide. Instead, they're pulled to the top in the Arduino code and made to be extra inviting to experiment with.
Similarly, there're no controls for other typical synth options like wave type, filter, envelope, etc. Arguably those operations are what make a synth a synth, but they're unnecessary for the target demo. Also no MIDI or Control Voltage support. Ditching all of that leaves out technical and cognitive complexity.

In startup parlance, the Scout is a Minimum Viable Product. I hope people like it, I hope it inspires them to play around with electronics and code and music, and I hope it will serve as a good foundation for me for future Oskitone synths.

How does it work?

Electronics

The heart of the operation is an ATmega328 microcontroller. It's programmed to play a simple tone and light an LED whenever a key is pressed.
The 17 notes' keys are mapped to switches that are set up as a matrix. (Instead of using 17+ GPIO pins they only use 9 [4 rows of 5 columns = 20 possible keys]. There are drawbacks to this approach but none that matter for a monophonic instrument.)
The tone from the microcontroller goes through a potentiometer for volume, a headphone jack for audio output, and finally to an LM386 amp chip to drive a small speaker.
Power for the ATmega and LM386 is supplied by three AAA batteries.
A UART header allows for uploading new code to the ATmega328.

All of that is reflected on the schematic:

And the PCB:

To encourage hacking, the ATmega's unused pins are pulled onto an unpopulated "HACK" header. There's one digital pin, five analog, two unused switches from the keyboard matrix, plus VCC and GND.

3D-printed parts

The electronics fit snuggly inside a snap-together enclosure, along with keys and some other odds and ends, all 3D-printed.

Battery holder

All previous Oskitone machines used 9v batteries, but 9 volts is too high for the ATmega328 and would require a regulator to bring it down, costing more BOM and space. The Scout instead uses 3 AAA batteries for power, in a custom container that clips into the enclosure.

Making this was fun! I'd never paid much attention to how batteries fit into things before, but all the battery-powered devices in my house got a new level of scrutiny while I was designing the Scout's.

Sure does make me want to spin off a custom battery pack company!

(For those curious, AAA was chosen over the more typical AA for size reasons, as 3 AAs would be a little too big to fit under the keys without making them longer, which I tried but didn't like. There're also off-the-shelf battery containers that I could've used and did prototype with, but they also have size and cost caveats.)

Enclosure

The enclosure expands on those of previous Oskitone projects, with some humble upgrades:

In addition to the screws through the middle to hold everything tightly together, the two halves snap together on the sides, cutting down on metal hardware and obviating trickier printed closures. Fine-tuning this took awhile but was worth it. It's very satisfying!
The big, gratuitous text engraving technique is borrowed from the POLY555 and APC. For the label text near the volume knob and on the sides, a new "placard" style engraving prints better and more legibly at small font sizes.
The "pencil stand" feature from the OKAY2 and POLY555 has resurfaced, with a minor upgrade for better fit. Jam a writing utensil in there to prop the Scout up for display.
The enclosure top prints upside down with its face on the print bed. To support the front lip under the keys, there's a breakaway support built into the model.
The front inner lip facing the keys has a rail that acts as a key endstop, hopefully preventing extra damage to the keys when they're played aggressively.
Hidden components! The speaker sits under the keys and uses the them like a speaker grill, and the LED shines through the enclosure top.

Abandoned enclosure ideas

One of the biggest things I worked on for the Scout was how to make its enclosure assemble more easily and look better than the POLY555's but without losing any of the structural/mechanical integrity needed for the keys. It's a difficult thing to get right and hard to articulate in words, but it's funny how hands kind of intuitively know when something doesn't feel good.

An early prototype design:

I tried earnestly to make the enclosure like the APC's and have it slide together with tongue-and-groove joints, but it was complicated by the fact that the batteries/speaker and PCB had to be wired together but attached to different halves.
I also tried thicker walls, thinking they'd make for stronger joints. But they were so strong that they lacked the necessary material "give" to bend, needed for the snap. Good lesson!
That green rectangle was going to be a lightpipe for the LED, a perennial but elusive idea. Also tried circular and heart-shaped exposures for the LED.
I did briefly have the power switch on the enclosure bottom like the POLY555 but abandoned it for aesthetic reasons.
To let folks know the battery size and count before they pop the Scout open, there was briefly a "AAA*3" placard engraving on the bottom, before I removed it for not being worth the potential print failure (that small text is the easiest part of the print to mess up).

Keys

The keys work the same as they did in previous instruments, and dimensions mostly match the POLY555's, despite myriad experiments. If it ain't broke, huh?

With the enclosure top off, we can get a good look at how the keys work with their switches.

Physics teacher voice: Those pieces together form a lever, allowing the user to actuate a switch with a fraction of the force that would be needed if pressing it directly. Basically, the closer the switch (the load) is to the end of the key (the fulcrum) and away from where the user presses down (the effort or force), the lower that fraction, expressed numerically in a unit called a Mechanical Advantage or MA.

A cantilever, which is a narrow bridge of material between the key block and the mounting rail, helps it to bend at the right place.

It continues to be remarkable to me how the slightest variation to this tiny little piece of plastic multiplies its effects to the user. Too thin a cantilever and the keys are loud and feel cheap. Too thick and they're silent but hard to press. Tenths of a millimeter make all the differences. Fine-tuning it is patient, patient work.

Volume knob

The Scout's lone control is its volume, adorned with a simple knob that's thoughtfully recessed into the enclosure and an accompanying "VOL" placard label.

The volume knob's code is extended from the APC's wheels, ditching the spokes and subbing a brodie knob for a dimple.

Switch clutch

Also borrowed from the APC is the switch clutch, which straddles the on/off power switch's actuator and exposes it outside the enclosure as a cute little grip.

To aid printing, a built-in support props up the grip and snaps off when done. And to aid assembly, the piece is vertically symmetrical, so it doesn't matter which side you put in top vs bottom.

Get (or make!) your own

The Oskitone Scout is available now for purchase, either assembled or as a DIY electronics kit:

Buy the Scout Synth
Buy the Scout Synth DIY Electronics Kit

The DIY Kits can come with the 3D prints included, but folks with access to 3D printers are more than welcome to print their own! The Scout's 3D models are on Thingiverse: https://www.thingiverse.com/thing:4933700

All code for the Scout is Open Source and under the Creative Commons Attribution/Share-Alike license: https://github.com/oskitone/scout

What's next?

More keys, different wave types? Polyphony? MIDI? Maybe! We'll see!

shopdocs

Sat, 24 Aug 2024 17:00:00 PDT

I sometimes get the honor to be an instructor for "DIY Synths for the Electronically Unacquainted", a virtual workshop put on by the fine folks at Dogbotic. For two hours a week over nine weeks, we meet on Zoom and trick antiquated logic gates into performing audio synthesis on breadboards. It is great fun.

And I'm open-sourcing the documents I make (and the code that makes them) for my workshop section as shopdocs. This blog post serves to show the project off, explain how it works, and wax a bit on what it's like pretending to be a teacher.

shopdocs on GitHub: https://github.com/rocktronica/shopdocs

(Importantly, this is the source code for resources I made for my section only, not the other instructors' stuff nor the real core material. Any opinions or errors they have are all mine. Obviously, it is no replacement for taking the actual workshop!)

Highlights

Schematic cards

All complex machines are composed of smaller machines, which can further be reduced and understood. That can be expressed with cards of small circuit schematics that add up into bigger circuit schematics as the workshop progresses: light an LED, add an oscillator to strobe it, add an amplifier to listen, add more oscillators, add a mixer, add filters, and so on.

Because newer lessons never start over from scratch, progress is incremental and summary recaps are (I've been told!) intuitive.

The cards are hand drawn and print on cardstock paper then cut to a 2" grid. Flip them over to abstract away their complexity and make a kind of high level block diagram.

Link: https://rocktronica.github.io/shopdocs/downloads/schematic_cards.pdf

Keyboard sequencer

Build an "LED chaser" light sequencer. Build an oscillator with buttons to play different notes. Make the sequencer play the notes. Optionally divide down for octaves.

I'm proud of this schematic. It accompanies a "Serial vs Parallel" doc that explores how to wire multiple button-and-resistor combos to make a multi-note, monophonic instrument.

Link: https://rocktronica.github.io/shopdocs/downloads/keyboard_sequencer-annotated.pdf

"Randomicity"

One of my favorite lessons explores the idea of randomness, what it means to people vs computers vs Las Vegas, and ways to implement it with the chips we have on hand. We build sirens, a "What's for lunch?" decider, and a Sample and Hold synth circuit:

Adapted from Elliot Williams' incredible Logic Noise Hackaday series, updated to use the workshop's preferred oscillator chip. See that article for what it sounds like!

Link: https://rocktronica.github.io/shopdocs/downloads/sample_and_hold.pdf

One Chip Star Tom

~~A faithless recreation of~~ A loving homage to an old EHX pedal called the Space Drum, done with just one CD4093 chip.

Press the button to make a funny "BWAOOWWM" space blaster sound. Adjust pots for drum decay and pitch. (A third pot can be added between booster and cap for volume control.) Doesn't need an amp!

Breaks enough rules to scratch heads but is simple to wire up. Makes a great candidate for a quick-and-dirty, untested Kicad PCB lesson too:

I did an Instagram promo with it I like it so much, though I did accidentally draw the NAND symbol wrong. Woops!

Link: https://rocktronica.github.io/shopdocs/downloads/star_tom.pdf

Open-Source license

Text and drawing content is shared under a Creative Commons Attribution-ShareAlike 4.0 license. Free to use, including commercially by other instructors or for other workshops, but please retain my attribution and this license. Code is MIT or as components allow.

My thoughts on teaching a technical subject to people with diverse backgrounds, how to strike the right balance between accessible-but-boring and interesting-but-overwhelming, and how to keep everybody engaged enough to keep coming back for the next lesson

It's hard!

Appendix: How to use Chrome to make PDFs, fast

Class resources are put in a shared Google Drive folder, so everything needs to be static and downloadable. For text, that means PDF, and PDFs usually mean writing in Docs or Word or something and writing/exporting each piece of writing individually.

But because I was a software engineer before I was an ad-hoc workshop instructor, the setup here goes:

Input content is written in Markdown, a minimalist markup language that reads as plain-text but compiles to have rich formatting.
That markdown is converted to HTML and combined with other static PDFs (mostly KiCad schematic plots) into a little website with Eleventy, a static site generator that coincidentally also powers this blog.
A Node script uses the input listing to scrape the site and export its pages as PDF with Puppeteer, a browser control tool used for testing sites during development. The script's output is identical to loading the site in Chrome and manually doing File->Print->Save as PDF on each page.
A bash script copied from the APC deploys the site to GitHub Pages. (This wasn't necessary for the workshop, but it was trivial to do and I couldn't resist.)

If you code and want to programmatically make text-heavy PDFs, this kind of Chrome-as-PDF-renderer technique is very pleasant: style/formatting changes are quick to apply globally, exporting updated PDFs is a one line command, and version control is baked in.

Fun with the Arduboy

Tue, 21 Jan 2025 16:00:00 PST

I've been having a lot of fun with this open-source game console, the Arduboy.

It's effectively an Arduino Leonardo in the guise of a minimalist GameBoy: 1.3" OLED display, D-pad+A/B buttons, and battery in a credit-card sized enclosure. Plug a cable into the USB port at the bottom there to swap the game or upload your own.

I think its limited specs are a blessing in disguise. The small screen and few buttons makes it kid-friendly (well, about as much as a video game can be!), and the tight program space is an effective guard against overengineering.

Maybe I'm jaded from slingin' websites for so long, but the tactility of my little idea on a device that fits in my pocket is deeply gratifying. The Arduboy makes for a great onramp into the world of embedded software, even if you're not out to make the next Mario.

Games Things I have made for it

Arguably, none of these are games, despite the Arduboy being a game console. C'est la vie.

Any Kind of Car and Any Kind of Truck (Any Kind of Any Car and Truck)

My first offering is "Any Kind of Car and Any Kind of Truck (Any Kind of Any Car and Truck)," made for my vehicle-obsessed child and named for an open challenge that I can draw him any kind of car and any kind of truck.

Play it right now!:

Play "Any Kind of Car and Any Kind of Truck" ►

(For this and the other emulated games here, click a couple times to activate, then use arrow and Z/X or A/S keys for buttons.)

To play:

Button B randomizes the vehicle's parameters: cab/box/wheel size, trunk/hood ratio, and the distance between wheels. The score tally increases with each randomization.
Button A toggles the title and theme song, something so important it couldn't be contained to just the game's start.
The direction pad moves the vehicle around and makes it jump, so I guess it's got hydraulics!
A+B+Up maxes out the vehicle specs. A+B+Down minimizes them.

My sketchbook reminds me I was first thinking of making it like a mix-and-match spinning block toy:

A two year old is kind of a great target demographic. The reward of their joy is immediate and they don't need any real complexity. Make all the buttons do something and the sounds fun, and you're good. I could have spent more time adding features to satisfy older players or do any of the code TODOs to satisfy myself, but he wouldn't have noticed, so why bother?

Links: playable demo, source code, forum discussion

Aside: Score as count as ID

Computers are strictly logical machines, inherently bad at being naturally random. If asked to generate random numbers, they'll always return the same sequence, which'd feel random at first but obviously not thereafter. (Imagine the lottery numbers being the same every single week!) This kind of Random Number Generator (RNG) is called a Pseudo-Random Number Generator (PRNG); it is deterministic, predictable, a machine of input and output.

The way around that determinism is to first provide the generator a new number called a "seed", which will change things around enough to output a totally new set of numbers. What's important about the seed is that it's unique when supplied, like the time of day or the shape of lava in a lava lamp or even radioactive entropy.

I left this game's PRNG unseeded (so, a fixed null value), so the score (which, again, is just the count of how many times the vehicle has been randomized) effectively serves as an ID for the its parameter set — the monster truck shown at SCORE: 123 will always look the same, even after device resets or battery changes. I think that's cool!

Separately, True Random Number Generators (TRNG) are RNGs on dedicated hardware that are non-deterministic without seeding. They make really, truly, very random numbers, useful in fields like cryptography for data encryption.

If your programming-language-of-choice doesn't explicitly require a seed yet still behaves expectantly random, it's almost certainly seeding under the hood and is probably not a TRNG.

2D6: Dice Roll Distribution Visualizer

Speaking of randomness...

Roll a six-sided die. Each of its possible values is equally likely, yes? In other words, a roll of one will occur just as often as two or three, etc. Now roll two six-sided die ("2D6," in game parlance) and add their values. Are their sums also equally likely?

The answer is no, they are not. Since the average roll from a 1D6 is 3.5 and 2D6 is twice that, the most likely roll from a 2D6 is 2 × 3.5, or seven. The likelihood of other rolls diminish as they stray from seven, with two and 12 being equally least likely.

And theoretically, if you graph that, you get a kind of bell curve.

Source: https://tadeohepperle.com/dice-calculator-frontend/?d1=2d6

So this is basically a math exploration tool to roll digital dice up to a thousand times and chart their results. Does practice match theory? You can additionally change the number of dice and how many sides they have, from two-sided coin flips to twenty-sided dice. How do the number of dice and their sides change the shape of the curve?

I promise it's more fun to play with than it sounds...

Play "2D6" ►

To play:

The menu screens flow sequentially. Button B advances and A goes back. Use up/down for selection. Go back from the title screen for credits.
The final screen shows roll results, where up/down slides between the graph and selected raw numbers. Press A to go back.
Holding the "roll" button for a second to auto-roll, and hold the right button while rolling to 10x rolls. You'll hit the arbitrary 1000 rolls cap pretty fast.

Unordered production notes:

A math utility on a 128x64px screen is a fun design challenge. How much can be shown without being cumbersome? How can I strike a balance between correct and accessible?
There are lots of playful little touches like the dice spinning out of sync and bouncing windows when you've reached their limit. It uses the same sound effects as "Any Kind of Car...", much to my child’s confusion. It is a very game-like non-game.
The Arduboy actually has two pins connected to its buzzer speaker. Some games will use these to for two tone polyphony, but sending the same tone to both pins makes it louder. This is how the HIGH/LOW/NONE sound volume control works.
It is an okay dice simulator but not the most polished. And also not withstanding the bias caveat mentioned below...
Abandoned ideas
- I briefly pursued a UI where you horizontally scroll left to right, since the dialogs are sequential. Wasn't worth the memory or overhead.
- The code has a drawEquilateralPolygon that I experimented with for other dice shapes like a four-sided die's triangle or the pentagon from a 12-sided die. Making odd shapes have text and fit together nicely was well outside of scope.
- The dice could animate more, bouncing into their container and off of each other before settling into place. Can you imagine?!

Sketchbook:

Brute-forcing dice roll distributions feels very much like a dumb way to do a smart thing. Right up my alley!

Links: playable demo, source code, forum discussion

Songs for Desmond

My opus. From its readme:

One thing nobody tells you about being a parent is that, as you go about the day taking care of your kid, you absentmindedly sing little songs about everything they do.

The other thing nobody tells you is that the songs... are good.

"Songs for Desmond" collects ours into a kind of 1 bit love letter: a 27 track album of minimalist square wave melodies, released exclusively on an Arduboy game console that he can carry around with him.

I believe it is the first kids songs album to be released on the Arduboy.

Play "Songs for Desmond" ►

To play:

Up/down change volume
Left/right change track
A to stop
B to play

My sketchbook drawings on this one are more about a standalone digital music box I keep thinking about. If I ever end up making it, it'll have something to save my ears from high pitch tinny square waves. (The Arduboy's 12mm piezo is not ideal for playing 5min straight of music.)

Unordered production notes:

Intro animation is from a video of my kid walking around, converted to sprite sheet with FFmpeg and cleaned up in Pixelmator.
UI is a simple music player. Instead of album art, the intro sprite is cropped to a square and synced to each song's tempo.
Melodies were written to MIDI with Signal, then compiled en masse for the Arduboy with a ./compile_songs.sh script.
Again, sound volume is accomplished with the two pin buzzer trick. I considered a bassline for the second pin but abandoned it for simplicity and file size. Doubling the music data would have pushed it over the device's program space.
The internet is full of jerks. Forums (and especially forums for technical topics) collect the worst of them. The Arduboy community, however, is a pleasant, encouraging oasis. It is the only forum of strangers I have joined and is a major reason I got into this at all.
- One user, @Pharap, was kind enough to offer a code review and advice on memory saving techniques. My C++ experience is zilch, so it's good to get some other eyes in there.
Songs include the theme for the car game above and half the game ideas below.

Links: playable demo, source code, forum discussion

Development process

For development, I edit in my regular code editor then run a run.sh script to automate the Arduino CLI compilation, Ardens emulation, and final uploading to device. For now, each repo has its own copy of this script.

 ./run.sh -h
CLI wrapper around Arduino and Ardens

Usage:
./run.sh -h                 Show help and exit

./run.sh compile            Compile
./run.sh emulate            Emulate
./run.sh dev                Compile and emuluate
                            Looped! Quit emulator to refresh
./run.sh deploy             Compile and upload
                            Default port: /dev/cu.usbmodem143101
./run.sh deploy -p PORT     ^ with arbitrary port
                            Run 'arduino-cli board list' for list

Of course, editing and uploading in the regular Arduino IDE also works perfectly fine, if less automated.

Ardens does profiling and debugging too, but the emulating alone makes it a must-have for Arduboy development.

Game idea doodles

A great thing about a new tool is that you start seeing places to use it everywhere, like it becomes a creative outlet or canvas or something. "I wonder what this'd be like as a game!" you say as you draw your little drawings.

This Town's Got a Lot of Construction
Job by job, construction trucks build a city. (Theme song: track 25)
Street Sweeper or Trash Truck
Clean/pick up all the trash on the street before your truck runs out of gas, a la Pac-Man. (Theme song: track 16)
Pixel art editor
Simple but usable pixel art program on native hardware; output hex code displays on screen for export.
Bouncing a Bouncy Ball
Physics playground for bouncing a ball, with settings like the old Incredible Machine game. (Theme song: track 11)
Binary Trainer
Race against the clock to convert increasingly difficult numbers between binary and decimal. Hard mode: hexadecimal.
Fair Share
Cut food at an ever-growing party of impatient guests envious of unequal portions. How well can you divide a circle into three pieces, a rectangle into five, etc? This one has some actual pixel concept art!
Higher Lower
Two tones play — is the second one higher or lower? The more you get right, the harder it gets. No screen needed to play.
BoyBoy
A handhold game console with a text character display? Name is placeholder.

Who knows if I'll make any of these!

What's next

The Playdate from Panic is next on my list to tinker with. I have one now and like it a lot, though it's a little too fancy for unsupervised play.
ArduboyFX, the successor to the older version that I have, has space for more games and can do grayscale colors. I'm sure I'll pick one up soon enough.
Another gadget I'm looking at is the PyBadge from Adafruit. It has more bells and whistles but you're on your own for the enclosure and battery. It's more a prototype board than an end-user product.
The Arduboy Mini has similar enough dimensions to the Scout's battery holder that I'm tempted to build an enclosure for the two. It could work!
~~Oskitone is going to put out a game...~~ UPDATE: Oskitone put out a game.

Higher Lower

Sun, 18 May 2025 17:00:00 PDT

The latest Oskitone kit is an electronic handheld game I made called "Higher Lower," where you have to guess if a tone is higher or lower than the previous one, and the more you get right the harder it gets to tell.

It was fun to make and is fun to play!

Prompt

The impetus for this project was Hackaday's "Tiny Games Challenge":

Sometimes the tightest constraints inspire the highest creativity. The Tiny Games challenge invites you to have the most fun with the most minimal setup. Whether that’s tiny size, tiny parts count, or tiny code, we want you to show us that big fun can come in small packages.

I have a pet peeve about devices too small for human hands, so I interpreted the challenge as a budget on input/output. What's the least a game can do but still be fun? How few controls do we need for input? What can we do without for output?

The microcontroller I targeted is the tiny ATtiny85: an 8-bit and 8-pin DIP chip long popular with hobbyists that I've been meaning to try for awhile now.

(Alas, the contest's deadline came and went without me even noticing, so "Higher Lower" was no contender. Life, huh?)

Design

Sketchbook drawings of initial idea and drafts of how it could be held:

To figure out actual dimensions, I traced some speakers and battery packs. My toddler helped.

Arduboy

The ATtiny85 can be programmed using C++ and Arduino code. Conveniently, so can my favorite DIY game console, the Arduboy.

Using the Arduboy for development made for a much tighter feedback loop than programming directly with the chip. And the Ardens emulator means I can work on the game with just my laptop. This is a screenshot of the proof-of-concept, made while waiting at my kid's swim practice:

Notes:

A regular Arduboy game would have something in the Display panel, but instead I'm using only the Serial Monitor to print out the interval stack; this won't deploy to the final target device. In the Waveform window, you can see the different frequencies of square waves being played.
The frequency intervals' directions and distances are random, but their distance is waited like the Arduboy 2D6 dice emulator on I made.
Instead of using a display to present the score to the user, its count rings out audibly after each successful round, like how a grandfather clock gongs the hours to tell the time.
There are no strikes for wrong guesses or other units beyond points, which I think would be hard to convey easily without a display. Any wrong guess and the game resets to the intro theme.
After ten rounds/points, the game plays the intro theme in a loop, faster and faster and faster until the device resets. The next game is more difficult, and so on.
Sound effects are lovingly borrowed from my "Any Kind of Car" game. The theme song is ascending thirds in a C Major scale.

Even though "Higher Lower" isn't an Arduboy game per se, the platform and toolset made a very compelling environment for its development.

Plus, it means I can embed a stylized version of the game right here in this blog post, no special hardware required!:

Play "Higher Lower" ►

(Click a couple times to activate, then use up/down keys to play. The default difficulty setting in the emulated game is very easy.)

Hardware prototype

Now to get the game out of the emulator and into the real world...

1. Arduboy to Digispark dev board

The Digispark is an ATtiny85-based development board with a built-in USB plug. I've had a couple counterfeits (unbeknownst to me, I swear!) collecting dust for awhile so it was good to put finally put one to use.

As a perhaps unnecessary exercise in refactoring and space saving, I rewrote any Arduboy-specific code to use standard Arduino functions: swapping ArduboyTones with tone() and rewriting the button handling that Arduboy2 would normally do. The pins were also remapped to the new chip using the Arduboy schematic as reference.

2. Digispark to ATtiny85 IC on a breadboard

The next step was to go from Digispark board to bare ATtiny85 chip. I used Sparkfun's Tiny AVR Programmer and followed their docs.

This step was less intuitive but had some good lessons for me. To get out of the Arduino IDE's menus and codify the settings that worked, I extended the shell script used for development to also handle programmer deployment.

3. Breadboard to soldered prototype on perfboard

Fun!

Prototype notes:

The 2x3 group of pins towards the top is an ICSP header for the AVR programmer to plug into. Alternative options are a UART header like the Scout (requires more parts and program space on the chip) or no header at all (requires swapping the chip to update code).
The "Skip" and "Reset" buttons are might-as-well for playtesting but don't make it to the final device. Resetting plays the theme song again which my kid likes a lot.
The schematic for this is roughly the final one below plus the extra buttons and some different cap/resistor values.
The speaker is a beefy boy left over from the OKAYs. The battery pack is the Scout's 3xAAA battery holder. The speaker fixture and base print are new parts.

I like soldering and prototypes and have opinions on them! (docs from my workshop gig)

Implementation

Schematic

This is the final circuit schematic, made with KiCad:

It's pretty sparse!

PCB

The PCB was also done in KiCad. For a design challenge about making something tiny, it is admittedly not very tiny:

But it makes sense in the context of its enclosure:

Button feel

To test how the rocker will work against its underlying switches, the first PCB rev duplicated them to be soldered at different positions against the rocker. The footprints overlap a little but OSH Park fabricated it just fine, seen here in their "After Dark" colorway:

The outer switches, SW2 and SW5, are directly under the rocker pad centers, how a normal "switch cap" would work. The inner switches, SW3 and SW4, are as close to the center as they can be, which is what the final PCB does. In effect, the rocker is a lever.

(The divots in the track from SW3 are part of an unrelated bodge!)

OpenSCAD and final design

All the non-electronics parts are 3D-printed and designed in my favorite programming language for 3D CAD modelling, OpenSCAD. Returning customers will see details from previous work.

New to the Oskitone design language:

Button rocker (AKA "D-pad")
Hard to miss this big ol' chonker, huh? This piece sits on top of standard tactile switches, strategically placed for a satisfying mechanical advantage. Cavities on its bottom register the switches' actuators, and nubs on the enclosure top hold it in place during assembly. I wanted to but did not over-engineer it. Maybe later...
Enclosure disassembly cavities
The enclosure snap fit is newly refined for tightness and doesn't need screws. Dimples and wedge cavities along the lip serve as design affordances to (try to!) subtly tell the user how to open it up.
2xAAA battery holder
The game is powered by two AAA batteries, housed in a reduced version of the Scout's battery holder. Instead of hitches on the sides to protect against wire fatigue at the solder joint, the wires run through a channel and fixture on the bottom of the holder.
Glue stick lightpipe
My new approach to LED lightpipes is an old maker standard: the humble hot glue stick. An 1/8" segment of standard 1/4" diameter glue stick fits into the enclosure top, discretely exposed in the corner of the speaker grill. The LED isn't necessary for gameplay and I waffled on its inclusion, but in the end I kept it as an assembly guide feedback mechanism — Is the board getting power? Is the chip working?
Hidden settings pots
The game's difficulty and volume are set with trimmer potentiometers on the PCB under the speaker. It's a middle ground between exposed knob controls (too focal) and requiring a code update (too much work). I briefly pursued putting the trim pots on the PCB's bottom and exposing them through the enclosure like the APC, but it wasn't worth the enclosure height increase.

Available... now!

You can purchase the Higher Lower Game DIY Electronics Kit from the Oskitone website. It takes about thirty minutes to put together, a little more if you're new to soldering. It is reasonably priced.

Have a 3D printer? The part files are available to download from Printables and Thingiverse.

Not everyone will want a full kit and there're many places in the world I can't sell well to, so I've additionally made the final Higher Lower game PCB available on OSH Park. I don't make any money from this but I'd rather the business go to them than anywhere else!

Documentation

Oskitone Higher Lower Assembly Guide: https://oskitone.github.io/higher_lower/

Like the other Oskitone guides, soldering is ordered by function (not by component type or size, which is typical) with clear tests at the end of each step so you know if it's working as expected before moving on.

New to the docs are "How it works" sections on each step too. What are these components doing? How is the microcontroller using these switches and pots? Wait, what even is a microcontroller? Some questions are hard to answer conclusively without writing a whole book, but an attempt was made!

Source

Source code and design files are open-source on GitHub, per usual: https://github.com/oskitone/higher_lower

Appendices

Two batteries, not three

The operating voltage range of a standard ATtiny85 is 2.7v to 5.5v.

A rechargeable NiMH AAA supplies 1.2v, and three of them make 3.6v, which is perfect! That's what the Scout does, and it's the Scout's battery holder pack powering the game prototype above.

The problem is that 3 AAAs plus the PCB length made the enclosure dimensions a kind of awkward rectangle, when I wanted it to be a square.

Dropping to two NiMH batteries for a total 2.4v isn't enough voltage, and I dare not prescribe non-rechargeable alkaline batteries even though their nominal 1.5v (thus, 3v total for two) would work great.

The solution was to switch to the ATtiny85V, a special version of the chip that runs on lower voltages, as low as 1.8v.

So RANDOM

Random number generators need a seed number to start, otherwise they'll present the same sequence repeatedly.

An unconnected chip pin has a value that's either high or low (or, in binary, 1 or 0), which is theoretically an okay seed. But, in practice, I didn't have much luck with this technique.

Now a great seed would be the number of milliseconds it takes for the user to take an action, which is not only higher than 0 and 1 but also almost certainly unique on each play. (This, btw, is how a lot of those "Prove you're not a bot" captchas work. They're not checking your answer but rather how long it took you.)

But if the game starts immediately on boot and launches right into the first round of should-be-random intervals, when can we get something like that?

The compromise I made was to delay randomization until the user has finished the first round, guaranteeing a unique millisecond seed each time. The first round's sequences of notes are fixed and from the intro theme, so it also feels like a nice, musical ramp into gameplay before the intervals become arbitrary.

Lightpipe cutting jig

To make the lightpipes, I first made this cutting jig. It holds the hot glue stick in place with slots at 1/8" intervals to run a utility blade through. The hole on the right is a "checker" that matches the lightpipes dimensions.

Parts Café

Since so many projects are sharing so much OpenSCAD code, I've started to extract as much as I can into a common Oskitone parts library, parts_cafe:

The prototype's base and speaker enclosure seen above
A "print test" for 3D printer calibration
Lightpipe cutting jig
Almost everything else you've seen in my projects: enclosures, engravings, piano keys, PCB mounts, fixtures, etc

There are better options for OpenSCAD parts libraries so I don't recommend anybody really use it (and I have no immediate plans to add any real documentation or offer support), but it's here for the curious: https://github.com/oskitone/parts_cafe

multi_tiny

The Sparkfun AVR programmer I'm using is designed to program one chip at a time, and it works great for that!

But if you want many chips programmed, your options are basically 1) a bigger programmer or 2) to outsource the programming.

This multi_tiny PCB is my research side-quest into how to connect multiple ATtiny85 chips to a single programmer. The idea is that the programmer's pins go through multiplex switches that direct them to different target chips' pins. When they're done programming, they pop out easily from the ZIF (Zero Insertion Force) socket. The multiplex destinations can be set manually, but the end goal is to control them digitally with another device that also handles queuing, testing, statuses, chaining...

It's a promising start but very much a work-in-progress. Follow along here: https://github.com/oskitone/multi_tiny

An animated GIF of the OpenSCAD development, git commit by git commit

As one does.