Driving Cheap EBay OLED Displays With Arduino

Posted on March 18, 2013 by steve

Kozig OLED DisplayOver the last couple of years I’ve picked up a few little 128×64 OLED displays, mostly through EBay auction sniping.  These displays are similar to those offered by Adafruit, likely using the same chip-on-glass (COG) OLED display with a SSD1306 controller.  The Adafruit version gives you direct access to the controller, so the SSD1306 datasheet is all you need to write a driver.  In fact, Adafruit has released a perfectly adequate driver for their offering; it’s available from the link shown above.  For some reason, however, the designer of the displays that I purchased decided to put their own microcontroller between the exposed I2C bus and the SSD1306.  The only feature that I’m aware of which utilizes this intermediate microcontroller is an 8×16 font; devices using these displays would require a bit less memory, as the font is stored on the display itself.  Other than this rather dubious advantage, the controller is more hindrance than help.  Adding insult to injury, the command set for the display is completely undocumented; the only information I was able to find was a rather spartan Arduino sample application.  Contacting the EBay sellers failed to bear fruit.  They are completely clueless regarding how to drive the display.

I’ve got three different variants of this display, all labeled as “Kozig”; a couple of them refer to kozig.com, a site which resolves to a single login page. Not much help there. The three variants of this display that I have on hand are:

Kozig 128×64 I2C OLED Displays (EBay Special) 
Model I2C Pins Status
ZT.SCOI2CM2 (monochrome, white) 0×51 2×4 Working
ZT.SCOI2CM1 (bi-color: yellow, blue) 0×51 1×10 Working
ZT.SC-I2CMx (monochrome, white) 0×27 2×4 Pending

The displays with part numbers ZT.SCOI2CM2 and ZT.SCOI2CMx are mounted on a PCB with black solder mask and have a nice metal frame surrounding the display; this is what attracted my attention in the first place, as they should be slightly more rugged than the exposed glass displays (at least in theory.)  I’ve contacted several EBay sellers about their offerings, and they seem to all be selling the Kozig ZT.SC-I2CMx displays now; I was unable to find anyone offering the ZT.SCOI2CM1.  Note that the sample code that I was able to track down DOES NOT WORK with this newer display; in fact, as of today I’ve been unable to find a working block of code for this device. Edit: 03/26/2013: Received an email message from Alexander Steingass, who was kind enough to send along technical details for the ZT.SC-I2CMx displays along with a driver from Kozig.  Here’s the driver file for the sake of posterity:  ZT.SC-I2CMx

If you’re in the market for a nice, bright little 128×64 OLED display, I’d recommend purchasing directly from Adafruit; they actually support what they sell, and the price is only a couple of dollars more than the EBay offerings.  If, however, you’ve purchased one of these displays and are looking to use it with an Arduino project, read on.

I’ve written a little Arduino driver for these displays which should ease the pain of incorporating them into your designs.  This driver utilizes my AnyDisplay core and provides some nice features – optimized buffered drawing, different pen and fill modes (none, normal, clear, XOR), filled shapes, user-defined fonts and bitmaps as well as polar lines and points which don’t require floating point support.  Since the driver uses an in-memory buffer it does require a chunk of your Arduino’s precious RAM (128×64 bits, or 1024 bytes).  Optimized drawing requires another 128 bytes if you choose to enable it; it’s a case of display speed vs memory, and you’ll need to make that determination yourself.  The ATMega328 only has 2K of RAM, so display buffering takes about half of it.  I’m also working on a version which uses an external SRAM or FRAM as the display buffer that I can make available if there’s any interest.

The driver will be available on my GitHub page soon.  Comments are encouraged!  Do you have one of these displays?  Let me know by posting a comment!

Posted in Arduino | Leave a comment

Vintage Digital VT420 Terminal on Raspberry Pi

Posted on December 16, 2012 by steve

