J1772 Hydra, v2.0

Well, the world (so far as I know) only has two Hydras in it, but even so, the hardware is about to move to version 2.0.

I'm switching to SMD components now that I can comfortably work with it. And because of that, I can make more of the real estate. I'm going to integrate the LCD backpack circuitry on the board and mount the LCD on the back, along with all of the terminals for connecting up to the outside world. The board will get mounted upside down and the whole thing should wind up being mechanically easier to deal with.

The board design is up at OSH Park. I haven't quite pulled the trigger yet to order a prototype. I want to ponder the design and layout a bit more first.

Yet another TRR controller design

To some extent, I sort of wonder why I keep doing this. So far as I know, I'm the only one who's actually used any of my designs to build a Toast-R-Reflow oven. But still.

There are three basic ideas I have for the TRR controller:

1. A standalone controller, intended to plug into a separate i2c "backpack" display. This one is based on the ATTiny85 and has an AD8495 thermocouple amplifier. That design is basically a done deal.
2. A display "backpack" controller. The first design still uses an ATTiny85 and the MCP23017 i2c GPIO chip to connect up to the LCD. Although my first prototype had a wiring error, it did prove the concept.
3. A "second generation" backpack controller, which uses an ATMega rather than an ATTiny to give it more flash space. This one is still TBD.

What I've done is come up with a new design for controller number 2: Instead of the ATTiny85 and the MCP23017, I've gone with an ATTiny84. It will use the traditional LiquidCrystal Arduino library intended to talk to a directly connected LCD display. The LCD data bus will be shared with a MAX31855 digital thermocouple amplifier as well as the ISP bus for programming, so that the pins can sort of serve double duty. I've stuck with the same analog thermocouple amplifier for now. It's much cheaper, and seems to work more than well enough.

The swap of the Tiny84 for the 85 + MCP23017 saves about a dollar off the design.

AD8495 KickStarter

If you're interested in any sort of experiments involving measuring temperatures with an Arduino, you should head over to the KickStarter for the breakout board. The goal is to pre-fund building 1000 of them. Why so many? Because the cost to build them falls dramatically when you purchase a "reel" of 1000 thermocouples. Not only does the price for the parts get cut almost in half, but the cost to have them assembled by machine is much lower as well. Unfortunately, a reel of thermocouples is over $2000 - which I can't afford on my own.

This is a great opportunity to get one for less than half the cost of buying an AD595AQ - the best alternative analog thermocouple amplifier available to breadboard.

Toast-R-Reflow variants

I've already now designed three different Toast-R-Reflow controller boards... First, there was the ATTiny85 board with an AD8495 and an i2c header for an OpenEVSE LCD backpack. The second design was the same, but done as an LCD backpack by itself. The third is going to be an ATMega328 based LCD backpack.

But it occurred to me today that the problem really breaks down into two hardware pieces:

1. Power control for the oven
2. Reading the thermocouple

The nice thing about the Toast-R-Reflow design is that the high voltage switching and control apparatus is a very static design. Since there are optoisolators driving the triacs, it really just amounts to treating the oven elements as if they were LEDs, and that's fairly trivial for Arduino/ATMel based systems.

There are a number of ways to read the thermocouple. There is, of course, the AD595AQ that I started with. Nowadays I'm using AD8495s instead, but in principle, you probably can get more accurate results with the MAX31855. It's a particularly good choice because the A/D converter is built right into the device. You just need to connect it up to 3 digital pins to make an SPI interface. SPI seems at first to be unfortunate, since most of my projects use i2c, but in this case, the interface is fairly easy to bit-bang. The other downside is it's a $8.19 part - double the price of the AD8495. But for your trouble, you get quarter-degree resolution and a signed 14 bit range - meaning you can read negative temperatures properly without resorting to supplying a reference voltage like for the AD8495.

I originally went with the AD8495 because the ATTiny85 only had a single pin to spare, so using it as an analog input was the direction I chose. One way to get more pins is to shift up to the ATTiny84. I was contemplating such a design when it further occurred to me that the i2c LCD GPIO chip has lots of pins to spare!

Of course, that means a fully customized version of the LiquidTWI2 library. And I'm already - more or less - heading down the road of of an ATMega328 based design with the LCD directly connected. In that design, I left the ISP pins unused so that I wouldn't have to protect them during programming, but as long as the CS line of the MAX31855 is not asserted (meaning there's a pull-up on its !CS pin), it can share SCK and MISO with ISP.

I was contemplating adding a 1.8 volt analog reference to that design to make better use of the available A/D resolution, but using the MAX31855 would obviate that. The only other downside is that the cost goes up, as it's a more expensive chip.

But I think, in the end, that that's the direction I'll go for the "next gen" controller design. It will eventually have a parameter and reflow curve editor UI built-in (since the ATMega has enough flash space). It'll have 3 buttons instead of 1 - up, down and select.

TRR backpack controller pictures

Despite the error in the LCD wiring, I did get the backpack controller working. I put a hack in the library to rewire the interface in software to match the error, but once it's up and running, it's good to go.

The button is the 'start' button for the oven.

It functions identically to the older controller design. While it's running, the temperature on the left is the current actual temperature, and on the right is the current target temperature just below the time within the current reflow session (generally the set point drifts gradually across a phase from one point to another, with the different phases effectively representing different line slopes).

LCDuino in action

Here are some pictures of LCDuino. First, the board itself, just after being reflowed - no LCD attached:

This is the LCDuino ribbon cable plugged into my breadboard. The two jumpers at the bottom are supplying LCDuino with power and ground. The jumper at the top is running up to a simple current transformer interface circuit (a 2.5 volt divider and a 0.1 uF cap to ground on one lead, an analog input pin on the other leg, and a 56 ohm burden resistor between the two):

And here's the display... a simple ammeter / amp-hour meter sketch reading the current transformer:

LCDuino update

The nice thing about prototyping is that you don't have to be backwards compatible. I've made a couple of updates to the design for the next (and hopefully final prototype):

1. I've added a 3.3 volt power supply to the shield adapter. LCDuino itself has no use for 3.3 volts, but it occurs to me that there may/are lots of shields out there that do. The 3.3 volt supply can be driven either by the internal 2.1mm VIN jack or over the I/O cable from LCDuino's USB connector. IOREF will, of course, still be +5v.

2. The LiquidTWI2 library doesn't actually come with support for a 6th button... Instead, it supports connecting and driving a piezoelectric buzzer from that pin. So I've swapped out the "back" button on the button board for a suitable piezo element. I've also added another row to the button connector (to make it 16 pins), adding a +5 volt pin, in case you want to design button boards that need to be powered.

Meanwhile, I've successfully installed a bootloader and an initial sketch on the prototype LCDuino. The first sketch is a GPS clock sketch that I've got running on my Uno. It's not actually connected up to any hardware, so the LCDuino just puts up an error message, but it does prove that control over the LCD, its backlight and the ability to upload sketches as if it were a real Uno.

I'm trying to work out what to put in the real "hello world" sketch for LCDuino. It's going to be something I can use also as a final check-out sketch to make sure everything on LCDuino is working, and something you can play with the minute you unbox yours.

Any suggestions?