DEV Community: Kevin Sidwar

Building an IoT Product: The Hard Parts 4 (Enclosures)

Kevin Sidwar — Thu, 02 Apr 2020 02:00:53 +0000

This series is meant to give a deeper look into the challenges you are likely to encounter if you decide to turn a maker project into an actual Internet of Things product. It's based on my experience over the past two years of creating a product from scratch. If you missed parts 1-3 you can find them at the following links.

One of the things I never saw coming while creating my product was the bankrupting cost of creating an enclosure. It's not something you usually bother with on maker projects. In fact, you love that your device is open air, on a breadboard, with wires everywhere. I mean, it looks super cool and techy like that. On a rare occasion you'll 3D print an enclosure that somebody else designed for something like that Raspberry Pi you bought. Now that you're serious about making a product though you need an enclosure of your own. Let's talk about it.

Buy a 3D Printer (Or Find a Friend With One)

It's almost certain your product will be on a custom PCB that you created back in part 1. It's one of a kind and unless you designed it to fit in an off-the-shelf enclosure you're going to need a custom enclosure designed specifically for your product. You can try this yourself but unless you really know what you are doing I'd recommend against it for reasons we'll get into in a minute. So be prepared to spend money right out of the gate on an enclosure design. Having a 3D printer to test designs and create a quick feedback loop with the designer is super valuable. If the couple hundred dollar price tag of a 3D printer scares you then it's time to press the abort button because we're just getting started. A 3D printer will give you a very quick way to test different enclosure designs. It will ultimately save you money because ordering 3D printed enclosures is going to cost about $20-$50 a pop. Just a few runs and the printer pays for itself.

Design for Manufacture

If you've never heard the term "Design for Manufacture" or DFM then you definitely need someone else to design your enclosure. DFM is a common term that you will hear in many aspects of creating an electronics product. The basic premise is not only whether your enclosure is possible but whether it will be possible to produce in high volume and at what cost. Just because you can get your (or your friend's) 3D printer to print it doesn't mean you're ready to have molds made up and begin production. You need to know about standard wall thicknesses and how to size screw holes for screws that are readily available in large quantities. How is your enclosure going to seal? Can it be glued shut? Who is going to glue it and with what? Does it need to be water resistant? All things you need to have answers for.

What's a Gate/Ejector Layout?

For my product I had the enclosure designed by a pro. Because I still wanted to be involved in the process I personally submitted the order for the injection mold. After the mold house took my $3400 I received an email with the following.

Your order confirmation and the proposed gate and ejector layout for your part are detailed in the link below. The yellow cylinders represent the ejector pins, and the yellow and red rectangle shows the location of the gate.

Please approve this layout by clicking on "Approve Layout" or identify any issues by replying to this email.

Here are the images that accompanied the email:

So, what do you think? Should I approve it? Do you understand the physics of how molten plastic will flow when injected into a mold and how pushing on certain parts of your enclosure during ejection can affect it? This was all completely new territory to me. I didn't know the answer to this question. I didn't even know what a gate or ejector pins were. Luckily I had access to the company that designed it. When you are asked for a go/no-go decision on a $3400 dollar mold purchase you better have the right answer the first time. Mistakes will sink you.

Injection Molding Costs Will Make You Cry

If the price of this journey hasn't scared you off yet it may be about to. Enclosure molds are expensive. Really really really expensive. My product enclosure had two parts. I only ordered a plastic injection mold for half of it because the other half was concealed in an outer enclosure so it didn't need a polished plastic finish. For just half of my 1.75" x 2.00" enclosure I paid $3400 for the mold and then $2.48 for each enclosure half created from the mold.

Why didn't I get a mold for the bottom?. Well, good question. The answer is simple, I was running out of money and it was cheaper to have the first pilot run 3D printed for the bottom. The bottom mold would have cost an additional $4000 and close to the same cost per unit. For my pilot run I only needed 110 enclosures and the cost to 3D print the bottom of the enclosure came out to just under $1500. That's a BIG difference. So, wait, why didn't I just 3D print the top of the enclosure as well? Another great question. I needed the top of the enclosure to have a specific polished plastic look (Black ABS with an SPI-C1 finish to be exact). It's not possible to obtain that finish with a 3D printed part.

