Hacking Eaton HomeHeartbeat Part 6: Autopsy

Well, the good news is that I got an entire day to dissect the HHB base station, and now have a much more thorough understanding of the inner workings of the device. The bad news is that I managed to kill my base station in the process, probably by mercilessly probing for continuity trying to decipher internal device connections. C’est la vie – good thing these things are cheap. I hopped on Ebay and ordered a couple of new base stations in case I manage to kill another one, should be here next week. Read on for full details!


I purchased my first HHB hardware before I had any experience with Microcontrollers. I was attracted to the device because it performed a lot of what I was looking for out of the box. The fact that Eaton had recently discontinued the service was not a major concern, as I figured that I would be able to get something out of the device, even if it was only a learning experience. My initial exploration of the device was via the serial console, and my discoveries in that area were quite heartening; at the very least I would be able to use the device to monitor the commercial sensors created by Eaton.

My attention was diverted last summer due to a number of personal issues, some of which I’ve written about on this blog. I didn’t have a lot of time for hands-on exploration, but I had boatloads of time available to read; I took advantage of this opportunity to dive headlong into the world of microcontrollers, starting with the Arduino. That lead to general microcontroller study, first with the AVR devices followed by the TI MSP430 and various PIC variants. It didn’t take a lot of experimentation before I realized that I really needed to brush up on electronics basics, as my designs often behaved oddly when fully assembled.

Fast forward nearly a year and my attention has ended up back with the Home Heartbeat hardware. It occurred to me that it might be interesting to tear down the base station, document the components, connections, and signals that I find, and see whether or not it would be possible to truly hack and extend the device.

The HomeHeartbeaat base station is an interesting device internally. The circuit board appears to be a four-layer design and contains a frightening number of vias, making it a bit more difficult to reverse-engineer. After spending some quality time with the device and a combination of my DSO, a logic probe, and my trusty multimeter I was able to track down most of the connections between components.

Major Sub-Components

Internally, the HHB base station is made up of the following components:

MCU: Atmel ATMega128L

This is the brains of the device. Bristling with I/O ports, it’s the big brother to the ATMega328 familiar to Arduino users. 128K flash, 4K EEPROM, 4K SRAM. The ATMega128 also utilizes a 256K parallel static RAM chip (ISSI IS62LV256) to provide additional working memory; Port A on the MCU is pretty much dedicated to this task. An LCX573 octal latch is also utilized in communication with this device.

RF Section: Ember EM2420

The EM2420 is a single-chip ZigBee/802.15.4 transceiver. This device is responsible with communication with wireless sensor nodes.  The MCU communicates with this device via SPI.

Note that the above diagram shows a 93C46B serial EEPROM connected to the MCU; I was actually unable to validate any connections to this device.  It is quite possible that the EEPROM is actually used by the EM2420 for code or device storage.

Modem: Silicon Labs si2404

Dial-up communication with the (now defunct) homeHeartbeat service was managed with a two-chip modem solution from Silicon Laboratories. This solution is a 2400bps dial-up modem with caller id capabilities, and is made up of two chips – the si2404 handles serial communication and modem logic, while the si3010 provides access to the phone line and all of the analog modulation jiggery-pokery.  The MCU communicates with the modem via UART1 (pins 27 and 28); There are a handy pair of vias available on the board for easy access to these signals for logic probe monitoring.

USB/Serial Bridge: FTDI FT232BM

USB/Serial connectivity is provided via this device, which at this point has nearly universal operating system support. Since most modern machines no longer contain an old-school RS232 serial port, this is a very handy feature.  The MCU communicates with this device via UART0 (pins 2 and 3).

Board Pictures

Back Side

Most of the important components of the base station are mounted on the back side of the board.

I’ve also indicated a couple of handy vias for monitoring serial communication between the MCU and the modem chipset.

J19 Appears to be an ICSP port, except that it is not wired as expected; pins 1 and 5 are connected to Rx/Tx of UART0 instead of MOSI and MISO.

ICSP Port Pinout

Pin Desc Pin Desc
1 Rx0 10 Vcc
2 NC 9 GND
5 Tx0 6 GND


Front Side

The two vertical bars at the top of this image are magnetic switches which correspond to magnets mounted in the case of the Eaton HomeKeys. Pins are for charging the keys; if you look at the front of the board in this location you will see a couple of tiny SMT LiPo charge devices.

Modem Communication

I was able to monitor the serial communication between the MCU and the modem using my Saleae Logic USB Logic Analyzer and the handy Tx/Rx vias indicated on the “Back Side” picture above. Pretty standard AT command set stuff for much of it, though it’s interesting to note that during the modem initialization step the MCU uploads a large amount of data to the modem (via the AT:P… command sequence documented in the si2404 manual); this process takes about 9 seconds (!) before the modem attempts to phone home.

Mystery Signals

