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?

LCDuino setback

Well, I got the LCDuino and the Toast-R-Reflow backpack prototype boards in the mail over the holiday, and I've discovered a flaw in them, unfortunately. The LCD module data bus lines are connected backwards.

It can be worked around in software, but I'm certainly not going to release them to the world that way. Meanwhile, the prototypes can be tested, at least, to make sure the rest of the systems work ok.

More on that later. But in the meantime, there'll have to be at least one more round of LCDuino prototype boards before they're released.

The Merry Celeste

I've got another idea...

I call it the Merry Celeste.

It's a play on the name Mary Celeste, which was a famous ghost ship, and the Celesta (or Celeste), which is a struck-bell keyboard instrument in the orchestra (think of the Dance of the Sugar Plum Fairy).

So what is it?

Amazon sells a set of 25 chromatic handbells (2 octaves worth). I intend to put a solenoid next to each one and drive them with an ATMega.

I'm thinking that the first thing I will do is connect it up to a MIDI shield and play it with a keyboard. I could then use a standard MIDI sequencer to play songs. 

Of course, I could also just have the sketch play canned sequences, but that just seems like more work (translating music into custom software).

We'll have to see. 

As for the hardware, that ought to be easy. A pair of 74154s can directly drive PNP driver transistors, each sharing four address lines from the controller, and each having an independent enable line. That's 32 outputs - more than enough.

That architecture wouldn't be sufficient for sustaining instruments, because only one solenoid can be addressed at a time, but for this application, that's not an issue. 

Design choices

I have a quandary.

The Toast-R-Reflow controller works really well... so long as you don't want to change any of the parameters of the reflow cycle without uploading new firmware. About all the ATTiny85 can handle is letting you push "start" and displaying what it's up to. If Atmel (seriously, you have GOT to go check out their website right now. It's got pictures of SOIC and TQFP packages and calls them "stocking stuffers." LOL) were to make an ATTiny165 - that is, an 85 with 16 kB of flash instead of 8, then that would solve an awful lot of problems.

But, in principle, I don't have to use the ATTiny85. I could swap it out for a TQFP ATMega328. The price is $2.80 instead of $1.20 (in single unit quantities. Not that you'd buy them that way, but it makes for a valid comparison) - which doesn't break the bank, but it is more.

What do we get for our trouble?

Well, we get a whole bunch more pins, most of which we don't need.

However, we may be able to do away with the MCP23017 i2c GPIO chip to drive the display. The LCD would take most of the digital pins, but so what? That would make up for most of the cost difference (that chip is $1.44).

What we really get out of the deal is quadruple the flash. That should be more than enough for a parameter / curve editor UI. Perhaps even one that could handle multiple time/temp profiles.

I might have to consider that...

ATTiny & 2.56 V A/D reference

If you google around, you see a lot of suggestions to use 6 as the analogReference parameter to select a 2.56 volt reference. And this is quite attractive - it means that the A/D units represent exactly 0.25 mV. This works spectacularly well for TRR, because the AD8495 outputs 5 mV per degree C, which gives a range of 0-512 degrees and a resolution of a half a degree, which is ideal. 

If you try, however, you'll find that what you actually get is the 1.1 volt reference. Why?

The value 6 comes from the ATTiny85 data sheet, table 17-3. But the problem is that the three REFSx bits are not adjacent to each other in the ADMUX register. The default code in wiring_analog.c will shift the lower two bits of the analogReference argument into the top two bits of ADMUX, but will throw away the REFS2 bit. 

The fix is to edit that line and or in 0x10 to ADMUX if analog_reference & 0x4 is not zero. 

Here's a patch:

--- wiring_analog.c.orig    2013-12-12 12:44:11.000000000 -0800
+++ wiring_analog.c 2013-12-12 12:16:16.000000000 -0800
@@ -66,7 +66,7 @@
    // channel (low 4 bits).  this also sets ADLAR (left-adjust result)
    // to 0 (the default).
 #if defined(ADMUX)
-   ADMUX = (analog_reference << 6) | (pin & 0x07);
+   ADMUX = (analog_reference << 6) | (pin & 0x07) | ((analog_reference & 0x4)?0x10:0);
 #endif

    // without a delay, we seem to read from the wrong channel

What the Arduino folks really ought to do is change all of the analogReference argument #define values to represent all four bits of the top nibble of ADMUX. That would allow custom, non-standard values to be passed into ADMUX at conversion start time. 

Toast-R-Reflow power board pics

I built one of the v0.2 TRR power boards today. It all went together pretty well, although I do think that the QD terminals for the hot and out lines are uncomfortably close to each other and the triac heat sinks. The v0.3 boards will have a bit more room around them. 