My first gig straight out of school involved supporting a large group of CAD drafters and engineers at a government facility. We used several different CAD systems at the time – AutoCAD on PC, DEC CALMA on Vax 11/785, and HP ME10 on quirky HP Apollo running UCSD P-System. Drafters using all of these systems submitted plot jobs to a big old Calcomp large-format electrostatic plotter. When I first took the job this was very much a manual process. The PCs were running a custom Ungermann-Bass network (ethernet came along a bit later) and plot jobs were sent to a central server on the network. I quickly grew tired of manually copying plot files around and developed a plotter queue application in C which would monitor a network share and automatically queued jobs to the plotter. The PC users loved it, as they got their hardcopy much faster than they had previously. The DEC and HP users quickly became jealous and begged me to extend this service to include them. A couple of classes and a lot of reading led to a very nice solution written in VAX assembly; the CALMA drafters got their plots much faster and the company ended up with another trained system admin for the 11/785.

Most of this initial development work was performed on Digital VT320 terminals. I always preferred the amber screens to green; they were much easier on my eyes, especially in the low-light environment that CAD drafters of the era preferred.

Fast forward a couple of decades. Sitting on my desk I have a $35 computer the size of a deck of playing cards with processing power an order of magnitude beyond that of the slightly more expensive VAX 11/785 that I used to support. What a cool industry.

A couple of weeks ago I was perusing eBay looking for treasures when I stumbled across an auction for a slightly used DEC VT420. The price was very reasonable, as was shipping. Since my Raspberry Pi is currently running headless, I thought it would be fun to put these two together and document the process. It was MUCH more straightforward than I had previously imagined.

The VT420 is a bit more modern than the 320 that I had used back in the day. The biggest advantage that I could see for this project is the 420′s multi-session support – it supports a whopping TWO SIMULTANEOUS SESSIONS running in either full-screen or “windowed” (split-screen) modes. The terminal supports text widths of 80 or 132 columns, and 25, 32, or 48 lines. Sweet!

Physical Connections

My terminal has two DEC MMJ (Modified Modular Jack) jacks on the back rather than the more ubiquitous DB9 or DB25 connectors that you may be accustomed to. From a purely physical standpoint, the MMJ jack looks like a 6-pin RJ45 with an offset latch connector. Fortunately, adapters are available online; I was able to find MMJ cables and DB9 adapters from a local firm, Pacific Custom Cables. If you are following along at home, I picked up two of each of the following: part number BC16E (DEC423 office cable, 3 foot length) and part number A9F12D (DB9F to DEC MMJ adapter). The office cable is available in custom lengths and is already configured as a null-modem (AKA “Crossover”) cable. The adapter has a molded-in female MMJ jack on one end and comes with a modular DB9F plug so you can configure the connection however needed. The following table shows how I wired the adapter:

MMJ Pin Color Desc DB9 Pin
6 White DSR 7
5 Black Rx+ 2
4 Red Rx- 5
3 Green Tx- 5
2 Yellow Tx+ 3
1 Blue DTR 8

Note: The offset tab on the MMJ connector is over pins 4-6. I clipped the metal socket off of the red pin and soldered it to the green pin prior to inserting it in the DB9 housing. For those interested in specific electrical details of this configuration, there is an excellent overview available at lammertbies.nl

I opted to use a USB-Serial adapter for this solution rather than using the on-board UART. There are many options available here – I’ve used several different Keyspan adapters with Linux in the past with excellent results. Since I did not have a spare adapter handy, I rolled the dice and ordered a cheap ($14 with free shipping) dual USB-to-RS232 adapter from eBay. The device I picked up did not claim Linux compatibility and is listed as a “Syba SY-ADA15033″ adapter. Turned out to be a good call – the Pi recognizes the device as an “IOCrest dual USB to serial adapter SY-ADA15033″; lsusb shows device ID 067b:2303, which is a Prolific Labs PL2303 chipset. Painless install; the Pi automatically loaded the pl2303 driver and created /dev nodes ttyUSB0 and ttyUSB1.

