A unified Hardware Abstraction Layer, declarative pattern engine, and real-time audio-reactive portal for LRAs, ERMs, and solenoid actuators.
Haxel is what happens when you ask "why doesn't WLED exist for haptics?". It's open-source firmware that turns any ESP32 board and a motor driver into a web-controlled haptic engine you can tune from any wireless device with a browser.
The name comes from the unit. A haxel is one discrete unit of vibration: tactile intensity and frequency collapsed into a single addressable value, the same way a pixel is one unit of light.
The concept is borrowed from the LED world, specifically from ElectroMage's Pixelblaze, which is the clearest demonstration I've seen of what happens when you stop hardcoding behavior and build a proper pattern runtime instead. Pixelblaze drives thousands of pixels through a scriptable compiler running on an ESP32, and the result is an instrument, not a firmware blob. That's the model Haxel is trying to bring to haptics.
Built at a hackathon. This came together at the State of Oregon | Claude Code Hackathon (Anthropic + Vibes DIY at the PSU Business Accelerator). I prepped a toolkit of prompts beforehand in my Agent Arsenal, dropped the API key in when the hackathon started, and let the agent swarm run.
The swarm had a decade of embedded hardware and firmware work to draw on from my codebase, and got it to a point where I could finish by hand. Most of it came from GestoLumina (GeLu), a gesture-sensing haptic and LED bracer presented at NIME 2024 and documented in a group autoethnography submitted to ACM SIGACCESS, both produced with the Universal Music Design team at CymaSpace. That work sits inside a broader practice of Deaf-led assistive music technology: a guest lecture at PCC's Interface Design course, and ongoing NEA-funded work connecting haptic and audio-reactive systems to Deaf and Hard-of-Hearing K-12 music education.
| Feature | Legacy Haptic Control | Haxel (HAL) |
|---|---|---|
| Driver Integration | Hardware-specific register hacking per driver IC | Unified Hardware Abstraction Layer |
| Pattern Generation | Hardcoded non-blocking loops | Declarative pattern library runtime |
| Control Interface | Serial monitor & manual uploads | Mobile-first captive portal web UI |
| Audio Reactivity | Custom DSP / external hardware filters | Built-in 32-band FFT & envelope follower |
| Actuator Support | Single actuator style per compile | Dynamic LRA, ERM, Solenoid mapping |
The core problem with haptic hardware is that every actuator type is fundamentally different. An LRA needs AC resonance tracking at its physical resonant frequency. An ERM just wants a DC voltage threshold. A solenoid is a different beast entirely. Normally that means a separate codebase for each one. Haxel's HAL pipeline, running inside a FreeRTOS task hides all of those headaches.
LRAs only feel right at their physical resonant frequency, usually somewhere between 170 and 235 Hz. Haxel reads back-EMF signals from the active driver continuously and nudges the output frequency to stay locked on, so you don't have to measure it yourself or recompile when you swap actuators.
Patterns run through a flat-bytecode interpreter that outputs normalized intensity values between 0.0 and 1.0. The active HAL driver then translates those into whatever the hardware actually needs—voltage ramps for an LRA, PWM duty cycles for an ERM, or timed pulses for a solenoid.
One of the things I'm most excited about here is the audio pipeline! Haxel runs a 256-point FFT on audio input from either an analog aux port or an I2S microphone, then maps the frequency spectrum directly into vibration envelopes. In practice that means music, speech, or ambient sound becomes something you can physically feel rather than just hear. The accessibility angle, giving the Deaf and Hard-of-Hearing community a real-time tactile window into audio, is exactly the kind of use case this was built for.