These boards definitely are an upgrade from the prototype board. I'll be installing this one in my oven in exchange for the prototype tomorrow. 

LCDuino and shields

It occurred to me that, while I think that the Arduino Uno architecture makes breadboarding more difficult, there's clearly quite a bit of value in existing shields.

To that end, I've designed an LCDuino shield adapter. It's the footprint of an Arduino Uno (thanks to the AdaFruit Uno library), but with the pins (except for the irrelevant ones) all connected up to an LCDuino header.

There is also a 2.1mm barrel connector for power, which is connected also to the VIN pin of the shield.

There are some differences to be aware of between a real Uno and the LCDuino + shield adapter:

1. There is no provision at all for 3.3 volt power. The 3V pin is not connected.
2. A4 and A5 are actually connected to A6 and A7. A4 and A5 are used for the i2c bus, which is exposed on the i2c pins which were an extension of the original shield specification. Shields that expect i2c to work on A4 and A5 won't.
3. There is no provision for selecting either 5 volts from USB or from the barrel connector. You should not connect both at the same time.
4. There are no LEDs for RX, TX, D13 or power, and there is no reset button. Those are already present on LCDuino.
5. The ISP connector is in a different location. Its orientation, however, is the same.

The board is on my OSHPark profile if anyone is interested.

I made a pair of earrings

I was sort of inspired by AdaFruit's FLORA. I put an ATTiny84 on a board with 8 LEDs and a very tiny tactile switch on a 1" diameter round board. On the back, I put a 12 mm coin battery holder and the ISP. The LEDs are arranged evenly around the outside. I designed in a series resistor for each LED, but in the prototype I stuffed in "0 ohm" resistors, and that seems to have worked out nicely.

I tried two different 0805 LEDs. I bought a set of super bright white ones, and a set of sort of ordinary green ones. I was surprised how astonishingly bright the white ones turned out to be. I asked the girls which they liked better and they picked the green ones. Since OSH Park boards come in sets of 3, they were the tie breaker for the second of the two earrings. The third one (with the bright white LEDs) will wind up being a pendant.

The firmware uses the button to change the blink pattern to one of four compiled in (with a short push), and to put the board to sleep (with a long push) and wake it up.

I was concerned that a CR1220 wouldn't have enough oomph to drive the whole thing, but so far it seems to be working just fine. No word yet on how long a single battery will last. If it makes it through a... wearing event... then that's at least met the goal.

Anyway, I've waited until now to share the design because I wasn't sure it was going to work, what with the concerns about the battery being able to supply enough current. But now that I've seen it go... The firmware is up on GitHub, and the board design is at OSH Park.

Basic Toast-R-Reflow controller design validated

Well, the Toast-R-Reflow project is now officially "ready for prime time."

The design of the power and controller boards and functionality of the firmware have been validated in the field, and that means that if you want to play with reflow paste, I've got a pretty good starting point.

Here's what you need:

1. A toaster oven. I used the Hamilton-Beach 31138.
2. A K type thermocouple. SparkFun sells them.
3. An OpenEVSE LCD backpack. You can get those from the OpenEVSE store.
4. A Toast-R-Reflow power board. You can get one from my SquareUp store as a kit.
5. A Toast-R-Reflow controller board. You can one from my SquareUp store as well. Those come assembled and programmed because they're made from surface mount components, and if you're building a reflow oven that's a chicken-and-egg problem.

If you buy either board from my SquareUp store, it includes an instruction pamphlet as well. Of course, it's open hardware, so you're more than welcome to do it all yourself, if you prefer.

Now that the basic controller design has been validated, the next step is the all-in-one controller/backpack. Stay tuned…

Today is a very "meta" day

The board for the first version of the reflow oven controller that actually had a chance of working arrived. And so the reflow oven controller on the breadboard toasted its last board - it created its own replacement.

From what I can tell, the AD8495 is doing its job perfectly. The software may need some tweaking, though, because the temperature being displayed doesn't really jive with the voltage being presented on the V.temp test point.

The latest firmware has some code in it that attempts to self-calibrate the D/A converter. That may be getting in the way. It seemed to help on the breadboard version of the circuit, though.

The board is going to get a couple of tiny tweaks, but I think the really big deal is going to be the LCD "backpack" version of the controller - the whole thing will be all-in-one!

Note that the thermocouple wires are just sort of stuck in the holes. The connectors for that haven't arrived yet.

AD8495 KickStarter

I've got the AD8495 breakout board listed in my Square store for $7.50 along with $6 for standard per-order shipping. That's based on single-unit-quantity pricing for the parts.

