06 September 2011

Arduino “Breadboard Helpers”

I think that everyone should breadboard an Arduino at least once (one approach here, another here). It’s a great learning experience that does a lot to de-mystify all that circuitry, or perhaps more correctly, it shows just how simple “all that circuitry” can really be.

For many projects, using breadboards makes a lot of sense to me. But after three or four times, it gets pretty repetitious, not to mention time-consuming and error-prone, putting all the basic wiring in place for the MCU.  I especially hate the FTDI and ICSP programming headers. My memory being what it is, I always have to refer to some cheat sheet to figure out all six connections for each!

I had the idea of using a pair of small breakout boards to make the repetitious part easier and allow me to get to the interesting part of the project sooner.  One board provides the FTDI header and the other provides the ICSP header.  I call them “Breadboard Helpers” (with apologies to Hamburger Helper ™).  With the first version of the boards, I concentrated mostly on the programming headers, although I added a reset button to the FTDI board and the Arduino “Pin 13” LED to the ICSP board.

Then I thought that I could expand the idea a bit and make things even easier.  So the second versions of the boards have the following features:

FTDI Breadboard Helper

ICSP Breadboard Helper
  • ICSP programming header
  • Arduino “Pin 13” LED and current-limiting resistor
  • AVcc bypass capacitor
  • Power supply bypass and filter capacitors
  • MCU power and ground connections
  • Under ¾ square inch

With Breadboard Helpers, I can literally breadboard an Arduino in less than a minute.  I don’t have to remember how to wire the programming connections, or worry about mixing up the power pins, RX/TX, or MOSI/MISO.  Plus, I end up with a much neater breadboard and more room for the rest of my project.

An Arduino-compatible made with Breadboard Helpers

The picture below is as compact as I think I can manage to breadboard an Arduino; 46 of the 5-position tie points are used, only leaving 14 available on this small breadboard. There’s only room for an 8-pin DIP device. I didn’t watch the clock, but I’d bet it took me the better part of an hour.

Identical circuit as in the above picture, made with individual components.
Not much room left on a small breadboard.

A couple things to note with Breadboard Helpers.  First, if you’re doing ICSP programming, you will need one wire to go from the RST pin on the ICSP board to MCU pin 1, the reset pin (this is the green wire in the first picture above).

Second, I have two kinds of breadboards.  The larger ones have the holes in the power rails aligned with the holes on the main part of the breadboard.  The smaller breadboards have the holes in the power rails staggered relative to the main part.  Breadboard Helpers have two positions for the power pins, to allow them to be built to work with one type breadboard or the other.

Breadboard Helpers are also flexible.  Several of the parts can be eliminated if you don’t plan to use them, and can be added later if needed.  Not doing ICSP programming?  Leave the 2x3 header off.  Don’t care about the LED?  Leave it and its resistor off.  If you’re using a resonator that has built-in capacitors, then the crystal loading capacitors aren’t needed of course.  If you don’t have any worries about power supply filtering, the small electrolytic capacitors can be eliminated; however, I do recommend retaining the 100nF bypass capacitors.

If you’d be interested in Arduino Breadboard Helpers, leave me a comment.  If there’s enough interest, I might put a small run of kits together (soldering required!).

If you'd like to roll your own, the Eagle files are available on github, and a bill of materials with all the components needed, including the microcontroller and a breadboard, is available on the Mouser web site.  Note that if you order the microcontroller from Mouser, it will need to be programmed with an Arduino bootloader.

11 August 2011

Engineer humor

