I'll be sticking around in the comments so feel free to ask questions. AMA!
What are some examples of good anti-counterfeit strategies? And, if you’re comfortable, which applied for JamCorder?
What I learned selling 2,500 MIDI recorders: Hardware is not so hard
11–20 of 276 posts
Re: What I learned selling 2,500 MIDI recorders: Hardware is not so hard
#12What was your anti-counterfeiting strategy? That sounds interesting.
I'm using an STSAFE chip - the same IC they use in StarLink terminals. Essentially the digital equivalent of a holographic barcode. I have some other protections too. e.g. Random 128-bit per-device IDs / product-keys. iMessage uses this strategy.
Maybe I'll write an article about that.
Re: What I learned selling 2,500 MIDI recorders: Hardware is not so hard
#13What was your anti-counterfeiting strategy? That sounds interesting.
I'm using an STSAFE chip - the same IC they use in StarLink terminals. Essentially the digital equivalent of a holographic barcode. I have some other protections too. e.g. Random 128-bit per-device IDs / product-keys. iMessage uses this strategy. Maybe I'll write an article about that.
Please do, that'd be very interesting. I imagine it's doable to use random per-device I'd when you're hand-flashing, but probably harder on a huge production run.
Re: What I learned selling 2,500 MIDI recorders: Hardware is not so hard
#14How did you navigate the world of compliance testing and certification, with all the different countries involved (FCC, UL, etc). Are there any markets you've decided not to sell to as they're not worth the paperwork?
Re: What I learned selling 2,500 MIDI recorders: Hardware is not so hard
#15Earlier quoted context omitted.
The app is about 85K lines: device connectivity, first-time setup, syncing, MIDI playback and visualization, library management, audio/video export, and OTA workflows. 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…
Yeesh, please tell me you didn't write all of that yourself. Which uC is it targeting, and which language?
From the photo in the link it looks like he's using an esp32-s3.
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.
Re: What I learned selling 2,500 MIDI recorders: Hardware is not so hard
#16How did you navigate the world of compliance testing and certification, with all the different countries involved (FCC, UL, etc). Are there any markets you've decided not to sell to as they're not worth the paperwork?
I chose to do FCC only and CE self-certify. If you use pre-certified radios it's not as expensive as you think. $5K should be plenty if you ask around. Just make sure you design your board so you actually pass, and don't let the labs over-sell you. They'll try to!
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.
Re: What I learned selling 2,500 MIDI recorders: Hardware is not so hard
#17Earlier quoted context omitted.
I'm using an STSAFE chip - the same IC they use in StarLink terminals. Essentially the digital equivalent of a holographic barcode. I have some other protections too. e.g. Random 128-bit per-device IDs / product-keys. iMessage uses this strategy. Maybe I'll write an article about that.
Please do, that'd be very interesting. I imagine it's doable to use random per-device I'd when you're hand-flashing, but probably harder on a huge production run.
Almost all commercial devices need a unique ID, private key, etc burned in on the production line. For a big enough production run, you'd likely ship an HSM to the factory
Re: What I learned selling 2,500 MIDI recorders: Hardware is not so hard
#18What was your anti-counterfeiting strategy? That sounds interesting.
I'm using an STSAFE chip - the same IC they use in StarLink terminals. Essentially the digital equivalent of a holographic barcode. I have some other protections too. e.g. Random 128-bit per-device IDs / product-keys. iMessage uses this strategy. Maybe I'll write an article about that.
Sounds like that'll be a great read.
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.
Re: What I learned selling 2,500 MIDI recorders: Hardware is not so hard
#19Earlier quoted context omitted.
Yeesh, please tell me you didn't write all of that yourself. Which uC is it targeting, and which language?
From the photo in the link it looks like he's using an esp32-s3. 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.
These numbers do not include ESP-IDF :)
Re: What I learned selling 2,500 MIDI recorders: Hardware is not so hard
#20It's a poor take to be honest.
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.