Lab Notes
Development updates, engineering notes, and design insights.
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