I received an email yesterday that I get occasionally from National Semiconductor, announcing new products and the like.  I was reading the datasheet for one of the new ICs and it had a couple terms in it that made me chuckle, and that made me think of this, one of my favorite datasheets of all time (tells you something about a person, doesn't it, if they have such a thing as a favorite datasheet).

Anyway this is a scan from my 1982 National Semiconductor Linear Databook.  I think the part that really did it for me is the first bullet under "Features".  Yes, it's a real device, although now obsolete I believe.  Evidently the name stuck for some years until the forces of political correctness prevailed.  Too bad.  Some people just aren't any fun at all, damn them.

Click to enlarge

21 July 2011

Arduino Thermocouple Library

This is a very simple library that I wrote earlier this year, I've just now added a couple example sketches and some documentation, so that folks might actually stand a chance of figuring it out.

The library works in conjunction with the standard Arduino SPI library to interface one or more MAX6675 Cold-Junction-Compensated K-Thermocouple-to-Digital Converters from Maxim Integrated Products.

I've posted the library on github, click the Downloads button to download the library, examples, and ReadMe as a .zip or .tar.gz file.

Questions, comments, suggestions, gripes, etc., always welcome!

02 May 2011

The Evil Arduino

I can't help but like a place called Evil Mad Science. I picked up a couple of their ATmegaXX8 Target Boards and a couple ATtiny2313 Target Boards with the intention of using them to do ICSP programming. I realized that with the addition of a few common components, the ATmegaXX8 Target Board could do that and also be used as a basic Arduino clone. EMS also has a good price on Zero-Insertion Force (ZIF) sockets which are great if you're swapping the MCUs in and out a lot.

So this is kind of a simple-minded project and I'd be surprised if it was an original idea, but I thought I'd show how I used EMS' "fine DIY and open source hardware" to make a simple Arduino clone. Just a fun little project that can be tossed together in about an hour.

On the other hand, a person could just go with EMS' Diavolino kit. At $13, it could well be cheaper than the target board approach, especially if you don't have the incidental components laying around as I did. And the Diavolino also has the Arduino form factor. So it depends what you want. The target board approach has more of a DIY flavor as opposed to a kit.

Parts list:

C1,2  18pF ceramic, or as needed to match crystal*
C3-6  100nF ceramic
C7    10uF 16V electrolytic
IC1   ATmega328P
LED1  Red garden-variety (Pin 13 LED)
LED2  Green garden-variety (Power LED)
Q1    16MHz*
R1    10K
R2,3  1K
S1    SPST MC NO Tact switch
n/a   ZIF or other 28-pin DIL socket
n/a   Evil Mad Science ATmegaXX8 Target Board

*EMS sells a 16MHz Crystal and Capacitor Set, which is what I used, but of course they could also be purchased individually, or a resonator could be used instead.


Arduino-compatible built on EMS target board

Action shot ;-)

01 May 2011

Engineers are some of the most fun people in the world

Sorry but this one is off-topic, and partly brag. Anyone who thinks that injuneers ;-) are not absolutely some of the most fun people in the entire world need look no further than Dean David C. Munson, Jr. of the University of Michigan. Dr. Munson is the Robert J. Vlasic Dean of Engineering at the U of M College of Engineering.

Yesterday we attended my daughter's graduation ceremony and we're very proud that we now have two generations of engineers in the family, and also two generations of Eta Kappa Nu members!

My Favorite Engineer

Dean Munson presided over the College of Engineering's graduation ceremony. Before the graduates were presented their diplomas, he explained that, in part due to the swine flu scare of 2009, various congratulatory rituals could be used in lieu of the traditional handshake. Alternatives included bows, high-fives, fist bumps, and chest bumps. As you may be aware, graduation ceremonies can tend to drag a bit, and this one was late in the day, after quite a long day. But certainly I have never been to one that held my attention more; this one will be a tough act to follow. If the Dean calls in sick Monday with bruised ribs, I'm sure that everyone will understand.

Dean David C. Munson, Jr., Coolest Dean In The World,
conferring a degree on an engineering graduate

28 April 2011

A "Minimal" Arduino/XBee/Pachube Sensor Network

One or two people have asked in online forums for code from my sensor network, and while I'm usually happy to share, it's full of a lot of extraneous stuff (RTCs, NTP, displays, thermocouples) that might not be of interest to everyone, but more importantly, that probably only obscures the fundamentals of XBee networking and communicating with Pachube.

So with that in mind, I cut out the extraneous stuff, and just left the bare essentials: A remote sensor unit which transmits a single reading from a photocell once per minute to a base unit which connects to the internet and forwards the data on to Pachube.

Bill of materials -- Base unit:
(1) Arduino Uno, Through-hole or SMD edition
(1) Arduino Ethernet shield
(1) XBee ZB low power Zigbee Module, Digi Product ID XB24-Z7CIT-004, XB24-Z7WIT-004, XB24-Z7SIT-004, or XB24-Z7UIT-004 (these differ only in the antenna, they are functionally equivalent)
(1) Adafruit Industries XBee Adapter
(1) LED for heartbeat (optional)
(1) 330-ohm resistor for heartbeat LED (optional)