Configuring the Raspberry Pi

I am running the excellent Occidentalis Raspberry Pi distribution from the folks at Adafruit on my Raspberry Pi. Since this distribution is based upon Raspbian Wheezy, I would expect the setup instructions to be virtually identical.

This distribution did not ship with a termcap/terminfo file for the VT420. The requisite file(s) can be installed easily by installing package “ncurses-term” with apt-get or aptitude.

I added the following two lines to my /etc/inittab:


T0:2345:respawn:/sbin/getty -L ttyUSB0 19200 vt420
T0:2345:respawn:/sbin/getty -L ttyUSB1 19200 vt420

Just for fun, I also created a new pi-themed /etc/issue file. This is based upon a file sent to me by a friend who did not remember where he found it – if you happen to know the source, please let me know so I can properly attribute the source!

Configuring the VT420

Pressing F3 brings up the VT420 configuration screen.


The initial screen is the setup directory – you will need to select “save” after making changes to store your settings in non-volatile memory.


Global setup screen. The important setting here is “S1=Comm1, S2=Comm2″. This enables session control for our two serial lines.


Display setup. This screen allows you to specify number of columns (80 or 132) as well as number of lines (24, 36, or 48). Each session can be configured independently.


General setup. It’s important to select “VT400 Mode, 7 Bit Controls”, especially if you use Emacs, or your arrow key behavior will be really messed up.


Communications setup. I selected 19200, 8 bits, no parity, 1 stop bit.


Keyboard setup. I set F1, F2, and F5 to “FKEY”, leaving F3 set to “Set-Up” and F4 set to “Session”. I’d recommend this configuration if you’re using multiple sessions (more on this later). The rather odd setting labeled “,< and .> Keys” needs this configuration if you ever want to be able to type the “greater than” or “less than” symbol; the default configuration does not generate these characters.

Beautiful Results


The login screen is gorgeous and is based upon ASCII art sent to me by a friend. If you happen to know of the origin, please let me know so I can give the author proper attribution – he didn’t remember where he found it.


Emacs at 80×25. Works like a charm. You can switch between the two sessions by pressing the F4 key.


Pressing Ctrl+F4 toggles between full-screen and windowed sessions. “Windowed” is a bit of a misnomer here – it really is just a split-screen view. The split can be resized via Shift+F4+Arrow keys.


This picture shows session 2 displayed at 132 columns by 48 lines.

Issues, Problems, Etc.

So far I have ran into surprisingly few issues. I initially wasted several hours trying to get things configured with absolutely no success until I realized that you simply cannot run agetty from a user shell, even as root – THIS DOES NOT WORK. After beating my head against the wall for an inordinate amount of time I remembered fighting this exact same battle way back in 1998 or so with an old DEC VT100 terminal and Linux. Once I added the entries to /etc/inittab it just worked.

Flow control is a problem. While the cable does indeed pass through DSR/DTR and XOFF is configured, fast updates such as directory listings will often contain garbled characters. If anyone has a solution to this particular problem I’d love to hear about it.

I had hoped to use tmux to run multiple sessions, but I’m an emacs user and tmux changes the $TERM environment variable to SCREEN for some reason, which causes emacs to flip out over control characters (backspace and arrow keys). There’s probably an easy fix for this but tmux was a nicety in any case.

Summary

I really love this terminal. I spent many, many hours writing code on a nearly identical terminal at the beginning of my career, and there is something very comforting about returning to this configuration with my Raspberry Pi. Since this Pi is destined to become the central controller for my home automation solution, it will remain attached to this terminal. I hope that others find this blog post useful and give a new home to a VT420 or similar terminal with their Raspberry Pi. Have fun!

Posted in Raspberry Pi | 2 Comments

Cook Technologies Steel Raspberry Pi Case

Posted on December 3, 2012 by steve

ButtonedUp