But the mold is a one time cost. After that you just pay the two fifty for each part right? Well, not really as it turns out. Depending on who you use for your molds you are likely going to pay a mold retrieval or setup cost each time you order more runs. For me that turns out to be $500 per order just for them to pull the mold off the shelf and set it up for another run. It's a real gut punch and frankly not something they made clear up front. So make sure you ask this question of any company you are looking to use for mold creation. I also learned that while the mold is technically mine because I paid for it, you can't really BYOM (bring your own mold) if you decide you want to change injection molding outfits. For a nominal fee ($500 + shipping) they will send you the mold you paid for. You will then be told by every other injection molding company that they will not use it and that if you want to work with them they will have to make their own molds for you. You know, because the processes are...different.

Navigate this part of the process carefully and shop around. Look for companies that are willing to work with you. This is an area where I definitely pulled the trigger too early and paid dearly for it. Don't make the same mistake.

Summary

I was floored when I learned about the cost of injection molding. Make absolutely sure that your enclosure design is finalized before paying for molds. Once you have molds there is no going back or tweaking. If you want to change something you have to pay the piper again. This is where that $300 3D printer pays for itself over and over again. Use it.

This part of making a product is one that can be a show stopper solely because of the price tag. There just aren't a lot of options for saving money here. As always, it helps to know this is coming and you can plan for it appropriately. Maybe you start by printing your own enclosures to get some revenue coming in to fund molds. If you're an incredible negotiator or you have a large volume order you might be able to work a deal out with the mold company. Most likely you aren't even big enough yet to have them return your calls for quotes. I'm not talking from experience or anything. 😞

Wrapping Up The Series

That's going to do it for our series. I want to reiterate that the items covered in this series do not constitute a comprehensive list at all. There are many land mines I encountered on the road to having a shippable product that I haven't covered. That's not meant to scare you off but to help calibrate your expectations and emotions. The quick victories of being a weekend maker are great at clouding our view of what really lies ahead when you take the product plunge. This leads to people giving up because those wins are few and far between the further you get into the journey. I think that's why a lot of people give up. I don't want you to give up. I want you to have the right expectations so that when these things arise you can be prepared to face them and know that they are part of the journey.

It's absolutely possible to turn a maker idea into a product. I'm living proof of that. It's very rewarding and it's easier and cheaper than it's ever been. But it's still an enormous amount of work and takes a lot of determination, time and money. If you have the right expectations going into the process you'll have a much better chance of seeing it through to the end and succeeding.

I would love to connect with anyone else out there that's on a similar journey or thinking of starting their own. Reach out to me anytime in the comments or via the social media links in my profile.

Building an IoT Product: The Hard Parts 3 (Connectivity)

Kevin Sidwar — Wed, 18 Mar 2020 14:58:13 +0000

Last time we talked about how even in your wheelhouse of writing code you are likely to encounter issues that cost you time and money. In this edition we're going to talk about the chicken and egg problem of connecting a piece of hardware to the internet. After all, this is an Internet of Things thing. This is also where you have to start interacting with people...a lot.

Connect to the Network to...Connect to the Network

Your customer just opened their new, fancy IoT product. The packaging is beautiful and the Thank You card makes them feel even better about the decision to buy from you. One of the very first things they need to do is get your product connected to the internet. For the purpose of this article we are going to assume WiFi as that is currently the most common connection option for consumer IoT devices. It's also the one with which I have practical experience. In order for the device to connect to the user's WiFi it needs some credential information. Back in MakerLand you probably didn't have to worry about this process at all. I've seen LOTS of code samples where there are simply some constant variables or #defines for SSID and password information. Unless you want to ask each customer for that information at checkout and then compile separate binaries for each of them you're going to need a better way. The two most common ways are SoftAP or using a serial connection over USB.

SoftAP is Hard

SoftAP stands for "software enabled access point" and is a common feature in many hardware platforms. When in SoftAP mode your device establishes its own SSID and acts as an access point to which other devices can connect. The process normally looks like this:

User turns on your device. It will enter SoftAP mode by default out of the box.
On a different WiFi-enabled device(phone, tablet, pc) the user opens the connection settings (you'd be shocked at how many people don't know how to do this).
In the list of nearby WiFi networks they choose your product's special SSID it is broadcasting.
The user device connects to your product's SoftAP.
Magic happens(more on this below).
You get the user's home network SSID and password.
Miracles occur(yep, you guessed it, more on this below).
Your device is connected to the internet and working as intended.

