04 April 2013

How Long Was The Power Out?

I’ve always liked clocks, and especially digital clocks, since I built my first one using TTL ICs back in high school. What I don’t like about mains-powered digital clocks is that many of them need to be reset when power is lost.

Our power has been quite reliable lately, but I can remember coming home from work many times to find all the clocks blinking, and of course the first question was always, “How long was the power out?”

For years my answer to this question was to keep an inexpensive synchronous electric clock in my workshop. (For you youngsters, these are mains-powered analog clocks that derive their timing from the utility frequency via a small AC synchronous motor. They have the characteristic of simply stopping when the power goes out, and when it comes back on, they begin running again right where they left off. Hence it is a simple matter to determine how long the power was out.)

I became increasingly dissatisfied with this solution, as in recent times the clocks didn’t seem to last that long before the motor became noisy, and then they either stopped or no longer kept accurate time. They just don’t make ‘em like they used to.

Last year I began experimenting with Microchip’s MCP79412 Real-Time Clock/Calendar. This chip has several nice features, not the least of which is the ability to store power-down and power-up times associated with a power failure. Not long after I had designed a breakout board for the MCP79412 and written an Arduino library to accompany it, there was a discussion on the Arduino forum about logging utility power outages.

It occurred to me that the MCP79412 could form the heart of such a logger, using its memory in conjunction with the power-fail time-stamps to create a simple Arduino-based “Power Outage Logger”. It seemed like such a neat project that I went ahead and designed a circuit and had boards made. My MCP79412 breakout board plugs in as a daughter board, as does a standard 16x2 LCD display.

The <2> on the display indicates that two outages have been logged.
The red LED indicates that the most recent outage has not been viewed.
The logger will record up to seven outages in the RTC’s static RAM. After a new outage occurs, an LED is illuminated. Using the buttons, the user can scroll through the outages on the display. In addition to setting the date and time, the user can select from several time zones, set the RTC’s calibration register to trim its accuracy, and clear the log.

Displaying the second outage logged, which was ten minutes long.

Ironically, since I built the Power Outage Logger, we haven’t had any actual power outages. There has been scant evidence so far, but they tell me that spring (which can bring storms and maybe some real power outages) is in fact on its way. I hope I haven’t jinxed myself by writing that, but if nothing else, the logger does make a nice little desk clock as well.

The main board with the display and RTC removed.

The Power Outage Logger is an open source project. Hardware design (schematic and board) and software are both available on github.

24 September 2012

Simple XBee ZB (Series 2) P2P Communications

Some folks have difficulty using the XBee Series 2 modules (now called XBee ZB) for simple point-to-point communication in transparent (AT) mode. For this reason, the XBee Series 1 modules (now called XBee 802.15.4) are often recommended for simple P2P applications, with the S2 modules being considered "too complicated".

I disagree with this recommendation because the XBee ZB modules are more capable (and are perfectly capable of simple P2P communication), their radios are a little better than the XBee 802.15.4 modules (both in transmitter power and receiver sensitivity) and they even cost a couple bucks less. With a pair of ZB modules, if you ever want to try mesh networking with three or more nodes, there's nothing else you need to do (except to buy more modules).

The downside is that the XBee ZB modules do require some configuration to establish a P2P link. (I have not experimented with the XBee 802.15.4 modules myself, and I have heard conflicting stories regarding whether a pair can be used as a P2P link "out of the box" without further configuration.)

Getting to the point, I was discussing an XBee ZB issue on the Arduino forum the other day, when I hit on what I think is the minimal amount of configuration required to establish a point-to-point, transparent mode (AT) link with two brand-new XBee ZB modules right out of the box.

First, two assumptions. One, we assume that the modules come from the factory with the Router AT firmware loaded. I think this is a pretty good assumption, all the ZB modules that I have came this way (and BTW, the interface speed is set to 9600 baud). Two, we assume that there are no other XBee networks operating nearby. This is probably a good assumption for folks with their first pair of XBees, but more on that later in case it's not a good assumption for you.

It turns out that there is only one step required to get the new pair of XBee ZBs talking! Using Digi's X-CTU program, load the Coordinator AT firmware on one of the two modules. (Every XBee ZB network needs to have exactly one coordinator, so the first thing when setting up a network is to satisfy this basic requirement anyway.)