I discovered this case while browsing through eBay looking at Raspberry Pi offerings. I’ve been looking for a slightly more rugged case for one of my Pis, and this one seemed to fit the bill nicely. Some may argue that spending $28 for a case for a $35 computer is excessive, but given how difficult it is to actually lay hands on a Raspberry Pi these days it seemed like an easily justifiable expense. I ordered two Raspberry Pis on November 1 and just received the first one a couple of days ago. I ordered this case from eBay on 11/28 and it arrived today (12/3).

Initial impressions of the case make it very clear that the case was designed and built by a competent, experienced manufacturer who actually cares about quality. The case is hefty, made of 19 gauge cold rolled steel, and is beautifully painted with a black powder coat finish. No sharp edges to be found. Screw holes line up evenly and are cleanly drilled and tapped. Cutouts for the Raspberry Pi line up precisely, have ample clearance for their intended use without providing too much of a gap. Inside the case the manufacturer has provided foam inserts to firmly hold the Pi in place and prevent any circuitry from shorting against the steel case. The Pi fits snugly within the lower half of the case without being “wedged in” to the provided space. Once assembled, the Raspberry Pi is held firmly in place and the case feels substantial.

I only have a couple of complaints about the case, and they are really minor quibbles. First, an option for mounting ears would be extremely beneficial; a provision for securely mounting the case to a cabinet would expand the case’s potential applications. Finally, the case really should have some kind of light pipe arrangement for the Pi’s LEDs. A hole is indeed provided for this purpose, but it seems odd given the otherwise stellar build quality of the case.

I am in no way associated with Cook Technologies, I’m just a VERY happy customer. It is, unfortunately, rare these days to discover a manufacturer who provides this kind of fit and finish in a product geared towards the hobbyist. This case is a pleasant exception to this unfortunate rule. The case is currently available for $28 USD from eBay seller cooktechinc with free shipping. Worth every penny, IMHO.

More pictures of the case follow…

Posted in Raspberry Pi, Uncategorized | Leave a comment

Raspberry Pi: first impressions and bluetooth configuration instructions

Posted on December 2, 2012 by steve

I got my first Pi a couple of months ago and finally got around to testing it out. Initial impressions are very favorable – it’s a well-engineered little embedded board. Performance is not stellar, but is about what one should expect from a 700 MHz device. I chose to use the Occidentalis v0.2 distribution from the fine folks at Adafruit. Installation was painless, but I’ve been working with Linux for many years so your mileage may vary.

My Raspberry Pi is housed in the awesome Adafruit Pi Box, a really nice laser-cut acrylic enclosure. I also ordered a small sheet metal enclosure from an eBay seller which should arrive sometime next week with my second pi. I’ll post a brief review once I get the enclosure.

For connectivity, I’m using a little 802.11b/g/n dongle from Adafruit. The device worked out of the box with some minor configuration to set up my SSID and password. Although the Adafruit site claims that the device requires a powered USB hub, it is working just fine for me connected directly to the pi.

The power supply that I am using is a 5V, 1A Power Supply from Adafruit. It seems to be more than adequate for the task.

For storage, I’m using a SanDisk SDSDU-016G-AFFP Ultra 16 GB SDHC Class 10 Flash Memory Card. I’ve experienced no issues with the card so far, and disk speed seems more than adequate.

I’m using an old analog VGA monitor for display. Since the pi doesn’t natively support VGA, I’m using a Sanoxy ViewHD HDMI-D to VGA Converter. It works OK, but I do experience an odd blink on the display that I did not see when I connected to my flatscreen TV or a composite monitor. I’m not sure if this is being caused by the converter or the cheap flat-panel monitor (which I purchased about 5 years ago for $20 at a drug store, of all places.) Since this pi will likely be spending most of its time running headless (without a display), I’m not that worried about this glitch.