If I could buy 1000 of them, I could drop that price down to $5 each, and $2.50 shipping via first class mail - a $6 savings.

Of course, if I buy the parts for 1000 of them and nobody wants them, I've lost my shirt. I don't want that.

So I'm going to KickStarter. The project isn't up yet, but I anticipate it will be in a week or so. Backers can sign up to buy a complete breakout board for $5 + $2.50 shipping, and they'll ship basically as quickly as I can get the parts, assemble and build them (probably 3 weeks or so).

The AD8495 is a great alternative to the AD595, and at $5, this project is just a bit more than a third the cost. You need to use a thermocouple when you're planning on high temperature monitoring, like for a reflow oven. Feed it 3-30 VDC and you get out a voltage of 5 mV per ºC, ±3 ºC max (per the data sheet for the less expensive A grade part. The C grade is ±1 ºC, but it's twice as costly).

AVR ISP breadboard adapter in action

Here's my AVR ISP adapter in action:

It's connected up to an ATTiny85 that's programmed and wired at the moment as my reflow oven controller.

You can find the board in my OSH Park profile. I'm not going to offer them for sale other than that, because they're the same thing as the SparkFun ISP adapter, and if you want just one, they sell theirs for only 95¢. The big difference, though, is shipping - you'd have to pay for shipping from SparkFun, but in principle, you could order a bunch more stuff to make up for that. You can get free shipping from OSH Park, and they're only 93.3¢ each, but you need to order them 3 at a time.

AD8495 Breakout Board now available

I've thought about how one might go about making the Toast-R-Reflow project more versatile for all the different folks out there who might want to make one.

The constant in the equation is the power board. It's the one piece of the project where all the hazardous parts are concentrated, and I don't see any particular need to fiddle around with its design.

The controller is another story. Some folks might want to try to build the controller into the oven, some might like the "backpack" controller concept, while some might want to use their own i2c display backpack, which means a separate controller. Others might want to breadboard it (like I did with the original prototype), and still others might want to build theirs with an Arduino Uno so they can re-use the Uno for other things.

Once you have a converted toaster oven with the power board installed, there are only three building blocks remaining of any consequence: the thermocouple interface, the microcontroller itself, and the user interface.

For the thermocouple, you need a thermocouple amplifier and a K type thermocouple. My original prototype used an AD595, but that chip is quite expensive. Analog Devices makes a newer part that does the same job at about a third the price - the AD8495. The only problem is that that part is an MSOP, which when you're building a reflow oven represents a chicken-egg problem. I've designed and now offer for sale a solution in the form of a break-out board. It has the AD8495's reference design constructed with SMD parts with a 3 pin SIP header for convenient mounting on a breadboard. Simply supply it with power and it will output a 5 mV per ºC voltage - perfect for feeding into an Arduino analog pin.

As for the oven, you can simply connect a 220 ohm resistor to two digital output pins and then to the power board. Setting the pins high will turn on the respective heating element.

The only part left is the UI. The Toast-R-Reflow firmware is designed to talk to the AdaFruit RGB shield (or OpenEVSE RGB LCD backpack), but you could instead use serial I/O and the Arduino serial monitor to do the same job.

LCDuino design updates

I had a great idea today... I'm going to make the bottom 6 pins of the I/O connector match the pinout of the standard 6 pin AVR ISP connector. I should be able to use my pogo adapter to fuse and boatload the chips before installing the I/O connector that way. Of course, anyone who needs to re-load the bootloader in the field can make an adapter. Or, perhaps, they could try and cram an ISP 2x3 socket on the bottom 6 pins, but I think the end of an IDC DIP socket is wider than the pin pitch, so that probably won't work too well.

Meanwhile, I'm having trouble figuring out the best pin count to use on that plug. It looks like 2x13 (26 pin) is the best choice for the female end, but the goal is to have the other end end in an IDC male .3 or .5" DIP plug, and it looks like those come only in 24 pins, from what I can tell. I'm not sure what to do about that. If anyone has any bright ideas, I'm open to suggestions.

The other big connector should be easy - 2x7 is a fairly common size, and that's just female IDC on both ends. The other end will go to a "keyboard" board that has the 7 switches mounted on it (6 inputs to the MCP23017 and RESET).

LCDuino - Preliminary design

I've got an initial design for LCDuino. A board is up on OSHPark.

LCDuino is an LCD backpack. That is, it's the same size as a 2x16 LCD display circuit board, with mounting holes that line up, and there's a SIP header that lines up and connects to the LCD.

