motionhexa - starduststorm.art

A motionhexa unit is tilted back and forth by a hand as a red, yellow, and blue spiral animation winds and unwinds alongside the motion

motionhexa is a hand-held, glowy stim-toy, incorporating buttery-smooth motion responsiveness, particle physics, and music waveform visualization into a familiar six-sided shape.

An encased motionhexa is lit up brightly with a palette of greens, oranges, and white pixels. Another motionhexa is laying front-up without the case on so that the pixels are visible. A third is laying back-up without the case on so the battery and circuitry are visible.

The pixels pcb has 271 pixels in hexagonal lattice. The controller is a wedge-shaped pcb with a dual core processor, an inertial motion unit, a microphone, and battery management hardware. A large 2000mAh battery takes up most of the space, giving the hexagon 9+ hours of battery life.

A motionhexa sits flat on a table, an antialiased hexagon drawn onto its panel using the colors of the transgender flag.

motionhexa started as a learning project. I wanted to make more advanced wearables, but i needed to learn how to put motion chips on pcbs, and i also wanted to play with a hexagonal pixel arrangement. My previous wearables had also been dependent on store-bought USB batteries while i vexed on the circuity needed for the integrated lipo charge + 5V DC boost chips i was finding, so i decided to tackle that for hexa.

A screenshot of the motionhexa pixels panel from inside KiCAD. Red lines and green lines criss cross at high detail, showing how power and data is wired in this design.

I use python for pixel layout. I went with a zig-zag ordering with all pixels in same orientation. I ended up writing a python type that would let me chain copper-trace draw commands in a compact and flexible way to handle all the routing cases when connecting the pixels. All the pixel and capacitor traces are placed programmatically.

An early prototype of motionhexa with a power control board on the left and a logic board on the right. A random loose debugging wire is soldered to GND pins.

To learn the motion chip and make my first nontrivial rp2040 board, I made a separate castellated logic controller. To learn battery management and boost circuitry, I made a separate castellated power controller. I intended for these to be independently-useful modules, but since the two needed to communicate using pins thru the hexa, this undercut the advantage of modularity. Still, it was good for me to do this practice, since i made mistakes and had to rev both boards anyway.

A motionhexa pixels panel is wired to a breadboard with two rp2040 logic boards on it and a lot of mixed breadboard wiring.

I learned that even though rp2040 says it can run at 1.8V (which is what the motion chip needs) and it can, the USB peripheral does actually need 3.3V. For the first rev, i would use one powered at 3.3V (so no motion chip) and one at 1.8V (no usb) connected over serial-wire debug to make one almost-working motionhexa.

A BQ25895M breakout board is spanning two breadboards with a lot of wiring connected to it both through the breadboard and also soldered directly on, for debugging.

I learned that using an integrated chip like BQ25895M is way overkill for my use case, and though i set out to make it capable of 3.1A boost, my prototype was never capable of that full current, (not that the pixels could handle the thermals anyway). Further, this chip is for charging cell phones I guess, and disabling their "on the go" power output did not actually disconnect the load from the battery, so my power switch didn't work without a bodged-on SOT-23 mosfet.

An early version of a motionhexa front case, printed in marble PLA, held in front of a 3D printer display and backlit with blue light, showinging many small segmented divots like honeycomb that allow light to pass through, while another part of the plastic that is not in front of the blue light appears opaque.

Around this time, @sequoia.farm designed a front-case for hexa with segmented pixel slots and printed in semi-opaque PLA. It snapped onto the pixels pcb and used tiny hexagonal-shaped divots to give the pixels area, which I realized I really liked vs the blur effect you get from led acrylic.

A motionhexa unit is held up by some fingers with purple nail polish. The back of the unit shows the two daughter boards for power and logic. A small lipo batt4ery is attached as well as a usb cable. The pixels are illuminating the desk behind it.

So far, hexa was an interesting prototype and I wrote some pretty and fun lights for it, including the swirling spiral and the pixel physics, but the object itself was awkward and I wasn’t sure what to do with it. It was educational but unsurprisingly tedious and inflexible. I became too familiar with the specifics of when the BQ25895M powers its PMID pin and at what voltages. My power switch was in a terrible location even when a hardware patch got it working at all.

A JLC rendering of a panelized version 2 motionhexa controller board, showing a wedge-shaped pcb with various circuitry and ports.

