All posts by steve

Excellent AVR-Eclipse setup HOWTO

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.

whatitook

Dangerous Prototypes Big Box of Parts

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

Hacking Eaton HomeHeartbeat Part 8: Sensors

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

Hacking Eaton HomeHeartbeat Part 7: Success!

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!