XBee configuration:
  • Load the Zigbee Coordinator API firmware (I'm using Version 2170).
  • Set the PAN ID as desired, to match that of the sensor unit(s).
  • Set API mode 2 (AP=2).
  • Set baud rate to 9600.

Bill of materials -- Remote unit:
(1) Arduino Uno or similar (Through-hole, SMD edition, Boarduino, etc.)
(1) XBee ZB low power Zigbee Module, Digi Product ID XB24-Z7CIT-004, XB24-Z7WIT-004, XB24-Z7SIT-004, or XB24-Z7UIT-004.
(1) Adafruit Industries XBee Adapter
(1) CdS photocell
(1) 10K resistor

XBee configuration is same as above, except:
  • Load the Zigbee Router API firmware (I'm using Version 2370).

Here are the sketches.  Unzip into the Arduino Sketchbook folder.  Before uploading, be sure to disconnect the XBee from Arduino pin 0.  Also be sure to enter your MAC, IP, and Pachube API key in the base station main module, and your Pachube feed number and the address of your network coordinator XBee in the main module for the remote unit.

Here is the Pachube feed. Pretty boring, but at least you can see that it does work. Not sure how long I'll leave it running, probably until I need the parts for something else!  Feedback and questions welcome!

Note that in the following wiring diagrams, the XBees plug into the Adafruit adapter, which in turn plugs into the breadboard. The XBee pins do not (in fact, cannot, spacing is different) connect to the breadboard.  The adapter plugs into the breadboard, this is represented by the 10-pin header below the XBee.

Wiring the base unit

Wiring the remote unit

My base unit

My remote unit (using a Boarduino)

08 February 2011

Easy NiMH discharge curves

This post is a bit of an aside, or at least it started out that way.  I thought it worth noting though, because it's a good example of how quickly and easily a new Arduino/Pachube application can be put together, once you have some basics in place.

A friend was having some difficulty with some older NiMH rechargeable batteries (actually AA cells).  He'd charge them up, but when he put them in his camera it would immediately complain that the batteries were low, and it wouldn't turn on.  The batteries seemed OK when checked with a voltmeter, reading 1.4V or a little better (the nominal voltage for NiMH cells is 1.2V).  My friend was aware that batteries are best tested under load, and I gave him a few resistors for that purpose, and he went off to try again.

In the meantime, I was looking at my recently-completed XBee/Arduino/Pachube lashup (see prior post) and a light went on.

I wired up two NiMH cells with resistors for loads, connected them to two analog inputs on the Arduino, added a few lines of code to the Arduino sketch, and literally within 10 or 15 minutes I had Pachube collecting the voltage data once per minute (in addition to the temperature data that I was already collecting).  It's taken me a lot longer to write this post than it did to get the thing working in the first place!

Now I could produce nice discharge curves for two batteries simultaneously.  It was just a matter of popping them into the battery holders, then waiting for 8 or 10 hours while they discharged and Pachube collected the data.  In the end this gives a heck of a lot better picture of what's going on than could have been accomplished with a voltmeter, and with a lot less effort!

This first chart shows two cells that I had.  The first was relatively new (~8 months old), and the other a few years old, and while I no longer used it in my camera, it still seemed to work OK in my old iRiver MP3 player.  You can see Cell A held 1.2V for six hours or so, but Cell B dropped below 1.2V after about only an hour.  What surprised me is that the curves aren't that different, just shifted down for the older battery.  If you do the math on the mAh capacity, it comes out pretty close!

The second chart shows two of my friend's cells that wouldn't work in the camera.  Cell C looks similar to my Cell B, but Cell D drops below 1.2V almost immediately, and after an hour, is below 1.1V.  Note the sharp initial drop in voltage.  This leads me to suspect that as these cells age, their internal resistance goes up, while overall capacity may only decline modestly.  This is contrary to my gut feel; when a battery doesn't work I think it's dead, empty, out of capacity.  Actually these older batteries might work OK in devices that aren't terribly voltage-sensitive.  Obviously the cameras watch the voltage pretty closely and let you know about it when it drops only a few tenths of a volt.  But consider the challenge: You need to know you're running low far enough in advance of the knee in the curve, because things go south in a hurry then.  And the camera has to make some sort of assumption about the quality/age of the cells.  Or maybe the camera people are just in cahoots with the battery companies ;-)  A 5-ohm load was used on all cells.

25 January 2011

A simple wireless sensor network

A lot of pieces come together in this project.  It seems to be working well; I'm pretty happy with it.  I'll jump right in and give a high level description of the pieces.

I started this blog with digital clocks and this project starts with one as the sensor unit.  It consists of a Arduino Pro Mini 328 (check the size of that guy!), a "Chronodot" Real-Time Clock (RTC) module from Macetech based on the Maxim DS3231 chip, and an XBee ZigBee module from Digi International (part no. XB24-Z7WIT-004).  Just for fun and to generate a little more data to collect, I connected a simple Cadmium-Sulfide (CdS) photocell to one of the Arduino's A/D inputs to measure light intensity wherever the sensor unit happens to be.  The readout is a 16x2 LCD from Sparkfun.  See the picture below.

Sensor Unit.  L to R: Arduino, RTC, XBee, Photocell and XBee status LEDs, power supply.

A few words on the parts.  The Arduino Pro Mini has the same ATmega328 microprocessor and basic specs as the Arduino Uno, but is much smaller!  I soldered on headers so it would plug into a breadboard.  What it doesn't have is a power supply or a USB interface.  Both Sparkfun and Adafruit make nice little breadboard power supplies that work great and accept the same wall wart input as the Uno.  As for the USB connection, you'll need an FTDI breakout board (about the size of a small postage stamp) and FTDI drivers to do the interface.  Once you have that (and it's pretty easy), the USB interface works pretty much the same as the Uno.

The DS3231 RTC is pretty cool too.  If you keep it between freezing and about 100°F, it will keep time within two parts per million, which is about a minute per year.  It accomplishes this by monitoring its own temperature (a major cause of oscillator drift) and switching capacitors in and out of the crystal oscillator circuit to trim the frequency.  The crystal itself is on-chip which also helps accuracy.  A very sweet piece of engineering.  In addition to the date and time, we can also read the temperature from it (in °C to the nearest quarter degree).

Last we have the XBee module, which uses the ZigBee specification, based on the IEEE 802.15.4 standard.  These modules are low power and don't offer terribly high bandwidth, which is just fine for sensor networks which tend to send very small amounts of data at any one time.  The really neat thing is that XBee modules form themselves (with just about zero help from you!) into self-healing mesh networks.  They can be configured either as network coordinators, routers, or end devices.  Every network must have exactly one coordinator.  Routers can do anything an end device can, plus forward messages between devices.  End devices cannot route traffic, and must do all their business through a parent node which is either a coordinator or a router.  Additionally, end devices can sleep in a low-power mode which would be very good for battery-powered remote sensors.  If an end device is sleeping, its parent node will store traffic for it.  The XBee in my sensor module is configured as a router.

Now we come to what I call the "base" unit.  This consists of an Arduino Uno, with an Ethernet shield added on top and connected to my internet router.  Also we have an XBee module, configured as the network coordinator, and a seven-segment LED display.

Base unit. Arduino and Ethernet shield at top. XBee, status LEDs, temperature display on breadboard.

The whole thing works like this.  Once a minute, the sensor unit sends the temperature and light intensity data to the base unit.  The base unit sends the data to Pachube (click here to go to the Pachube feed for this project) and displays the temperature on the LED display.  We can then download the data from Pachube, or have it create charts like below.  These are live charts and will refresh every few minutes (not sure how often exactly, haven't found the spec on Pachube yet).  So if you refresh this page, you will see current data, assuming that a cat hasn't chewed through any wires on my end in the meantime.

DS18B20 Temperature Sensor

It would be straightforward to add additional sensor units to this project.  One idea I have in mind is to measure the temperature of my wood stove with a thermocouple.  Maybe send a text message to my mobile phone if it got over a certain temperature.

Hard work!

Boy this blogging is hard work.  Takes a lot of time.  I've been having way too much fun with the technology to blog about it.  My intent was to document steps along the way.  I'm going to break away from that for now, then come back and catch up later.  So the next post will be where I'm at currently, which is a sensor network which consists of two Arduinos talking together via XBee radios, and sending data up to Pachube.com.

12 January 2011

What, actual numbers?

Binary clocks are lots of fun, but most people appreciate base ten.  I used to have a binary clock on my desk at work, and people would ask, "What is that?"  Before they could recover from the cognitive dissonance caused by the short answer ("It's a clock, can you tell what time it is?"), I'd rattle off the time to them, down to the second.  They'd check their watches and shake their heads.  I'd say, "It's binary.  You can read binary?  This is a computer company..."  (Actually it was a BCD clock, but that was a finer point I usually didn't want to get into.)

In order to move on with the clock project, we'll need to add hardware, namely a display, and software to run it.  I always like to test things out by themselves to make sure I understand them before using them in conjunction with other components.  This is called unit testing.  The only objective here is to understand how to hook up a display and talk to it, so that we can make it display whatever we want.

I chose to use a Sparkfun 7-segment serial LED display.  This seems to be a simple enough display, not very imposing, just four digits.  Appearances are deceiving.  This display can communicate in two different ways (!) and it uses the same microprocessor as the Arduino (!!) to manage the communications and drive the LEDs.  So maybe not so simple.  Witness the abundant, ummm, grousing in the forums regarding defective displays of various type and manufacture.  There seem to be lots of displays that just don't work correctly right out of the box, they just display gobbledegook and otherwise behave strangely.  Well like I said, not so simple, we are not dealing with a light bulb here.  Several things have to be done correctly.  Wiring it up for starters, and then getting the software right.  Depending on how a display communicates, there may be a couple or many parameters that have to be correctly set, and if any one of them is off, then we won't get anything useful on the display.

Now I certainly had my share of gobbledegook at first with this display.  But I assumed (correctly ;-) that the display was OK and that the trouble was in my program, and indeed it was.  Bit of a learning curve.  Maybe by reading this, yours will be shorter.  Anyway, I like this display a lot.  I can operate it in either communications mode and it works nicely.  So let's get on with it and demonstrate both methods.

The first method is sometimes called just "serial" communication, or (better) "serial TTL" communication.  This is a variation of the RS-232 communication standard that uses the 0-5 volt levels associated with transistor-transistor logic (TTL) integrated circuits.  For two devices to communicate in two directions, serial TTL requires two wires, one to send on and one to receive on.  One device's send line is the other's receive line and vice versa.  Since we will only be sending commands to the display (it's polite and never talks back), we'll only need to connect a single wire to the display in addition to the power connections.  Note that you will see the abbreviations RX and TX for receive and transmit.

The second method is called a Serial Peripheral Interface bus or SPI.  This is similar to serial TTL in that there are two lines for receive and transmit, but there are two more lines, one called a (serial) clock, and one called slave select.  The clock is used to time and synchronize the data bits sent over the receive and transmit lines.  But they're not called that; when you invent a new communication protocol, you need new terminology, so SPI doesn't use transmit and receive, but Master In Slave Out (MISO) and Master Out Slave In (MOSI).  One big difference is that SPI can connect more than two devices on the same set of wires (which is what makes it a bus): One master and one or more slaves.  Of course they cannot all talk at the same time, or things would get all confused.  So to ensure polite conversation (one at a time, please!) each slave device has a slave select line which the master controls to tell the slave that it's ok to communicate back to the master.

There are pros and cons to the two methods.  SPI can send data faster, but requires more wires.  For this project, there really isn't much advantage to one method over the other, since we won't be pushing the limits of either.  But it's a great learning opportunity to become familiar with both methods, so we will do just that!

With that as background, check out my sketch demonstrating serial TTL communication.  I tried to include lots of comments, not just on the software, but also a description of how to wire up the hardware.  This sketch can use either the Arduino SoftwareSerial library which comes with the Arduino software, or the NewSoftSerial library which has many improvements (see my Arduino Libraries and Hardware page for a link to download NewSoftSerial).  I've read a lot of less-than-flattering comments on the SoftwareSerial library.  In fact I'm not sure if they still apply, whether issues have been addressed, or whether it has just sort of been abandoned and is no longer being actively developed.  Many people prefer the NewSoftSerial library instead, which works the same from a programming standpoint.  I tried both, and they both work fine for this project, but this is a simple project not likely to test library limitations.

Display connected for serial TTL communication.  Note only one wire for the data and two for power.

Yet to come: SPI comments, picture, link to sketch...

11 January 2011

First project

I gave the kids Arduino Inventor Kits for Christmas, you can read all the gory details on my About page.  If you'd rather cut right to the chase, I was way more impressed than I had expected to be, to the point that I decided to jump in to the world of Arduino myself.

I needed a first project and really didn't have to think.  I've always liked digital clocks so that seemed like a natural.  (This may go back to high school, when I built a digital clock from small-scale TTL integrated circuits.  I still have it, and I think it still works.  Maybe a topic for another time.)

So I ordered up a bunch of hardware, and luckily the Arduino Uno came first, along with a real-time clock (RTC) module.  The seven-segment LED and LCD displays were taking longer.  So I borrowed eight LEDs and a shift register from my son's kit and went at it.  I could have used some old individual 7-segment LEDs I had kicking around, along with some 7447 TTL BCD-to-7-segment decoder/drivers, but that gets to be a lot of hardware on a small breadboard and I had better ideas coming anyway.

The requirements for the first project were therefore:
  1. Read the date and time from the RTC via an I2C interface,
  2. Write to the shift register via an SPI interface, in order to
  3. Display the seconds in binary on six discrete LEDs, and finally,
  4. Write the complete date and time back to the Arduino serial monitor.
Good enough to know it's working, and also to check the accuracy of the RTC.  More on that later.

Lessons learned

Libraries needed for the project

Connecting the shift register and talking to it with SPI

Connecting the RTC, setting it, and talking to it with I2C

Sketch code
void setup() {

void loop() {