Tinkering

My previous post highlighted some of the initial design behind our reflow controller project. It’s been a few weeks since then and in that time we’ve come a long way on this project.

After a few more revisions of the relay and reflow boards, we shipped off the PCB design to have it manufactured. At the same time, we placed the orders for the parts, the cases, an AVR ICSP for flashing the firmware, and a handful of screws.

Here are some photos of the assembly. In reality, the device stayed partially assembled while we worked some of the bugs out, but a few weeks after our initial assembly, we finally closed the case up.

As expected, the mistakes we made on the initial design, despite all of the revising, quickly became apparent. Fortunately the mistakes we made were extremely minor and did not ultimately affect the viability of this manufacturing run.

On the relay board, the worst mistake we made was that we had flipped the footprint for the relay across the Y axis. Because of the asymmetric layout of the pins, this meant that the relay simply wouldn’t fit into the PCB the way that we had it oriented.

Fortunately for us, because it was the perfect mirror image, we ended up flipping the PCB upside down and placing all of the through-hole parts on the back of the PCB. Other than being a little bit strange and highly amusing, this did not affect the functionality of the relay board.

We also managed to rotate the silk screen of the transformer by 90 degrees. This did not affect the pin layout at all, but made the transformer hang out over the edge of the PCB and come dangerously close to interfering with the relay. However, other than being a close call, everything still fit into the case perfectly, if only with a few millimeters to spare.

After flipping the board and the components that we had already soldered to the other side, the relay board worked spectacularly well. An initial test gave us correct voltage readings on both the 3v and the 5v pins. Furthermore, shorting the relay pin to power gave us the satisfying click of a fully functional PCB.

Next up, the reflow controller board. While we ended up hand-soldering the choice few surface mount parts on the relay board, the controller board had significantly more parts with smaller pins. As such, we decided to reflow solder it.

Despite being only the 6th or 7th board we’ve ever reflow soldered, the application of the solder paste is becoming easier and easier to get right. It seems to me that the best take home for this is that less is more. As cliche as it is, the amount of solder paste needed to get a good contact on pins that are so small is much smaller than you might think. In most cases even just barely coating the dental pick with paste and smearing it over the contact was sufficient to get a solid contact on the reflowed board.

After reflow soldering the surface mount parts, it was a fairly quick matter to get the remaining through-hole parts soldered in and functional. Miraculously we were able to program the board easily using the Arduino IDE via the “Upload Using Programmer” option.

At this point, we discovered an additional oversight. When designing out the connections between the Atmega microcontroller and our various components, we neglected to take into consideration that the Arduino bootloader not only performs a mapping between the different port and pin combinations to a more consumable numbering scheme, but also reserves some of these pins for it’s own use.

Fortunately only a few of the pins are reserved and unavailable. As it turned out, one of our LEDs that we had indented for an indicator was hooked up to what the Arduino bootloader uses as a TX indicator. The other one, a segment of the LED display, was hooked up to the HWB pin. To this day, I don’t entirely understand what this pin is useful for, however, ultimately the HWB functionality seems to easy to disable by the fuse bits at which point it becomes a regular input/output pin. However, instead of being nicely mapped to an Arduino pin alias, we had to address it directly through port manipulation. This of course, resulted in some ugly code that will fortunately be easy to remove when we hit the next iteration of the PCB.

The last piece of functionality that was a bit stubborn to get working was the USB programming using the Arduino bootloader. Anyone familiar with Arduino will know that most of the boards are easily programmed via a USB cable. Because we’re planning on marketing this product not only to the “hacker” community but also as a hackable device, we plan on providing a USB port with which anyone with some Arduino knowledge will be able to use to reprogram the hardware to do their bidding.

We had chosen a 20Mhz oscillator to run the Atmega32u4 and it turns out that this was not the correct choice. In order to successfully communicate on the USB, an interval of 8Mhz is required. Fortunately, the Atmega has an 8Mhz internal oscillator that can be used instead. While this is an easy operation in theory, in practice, it meant that we had to recompile the bootloader to use the new speed. We have some research to do yet about how to make this a bit more developer friendly in the future. That said, once we managed to download the bootloader source code and all of the dependencies, tweak the processor speed options, and upload the new code as our own custom entry in Arduino’s boards.txt, the USB worked like a charm.

For our next iteration of this project, we are probably going to switch to a 16Mhz external oscillator and hopefully end up with a board that is 100% compatible with an existing Arduino board so that when a developer wants to reprogram the board, they simply pick an Arduino from the list.