After the user connects to the SoftAP of your device they have to communicate with it somehow. This is usually in the form of an app or web page. An app or web page that you have to write and maintain. If you aren't a front end or app developer it's time to open your wallet again for another freelancer payment. This is the very first interaction customers will have with your product. It's not a place to cut corners. It can literally mean the difference between them loving your product or asking for a refund because the process is clunky. This interface has to handle all sorts of scenarios. What happens if the user fat-fingers their password. Your device will simply not connect and hopefully give you a valid error code. What should your device do in that scenario? What should your setup UI do in that scenario? There are lots of things to consider and handle here that you never spent a second thinking about when this was all just a maker project.

But your users never fat-finger anything and they enter their password perfectly. You have the correct SSID and the correct password. All we have to do is send it to the device. Done. But it's still not working. WHY ISN'T IT WORKING 🤬!!! The magic of it all starts to break down and you are forced to face the reality that all of this is very complicated and high tech. We are sending letters of the alphabet and numbers through the air to a device which then sends more stuff through the air to another device which then has to respond back. It really is magical when you think about it but wow can a lot of things go wrong. When you consider the number of settings that exist between the 3 devices involved in this process (your product, the configuring device, and the WiFi router) there are literally hundreds of millions of possible configurations. Most of the time things just work but when they don't, that's the problem field you are staring into.

Terminal?!? This Ain't the Airport

The other common way to configure your device with WiFi credentials is over a USB connection. This is pretty common in maker projects. One thing to be aware of though is that many of your customers will not even own a device with a regular USB 2.0 or 3.0 port. They have iPads or phones so this approach is not even an option for them. But suppose you do have some customers with USB-capable devices, how are they going to get their WiFi credentials to your product over that interface? Well, when it was a maker project you would crack open a terminal window and do your hacker thing and, viola!, connected to the network. I can promise you that is not going to work in over 90% of your customer scenarios. To them a terminal is something at an airport. So, if you want to use this approach you're going to need some form of application running that is dead simple and handles all of the serial connectivity. The user should launch an app, enter the username and password and hit "Connect". Now you just signed up to write and maintain another cross platform application.

Customers Aren't Developers

This is a blind spot of so many software developers. We are so intimately connected with technology that we forget all of this is complete black magic to most people. They have absolutely NO idea how any of this stuff works. Radio waves, gigahertz, tcp packets, and HTTP headers. It's all Greek to them. And it should be. The entire purpose of our job is to abstract those things away so they can use software and devices that make their lives easier. Just like you don't have to know the details of the CAN protocol to drive your car, your customers shouldn't have to understand the difference between WiFi channel 6 and 11.

If you have never had the pleasure of trying to walk a completely non-technical customer through the process of connecting to a device via putty or screen I highly recommend it. It's a very...educational...experience. You will get a lot of feedback around things that seem so obvious to you that are complete mysteries or giant mental leaps for your customers. Remember, they aren't developers.

