Bench Talk

In a recent article published last month titled Solar Energy Harvesting Project to Power a Remote MSP430 with 2.4GHz Notification, we tried to inspire designers and makers that have limited experience outside of the Arduino microcontroller platform to explore different platforms typically used by more seasoned design engineers. We did so by using a project based approach to demonstrate the possibilities of the Texas Instruments MSP430 family of low power microcontrollers. I built a device that would detect when mail had been delivered to a mailbox (yes snail mail, not the electronic variety!) and relay that to the inside of the house where another device would give the end user a decidedly physical indicator that the mail had been delivered for the day. If you are interested in the project, I encourage you to click the link above and read the article first. The rest of this blog is going to be a deeper dive on the lessons learned and some thoughts about designing with non-Arduino platforms in general.

As I mentioned in the article, I think it is imperative for professionals and hobbyists alike to gain proficiency in as many different embedded platforms as practically possible. No two problems are the same, and each will require different solutions and technologies. If you pigeon hole yourself into a single technology, that makes you vulnerable to the inevitable and unrelenting sea of technological change. In other words, there should always be more than one tool in a toolbox, and chances are the tools you need tomorrow will be different than the tools you needed yesterday. Learning on different platforms today makes you appreciate the different options that are available when confronted with a new challenge you must tackle. It also teaches you how to learn new technology, which means picking up new technologies in the future will be less of a headache. Additionally, because each platform has its own peculiarities (e.g. voltage levels, onboard features, communications protocols, and programming languages) you will gather more breadth and depth of technical know-how by developing for multiple platforms rather than focusing on a single one. In short, it’s the best way to become a better engineer or maker.

In this blog and in a few of the subsequent blogs I will attempt to “complete the picture” of the automated mailbox article by discussing some of the lessons learned in developing that project. Let’s get started.

• Read The Manual: Most development kits come preloaded with an application to test the hardware and to show some basic functionality. Always try these demonstration applications first. By reading the manual and doing the demo application I was able to overcome three issues before I even started on my project. First, I had a more recent version of the energy harvester board that was not backwards compatible with the current version of the Energia Integrated Development Environment (IDE). Good to know and prevent a lot of needless troubleshooting that could have occurred when I tried to upload new firmware. The second issue I avoided involved a jumper on the battery pack for the MSP430 target board. The jumper needed to be removed in order to operate. Had I not read the manual, I would have assumed the jumper needed to be inserted for the battery to work. The last issue is one that I did encounter and it caused a good hour of frustration. When I connected the MSP430 board to the energy harvester, the LEDs did not flash like they did when I connected it to the battery pack. Luckily I read the manual beforehand and knew there was a troubleshooting procedure, so I got out my digital multimeter and began to probe the harvester board. Sure enough there was a bad capacitor as part of the boost converter on the energy harvester board. It pays to test the development kit out of the box. Assuming the hardware would just work could have led to hours of hair pulling troubleshooting after I connected my custom circuitry and uploaded my revised firmware. It is rare these days, but sometimes you get a bad part. Knowing how to troubleshoot is key.

• Open Source Means Not Having To Reinvent The Wheel. In undergraduate education we (at least in my day!) prided ourselves on writing every software project from scratch. Fast forward to today and reality is while knowing how to code from scratch is important, it is equally important to know how to interface with an existing code base. Rapid prototyping is all about speed and proving that a concept is technically feasible. Which is why the use of development boards and existing code libraries are the best weapons in your prototyping toolbox. Less time spent inventing a communications protocol stack is more time focusing on end-user focused details and making your product unique enough to stand out in a very rapidly crowding stage of inventors.

In the next blog post I will continue the lessons learned and provide some insights into my design process and decision-making. Let me know if you’ve read the automated mailbox article in the comments below. Please share your thoughts and ideas. How would you improve on the design? What other uses for the project could you come up with?

If you want to see the project in action, check out this YouTube video.

See part two of this blog.