Maybe I'll write an article about that.
99.99% of cheap Chinese products you buy on Amazon don't actually have this testing done at all. So by doing any testing you're already way above them.
CE is all about self certification. The lab testing gives you the confidence to do this.
It can be expensive - but Chinese test labs are very affordable and do a really professional job.
There is now quite a good EU based service - https://early.smander.com/ I used them to get some advice early on (disclaimer, I know the founder).
Yeah, but those Chinese dropshippers don't have significant local presence. If they are caught doing shady stuff they'll just let their $100 letterbox company go bankrupt and start over.
You, on the other hand, would actually have to pay whatever fines some regulator charges you with, because you are physically present in a jurisdiction they can apply power to. This makes self-certification a bit of a footgun: you essentially pinky promise that you fully understood all the relevant rules and regulations, and otherwise pay what in the worst case might be a hundred-thousand-euro fine. Quite a bit of a gamble!
The main saving grace is of course that the authorities are way too busy to investigate some random guy selling a handful of devices from his kitchen. But get too successful, and some competitor might just decide to give them a little hint on exactly what part you missed because you didn't even know you had to comply with it.
I'm an EE with main expertise in IC design but I design a lot of the chip packages, PCBs, mechanical stuff like custom made sockets etc and write a ton of SW, be it tools for myself for development and testing, be it the firmware of the chip I'm designing or another chip I use on the board. For me it never felt like SW was the hard bit, because you can write and test it pretty immediately and pretty much for free. HW felt harder because of the tooling costs, lack of documentation and examples, things that aren't obvious at the beginning (EMI/EMC) etc etc but these are very minor compared to the actual issue: long and expensive development cycles. Now, that doesn't apply if your HW is extremely simple and just a glorified uC and rhe development time is mostly the code running on it. This is why this is such a poor take. One can argue for anything at extremes. SW can be very very complex and much harder than HW, and vice versa at different extremes.
Any tips on how or where I could get my design reviewed?
I did this as an experiment on my current project and it found a bunch of minor, non-critical, but completely valid problems with my deisgn.
At the same time, it doesn't take much time at all, and is a good excuse to get out of the house!
What understanding about hardware did you start with, and what tools did you use to learn what you didn’t already know?
Electronics, PCBs, CAD, injection molding was all new to me.
https://www.izcorp.com/wp-content/uploads/pm_Pocket-Record.j...
Never understood this, was the "most of the fun of programming" the literal typing for you? For me it was about solving problems and building things, and I get to do that more now than before, and without all the literal typing.
Sounds like a story. What parts of it can you share?
>>> The hardest part of building Jamcorder was still, by far, the software -- roughly 200K lines of code spread across the firmware, app, and manufacturing tooling. It took over 3 years and many long nights in a pre-LLM world.
>>> When compared to that, the hardware was undeniably smooth sailing.
>>> For the record, I don’t think I’m special. It’s just that hardware’s reputation for being difficult is, IMO, overstated.
For me, when I complain about hardware, its actually usually complaining about drivers, compatibility, underdocumented interfaces, firmware etc. If one were to put firmware and manufacturing tooling in a separate bucket, that is indeed the problem!
It's rare that I come across a product I have literally zero complaints about, or any feedback to offer. Even my concern that it was tied to an app that might disappear one day is of course covered by the fact that it's all just MIDI files on a card.
Thank you so much for making this, it's basically a perfect product for me and I love it. No notes.
If I ever get good at piano it'll be handy
Also, pretty cool that you set up your website real fast. Would you mind adding your Twitter link onto the site?
If there are no more app updates, presumably there are no more firmware updates either, so the flashing part probably doesn’t matter (and you can probably flash the last published image to an authentic device by other ESP32-y means if you really need to).
As to the day-to-day: Pretty sure the hardware still records regular ol’ MIDI files to the SD card. The app seems incredibly well-thought-out and ergonomic but, at the end of the day, nonessential to the device’s core function.
Somebody could presumably build and sell their own “MIDI Recorder Loop Nonstop Device Digital Piano Upgraded New 100%,” but it wouldn't be a Jamcorder, you couldn’t flash Jamcorder firmware updates to it just by slapping an ESP32 in a case, and the official Jamcorder companion app would not talk to it. Which… fair enough, right?
For that matter it wouldn’t surprise me if somebody could write their own client for the real Jamcorder, if they felt so inclined… but with the official stack so absolutely perfect from a design perspective, why would they?
That doesn't mean it is completely impossible, though. Fab2 (formerly Atomic Semi, of Jim Keller and Sam Zeloof fame) is trying to do exactly this by aiming at making small-scale production affordable. The trick is to replace the whole mask-based lithography with electron beam scanning: way slower, but no mask costs.
But they are now targeting selling mini-fabs to R&D labs rather than offering an affordable ASIC-as-a-Service. Let's hope one of their customers makes it available to the public!
(Although I spy an SD card slot, a favorite of the "hardware isn't hard" faction that will explode in their face)
This feels though a little to me like building a simple SaaS service, and deploying it on a managed cloud service, and concluding all software is really easy!
This project is near to (if not at) the easy end of the hardware product difficulty/complexity spectrum. Some great choices were made to keep it simple and therefor easy.
An alternate take-away: "If you keep things simple, hardware doesn't have to be as hard"
It is mentioned elsewhere here that a lot of time was burned on unused firmware features. It takes surprising discipline to cut stuff and still deliver.
Congrats though, making a half-million a year business is a massive accomplishment! The headline just irked me a bit, haha (but, it got my attention, so I guess you win there)
Here's a good example: https://duckduckgo.com/?q=brick+smartphone+blocker&ia=web
Why custom MIDI connectors of all things? What requirement couldn’t be met off the shelf?
What is this strategy? You're building this in China, it's already over.
These niche hobby products are usually reasonably safe because they rely on community network effects, becoming the darling of a random subreddit or discord group and people aren't going to save $20 to get some device of dubious origin.
Would love to talk to you more about hardware supply chain issues and challenges.
Meanwhile if anyone is tired of their smart TV being a spyware or showing ads, I would love to talk to you. This is what I am building: https://soljacast.com
And let's not forget that. And let's not just follow the headline.
Greetings from a hardware engineer with decades of experience building hard things.
Would like to see this highly non-obvious point expanded upon.
Are you still below any significant scale thresholds and are there any you dread crossing?
I ask this because I tend to find things are simple until they are not. e.g. it's easy to write an e-commerce platform until you have to deal with shipping, duty, tax, tax on shipping, etc., for multiple countries.
There are scale thresholds I am aware of in hardware that I have not yet run up against. For example I am using Free software, but I am aware that with commercial CAD you can cross over price tier thresholds. Or for another example there are sales quantities where with electronics you might end up needing compliance testing, consumer safety testing etc.
Which ones haven't you crossed yet that you expect to have to navigate?
You hear about firms that go over certain thresholds, get noticed and then find out that their production facility is no longer "small" or exempt for example.
Some amount of defensiveness in planning and design can mitigate but I'm interested to know if there are thresholds I didn't know about.
Complexity-wise this is probably the easiest board one could imagine. It's an off-the-shelf MCU module, a 1:1 copy of the MIDI circuit from the specification, and some ports wired straight to the MCU. Throw in a trivial I2C-connected RTC and HSM for good measure. You could probably design this in an afternoon. But indeed: that is a good thing. Not everything has to be complicated, and plenty of people are willing to pay for simple products.
On the other hand: what is the cost for that?
The USB-A Host port has ESD protection, but as far as I can tell MIDI Out and SD do not. Sooner or later this will result in some static-prone user frying their expensive board. Have you got a proper Customer Support / aftersales pipeline yet? How many units did you reserve for warranty replacement? Luckily you've got a huge margin, so a few replacement boards shouldn't bankrupt you.
Similarly, the MIDI ports seem to be using low-double-digit series resistors for the MIDI Out current loop - in 0402 form factor. As the spec says: short the port and they'll draw over 0.5W, which a 0402 can't dissipate. To be fair, the exact circuitry is a bit hard to tell from the image, but will this mean they'll catch fire?
The AMS1117 is also an interesting choice. It's a classic option so it is often seen in beginner tutorials, but it is absolutely terrible[0], and with the capacitors used you shouldn't be surprised to eventually run into stability issues. It might work Just Fine for 99% of units, but the 1% will have weird undiagnosable heisenbug issues.
From a UX perspective I'd also question the use of a coin cell battery for the RTC: it'll eventually run dry or even start leaking. A supercap would've been a more durable and convenient option - especially considering the "always leave it plugged in and forget it" use case. Or, if you need a battery anyways: go for li-ion so it can be used on-the-go. Similarly: USB-B for Power In in 2026? That's just lazy. USB-C is trivial to add with a 5-minute-guide and would've been cheaper. The USB-A Host port is just about excusable, though: doing that in USB-C is a bit harder. And the Power In port not being usable for a connection to a host PC and telling people to buy some sketchy adapter on Amazon? Understandable considering the MCUs peripherals, but a disappointment.
And then there's the elephant in the room: certification. It seems like you just... didn't? Which is understandable for a small hobby project! But making it EMI/EMC compliant is by far the hardest part of designing market-ready products. You can't just completely ignore all the stuff involved in making it compliant with FCC/CE/UKCA/whatever rules and call it "not so hard". It's the difference between baking a pie for your birthday party, and opening a bakery.
Your hardware project wasn't hard because you've only done the easy stuff. And kudos for shipping - many people don't make it even remotely this far. Especially using an injection-molded housing is quite the achievement! The startup costs for that make it a real showstopper for many small-scale projects, and making mistakes can easily bankrupt you.
But this is where the actual adventure starts: scaling it to 25k / 250k units. You basically have to start from scratch and do 10x as much work. Meanwhile, China is pumping out $10 clones for your $250 recorder. Sure, you put DRM in it, but is your software moat really wide enough to protect you?
Many congratulations on your achievement, but please understand that writing this blog post is almost naively premature. The hard part hasn't even started yet.
[0]: https://www.reddit.com/r/esp32/comments/1m7ne4i/psa_avoid_us...
But for providing power over USB-C, you generally need a dedicated IC to handle VBUS switching. It wasn't worth it.
Also, once you ship a consumer product with a USB port on it, you'll realize a lot of people really don't understand how USB works, and USB-C doubly so. Square holes for square pegs goes a long way.
I'm curious to hear more about your anti-counterfeit strategies beyond just enabling encryption. I'm curious if you feel like anti-counterfeit and open source firmware are mutually exclusive. I made the choice to embrace an open firmware approach on my project while keeping the hardware closed, while knowing that if someone tries hard enough they can completely reverse engineer if they put their mind to it. Desoldering caps and x-raying PCB layers etc.
I'm also very curious to hear more about your adventure in injection molding. What starting resources do you recommend, how much did it cost? Would you do it the same way today, or have the recent innovations in 3D printing forms for injection molding present superior paths?
Finally, I'd love to hear about your certification process. What certs did you get, how much did it cost, what were the gotchas?
When I want to record for real, I'm going to use my DAW. But I want a way to quickly record tracks and this looks pretty great.
Another complication is that at least in theory, if you're selling electronics, there are actual regulations and third-party testing that needs to happen, and if you fail emissions, you might have to redo your design from scratch. Imagine we had that for software - "your JS is too big, you can't ship until you get it under 50 kB".
So, I'm happy for the author, but I think he had an outlier experience. When you look at Kickstarter stories, people repeatedly stumble over this. Manufacturing / cost difficulties, supplier issues, reliability issues, etc.
Has that happened to you?
At this point I have the only stock of this part in the world, and it's more than a lifetime supply, but otherwise I'd have been faced with a re-design and limited options.
For another of my products, during the pandemic, the part I was using became unavailable, and I had to re-design my board to accommodate a part of the same type in a different package. Then I couldn't buy either part, but found an odd lot at a Texas Instruments factory in China, which I bought.
Dealing with shortage and obsolescence issues is a constant battle. There have been crises in the industry caused by plants catching on fire.
Would love to hear more on that but I suppose the omission is not an accident.
Just that hardware equivalent of 200K of lines of code would take far, far more time and resources and with way longer debug cycle, especially when you hit the complexity point where bodging few wires to fix the prototype gets harder and harder.
That's what people mean when they say hardware is hard - if you need to start iterating on a board and not just board's software it gets complex and expensive really quick
But it is far better than it was before - I got my 5 board prototype of similar complexity (also esp32 based) within a week, assembled board, for like $100 (and it was my design mistakes that made it so expensive, like picking screw connectors in places that could totally use far cheaper generic part JLCPCB had in stock, i just didn't know any better), just a decade ago that would probably be order of magnitude more expensive.
So yeah, for those that always wanted to build a hardware project, it's probably best time in the history to do that. Both PCBA and mechanical part got cheap and commoditized enough.
It’s actually not hard to hack this together as a .net application and run it on a laptop, but I suspect your target market has a bit of money to spend.
Learning piano is already largely an upper middle class active and after that what’s another 200$ or 300$.
A higher end digital piano is easily over 2k.
Making sure your target market has money is the key take away.
Not sure if this is in scope, but I’d love an easy way for the community to share midi files. I can somewhat do very basic piano progressions, but I still can’t play well.
I’d be grateful if someone would share midi files for me to plugin to my music software. Of course I’d provide full credit
I was originally planning to do 4000 units as my first run. Boy I'm glad I started to run out of money and cut it way back. That would have been way too much as a first run.
There was another post, a year or two ago, about someone that really tried to manufacture a webcam, and gave up.
I spent my career at hardware companies.
Glad this worked out, but past performance is no guarantee of future success...
Is it just me, or is there some kind of unusual photo editing going on in the photo at the bottom of the article? Something looks uncanny valley, related to the bottom of the box on the left side of the photo, and related to the background. Did some kind of "erase background" mechanism go wrong here?
I dislike this statement. Hardware is as hard as the product dictates it needs to be. A 25 component PCBA and a clamshell of 2 injection molded parts is about as simple of a product as you can make. Heck, most people would just buy an off the shelf clamshell for that type of product.
That doesn't work for the vast majority of products, building a product with 20 COTS parts plus 60 custom tooled parts, and 4 complex PCBAs is what is hard. Getting everything to fit together, pass testing, arrive on time from dozens of suppliers, etc. it where the complexity comes in. Then consider that hardware is cash intensive, you need to pay ahead of time for all the tools, you need to pay to buy the individual parts and warehouse them somewhere while you build the products you hope are going to sell. If something goes wrong there, then your expensive parts are just sitting there waiting for replacement components before you can ship. Then even when you ship, that revenue goes into buying the next round of parts you are going to receive in 3 months. This is where many hardware projects fail as they run out of cash before the project breaks even.
Oh, if that’s how you build hardware then sure, hardware isn’t hard to do at all.
I figure that the factory is exactly the adversary in the whole threat model? So why give them the keys to the castle so they can moonlight their own genuine batch?
You probably aren't going to do this whole rigmarole for small runs of devices like in the OP.
Serious question: why?
A local-only device with no telemetry can probably skip some of those
This is (literally) none of my business, but would you consider a cut down or basic open source version (hardware and software, with open software running in the proper hardware). Yes it'll be cloned by factories, and yes it will cut into sales no matter what proponents claim. (And yes it's probably more work than I imagine it is).
But also yes, it'll be genuine open hardware and might out live your interest in the project.
If you want a Free work-alike, why don't /you/ put in the work and make it happen?
[1] https://www.kicad.org/community/chat/ [2] https://www.reddit.com/r/PrintedCircuitBoard/
LLMs move me away from the implementation, which is more a managerial role, something I personally have zero interest in.
I'm sorry if I gave the impression I think programming is just typing. For me "programming" is the whole activity of creating software with code, you can do programming without the literal action of typing.
> Writing the code and thinking about the exact logic you want to apply and all its implications are part of the same problem solving process in my mind.
That's really interesting perspective to me, as these two activities for me are two completely things, and "thinking about the exact logic" happens way before I actually write any code at all, sometimes weeks/months even.
> putting things together in code is a very satisfying and IMHO is the actual building part of the job.
I agree that it's satisfying, but I guess "putting things together in code" still for me is more about being able to mash two concepts together in an elegant way, and none of that actually requires actual typing still.
> LLMs move me away from the implementation, which is more a managerial role, something I personally have zero interest in.
This is also interesting, because it feels like LLMs give me the opportunity to do more implementation, and not get stuck in the minutia so much, but rather focus on how the design and architecture actually fits together. Refactoring no longer is "I want to but also I don't want to spend the time nor get stuck in more rabbit-holes", so being able to focus on architecture/design more feels like it lets me care more about the implementation than before.
Maybe they just like doing it the old fashioned way. You can both exist.
Unless you’re getting a commission to sell LLMs to people I struggle to understand what you’re trying to achieve.
In the past when my junior engineers were fighting with a bug all week, I always told them the dopamine hit of solving the bug is what keeps you coming back to work for 20 years. Half joking, but the dopamine hit of from the satisfaction getting complex working software in a weekend is like crack to me, we'll see how that plays out long term :)
With code, I'm not planning everything down to the finest detail before I start writing. I know what I ultimately want my code to do but there are many unknowns I hadn't considered. Coding with an LLM is different depending on how you use it. When I'm using code completion, that's usually just helping me prevent syntax errors or to write an efficient snippet of code without having to check docs. But when I tell Claude "I want a web app that does xyz" and it creates it whole-cloth, that takes away the challenge of learning something new and building. I'm not a web developer and anything I could create is going to take me a long time to make (and it probably won't work well or look good) but Claude cranks it out with ease. I get to play software project manager and let the expert do the technical work. It's kinda fun being able to quickly get resulrs. Rather than debugging individual lines of code and thinking about the best way to implement code, I get to test features and think about better ways for the overall system to operate.
Beyond the typing though, I find enjoyment in perfecting the structure of the code, thinking deeply about how the pieces fit together. I enjoy the process of iteratively refining the code so that it clearly represents the program using the optimal level of abstraction and minimizes superfluous code/syntax. I find that using an LLM eliminates all of this and produces code that lacks all of the elegance and readability that I aspire to in my own code.
Your take is so reductionist it's hard to believe you actually like to solve problems.
The problem at least I have is... when something goes wrong, often enough even you as the original author / LLM slave-driver have no idea what is going on where, and completely forget trying to dig into someone else's pile of vibe-coded garbage. For every single problem you now are completely beholden to the AI agent.
Some people fall to that temptation instead of using LLM to just do the menial stuff and do the fun stuff themselves.
It's more the opposite. The app requires a genuine device.
The value you have created is actually more in the App than in the hardware.
As a maker of small devices (mostly open source) including MIDI - and putting aside commercial aspects like injection molding - I could recreate the hardware side of this project without much issue. The necessary components are likely already in this room with me. (I won't - I'm not in the business of copying things that people don't want copied)
But I'm not a software engineer, and therefore could not produce software of the scope and quality that you have, which is where the unique functionality of your device sits high above the relatively simple "receive MIDI data from MIDI devices" principle of the hardware by itself.
I think there's a lot of people talking past each other here. Sourcing parts internationally, preventing counterfeiting, slow iteration time, inventory management...all this logistical stuff is hard enough that the conventional wisdom in the software business world is to never attempt it. You're here presenting a counterexample and that's wonderful. The people criticizing aren't talking about this though, they are talking about whether logging digital inputs on an esp32 counts as a real hardware project and they act as if you've insulted their expertise in [signal processing/antenna design/insert specialty here]. You didn't do that, most of us know you didn't do that, but the word "easy" sets a lot of engineers off.
Just ignore the noise and keep writing great articles. My personal request, if I may - I'd like to hear how you did injection molding since I always assumed that was out of reach for small business.
And they’ll make the molds in China anyway. Chinese molders are hungry — they will work with low volumes and offer a bunch of integrated services. But if you don’t know what you’re doing you will end up with bad parts over schedule.
Easiest way to get started is to use ProtoLabs. They charge lower prices on molds in exchange for higher part cost, are way faster than China, and have way better customer service.
First, so far, there have been 0 failures in the field. My email address is on the website, the app, and the first page of the instruction sheet, so I'd probably know if there were.
But since it's fun, I'll address some of these :) I'm not flying by the seat of my pants here as much as you expect.
- The ESP32-S3 includes ±2 kV ESD, which is respectable. Adding more is a bit precautionary IMO, but I did add it in some places where the user is more likely to touch metal (like the USB ports). The sdcard's metal housing is not exposed.
- The AMS1117 is just more available than the alternatives. Again, no failures yet so seems like the right tradeoff was made here.
- Supercaps don't last long enough for my liking. A CR2032 can go for 10+ years. A supercap, only weeks. I want correct dates even if the device is left unpowered for months.
- The 0603 47ohm resistor is a good callout. Worth beefing that up. But at 3.3v and 232 mW it's not a fire hazard. It will fail open.
- USB-B for power was very intentional. It's a great firm connector and more importantly prevents users from plugging it into their piano wrong. Many of my customers are in their 70s or older.
- USB-A for data was made for manufacturing simplicity, but again, USB-C is too complicated for many of my users. I'd only switch to USB-C if both ports could be used interchangeably, but they can't be / it's not worth the complexity.
- As for the software moat, time will tell. You can't stave off competition forever!
- The device is FCC and CE compliant.
Again, I actually do appreciate your critiques!
https://www.simonberens.com/p/lessons-learned-shipping-500-u...
... But also that needs to be an official measurement, and if you're sloppy you can measure it wrong during your own testing and then be surprised.
yeah, and looking at their board I see they use one of "ESP32-WROOM" modules, which has the wifi & blutooth & antennae (pre-certified by Espressif for FCC, CE so itself doesn't need testing) & flash & processor (which even has its own RC oscillator), which takes care of a whole ton of difficult stuff so all the designer needs to do is plop that module down and power it up and wire some SPI/I2C peripherals which I'm guessing don't need super fast clocks or electrical constraints. Without something like those ESP32 modules, this would be much more difficult.
I don't disagree. It's important for us to recognize that we stand on the shoulders of giants, but I also think it's a little silly of a critique of someone happy about it being easier than he expected. It's true that hardware would be much harder if you had to do it all yourself, but is that meaningful? The wonders if the modern supply chain is that you don't need to do it all yourself.
Not only that but every single update you push requires paying $$$$$ to get certified. It is freeing that the cost of releasing a fix or improvement to a product is $0.
In the past I considered selling a custom adapter to hobbyists, but all the certification costs just did not make it a viable option to pursue. I didn't want to up front thousands of dollars to make like $100 if I was lucky.
chipweinberger•10h ago
rwmj•9h ago
chipweinberger•9h ago
The firmware is about 110K lines: MIDI recording + streaming, USB, Bluetooth, Wi-Fi, web APIs, storage, OTA updates, diagnostics, security, peripherals, provisioning, and an embedded web interface.
There’s a lot required to make a full-featured product.
lukeweston1234•8h ago
junon•8h ago
cazum•8h ago
I suspect that 110k number might include the ESP-IDF libraries as well as his own code.
I've written a fairly feature-complete handheld device based on the esp32-s2 and the codebase is about 9k sloc of the C I've written, but that number explodes to almost 40k sloc if I include the esp-idf's imported libraries.
chipweinberger•8h ago
bonzini•7h ago
chipweinberger•7h ago
Nearly every component gets tested: sdcard, clock, battery, anti-counterfeit IC, led, buzzer, the tactile-switch!
hasbot•8h ago
chipweinberger•8h ago
shizcakes•8h ago
etrautmann•7h ago
discordance•8h ago
How did you find customers?
How did you get your hardware design verified?
msandford•7h ago
iamflimflam1•7h ago
logifail•7h ago
chipweinberger•7h ago
lifeisstillgood•7h ago
Can you expand? What counterfeits do you see (literally someone selling boxes labelled jamcorder? How do you handle that? Lots of scanning amazon and sending cease desist letter?
raphman•7h ago
But why do you spell MIDI in lowercase there?
> plugs into your piano via midi
chipweinberger•5h ago
The real answer: I got tired of deciding what should and shouldn't be capitalized. Sounds easy but it gets ambiguous fast.
I'll revisit this decision at some point. Capital letters do make reading easier.