Launching today
Hardwave
Simulate hardware failures before they cost a respin
4 followers
Simulate hardware failures before they cost a respin
4 followers
Know your motor will overheat, your battery will sag, or your drivetrain won't couple, before you spend weeks and a BOM finding out on the bench. Hardwave lets you compose your actual hardware system in Python and stress-test it in software first. As real bench data comes in, fold it back into the model so every iteration starts smarter than the last one.
Hi everyone! I'm David, the founder of Hardwave.
If you're building hardware, you know this pattern: you size a motor, order the board, assemble everything, flip it on, and find out the drivetrain draws twice the current you budgeted for, or the thermal path you didn't think about is the thing that actually fails. Now you're waiting on another spin, and every week of that wait is runway.
Software engineers don't live with that loop. We have tests, hot reload, and tools that tell us something's wrong in minutes, not after a multi-week board turnaround. I kept wondering why more of that feedback couldn't move earlier, before the BOM, not after it.
That's why I built Hardwave.
Hardwave is an open-source Python framework for composing and simulating full electromechanical systems, not just a circuit or a single subsystem, but the electrical, mechanical, and thermal pieces together as one graph. Getting started is as easy as...
Under the hood, each component (a motor, a driver, a controller, a thermal path) exposes typed ports and its own solver, and you connect them into a simulation graph. That means you can model your actual product, your actuator, your custom mechanism, your power stage, not just generic reference circuits.
As an example: model a battery, an H-bridge, a DC motor, and a PID controller, then simulate how the system responds under load, current draw, voltage sag, control response, before a single part ships to your bench.
Hardwave is early. The standard library today is generic building blocks (motors, drivers, sensors, thermal elements), and the part I'm most excited about long-term is closing the loop with real hardware: once you've got a prototype on the bench, the same graph should let you fold in your measurements and get a model that's sharper for the next iteration, instead of bench data dying in a notebook.
If you're a technical founder or engineer bringing up your own hardware, especially anything with actuation, motors, or a multi-domain system where "it worked in isolation but not together" is a familiar sentence, I'd genuinely love to hear what broke on your last spin and whether this would've helped.
Hardwave is MIT licensed and fully open source.
Website: https://hardwave.dev
GitHub: https://github.com/HardwaveDev/hardwave
I'll be here all day to answer any questions you may have, cheers!
The Python composition approach feels really natural for iterating on hardware designs without burning time on the bench. Curious how it handles more exotic setups like sensor networks or mixed-signal boards.
@edasayakaldf Glad it feels natural
Sensor networks and mixed-signal boards fit the same pattern: model each piece (sensor, analog front-end, MCU, plant) as a Python component and compose them into one system to catch interaction bugs before the next board spin.
We're system level/behavioral, not a SPICE replacement or bit accurate sim, so this shines when the question is "does the whole thing behave correctly together" rather than transistor or timing level detail.
You can also feed telemetry data from your real hardware runs back into the models over time, so accuracy improves with use.
If you've got a specific setup in mind, happy to sketch what the composition would look like.