There's no right answer whether or not to use modules or sub-assemblies; both options carry risks and rewards. Today I cover those options and what to consider when faced with this decision.
Don’t forget, today SparkFun will give five percent of its customer sales to the Electronic Frontier Foundation, as part of SparkFun Gives Day.
Before we dive in, let’s define what we mean by sub-assemblies or modules. Technically, anything could be considered a sub-assembly, but what I’m talking about is populated PCBs that you purchase or add to your product or project (sometimes covered by an aluminum shield). The same definition stands for modules; they might be standalone boards or have castellated vias for mounting onto another PCB.
While always a part of electro-mechanical designs and products, they’ve gotten a lot more attention in the past decade due to IoT. The connected aspect can be crazy difficult, so if you’re able to simplify things with a sub-assembly - which not only takes care of the RF design needed with the radio, but also the software end of things - it can be beneficial. However, with that comes a myriad of pitfalls and considerations. If you’re doing a one-off project, using sub-assemblies is much less perilous, but it isn’t without its risk, especially when software comes into play.
I’m seeing more and more Raspberry Pis going into products.
Smaller and faster seems to be the direction for electronics right now. This can make for a difficult time if you’re a smaller outfit or don’t have access to PCB population tools, especially when IC packages like BGA come into play. Using sub-assemblies or modules can definitely help provide the latest electronics tech without the need for an X-Ray inspector. In fact, I happen to know a company that provides products that do just that…
These are the dark arts, as the EEs at SparkFun often say. It’s one (of many) aspects of PCB design that can be incredibly difficult without training. If what you’re working on is slated for market, it’s going to need FCC approval, so taking a trial-and-error approach here is often not the best. One way to skip this headache altogether is by using a wireless module. The module provides (assuming it’s been FCC certified) a certified RF design ready to be implemented in the product, complete with antenna. This comes with its own challenges, including price, but it could save a lot of time and result in a much better-performing product. I could go on about RF modules and sub-assemblies, but it’s enough to take up its own blog post. I highly recommend looking further into these.
The trend now is adding a microcontroller to the wireless radio module in what people are calling “IoT Modules” (not all of them, but it’s becoming an accepted term). Most come without specific software, but some come with an IoT software stack that contains all the necessary components for working with the device remotely, as well as access to cloud storage, so there’s a lot to be gained from a sub-assembly. You could potentially replace this in a design with a current, comparable microcontroller to turn your existing product or project into a connected device with relative ease.But, with these added aspects come lots of potential for risk, most of which I’ll explain in the coming sections.
With most electronic parts, the lifetime of the part and its successor are considered seriously in design and product management. Companies don’t want to leave their biggest customers in a tough place, so new products take design considerations from old products to keep things simple. Sometimes though, an end-of-life comes without a direct replacement – this seems to be more prevalent with sub-assemblies and modules. As the demands of the market and customer base change, so do the specs and availability of these sub-assemblies. Whereas a single part is usually easy to find a replacement for, it can be quite difficult to source a sub-assembly replacement that fits your needs – being cognizant of the lifetime of the sub-assembly or module is a must. I recommend asking questions about lifecycle status, future plans, etc. to the supplier.
Take a lot of the advice I give here with a grain of salt. While some manufacturers are more risky to work with in general, the truth is that any manufacturer can pull their support of a sub-assembly or module at any time. However, looking into the manufacturer is still pretty solid risk mitigation. A newer company is going to hold risks not normally associated with a larger company; there is more risk it could go under or run short of funding before the product reaches its full specs. In addition, some of these companies start with the short-term goal of getting acquired, which puts the status of the sub-assembly into question. While it might seem like a minefield, sometimes a smaller company is more desirable. The fewer customers, the more readily they could support your product. In the interest of spurring their own sales growth, they might promote your product’s usage of their device. My advice here (as with the last section) is discuss your needs with the company and see how ready they are to work with you – some might even tell you that they never intended the assembly for OEM use.
In the past, my advice has been, “If the price seems to good to be true, it is.” There was usually something you’d be giving up that made the price seem reasonable for what you’re getting, like a lack of support or documentation. However, these days, with the magic of open source and the great communities being formed, the too-good-to-be-true pricing is sometimes true. Either way, my advice in approaching these super low-cost modules and sub-assemblies is, “If it went away tomorrow, could your BOM survive?” One of the best ways to test this is to do a rough BOM cost for the identifiable parts on the sub-assembly. Figure out the difference in BOM pricing and decide whether it would be feasible to continue sales. Obviously this is a worst-case scenario, but it’s something that will benefit you to figure out ahead of time rather than when it happens.
I hope this quick list of suggestions and considerations helped a little. It’s by no means complete, and if you can think of anything else to consider, please add it in the comments. This was written in response to some of the comments I’ve been hearing among the local hardware community. The more planning you do now, the less headache when your sub-assembly maker shuts down their cloud service or focuses the hardware on a use case that isn’t yours. My best, all-around advice is to talk with the manufacturer a little before moving forward with a sub-assembly. Beside answering any questions you might have or revealing issues you might not have seen, it gets you on their radar, which could carry its own benefits.