This backpack has an ATMega328 TQFP, an FTDI FT232RL, and an MCP23017 i2c GPIO chip. The FTDI chip is configured to connect to D0 and D1 just like an Arduino Uno. DTR is capacitor-coupled to the !RESET line so that the Arduino IDE can upload sketches with the right bootloader. A4 and A5 are configured as an i2c bus and fed into the MCP chip, which is in turn hooked up to the LCD, just like the AdaFruit RGB LCD shield.

The board has two DIP headers. One is intended to hook to a board with the buttons on it, and the other is intended to go to a ribbon cable leading to a breadboard. D0-13, A0-4, A6 & A7, the i2c bus (SDA & SCL), AREF, !RESET, +5 and GND are available.

The board will have a micro-USB connector on it which will both supply power and provide serial I/O for sketch upload and serial monitor. Initial bootloader installation and fusing will be done with a jig on the GPIO connector to adapt it to ISP.

Here's the full schematic:

LCDuino

I've come up with a name for the LCD backpack Arduino clone. I call it LCDuino. Yes, the Arduino FAQ talks about how lame Italians think that <mumble>uino names sound, but I'm not Italian.

The board is turning out to be a bitch to route. I'm going to have to add a couple dozen more vias before I'm done.

I do, however, have an initial layout for the DIP header. It's going to be a 32 pin .1" DIP header. The intent is that on one end of a 32 pin ribbon cable you'll crimp a standard 2 row IDC socket, and on the other you'll crimp a .3" or .5" IDC DIP plug, which you will, in turn, plug into a breadboard.

Down one side of the header will be D0 through D13, then +5 and GND. Down the other side will be the 6 pushbutton pins from the MC23017 (yes, you get 6. I'm calling the last one "BACK". Why not?), the two i2c bus pins, then A0-A3 and A6 & A7 (A4 and A5 are actually the i2c bus. A6 and A7 are not normally available on an Arduino, but the TQFP ATMega variant adds them), AREF and !RESET.

The board will come with a select button and a reset button on the board, plus a 16 MHz crystal to make it Uno compatible. It'll also come with the 2.1mm barrel jack and a 5 volt regulator. It'll be good for a couple hundred mA in addition to the LCD, backlight and controller load, but more than that and you're on your own.

The board, at present, does have an ISP socket on it, but there's nothing to stop you from programming it by wiring your own ISP to +5, GND, D11-13 and !RESET on your breadboard instead.

So why bother?

Arduino shields just don't lend themselves to breadboarding. Yes, there's a breadboard shield, but if you  then stack the LCD shield on top of it, then you've effectively built the breadboard into a sarcophagus, making it a pain to adjust the circuit. The best I've been able to do with an Uno is use pin clips between shields to bring the signals off to a breadboard on the side. That works… but this will work better.

A display backpack arduino clone?

Most of the things I've made so far have interfaced to a 2 line LCD display based on the LiquidTWI2 library. Every time I've wound up making a small board with a 4 pin i2c connector to go off to the OpenEVSE LCD backpack.

It's just occurred to me...

Why not put the controller on the backpack? In fact, why not make the ATTiny equivalent of a combination of the Uno and the AdaFruit RGB shield, more or less?

I'm envisioning something the size of the LCD backpack that would have a power jack on it, an ATMega328 TQFP, an MCP23017 wired up to an LCD, all wired up to a pin header designed to connect up to a breadboard for adding whatever it is you want to prototype.

But what to call it? I'll have to think on that one.

Welcome!

I've been using Arduino to make handy little electronic things for a few months now, so it seemed like the time was right to make a home for all of my humble little creations.

I'm going to create a tag for each of the things you'll find here. At the moment, the list is…

1. The J1772 Hydra - a box that will safely charge two electric vehicles from a single charging station
2. The EV Sim Mark II - an electric vehicle simulator with pilot signal analyzer
3. Toast-R-Reflow - a toaster oven reflow conversion system
4. HandyTimer - a simple real time clock switching system
5. BlinkyEarrings - my first attempt at a wearable - it's the tiniest blinky LED thing I could fashion

So why the name?

Arduino is what got me into the hardware design arena at all. Even though I don't do a lot of work with Arduino shields anymore, I still use their IDE and library system for all the firmware authoring and uploading. I exclusively use Atmel Mega8 and Tiny controllers (at least as of this writing). Arduino was an Italian creation, so Geppetto is a nod to Arduino's Italian origins. Geppetto hand-crafted a thing that wound up with a life of its own - a little bit like the firmware adds a modicum of intelligence to a controller, and the circuit into which it is embedded.

It's going to take some time to fill in the content here, and over time I hope that there will be more stuff added.