Get more out of your Rev A hardware
Delivering an IoT hardware product is expensive and risky. This talk is about how engineers can squeeze more learning from their first prototype to build a successful product.
IoT projects and products fail at a spectacularly high rate; not in the field, but by never making it out of the lab. One of the myriad reasons is time to market. When you have a fixed amount of time to make an idea work and deliver that product to the marketplace, you don’t get a lot of retries. That’s why I gave this talk about how to get the most out of your “Rev A” (first revision of) hardware. It was delivered as [one of the free talks from the Embedded Online Conference (EOC) in 2023][1]. You can view this and many other highly specialized talks on the EOC site. Registration is required for viewing the other free talks and there is a nominal fee to join the site and view the talks from this year and last year.
Balancing Act
Why not “move fast and break things”? Why bother caring about Rev A? Despite reduced costs around hardware thanks to quick turn manufacturing services domestic and abroad, it’s possible to get hardware fast…but there is still a delay between a Rev A and Rev B board. What’s more, the decisions you make in your early hardware prototypes can carry with you throughout the life of a product, and it makes sense to shoot for a best-case scenario when planning and executing your first spin of a prototype. This talk covered three areas of the prototype process.
Before Rev A
The “before” is all about planning, especially across different teams. Hardware designers for IoT products need to make sure they communicate properly with their firmware and cloud teams, in order to maintain good expectations. A written plan about what you’re hoping to get out of the Rev A prototype and how to maximize the testing of that prototype will ensure you don’t waste or duplicate efforts later. Design reviews are a crucial component to allow different teams to voice their needs before manufacturing.
During Rev A
Once your prototype is planned, designed, and manufactured, you need to execute on your testing plan. Your testing methods will help you to understand when a prototype has met or missed goals set during planning. This part of the talk also reviews some testing tools that can help teams get more data from their prototype device.
After Rev A
Once you have thoroughly tested your Rev A prototype, a post-mortem of what went wrong (and right) is crucial. It will ensure you improve your process (for future Rev A prototypes) and also capture all of the needed changes for a Rev B prototype.
Case Study
Golioth does not build and sell finished hardware products. But we do regularly create “Rev A” hardware [when we create different Reference Designs][2]. These are built to help accelerate teams looking to build an end product but wouldn’t mind benefiting from someone else showing how to build the first spin of a design. Our Reference Designs are built on top of a prototyping platform we created that attempts to balance flexibility, a quasi-finished look, and a relatively compact design. None of these categories are super optimized, as that is left up to the user hoping to build a finished product. We’re always looking for new Reference Designs to build to help accelerate engineers’ Rev A prototypes. If you have any requests or need help building out your prototype, [let us know on our forum][2] or [drop us a note][3].