I’m using an Azio BTD-V201 USB Micro Bluetooth Adapter to interface with a Motorola bluetooth keyboard Motorola Wireless Keyboard and Motorola 89519N Bluetooth Mouse. Configuration was fairly straightforward after I installed the appropriate bluetooth modules. For the sake of posterity, these are the modules that I installed (via aptitude):

  • bluez
  • bluez-tools
  • python-gobject

Note that I DID NOT install the “bluetooth” meta-package, as it dragged in a large number of unnecessary packages and wanted to replace the Occidentalis-included versions of php and perl. The “python-gobject” package was required to resolve a missing reference required by the bluez tools.

The Azio bluetooth adapter shares a chipset with many cheap BT dongles available on eBay. The tool lsusb reports the device as ID 0a12:0001 with description “Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)”.

To configure the devices, I connected to my pi via SSH:

ssh pi@raspberrypi.local

After plugging in the device and booting up the pi, check to see if the keyboard is visible. My keyboard’s MAC address is 00:0F:F6:81:5D:C0. Type “hcitool scan” to list visible bluetooth devices. Once I verified visibility, I needed to pair the device:

sudo bluez-simple-agent hci0 00:0F:F6:81:5D:C0

The program prompts you to “enter pin”, I typed “0000″ at the SSH prompt and quickly typed the same on the keyboard. Timing is a bit picky, so this may take a couple of attempts.

Once paired, I needed to mark the device as trusted:

sudo bluez-test-device trusted 00:0F:F6:81:5D:C0 yes

And then connected the device:

sudo bluez-test-input connect 00:0F:F6:81:5D:C0

Once these steps are completed, the devices are automagically connected at startup.

I also installed a few additional packages:

  • ipython, an enhanced Python shell
  • emacs, my preferred text editor
  • lynx, my preferred CLI/text-only web browser
  • mosquitto, a MQTT 3.1 message broker
  • python-mosquitto, Python libraries for MQTT
  • mosquitto-clients, MQTT command-line tools
  • owfs, Linux support for 1-Wire devices via the excellent One-Wire File System tools
  • owfs-fuse, Userspace bindings to OWFS filesystem
  • python-ow, Python bindings for OWFS

I ordered two of the expanded memory Raspberry pis from Newark the day that they were announced, so my first pi will be going to my nephew tomorrow. He is a freshman in high school this year and is very interested in software development, so this is part of my continuing strategy to introduce him to Linux and other non-Microsoft technologies. Mojang’s announcement regarding a new Raspberry pi version of Minecraft was extremely timely and has helped to increase his excitement about experimenting with the platform.

Posted in MQTT, Raspberry Pi | Leave a comment

1,001 Uses for the Cypress PSOC-1

Posted on November 24, 2012 by steve

PSoC-1I discovered the Cypress PSoC family of microcontrollers via the FreeSOC Kickstarter Project. It’s a really neat idea; Rather than producing a bunch of variants of their MCU parts with different peripheral options, Cypress PSoC parts leave the wiring of peripherals to pins up to the developer. It’s a bit more complex than that in reality, but that’s the crux of the idea.

The FreeSoC project uses the PSoC-5 MCU, which is a 32-bit ARM Cortex M3 variant. This is an amazingly capable chip, but it is hardly hobbyest-friendly as it is available only in QFN and TQFP packages with over 100 leads. Doable as a reflow project, but beyond the capabilities of all but the hardiest of hobbyests. Cypress offers three different PSoC product families – PSoC-1, a low-power custom (“M8C”) 8-bit core, PSoC-3, an 8051-based 8-bit core, and PSoC-5, with the aforementioned 32-bit ARM core.

I discovered that Jameco had the CY8C24123A-24SXI on sale for $1.35 in quantities of 10 or more, so I ordered 40 of them to use in projects. These are little SOP-8 devices, so they are pretty easy to hand-solder. The devices are certainly capable of emulating lots of other devices, and at this price point they are actually cheaper than many.