The boards in this position also made it difficult to attach a battery. To resolve this, I started over with the controller and put the logic & power control on a single wedge-shaped pcb, leaving a rectangular space for a large battery. I used an MT3608 for boost and a cheap lipo charger.

A version 2 motionhexa is shown rendering a red, orange, and blue spiral design on bare pixels, while the back of an assembled motionhexa lays on the table behind it, showing the way the wedge-shaped controller fits into a corner on the back of the hexagon-shaped pixels pcb

now i was cooking, and it was coming together as a self-contained object. I had so much space for a battery. It needed a back case, it needed more pretty motion-reactive animations.

A stack of seven form-factor v2 prototype motionhexas, with front cases printed out of marble PLA and back cases printed out of black PLA.

Freshly armed with CAD, I put together a back case to cover the controller and hold in the battery, and the hexa came together into An Hexagonal Object.

For the first form-factor prototypes, I had a power switch and a punch-out affordance for a push button. This worked, but required a lot of hunting for the switch and button since they were hard to find tactilely.

The seven form-factor v2 prototype motionhexas are arranged in a hexagonal grid themselves, each drawing a different pattern.

they looked no less gorgeous. chance would have it that i had seven working prototypes, a centered hexagonal number. these seven went with me to a late-spring festival in the forest, bringing so much delight, and showing me where to go with it next

A microscope view of the pixels on a motionhexa panel.

It needed:

No tiny flimsy power switch
A button you could find by feel, or a button that was everywhere
A way to tell it was charging, ideally on the main pixels
Lots of polish

And it was three months until MakerFaire 2025!

An ill motionhexa lays back-up on a desk and there are multiple resistors and capacitors soldere to it in a debugging scenario.

I spent three hardware iterations on the controller over the summer to design a power path that could do power-on-off as well as act as a software button, as well as keep running everything on usb power even if the hexa was “off” so that it could draw a charging ring on the main pixels, and also have the whole thing not fall apart in the absence of a battery. My scope got a lot of use.

A screenshot of the hexa controller schematic saying 'life changed when i put
another regulator in my schematic'

the key learning for me, to avoid ever relying on the lipo charger's output voltage in a button-based power-on circuit, was to use a second, always on linear regulator to unify battery+usb voltage, rather than using a mix of zeners and dividers and other diodes for voltage management, and to use that stable voltage across the button to power the main dual-zone ldo, which powers the rp2040 and sensors.

A gif showing a motionhexa being plugged into usb power, after which it draws a green ring around the outer ring of pixels to show the charging level.

Having finally sorted this out, hexa finally had a polished-feeling charging experience.

Many motionhexas without cases are shown lined up together in a tesselated hexagon arrangement. They are all drawing the same animation with red, green, and blue particles bouncing around wildly.

I polished software a lot for Makerfaire, but had just as many things not make it in time. I had an improvement/rewrite of my pixel physics that wasn’t stabilizing yet. I had failed to get my (LinkMems) microphones working at all (I later learned it was due to unusual PDM wire timing). I did not get auto brightness working. I was painfully aware of several bugs.

What we ship is always imperfect.

A motionhexa held up by two hands is tilted around in a circular motion and the pixels draw on the display fall and slosh around with gravity as it is moved.

Nevertheless, so many things came together just in time, from working power and charging, to the MJF nylon back cases, and it was such a joy to see people's faces light up when they moved it around and find it moving back. It's such a stim toy that it's hard to put down.

A motionhexa sits upright and draws a yellow and purple pattern in response to ambient music.

After Makerfaire and sold fresh out of hexagons, I kept iterating and revised the controller to remove the boost circuit, having ironically sorted out that the pixels and power were all working fine at lipo battery voltage. I shrink the controller slightly since the castellated joints were interferring slightly with the case assembly, and a few other small changes. I got the microphone working in software. I am slowly adding spice, variety, delight, easter eggs to various patterns. It remains a work in motion.

Many unassembled motionhexa panels and controllers are laying on a desk, awaiting hand assembly.

Future: I would like to further refine the hexa by combining the controller and pixels into a single board. This multi-board (3, down to 2) strategy was a good way for me to learn, but it is more expensive to manufacture and requires more hand assembly from me once the boards arrive. It would also make it easer for me to add multiple light sensors to the front of the device to implement more reliable autobrightness. To do this, I will have to re-layout the pixel wiring as well as the controller. and share via space, which is the most challenging part.