JulianHartline.com Rotating Header Image

February, 2014:

Reflow Controller Update

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.