Bench Talk

We’re going to jump right in with this blog post. If you haven’t done so already I highly encourage you to read this article about an automated mailbox delivery project I recently completed. Also check out the first blog post in this series that discussed some key lessons learned, including the importance of reading the manual and some thoughts on open source software. After reading those two pieces you can come back here and we will continue on together.

• The Big Picture: Using Storyboards. As a graduate student I studied principles and practices of systems engineering. During my course of study, I was introduced to the Unified Modeling Language (UML). In short, UML is a set of graphical ways to present various aspects of a system’s architecture or process flow. We discussed one such diagram, the Functional Block Diagram, in an earlier blog post on Bench Talk. In that blog post I made the argument that formally documenting your solutions is an invaluable way to conceptualize not only the final solution, but it also helps to define the process of how to get there. There are times, however, when your client will be non-technical and showing them UML diagrams will be enough to scare them off to another design firm (Composite Structure Diagram is one that comes to mind). Over the years, I have grown to be quite appreciative of the concept of storyboarding, sometimes also known as sketchnoting in productvity guru circles. If you know something about the behind-the-scenes magic of moviemaking, you will know that storyboarding is the first step in translating a script (e.g. requirements document) into the final audio/visual product we call a movie. Here are some of the rough sketchups I did for this project:

So how did the process of doing these drawings and going through the design mentally affect the final product? In my original concept I did not have a button to cause the system to reset for the next day’s delivery. I had originally intended for the system to reset the next time light was detected, thinking that would be a good indicator of the user picking up their mail. However, in drawing the sun as component of the system (e.g the power source for the solar collector), it hit me! Chances are the Post Office will deliver the mail during the day (at least that was my design assumption) but what would happen if the homeowner doesn’t get home to check the mail until night time? If the sun had already set, chances are there would not be enough light to trigger the ambient light sensor. So at that point I knew a manual solution to reset the system was needed. Now, there is a good chance I would have caught this during a test of the system, but that’s not a guarantee. So why does this matter? Adding a button is trivial, right? Well in the example, yes it is not much of a problem to correct. But consider if you were doing a much larger, complex problem as an engineer. If you can identify as many pitfalls as possible before leaving the design stage, then fixing them is a much less costly proposition. Consider that if you were doing a design on a fixed-cost basis, if the design change causes the Bill of Materials (BOM) a client has already agreed with to now be incorrect, chances are you will have to eat the additional costs out of any profit you built into your estimate.

• Resist The Urge To Over Engineer. As engineers we find ourselves frequently enamored with the latest and greatest technologies. We enjoy adding features to everything we do, because we can. And in many hobbyist's situations that’s just fine. But when you transition from enthusiast to professional designer or small business owner, you have to look at technology in a different context. In engineering we are constantly struggling with three competing needs; cost, schedule, and performance. To quote a former design professor I once had, “Perfect is the enemy of good enough”. That’s not to say that putting forth half-hearted attempts will just get you by. Rather, while getting a product just right feature-wise, it is also important to get to market in a timely fashion and offer the product at a price that consumers are willing to pay. It’s far better to build a product that does it’s functions extremely well then iterate on the design as you get customer feedback as to what they really want, versus what even a small group of highly intelligent designers thinks a customer wants. My vision for this project was quite simple, I wanted to design a device that automatically notified a user that snail mail had been delivered to their mailbox by way of some physical mechanism. In looking at the design there is really not much to it outside of the microcontroller platforms. A few resistors, capacitors, phototransistors, wires, and perhaps a few dozen lines of code. I chose to leverage capabilities baked into the Texas Instruments MSP430 including energy harvesting, energy storage, and RF communications instead of creating on my own from scratch. Good designers know what to add, great designers know what to take away. Minimizing part counts not only saves money, but also makes future troubleshooting and repair a bit easier.

So there we have it. A deeper look at the design process that I use in my customer electronics design work. I have a few more posts coming related to some specific technical issues that my design faced, and we will look at the ways to handle those problems so they don’t affect your circuits in the future. Specifically, we will look at floating inputs and button debounce. For now though, what are some ideas you have to build upon this project? Let us know in the comments down below.