My intent is to create a simple little AVR-based programmer which can program these devices without computer involvement. While the PSoC IDE is only available for Microsoft Windows, I should be able to create a large enough set of useful personalities to avoid having to spend too much time in Redmond hell. Burn the resulting .hex files to an EEPROM, build a simple AVR-Based programmer with a trivial GUI, and I can build custom devices to order as I need ‘em. That’s the theory, anyway.

But where’s the 1,001 uses that you hinted at in the article title? Well, I’ve got a good list started, but I need to prove the viability of the idea before i get too far ahead of myself. Stay tuned…

Posted in PSoC | Tagged | Leave a comment

Excellent AVR-Eclipse setup HOWTO

Posted on September 28, 2012 by steve

The Arduino environment and associated hardware is nice and very straightforward for quick-and-dirty prototyping and development, but it’s sometimes overkill. Some projects just don’t need a full Atmega328. Atmel manufactures a wide variety of 8-bit MCUs with different features to meet simpler design requirements; the ATTiny family fills the lower end of this product line with 8-, 14-, 20-, and 28-pin variants and a variety of features and memory capacities. My favorite devices in the ATTiny family are the 8-pin ATTiny85 and the 20-pin ATTiny2313, which are available for well under $1 each in quantities of 10. While it is indeed possible to develop code for ATTiny with the Arduino IDE (thanks to the folks at the MIT Media labs High-Low Tech research group), I often prefer to code directly in C. Direct manipulation of the Tiny allows for much tighter code without the bloat and performance implications introduced by the Arduino’s hardware abstractions. This often allows me to fit more complex functionality into the Tiny than is possible with Arduino + Tiny.

My initial foray into ATTiny development was through Atmel’s AVR Studio. While AVR Studio is a very nice, very capable IDE, it suffers from one major flaw from my perspective: it’s Windows-only. I’m no stranger to the environment – I held both MCSD and MCSE certifications in the 90s and developed commercial applications for the platform for well over a decade. My professional roots, however, are in UNIX development, and I submitted myself to the penguin’s warm embrace in 2000. I managed to purge the last vestiges of Windows from my house (and my family’s houses) in 2006 and frankly I don’t miss it one bit. My primary development machines are Apple Macs (at home and at work), but I primarily use them as shiny UNIX boxes. But I digress…

Most of my experiments with the ATTiny have been decidedly old-school: coded in emacs, built with avr-gcc, and flashed with avrdude. Not bad, really; avr-gdb is available for those odd occasions where a debugger is necessary. I found myself missing some of the niceties available in a modern IDE, however, which led me to search around for alternatives. Several options are available on the commercial front; I played with several and was quite impressed by Rowley Crossworks. It’s an interesting business model – they provide a common IDE that supports several microcontrollers (AVR, MSP430, ARM, MaxQ), but you need to license each controller family separately. This would be an easy value proposition for a professional shop, but the pricing is higher than I can justify for my hobby ($150 each for a personal, non-commercial license, $300 for education, and $1500 for commercial.) Sorry guys, above my pain threshold.

While browsing the other day I stumbled across a forum post discussing the AVR-Eclipse plugin and decided to check it out. One of the more interesting links that I discovered was this excellent tutorial by the folks at Interactive Matter. I think I’ll be using this environment for my next couple of ATTiny experiments, as it’s pretty nice. Stay tuned for additional feedback.

Posted in AVR | Tagged , | Leave a comment

Dangerous Prototypes Big Box of Parts

Posted on September 26, 2012 by steve

I discovered The Great Internet Migratory Box of Electronics Junk (TGIMBOEJ for short, ranking right up there as Worst Acronym Ever) recently. It’s a neat idea; sign up on The TGIMBOEJ site and a box chock full ‘o stuff magically appears on your doorstep some time later. Relying on the principal that one person’s junk is another person’s treasure, these magical boxes of cruft get passed along, telephone game style, from one geek to the next. Participants in the game take items out of the box that they find useful and put some of their spare parts in as a replacement. In theory, this process should be very effective with electronics components, as deep discounts can often be attained when purchasing items in larger quantities. Most electronics hobbyests that I’ve met have acquired small hoards of components, whether due to the psychology of THE DISCOUNT (one part for $5, or 20 for $10? Sold!) or through some failed project notion which never fully materialized.