This works because the modules' default value of zero for the network ID (PAN ID) causes the coordinator to select a random PAN ID and causes the router to join any PAN ID available. Hence there is a potential issue if there is already another XBee network operating, the router may join it instead of talking to the new coordinator. If this is the case, then there is an additional step: The PAN ID for both units needs to be set to some non-zero value different from that of the other network(s). I like to always set the PAN ID anyway, since what passes for normal around here seems to be a minimum of two separate XBee ZB networks in simultaneous operation, but if you just have that first pair of modules, then more than likely you don't have to worry about it (unless your neighbor hasn't come out of the closet about his XBee addiction).

The other thing that makes this work is that the default destination address (DH and DL parameters) will be zero for the router and 0x000000000000FFFF for the coordinator. Zero is a special address that causes the router to send its traffic to the coordinator. 0x000000000000FFFF is also a special address called the broadcast address. This means that the coordinator will send to every other node on the network.

To broadcast or not to broadcast

As it turns out, using the broadcast address is OK for a simple demonstration with two nodes, but in general, broadcast transmissions should be used sparingly because they cause a lot of network overhead, and this can be significant on larger networks. In the case of two nodes, it's easy enough to avoid and just have the coordinator address its traffic directly to the router. First determine the router's 64-bit (16 hex digit) address. In X-CTU, it's the SH (Serial number High) and SL (Serial number Low) parameters. It's also printed on the label on the bottom of each XBee. SH and SL are each 8 hex digits, and the high part will always be 0x0013A200 for XBees made by Digi International. The low part will be a unique number, for instance 0x406B85A5. Next, connect the coordinator to X-CTU and set its Destination address High (DH) and Destination address Low (DL) to be the router's address. This will cause all transmissions from the coordinator to be unicast transmissions rather than broadcast, and to be directed to the router.

Well this post ended up a bit longer than I thought it would. I hope you stuck in there, and I hope it was useful. I hope to expand on this in another post at a later date, with more details regarding loading firmware, setting parameters, and connecting the XBees, but I wanted to get the thought out there for now. Happy networking!

14 September 2012

Yet Another Real-Time Clock

The MCP79412 RTCC Breakout Board is now available on Tindie.com.

Real-Time Clocks (RTCs) are popular add-ons to microcontroller projects. I am no exception, I have a lot of them kicking around. The most common RTC seems to be the Maxim DS1307. A lot of my RTCs are DS1307s. It's a real workhorse chip, and easy to use. Still, it has disappointed me in a couple ways. For one, it's not always as accurate as I would like. I've used inexpensive no-name crystals and I've used more expensive ones from the top-shelf distributors. Sometimes they don't even seem to operate within the crystal's specs (typically ±20ppm). Not sure why this is, and it certainly could be my fault, but there it is. Another thing is that sometimes I have a 3.3V microcontroller circuit, but the DS1307 requires 5V.

Another alternative is the Maxim DS3231 (or its SPI relative, the DS3234). I love this chip, it is so cool. The integrated, temperature-compensated crystal makes it very accurate (±2ppm from 0°C to +40°C), and it will operate on 3.3V. This addresses all of my gripes with the DS1307. But it is more expensive, nearly $9 from Mouser in single quantities as I write this, where the DS1307 is about half that. (Yes, I know DS1307s can be had for significantly less from other sources.) But the DS3231 is harder to find at discount prices, and is only available in a surface-mount package if that makes a difference to you.

Enter the Microchip MCP79412. It operates off a crystal similar to that used by the DS1307, so the basic accuracy is about the same. But, it can be calibrated by setting an internal register. It will operate down to 1.8V. And while it does require a few more external passive components than the DS1307, it costs only $1.23 in single quantities. I popped for ten and paid $0.98 per copy. Again, it is only available as a surface-mount component.

The MCP79412 has some other cool tricks up its sleeve as well, including alarms, tracking power outages, and EEPROM in addition to SRAM. I've detailed these in the table below.

To summarize, I've been tinkering with the MCP79412 on and off for the last couple months and have come to like it quite well. I designed a breakout board for it (pictures below) and wrote an Arduino library to support it. I've only used three of the ten chips so far, but they have all operated well within the ±20ppm spec of the crystal I chose. One unit seems to be within 2ppm, and so hardly needs trimming.

If you are also using this chip, or would be interested in it, I'd love to hear from you!

PS: For a comprehensive example using the MCP79412, see my Power Outage Logger project.

Real-Time Clock Comparison
Feature MCP79412 DS1307
On-Chip Calibration ±127 ppm N/A
Alarms Dual alarms (single output) N/A
Power Fail/Restore Timestamps Yes N/A
Unique ID 64-bit ID N/A
EEPROM 128 bytes N/A
Battery-Backed SRAM 64 bytes 56 bytes
Vcc 1.8 - 5.5V 4.5 - 5.5V
I2C Interface Clock Frequency 400 kHz (Vcc ≥ 2.5V) 100 kHz
Square-Wave Output 1, 4096, 8192 or 32,768 Hz 1, 4096, 8192 or 32,768 Hz


MCP79412 RTC Breakout Board, Top
MCP79412 RTC Breakout Board, Bottom

04 September 2012

Warning! One Million Ohms

This is a little microcontroller project I've been playing around with for a while now. Enough people liked it and encouraged me, so I am selling them as kits on tINDIE.com.



Amuse your friends and confuse your enemies! Keep the uninitiated away from your workbench or desk and out of your lab!
  • Great conversation piece or gag gift
  • Big, scary 1,000,000 Ω resistor in the middle of the board
  • Pre-programmed AVR microcontroller (ATtiny85)
  • Arduino-compatible, hackable open-source hardware and software Can be re-programmed with an ICSP programmer, using either the Arduino integrated development environment or WinAVR
  • Runs on two AA batteries (not included)
This soldering kit is an electronic version of an old joke known among physicists and engineers. Pressing the SELECT button turns the circuit on and causes the red LEDs to flash. To change the flashing speed and pattern, press SELECT again. Hold SELECT down to turn the circuit off, or it will automatically turn itself off after five minutes.

Stand it on your desk!

17 March 2012

Arduino Timezone and DST Library

The Timezone library facilitates time zone conversions and automatic daylight saving (summer) time adjustments. This is accomplished by setting a Real Time Clock (RTC) to Universal Coordinated Time (UTC) and then converting UTC to the correct local time, whether it is daylight saving time (a.k.a. summer time) or standard time.

The Timezone library is designed to work in conjunction with the Arduino Time library at http://www.arduino.cc/playground/Code/Time. To download and use the Timezone library, including documentation and example sketches:


  • Go to https://github.com/JChristensen/Timezone/downloads and download the file in the compressed format of your choice (zip or tar.gz) to a convenient location on your PC.
  • Uncompress the downloaded file. This will result in a folder containing all the files for the library, that has a name similar to "JChristensen-Timezone-42e98a7".
  • Rename the folder to just "Timezone".
  • Copy the renamed folder to the Arduino sketchbook\libraries folder.
  • Read the ReadMe.txt file!
  • 07 February 2012

    A high-tech night light

    Often I find myself working on small projects that might be categorized as silly and/or impractical. However, my aim is usually to learn something new and to have a little fun in the process. So here is an example of such a project that I've been tinkering with recently.

    Worlds highest-tech night light?  The two AA cells are underneath and connect via the connector on the upper left.


    This project is a night light that just consists of a common 5mm LED for the light, an ATmega328P microcontroller, two AA cells, and a minimum of other parts. The twist is that the LED turns on at sunset and off at sunrise, adjusting its on and off times automatically day by day throughout the year, including adjustment for daylight saving time. I also added a piezo transducer to make some noise at sunrise and sunset. This was mostly a debugging aid to make it easier to check whether it was turning on and off at the right times. This project has several features of interest:
    1. Timer/Counter2 is clocked from a 32.768kHz crystal and configured to generate an interrupt every 8 seconds.
    2. The interrupt service routine (ISR) that handles these interrupts comprises a software real-time clock (RTC) that tracks hour, minute, second, day, month, and year (and adjusts for leap year).
    3. A friend found a function on the web that calculates sunrise and sunset times given day of the year, latitude, and longitude. (I tweaked it a bit, I think that I improved it some.) Combining this with the RTC makes it quite straightforward to turn the LED on and off at the appropriate times. (But I definitely do not get all of this astronomical right ascension and declination stuff!)
    4. I had previously written code to automatically adjust for daylight saving time, so it was easy enough to include (feature creep!) The rules which determine when DST starts and ends are stored in EEPROM. There is a small separate sketch to store the DST rules.
    5. Since the project runs on batteries, we want to conserve power. So in between interrupts, the MCU puts itself into Power Save mode, which keeps Timer2 running so that the RTC continues to keep accurate time, but powers off most of the other systems. An interesting point here is that the MCU can sleep regardless of whether the LED is on or off. Once the pin driving the LED is set, it retains its state while the MCU sleeps. While sleeping, with the LED off, the project draws right around one microampere. The Timer2 interrupt every 8 seconds serves to wake the MCU, update the RTC, and switch the LED on or off if appropriate. I haven't kept track of how long the battery will last, but I'm guessing at least a few weeks.
    When not sleeping, the MCU is clocked from the internal RC oscillator, running at 1MHz. Because of this, the sketch needs to be uploaded from the Arduino IDE using an ICSP programmer (I use Adafruit's USBtinyISP).

    I added the following entry to the Arduino boards.txt file, which is used for this project. Note the fuse byte settings. The extended fuse byte sets the brown-out detector level to 1.8V (to keep the MCU in reset if the battery gets too low), and the low fuse byte is the same as the factory default setting to give the 1MHz system clock.

     uno1.name=Arduino Uno ICSP @ 1MHz
     uno1.upload.using=arduino:usbtinyisp
     uno1.upload.protocol=stk500
     uno1.upload.maximum_size=30720
     uno1.upload.speed=19200
     uno1.bootloader.low_fuses=0x62
     uno1.bootloader.high_fuses=0xD6
     uno1.bootloader.extended_fuses=0x06
     uno1.bootloader.path=atmega
     uno1.bootloader.file=ATmegaBOOT_168_atmega328.hex
     uno1.bootloader.unlock_bits=0x3F
     uno1.bootloader.lock_bits=0x0F
     uno1.build.mcu=atmega328p
     uno1.build.f_cpu=1000000L
     uno1.build.core=arduino

    Even though the project works well, it's not what I'd call a practical project that will ever get past the breadboard stage. It ended up with a fair amount of code, which seems like definite overkill for a crummy night light (wouldn't a photocell be more straightforward?) But I figure why not, if I learned some things and had a good time with it. I hope you enjoy it too!

    The code and schematic for this project are available on github.

    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