Lab Notes
Development updates, engineering notes, and design insights.
Lab Note #004 — The Bodge Wire That Crossed the Entire Board
Published: June 2026
I built a board without enough test points.
The project has a bunch of addressable LEDs controlled by the MCU. Signals worked great; data line was clean, timing was right, LEDs responded perfectly.
But when I told the MCU to cut power to the LEDs, current kept flowing. Not a little; a lot. I did the math and my battery was only going to last about 5% as long as expected.
It took a while to track down; turns out I'd used a reference circuit incorrectly and never connected the power enable pin on the LED driver. Without test points, narrowing that down meant probing blindly through a dense layout.
The fix: I pulled a pulldown resistor off the board and used its pad to solder a bodge wire to a completely separate test point meant for a different purpose. Rerouted the signal through copper I'd laid down for something else entirely.
It works. Board runs, LEDs shut off properly, battery life is back where it should be. And it's got more character than it had before.
Next revision gets more test points. But this one stays on the bench as a reminder.
— Odderon Lab
Lab Note #003 – Simulating Sensors Instead of Chasing Them
Published: May 2026
A lot of debugging time gets wasted waiting on a sensor that isn’t cooperating.
Sometimes the hardware isn’t mounted yet. Sometimes the engine isn’t running. Sometimes the sensor is buried inside a machine you don’t want to tear apart again just to test one input.
Lately I’ve been experimenting with a small board designed to do the opposite: instead of reading sensors, it emulates them.
The goal is simple — generate predictable outputs that look like real-world sensors so embedded systems can be tested without the actual hardware attached.
Right now the prototype can produce adjustable analog outputs ranging from 3.3 V up to around 12 V, which opens the door to simulating a surprising number of automotive and industrial signals.
What started as a quick internal tool is slowly turning into a broader question: what kinds of sensors would actually be useful to emulate?
Automotive systems alone cover a huge range:
- Pressure sensors
- Throttle position sensors
- Temperature senders
- Fuel level sensors
- MAP / MAF style outputs
- Variable resistance sensors
- 0–5 V analog industrial sensors
There’s also the question of how “real” it should behave.
Should it just output fixed voltages? Should it generate changing waveforms and noisy signals? Should it emulate sensor faults intentionally for diagnostics testing?
Part of me wants to keep it simple and reliable. Another part keeps sketching features that would turn it into a general-purpose automotive development tool.
I suspect there are plenty of niche debugging tools that don’t exist simply because nobody bothered building them.
If you work on ECUs, industrial controls or embedded systems and have thoughts on what sensors are most annoying to test without real hardware attached, I’d genuinely like to hear about it.
This one may end up becoming something larger than originally planned.
— Odderon Lab
Lab Note #002 — Is USB 5V Good Enough?
Published: February 2026
I’m working on something that started as a small circuit and is slowly turning into something more serious.
It runs from USB.
At first, I did what I always do — route VBUS to the 5V rail and move on.
That’s how most dev boards work.
It’s simple.
It usually behaves.
But this build isn’t meant to be “usually fine.”
The more I looked at it, the more I realized USB 5V is really just “close enough.”
Different ports sit at slightly different voltages.
Cables drop a little under load.
Switching relays or driving outputs can nudge the rail just enough to matter.
For quick prototypes, that’s acceptable.
For something that’s supposed to behave like a bench tool — predictable, repeatable — it feels like cutting a corner.
So instead of trusting VBUS directly, I added a current-limited input stage and a buck-boost converter to generate a steady internal rail just under 5V.
It might be overkill.
But I’d rather eliminate variables now than debug strange behavior later and wonder if it was the cable.
Small decisions like this are starting to define whether this stays a prototype — or becomes something more refined.
If you’ve built something similar and have strong opinions about USB power architecture, I’d genuinely like to hear them.
Reach out at odderonlab@protonmail.com.
— Odderon Lab
Lab Note #001 — The Board I Built After Frying Too Many Dev Kits
Published: February 2026
If you prototype long enough, you’ll eventually do it.
Reverse polarity.
Hot-plug a supply.
Grab the wrong wall adapter.
Move a jumper one pin over.
And something quietly dies.
I’ve done it enough times to stop pretending it wouldn’t happen again.
So I built a small inline protection board that lives between my power source and whatever I’m testing.
Nothing fancy. Just:
- MOSFET-based reverse polarity protection
- A TVS diode for transient suppression
- A resettable polyfuse (500mA or ~1.1A versions)
- 3V–24V DC pass-through
It does not regulate voltage.
It won’t save you from intentionally feeding 24V into a 5V board.
But it will absorb the kinds of mistakes that tend to happen when you're moving fast, tired, or swapping supplies mid-debug.
It’s basically a small layer of insurance between you and an avoidable failure.
No firmware.
No measurements.
No blinking LEDs.
Just something that sits there quietly and takes the hit instead of your board.
If that sounds useful, you can find it on our Products page.
More small lab tools coming soon.
— Odderon Lab