Alas, though I have volunteered my name for one of these mystical TGIMBOEJ packages, I have not yet been blessed by the arrival of the magical component fairy. However, one day while eating a particularly terrible bowl of soup for lunch and reading through my RSS feeds, I discovered that a user on the Dangerous Prototypes forum was starting a new box of parts in the TGIMBOEJ tradition. I threw my hat in the ring and became recipient #3 of this box! Continue reading →

Posted in Electronics | Leave a comment

Hacking Eaton HomeHeartbeat Part 8: Sensors

Posted on March 5, 2012 by steve

This post documents my research into the HHB sensors, complete with pretty pictures. With the exception of the power sensor, these devices are all variations on a similar theme. They all contain the same Atmel ATMega64L MCU and Ember EM2420 ZigBee/802.15.4 wireless chip with supporting devices. There are some minor variations in the area of the board which interfaces with the particular sensor function (magnetic switch for open/close sensor, header for tilt sensor, etc.) The footprint of the ATMega64L and utilized pins are identical across all of the sensors, as is the magnetic reed switch (for HomeKey sensing/registration), crystals, and ZigBee antenna.

Power Sensor

As configured, this sensor simply reports whether or not a load is active on the device plugged in. Device class is reported as (id: 0004). State reports (state: 1) when load is off and (state: 2) when load is turned on.

The internal design leads me to believe that the device was originally intended to me much more fully featured than what was actually shipped:

This is an interesting design, and I believe that it’s capable of a lot more than is being utilized at present. Looking at the front side of the board in this image, you will notice four main sections: The MCU with the ATMega64L and ICSP header, the RF section with the EM2420 ZigBee chip and supporting components, and a bunch of other components. After following traces on the board and consulting a couple of datasheets I realized that these remaining components actually provide two discrete functions. First, the majority of the remaining components allow the sensor to be directly powered via AC mains voltage. This function is primarily provided by U5, which is a LNK305 switching IC. The final function provided is load sensing, which is performed by a large current transformer (CT), which is an AC-1005 5 Amp Current Transformer from Talema India. Output from this CT is converted to DC via a small HD04 Bridge Rectifier which then presumably feeds in to the ATMega64. I was unable to find the specific analog pin which reads this value, though PC0 and/or PC1 are likely candidates.

What this means, ultimately, is that it should be possible to measure actual current consumption for the load plugged into the device rather than simply reporting an “on/off” state condition. The fact that the device configuration available through the HomeKey provides several different sensitivity profiles tells me that the output of the rectifier is indeed being measured. Whether this omission was due to cost cutting efforts, safety concerns, or limitations of the rest of the stack is unknown.

Another interesting point worth noting are the empty footprints at U7 and U8 on the back of the device; this layout is identical to the footprint for the IS62LV256 static RAM used on the base station. Perhaps this was intended to support more advanced load tracking / current consumption metrics?

Moisture Sensor

Sensor utilizes simple dry contacts to determine wet conditions. Device class is reported as (id: 0005). When the pins on the remote sensing puck are shorted, the device reports (state: 2); otherwise it reports (state: 1). This is a transmit-only sensor.

Reminder/Attention Sensor

These two sensors perform nearly identical functions and are absolutely identical physically. Device classes are reported as (id: 0006) and (id: 0007), respectively. I still need to document the state transitions for these two devices. Ultimately I question their usefulness. From a user interaction perspective, they blink a light until the button is pressed. Time between initial trigger and new states is configurable. These sensors both transmit and receive data; they contain a button which sends a message to the base station when pressed, and they also have a single green LED which indicates status.

Motion Sensor