Despite all of these minor glitches, the controller actually functioned beautifully. Here is a picture of it in action. It is currently heating the toaster up and displaying the current temperature on the display.

After the first taste of reflow soldering, Eric and I, as good engineers are wont to do, decided that the task was begging for automation. In particular, we decided that it was sorta silly that the cheapest commercially available reflow oven goes for $500 driving most hobbyists to resorting to a mundane toaster oven. A thermocouple ordered on Ebay, a simple relay, and about 30 minutes later we managed to hack together a simple reflow toaster oven with a soldering profile hard coded to the paste that we are using.

The exercise, and the fact that the breadboard solution was rather unwieldy and inelegant got us thinking that it might be worth building a more integrated solution to what seemed like a fairly common problem with no particularly easy solution. A little bit of market research did reveal some previous projects that people had done to the same basic effect, but none of them were particularly convenient or streamlined.

The reflow controller that we were planning would consist of a relay to control the power to the toaster, a thermocouple to measure the temperature of the oven, and a simple interface. The interface would be comprised of a 3 digit 7-segment display, a knob, a button, and some LED indicators. All of this should fit into an AC wall plug enclosure from Polycase that we will eventually be able to customize to our needs. The idea is that you plug this unit into the wall and then use the receptacle on the back to plug in your toaster oven.

The first part of this project is the relay and power supply. The goal here is to create a module that can both transform and control a standard AC 120V wall outlet. Normally our electronics projects utilize an external AC adaptor that brings us 5V DC power directly to our board. In this project, because we want to keep everything self contained and because we’ll be controlling the outlet, we want to avoid the inconvenience of plugging in multiple devices and combine these two items into one.

To do this, we connect a transformer in parallel with the relay and the outlet in series with the relay. This will make sure that the microcontroller receives power even when the relay is cutting power to the outlet. The power supply half of the board consists of a transformer to bring the voltage down to 5V, a bridge rectifier to flatten the AC signal out into DC, and a collection of voltage regulators and capacitors to generate a consistent output. We ended up providing both a 3V and a 5V output. For the relay part of the board, we used a relay driver and a power relay. Many other solutions use a solid state relay, but our initial experiences indicate that it may not be necessary and would be significantly more expensive. It remains to be seen whether the power relay will be sufficient.

Here is the PCB that we ended up designing. Notice that there are mounting holes and a cut-out on the right side for the outlet pins that protrude up into the inside of the case.

Polycase very nicely provides 3D models of all of their cases for download. It was a bit of a trick to get the CAD file transformed into a format that SketchUp could recognize, but once done, the model proved an extremely useful tool for both visualizing the product and ironing out details such as PCB size and shap, hole location, and header location as well as part clearance.

Here is a view in SketchUp of one of our earlier versions of this. Because this 3D model is only used for planning purposes, many of the pieces that I used are simply approximations of how the part would look. Most of these components were build in SketchUp using their respective datasheets as a guide.

The upper layer PCB shown in the image above is where the controller itself lives. This board will contain the microcontroller, the controls, and the connectors. We decided to build this board “upside down” by placing almost all of the parts facing down (away from the front panel). The exception, of course are the pieces that actually do need to face the front panel such as the 7-segment display, the buttons, the encoder, and LEDs. We did this to provide a little more breathing room for all of the parts that we needed to fit on there as the PCB was getting pretty tight. Here is the current version of the PCB as of writing this.

One of the most exciting things about this project so far has simply been all of the designing that has gone into the 3D aspect of working within the case. In the past it has simply been a matter of getting all the parts on the board and hoping for the best, but now there are real world space constraints and physical requirements such as mounting holes and clearance is something that matters much more now that we’re working in multiple layers on multiple boards with large components.

Look for the Kickstarter when this gets off the ground and I’ll hopefully post again with an update when we start getting these boards printed.

At the same as working on the nRF24L01+ PCB,  I’ve been progressing on another project. I picked up a 30/m addressable LED strip from Macetech. These LED strips are comprised of the WS2812 tricolor LED and controller package.

The WS2812 contains a red, green, and blue LED and a controller complete with a single line data interface and 3 PWM modules for running each of the LEDs individually at independent brightnesses. Furthermore, the controller is set up so that it can transmit signals to the next WS2812 in the strip so that these modules can be daisy chained.