Some of the signals on the ATMega128 were hard to trace and remain something of a mystery. For example:

  • PE2: 1 square wave pulse every 3 seconds
  • PG3: 1.4Hz sine wave (sorry, I didn’t measure vPP)
  • PG[0:1], PC[0:3]: Square waveforms indicating either a serial or bit-banging data stream

The last could quite possibly be related to SRAM or the mysterious EEPROM mentioned above.

Unknown Components

On the top edge of the front of the circuit board there are two components which I was unable to successfully identify. The first component, marked as U14 on the circuit board, is stamped with identifier “R1022G50 62A9HHE”; Based upon the package, I’m assuming that it’s either a voltage regulator or provides charging support for the HomeKeys. The second component is marked as U12 and is stamped with identifier “806I 0428”; there are several test points on the circuit board surrounding this component. Again, I’m assuming that it is involved with HomeKey charging, as I didn’t see any activity on this device during my bench tests. If you’ve got any information about these components please let me know and I’ll update this post accordingly.


The HomeHeartbeat base station is surprisingly hackable. It would be quite possible to replace the firmware on the ATMega128 to perform any number of tasks, either via ICSP or through the onboard firmware (which natively supports firmware uploads). The onboard modem supports Caller ID, so this may be useful to someone who still had a landline. The most challenging aspect to hacking this device would be communicating with the Ember ZigBee chipset. Fortunately, there is no shortage of publicly available information in this arena, so that should not present an insurmountable challenge.

I purchased two new base stations to play with; the first will remain sealed and pristine, and I’ll try messing with firmware on the second. If anyone would like to help out with this endeavor, I’d be happy for the assistance!

3 thoughts on “Hacking Eaton HomeHeartbeat Part 6: Autopsy”

  1. Great writeup and pictures of the guts of the base unit. Thank you for posting this. I bought one from Ebay and it just arrived yesterday. Only had a few minutes to play with it. Even though the manual says the USB port is for future use, I plugged it into my computer.

    I had the required FTDI driver already installed, so it quickly found the hardware. I opened a serial port console window and started playing with the baud rate and sending it jibberish. I found that at 38,400 8-N-1, the base unit started responding with valid ASCII characters. Entering a ? gets you a menu. You can poll for info about the Radio. Look at some other settings. There is also a debug mode. When I enabled this, it started printing modem messages ever 10 seconds. (I guess it was trying to find the mother ship.)

    I did not have time to do much more yet. I did not even unwrap the dongle/key or the sensor. However, I wonder if this can be hacked through the USB port? Perhaps Eaton will release the underlying interface to this port?

    The ISP connector in your picture is most likely used to change the firmware via bootloader. The USB port also mentions bootloader in its menu. For the $20 that I paid, I am considering just wiping the entire Eaton software from the base unit and making it a USB to Zigbee smart link. This seems doable since there are reference designs for the MEGA128 and the EM2420. Some websites list ChipCon as the actual fab for the Zigbee radio. ChipCon was bought by Texas Instruments. So the original ChipCon website is gone. The new reference designs with this chip are using TI processors. Wonder why?? However, the older Atmel based designs are still floating out on the web.

    1. More info about fun with the serial port in Part 2 of this series. My new unit came in the mail yesterday so I’m hoping to spend some quality time with the serial interface this weekend.

      Eaton is unlikely to respond with any useful information – see my brief rant about this on my blog :) Please do try to get information from them however, maybe you would have better luck than I have had. If you do hear back from them please be sure to share your findings!

      There’s nothing special about the USB port – it’s just a USB/Serial bridge to UART0. As you’ve seen, the bootloader that Eaton installed on the AVR provides several features, including firmware updates.

      Interesting information about the Ember/ChipCon connection – I was not aware that these were identical devices. That’s good news, as there is a lot of publicly available information for the cc devices on the TI developer site and elsewhere. TI actively supports and develops the cc devices and provides copious quantities of documentation on their developer support site. New reference designs will undoubtably be built using TI’s MSP430 microcontrollers; this is not a bad thing, as the MSP430 is a very competent and well-supported uC. Since the EM2420 is an SPI device, any documentation found will apply equally to the AVR or MSP430.

  2. Over my lunch break, I poked around on the Internet. It appears that Eaton had only a partial role in developing this product. The main developer appears to be a company called MAYA.

    I sent them an email asking for the serial protocol or any documentation they could spare. I will let you know if I get a response. Their website also credits Ember with working on the development. Perhaps you should check your web hits for accesses from MAYA or Ember. It would be interesting if they are also following your blogs.

    For those silently monitoring these posts, it is extremely wasteful and “Un-Green” to just dump all this stuff into landfills. I am not asking you to support the protocol, just release whatever documentation is available so that the existing products can be used.

Leave a Reply

Your email address will not be published. Required fields are marked *