Simple passive infrared (PIR) motion sensor. Device class is reported as (id: 0017). Reports (state: 1) when no motion detected, and (state: 2) when motion has been detected. No additional alerts are transmitted if additional motion occurs within configured delay. After motion is detected, the sensor will send a new (state: 1) alert when no motion has been detected within the configured delay. This is a transmit-only sensor.

Garage/Tilt Sensor

This is a simple tilt sensor. Device class is reported as (id: 0018). Reports (state: 1) when vertical, (state: 2) when tilted to horizontal. This is a transmit-only sensor.

Pictures

Posted in ZigBee | Tagged | 15 Comments

Hacking Eaton HomeHeartbeat Part 7: Success!

Posted on March 4, 2012 by steve

Spent a good deal of time on Saturday working with the Base Station and my collection of sensors. I’ve managed to decipher enough information from both the Serial and ZigBee side of things to come up with a workable solution for my needs.

I picked up an Atmel RZUSBSTICK (Available on Mouser and elsewhere) based upon information from Josh Wright’s published ZigBee documentation. His KillerBee framework was invaluable in my effort to understand the Home Heartbeat’s wireless communication. I’ve ordered a copy of Hacking Exposed Wireless, Second Edition in order to delve a bit deeper into this realm, as it’s quite interesting. Josh’s Toorcon slides are a good read as well if you’re interested in this sort of thing. The HHB’s usage of ZigBee is very basic, and took surprisingly little time to decipher once I had the proper tools to monitor the traffic.

I’ve explored three primary avenues for modding the original HHB base station for my needs. The first option involves developing new firmware for the HHB. Since the HHB base station is based upon an Atmel AtMEGA128L, this would certainly be technically possible. If I had more time at my disposal I may have selected this option; starting with an assembly dump of the existing binary image would provide a pretty good start.

The second option involves developing an intermediate device which acts like a Home Heartbeat key but which provides an interface to additional functionality. The device would utilize a simple ZigBee radio to speak with the base station. The base station/key protocol is quite straightforward. This approach has several advantages: the base station basically remains in its unadulterated form, and the new device could provide any number of additional features (internet connectivity for notifications, etc). The Chibi Wireless Board from the fine folks at FreakLabs would be an ideal platform for this effort, as it provides the necessary wireless hardware, is Arduino compatible, has a proven track record (Safecast.org hardware is based upon this board), and is cheap as well – $30 USD for the bare board. I will probably pursue this option in the long term, as it would be an interesting project to work on. I’ve already ordered a couple of Chibi boards with enclosures to experiment with. Check out the site’s wiki as well – Akiba does some amazing work, and the best way to support his efforts are by buying stuff from his store.

The final (and simplest) option involves interacting directly with the base station as a serial client. There is enough information available via serial to interact with the sensors and report on activity. I’ll be basing my solution on this approach using the Arduino Ethernet board; stay tuned for build details.

Throughout all of my digging I’ve come to the conclusion that the HomeHeartbeat device and sensors have a lot of hacking potential. As they are all built around the Atmel ATMega microcontroller (ATMega128L and ATMega64L), it should be possible to build out some simple tools to take advantage of all of the available Arduino libraries to build some pretty cool devices. The HomeKey in particular would be fun to hack, with its built-in backlit graphical LCD screen, thumbwheel, and ZigBee radio. I’ll spend some time tomorrow documenting my findings with the HomeHeartbeat sensors; lots of pictures and technical information to share!

Keep the comments coming – I’d love to hear more about how people are using this hardware as well as any crazy ideas that you may have for hacking the hardware. Please respond via comments rather than emailing me directly so that the discussion is not just limited to two people. I’m hearing a lot of duplicate information and requests from people via email. It’s been really cool to see my site traffic picking up over the last couple of weeks!

Posted in ZigBee | Tagged | 10 Comments

Digital Electronics Basics: Open Collector Outputs

Posted on February 29, 2012 by steve

Check out the excellent overview of open collector outputs over on the Evil Mad Scientist page.

Posted in Electronics Basics | Leave a comment