When put together into an LED strip, a microcontroller can simply provide power, ground, and a single line of data to control the entire strip. To populate the LED strip, a series of  bytes is sent to the first LED. Once 3 bytes are sent (the color definition for one LED) the next byte causes the first color to be “pushed” on to the next LED. When the entire strip is populated, sending a reset signal causes each LED to display the color that it ends up with.

Sending a byte to the WS2812 requires 8 transitions on the data line each spanning 1.25 microseconds for a total of 10 microseconds per byte. Unfortunately, using a PIC18F25k80, this timing requirement allows for about 20 processor cycles for each bit transition. This is is a pretty tight requirement and I was unable to make it with my C compiler. Instead I ended up writing a method in assembly to get the timing I needed. It took awhile to get it right and it still has some minor bugs, but it was an interesting exercise.

After getting the code working on the nRF board that I previously blogged about, I designed a new PCB to better fit my requirements in a smaller package. This time I used primarily surface mount parts in significantly smaller packages. Here is the final PCB design and the populated board.

Remarkably, this board seemed to work flawlessly the first time around. Both the nRF module and the LEDs worked exactly as expected.

One additional piece of progress made with this board was our first successful use of reflow soldering to populate the board. Reflow soldering uses solder paste instead of traditional solder which is viscous at room temperature. To solder a board, solder paste is applied to all of the pads and then components are placed in the sticky paste. Once prepared, the board is simply baked to just over 180° C which causes the paste to fuse to the contacts and turn into solder, thus soldering your entire board in moments.

I’ve continued writing code for this board and have a simple proof of concept that lights the strip in some demo patterns during until it receives a packet on the wireless module. At that point, the LED strip is under remote control. Packets consist of an starting index, a length, and the payload that is copied into the LED buffer and then displayed to the LED strip.

The next step in this project is to design a new board, probably using an Atmega microcontroller that will fit into a case sold by Polycase. Getting a PCB and components to fit into a case is a new hurdle that has involved a significant amount of 3D modeling in SketchUp as well as extra spacial considerations such as switching to a flatter power jack.

It’s been awhile since I’ve posted anything, but I’ve been anything but boring the past few months. After hacking out the Hot Tub Remote project, I moved on to tinkering around with a PIC18F25K80. This PIC is a a very reasonable middle of the road processor. At 16Mips and 32K of program memory it has enough power for fairly ambitious projects.

Eric and I spent a decent amount of time and a few iterations to streamline the interaction between this PIC and the nRF24L01+. The nRF24L01 is a cheap and easy little wireless module that communicates in the 2.4GHZ frequency range. After breadboarding out a communicating pair of nRFs and spending a few weeks cleaning up, streamlining, and fine tuning our communication library, we started designing a PCB to make working with this module easier.

Eric did most of the work on this board and here is what the final board looked like. We shipped this board off to our Seeed Studio to be printed and received the boards and parts in the mail a few weeks later.

For this board, we carefully avoided any surface mount soldering (with the exception of the mini USB solder pads) in order to make populating the boards easier. The headers are optional and can be populated on a per-board basis depending on our needs. We ended up building out a total of 5 or so of these boards. Here is the populated board.

This board helped tremendously as far as getting the kinks worked out of our nRF code due to the increased stability afforded to us by soldered connections. A good number of the flakey behaviors from the breadboarded solution disappeared when we moved to the PCB.

The library that we ended up developing is available on Github: nRF_PIC18F25k80

In my next post, I’ll continue filling in the missing pieces from the last few months including a few more circuit boards that Eric and I designed and had printed.

If you’ve ever owned a hot tub, you’ve surely been driving home from a long day or night wishing that the hot tub would be ready for you when you got home. I decided to do something about this.

Because we’re renting, I decided that instead of trying to pull apart the wall unit for controlling the hot tub, I’d go with the more mundane approach of wiring up a servo to push the hot tub button on command. I chose the Electric Imp as my platform primarily because I’ve been experimenting with it recently for another project that I’m working on. Having worked only with PIC microprocessors before, I found the Electric Imp to be surprisingly intuitive and easy to set up and  use. Instead of spending hours tinkering with a breadboard full of wires and a resistor or two, the Electric Imp fits easily into a development board, can be powered by a mini-USB cable, and configures itself to your home WiFi network without too much difficulty through a mobile app.

The Electric Imp, once connected to your wireless network, is accessible via the Electric Imp web application that allows you to track all of your devices and upload code to each one of them as well as configure the way that they interact with each other.

Once getting past some of the initial setup woes inherent in every tinkering project, the programming and wiring was very simple.

(more…)