The last thing to remember about your customers not being developers is that they are unlikely to RTFM (read the freakin' manual). You'll put an instruction card right on top of the box with beautifully illustrated steps on how to set things up. They will still send you emails asking questions that are clearly and eloquently explained in step 5. There is nothing you can do about this other than be prepared. It's human nature and you signed up to deal with it when you decided to turn this thing into a product.

You Can't Test All Scenarios

As I mentioned above the number of configuration permutations that exist for your device to handle is astounding just to get connected to WiFi. Did you know that some routers shipped to the US broadcast on a non-standard US WiFi channel by default? Did you know that your main WiFi chip doesn't support every standard WiFi channel? What happens when somebody has WiFi repeaters set up and your device gets placed right in the gray cross section zone in the house where the signal is really not great to either of them? What do you mean you don't have an Actiontec router that was configured by my super-smart nephew 5 years ago when he was just learning all about computers?

You can't test every scenario and thus you are bound to find some crazy ones. They'll find you actually. They'll find you in the form of "My device is not connecting to the WiFi, please help." Emails like that mean you're in for a fun adventure of learning about somebody's jacked up home network configuration.

Wrapping Up

When it comes to getting your device connected to the internet you do the best you can. You have a Mac, Windows, and Linux machine to test with. You have an iPhone and Android device to run through your setup process. You try your very hardest to do stupid, unthinkable things to break that process and then harden it so your customers can't break it. And then they will. You'll cry a few tears, learn something new, and then you'll make your product setup procedure even better. As long as you're prepared to do that you'll be ok.

That's it or part 3. Next up we're going to talk about creating an enclosure and how angry your wallet is going to be about it.

Building an IoT Product: The Hard Parts 2 (Firmware)

Kevin Sidwar — Wed, 11 Mar 2020 15:34:58 +0000

This series is meant to give a deeper look into the challenges you are likely to encounter if you decide to turn a maker project into an actual IoT product. It's based on my experience over the past two years of creating a product from scratch. If you missed part 1 you can find it here.

Last time we talked about a few of the hardware obstacles you'll run into when creating a product. In this part of the series we're going to talk about the challenges that are probably more in your wheelhouse; firmware programming.

Getting to what I call "hardware complete" is the best feeling. You're done with the back and forth of fab and assembly and, even better, you're done draining your bank account. Well, for now. You've probably been working on the firmware code all along but now you are ready to focus on it completely. This is where you are most comfortable. In the IDE or text editor of your choice beautiful keystroke follows beautiful keystroke as you hammer out features and functionality. So what could go wrong here.

Open Source...Open Issues

If you're like most makers your original prototype firmware is probably a hot mess of glued together library code that you didn't write. It all just worked. "I'll just polish it up a bit and we should be good." It's at this point you realize those nice, open source libraries aren't as production ready as you thought. As your feature set grows you start to find the cracks. Gasp, turns out there are actually lots of bugs in this code. You go to file an issue on the repo and find that it's already logged along with 57 other issues. "WTF! Why isn't this person who works for free to support the community solving these things? I'm trying to get this product out the door. Upvote. Upvote. Upvote."

This gap actually surprised me more than it probably should have. The people at Sparkfun and Adafruit are smart and talented people. But they aren't production library maintainers. They write sample code to sell more products to makers. And that sample code largely supports simple projects and use cases. And it does so very well but you will find that most of those libraries are either not production ready or have feature gaps that you need filled. And as for everyone else out there generously writing free code for you, well, they are just normal guys and gals that wrote some code for their project. They don't know or care about your product and they too have no interest in being a free-labor library maintainer.

At this point you have two options, fix the 3rd party open source code or roll your own (there is actually a 3rd option, kinda, that we'll discuss in a minute). Your built-in programmer DNA is going to scream at you "DO IT YOURSELF! You don't want to have to figure out and fix this other person's code. Your version will be 100 times better anyway. We GOT this! ✊" And your programmer DNA may be right. Let's explore both paths.

Write It Yourself

If you have any experience at all you know this is likely to turn into a rabbit hole. You take too much pride in your own code to rush out shoddy work. You are going to write the most beautiful temperature sensor library the world has ever seen. And that's fine, but it's going to take you time, perhaps lots of it as you figure out all of the nuances and gotchas inherent in writing firmware libraries for physical devices. Be prepared for this to take longer than you expected. At the end you'll have another one of those libraries that's perfect for you. You can open source it and maybe somebody else will use it for their prototype before throwing it away when they decide to start their own product journey. The cycle continues.

Fix the Existing

You decide to fork the repo and address the things you need fixed. This is going to be like hopping into any piece of code you didn't write. The original author's style is going to be different than yours. Things that don't make sense maybe have a perfectly good reason for existing. You'll have no context unless you want to read every commit back to initial. You're going to have to go through the learning curve of assimilating another person's codebase and then fixing it. It's going to take longer than you think. In the end you fix the issues and you get back to the core firmware. That's awesome but remember that you are now the owner and maintainer of that library.

Debugging the Old Fashioned Way

One of the first things you are going to find as you dig deeper into your firmware is that you don't have that beautiful F5 option to spin up the debugger. Line by line debugging firmware on a device is messy business even when you have all of the proper equipment. I really hope you had that schematic/PCB freelancer break out JTAG pins on your board. If not you have no option to line-by-line debug. But, now that you know that's important, let's assume that you did. Stepping through code using OpenOCD is non-trivial. At least that's been my experience. Even when I was able to step through code it exhibited weird behavior like executing several lines of code twice that weren't enclosed in a loop. Sometimes things will disconnect abruptly. Remember, you are communicating with a device across physical wires.

Oftentimes you'll find good ol' fashioned println is the way to go. Or even more primitive on hardware devices the 'ol blink an LED 8 times to indicate a connection error and 9 times to indicate a socket error. The common theme here is that everything is going to take longer than you think it should.

Licensed to Write It Myself

As mentioned before you're probably using a fair number of open source libraries you cobbled together in your prototype. During that "just polish it up" portion of creating your product you need to look at all of the licenses on those libraries. It's very likely that one of those license will be, what I call, a virus license like GPL or AGPL. That means that you must inherit that strong copyleft license for your product and release it publicly. You may be fine with this. If so, you don't have much to worry about and you can go on your way. Feel free to skip this section as it won't apply.

Before I go further I want to be very clear that I am pro open source and improving the community. I have released many repos to the public domain to help other makers. I simply prefer to do that under more permissive licensing such as MIT or even LGPL. I don't personally agree that simply using an unchanged library that is AGPL-licensed should require that your entire project be licensed as such. But I digress, let's get back to the point of this section.

One thing I would like you to consider is that you might want your firmware to be closed source. Why? After you've spent all of that time and money we talked about in Part 1 of this series your beautiful working hardware is a few hours away from being completely reverse engineered by someone who knows what they are doing. Your hardware is a commodity that can be easily copied and reproduced. What is less easy to duplicate, although not impossible, is your firmware. As such, you may want to keep it proprietary to give you some amount of protection from copycats. Remember, this isn't a maker project, it's a product you want to sell for profit.

Let me share an example from my journey. My product contains a display. During prototyping I used a combination of libraries including a driver for the display and a graphics library to draw things on it. I soon found out that the display driver uses a GPL license which would require my firmware to inherit that same license even though I had made no changes to the library. I would have to open source my entire code as GPL just because a portion of my product used that code. That is not something I was interested in doing. Instead I wrote my own driver from scratch using example code from the display manufacturer which is unlicensed (they sell displays, not libraries). This took me the better part of two months. It was a huge time sink. Be prepared to either go with the flow of licenses you use or rewrite portions of your firmware.

Now before everyone attacks me with the classic "So you just want everyone else to write open source code so you can profit from it?" Let me clarify. I never said I wasn't willing to pay for it. Read on.

Borrow, Buy, Build

When I worked on the Microsoft Internet of Things Maker team (best job ever btw) my manager always liked to say "Borrow, Buy, Build. In that order". The idea is that when building a new project from scratch you should first try to borrow existing code a.k.a open source projects. No sense in rewriting something that another person or team of people have already done. It's the fastest and cheapest way to get moving. If there is nothing to borrow then you should look to buy. This can be in the form of software packages or cloud services that can accelerate your development process. Finally, when all else fails, you should build which essentially means write it yourself. This is by far the most time consuming and expensive option which is why it's last on the list.

In the case of my driver dilemma I ruled out borrow because of the license. I would move on to "buy" but that simply isn't an option for almost everything you need in your product firmware. Firmware isn't like software...yet. There are not hundreds of shops out there selling all of the libraries you need. I absolutely would have paid either a lump sum or some form of licensing fee for a display driver to save me the time and hassle of writing it myself. But there simply was no option to do that. Thus I was left with building it myself.

There are literally thousands of sensors and chips out there you may choose to interface with. Some may have open source libraries and some may not. What is almost certain though is that there are very limited "buy" options for any of them which means you either have to accept the license or build it yourself. Even if you accept the license there is still the issue above of finding issues or feature gaps.

Wrapping Up

One of the biggest surprises in going through this process was how mediocre most of the open source libraries are for hardware devices. From obvious bugs to simply being written in a way that doesn't lend itself to running in an embedded environment. I've seen simple sensor libraries use half the flash and memory space of a microcontroller because programmers are used to garbage collection and having near-infinite resources. Just be aware that while your cobbled together prototype "works" you may need to invest a lot more time than you think in addressing firmware issues.

That's going to do it for part 2 of this series. Next up we're going to talk about device config and how you just became a full time customer service rep.

Building an IoT Product: The Hard Parts 1

Kevin Sidwar — Wed, 04 Mar 2020 17:14:55 +0000

So you've prototyped the coolest new IoT device ever with an Arduino or Raspberry Pi and now you want to make a product from it. You're gonna be rich! Step 2 is always "Profit". What you don't realize is there are actually 497 steps between 1 and profit. My hope is that this series will shed some light on just a few of those things to help you be better prepared on your journey from maker to product builder.

My name is Kevin and I've spent the last two years turning a weekend maker project into a full-fledged IoT product. I want to share what I've learned to help others who may be thinking of taking the plunge.

I've been working as a software developer for 15 years. Not exactly where I thought I'd end up considering my degree is in Electrical Engineering. Little did I know my EE degree combined with my love of programming was going to perfectly coincide with the rise of the Internet of Things. 15 years ago there were virtually no software developers in the hardware maker arena. Nowadays I can't find a software person that hasn't tinkered in some form of hardware project. The progress we've made in that amount of time is astounding. Access to tools and hardware is unprecedented. Even with tariffs the costs are as low as they've ever been. The rise of Sparkfun and Adafruit has created a flourishing space for individuals to build their wildest dreams with little to no hardware experience. Components that were previously unusable due to hard-to-solder packages now have breakout boards. Thanks to more developers entering the space, sample code has flooded the internet making datasheet reading a lost art. For many projects it's a lot like Legos. Connect all the things together and run the sample code and it works. The downside of all this progress is that it tricks us into thinking that making a product is easy.

So let's run through a scenario. You've got your maker board wired up with all the sensors and actuators you need. It's a mess of wires and breadboard and you've never seen anything so beautiful. "This is awesome!" you think. "People will pay me for this!!" you convince yourself. How hard could it be? You have all of the open source schematics and source code. You're a smart person. All you have to do is combine it on a single board, put it in a case and slap a price tag on it. Hold on Tiger, let's talk about this. In part 1 of this series we're going to cover a few hardware bumps you're going to run into.

TL;DR - Hardware Design Costs Time and Money: You Better Have Lots...Of BOTH

The Schematic

The first thing you're going to need is an electrical schematic of your product. It seems like you should be able to take all of the breakout board schematics from your prototype and just combine them in a single schematic. Ok, that's not too bad. The first question you have to ask yourself is "Who is going to do that?". Are you going to do it? Are you going to pay somebody else? Whether it's with your time or money, you're paying for it. Maybe you've never used an EDA program before in your life. Sure, there are lots of options out there, even free ones. But do you want to spend weeks learning how to use it? Let's say the answer is no. We can solve this with money. "I'll pay somebody to do it for me." you say, feeling content you've solved your first major hurdle. Alright, great. We solved that problem. Wait...but how much should you expect to pay for that? If you're going to pay by the hour how many hours is reasonable for a job this size? How do I know I'm getting a good deal for the price? The answer is, you don't. If you did you wouldn't be asking those questions in the first place. You've just been hit with your first dose of "We're not in MakerLand anymore."

The Printed Circuit Board (PCB)

It's been several weeks since you started this journey and you finally have your schematic. In the delivery email the nice contractor/freelancer says "Let me know if you have any questions. I'd also be happy to quote you for doing the PCB layout when you're ready." WHAT!?! I gotta pay for more stuff? If that's your first reaction then I'm going to save you a lot of time and money. Product making is not for you. Stick to being a happy, financially stable nights and weekends maker. Making an IoT product is going to cost you sums of money that will make you blush. Convincing your significant other to let you buy some breakout boards and some Raspberry Pi Zeros is a very different conversation than "So...uh...I need to spend 10 grand for an enclosure mold". But I digress, more on molds later.

The cost of doing PCB layout will depend on the complexity of your product. Let's assume it's nothing fancy and doesn't require more than 2 layers and has no complicated high frequency routing requirements. You'll be doing well if you can stay in the $500-$1000 range. This is not an area where you want to cut corners. Shoddy work on the layout will cost you in spades down the road whether it's in redesign and additional prototype runs or even failure in the field.

As always, you can do the PCB layout yourself but a word of caution on this. At this point in the process the financial commitment is going to get real. Very real. Small prototype runs are going to cost you, at minimum, hundreds of dollars. Every time you make a PCB layout change you have to do another one of those runs. You may think you are saving yourself the thousand bucks by doing the layout yourself until you realize that you keep making mistakes and have to do another $400 prototype run to make sure your changes work. There is a careful balance here so be thoughtful about how and where you "save" money.

Whew, you've made it this far. It's been a couple of months now since you started this journey and you have your PCB laid out and ready to go. Things are moving and it feels great.

Component Selection

Before you can do that first prototype run you need a list of every component used on your printed circuit board. R23, which is a 10k resistor, now needs a part number. As does her neighbor C14, the 10uF capacitor. Component selection is not a singular event. It is ongoing and never ending. Let me explain. At a very minimum you have to do a form of component selection twice. Realistically plan on half a dozen just to get your first production run out. Here are some major milestones of component selection.

During PCB Layout

During PCB layout you need to know what footprint to use for every component. The footprint is the copper landing area on the PCB to which each component is soldered. If your board has 70 total components (resistors, capacitors, transistors, etc) your PCB will have 70 footprints. A surface mount resistor has over a dozen footprints to choose from. That open source breakout board schematic tells you the value of the resistor but oftentimes that's it. Sure, it's a 10k resistor but do you know what wattage it needs to support? If you put a 0402 SMD resistor on your board and find out it has to be rated for 1W your product is gonna go boom. The capacitor is labeled 10uF on the schematic but what voltage rating does it need to be? What the heck is the difference between an electrolytic, ceramic, and tantalum capacitor? Your product also has a micro USB connector on it for charging. You flip to Digikey and search "Micro USB Connector". Not bad, only 766 options available covering 3 dozen different footprint configurations. Which one do you choose? What do you mean you don't know? You better figure it out so the PCB layout can move forward.

Repeat this process for every component on your board. For most of the components you don't have to get as granular as a single part number to get PCB layout underway. In fact, where possible, you don't want to get that specific. More on that in a minute.

Prototype Run

Before you have 1000 of these new widgets made you need to verify that everything works. You have to do a prototype run with a fab and assembly house. Many places offer both services. "Fab" stands for fabrication and it's the process of actually producing a printed circuit board from the layout you did earlier. "Assembly" is just what it sounds like, it's the process of populating that PCB with all of the components. Typically you will place an order with a fab and assembly house by sending them your layout files and a list of all the components. At this point you have to have every component defined down to the part number. You can't tell the assembly house "Just use a 10uF resistor for C5". You have to say "C5 is a 10uF 16V X5R 0805 capacitor. Part number ‎CL21A106KOCL3RC‎." You can either mail them all the parts (I don't recommend this) or you can have them source the parts for you (better, but be careful on quality). Either way they need the exact part numbers. Depending on the number of components in your design this can take a very long time. You may even find that super cool button you chose is out of stock and now listed as "Not for New Designs" on Digikey. Time to call that PCB freelancer again.

Production Run

You somehow won the lottery and your prototypes worked flawlessly after extensive testing. No PCB layout changes and no component changes are required. "Great, I'll just place another order and set the quantity to 1000." You shoot off an email to the assembly house in China and get the best sleep of your life. It's all coming together. You wake up in the morning with the following note in your inbox from the assembly house. "Sir, thank you order. Please advise no stock on C5, C17, C31. Suggest other part number." Now is probably a bad time for you to learn that there is a global shortage of MLCCs (multi-layer ceramic capacitors) and you're almost guaranteed to have at least a few on your board. I've done 4 runs of my product and getting ready for a 5th. I've had to re-select capacitor part numbers on every single one. I had to do this even when 2 runs were only a couple of weeks apart. That's how bad it has been at times.

Future Runs

Hardware components, like everything, have an end of life. A linear voltage regulator that you've used for years is no longer being made by the manufacturer. They have a new part that's better. Most times they will make the new option footprint-compatible with the old. If so, all you have to do is find the new part number and update your BOM (bill of materials) that you send to the assembly house. If you can't find a replacement that is footprint-compatible it's time to get your wallet out again because you're going to need another PCB revision.

Mo Money Mo Money Mo Money

The hardware side of making a product is one of the most expensive parts. If you are serious about making an actual product you're going to need cash. A lot of cash. Everything costs money and there are little extra charges everywhere that you don't think of until you're paying them. Tariffs, as much as the news wants you to believe otherwise, are the least of your problems. Shipping is going to get you at every turn especially if you have to source parts from multiple locations. Most assembly houses require a 5% to 10% headroom on components. So even though you only need 100 capacitors you have to send them (or have them source) 105 to 110. Not a huge deal but it starts to add up across dozens of components. And last but not least volume is your best friend. Problem is, you don't have it yet so you're gonna pay the "I'm not Apple" price for everything.

That's going to do it for part 1 of this series. Hopefully that gives you some insight into what hardware challenges you might encounter when you have the crazy idea to turn your maker project into a real product. Next time we're going to talk about the hurdles you'll encounter trying to piece all of that open source firmware together now that you have your hardware in hand.