Computing stuff tied to the physical world

Archive for January 2009

16 x 8 LEDs

In AVR, Software on Jan 30, 2009 at 21:51

Here’s the umptieth LED board:


It’s been hooked up to SPI and FTDI connectors, and the two 8×8 LED matrices have been tied to an ATmega168 and an A6276 chip, described as a “16-Bit Serial Input, Constant-Current Latched LED Driver”. The voltage regulator and the I2C/power pins on the right haven’t been hooked up yet.

This shows the backside, which is surprisingly robust once done, but a huge pain to build:


I use wire-wrap wire because its insulation can stand the soldering heat without problems and because the wire bonds easily with solder. For anything but one-offs, pcb’s are obviously a much better way to go.

Here’s the unit hooked up via a USB/FTDI board by ModernDevice:


Here’s a better view with one LED actually turned on:


The brightness and contrast are actually far better than in the above picture.

The design is made for scanning across columns while providing 8 bits of on/off data for the current column via 8 output pins on the ATmega. There’s a 16 MHz resonator on board, so this thing is fully compatible with the Arduino IDE.

Here’s a sketch which makes a single led turn on and meander across all positions:

Picture 1.png

This was used to verify that each dot is accessible and that there are no short circuits. The analogWrite() call is used to vary the display brightness, by controlling all LED driver outputs via PWM. Another useful property of this driver chip is that it needs only one resistor to limit the current through each of the leds.

Update: Silly me, with constant current on the columns, I have to cycle the rows of course. Will need to add an ULN2981 driver to allow the row pins from the ATmega to drive up to 16 leds at once. With this change the LEDs will cycle at 125 i.s.o. 62.5 Hz and can be slightly brighter.

PCB layout

In AVR on Jan 29, 2009 at 12:47

My first exposure to EAGLE, a CAD/CAM package for printed circuit boards, produced this 82×23 mm board:


It has an ATmega168 MPU, an RFM12B radio, a 3.3V regulator, and 4 identical pin headers intended to be used as simple I/O “ports”, such as sensors. There’s also an FTDI connector, a power/I2C bus, and an SPI/ISP connector for hooking up a few more SPI devices.

Each of the I/O ports can be used in different ways:

  • 2 center pins: analog or digital I/O + ground
  • 4 center pins: the above, plus a second digital I/O pin and 3.3V
  • all 6 pins: the above, plus unregulated power and a shared interrupt pin

In many cases 4 pins will be sufficient.

I’ve ordered a couple of prototypes, just to see how they come out. I’m sure I made all sorts of silly mistakes, but hey… it’s all a learning process.

Logic Analyzer: fantastic!

In Hardware on Jan 27, 2009 at 20:39

Today, I received my new USB-connected/-powered 16-line 100 MHz logic analyzer:


It captures signals in time and displays / analyzes patters in them. Here’s a setup which decodes 2 signals of an I2C bus:


The instrument shown here is a ZeroPlus LAP-16032U (old version: 32 Kb memory w/ compression), now superseded by this one. For € 120 this includes several protocol analyzers, including I2C, SPI, and async serial (RS232). And the built-in hardware compression means it can capture very long pulse sequences.

This is a phenomenal debugging tool and time-saver. Well… for people who deal with logic signals and need to analyze them, that is!

Wireless power monitoring

In Hardware on Jan 25, 2009 at 16:47

Looks like lots of hobbyists are starting to explore the world of tracking energy usage in the home in real time.

Here’s a recent weblog entry by LadyAda, called Wattcher. It uses off-the shelf components and modifies them (could that be called a hardware mash-up?).

Great, very similar to what I’m after – but I hope to get there at a lower cost…

RFM12B up close

In Hardware on Jan 24, 2009 at 16:28

Here are some pictures of the RFM12B radio module (there are versions for 433, 868, and 915 MHz).

With wires to adjust between the module’s 2 mm spacing and the breadboard’s 2.54 mm (0.1″) spacing:


This is how I’ve been mounting a couple of these modules lately, the white wire is an 85 mm wire antenna which appears to work well:


And this shows how I’d like to mount these modules onto a PCB – with proper 2 mm spacing of course, this was just soldered on to give you an idea:


IOW, in this last case the radio module would be flat on top of another board, with just the solder masks as isolation between them.

Reliable comms with RFM12B

In AVR, Software on Jan 23, 2009 at 16:34

The driver code for RFM12B radio modules is starting to shape up nicely. It’s all interrupt-driven, so it works mostly in the background. Here’s a complete sketch for Arduino, allowing bi-directional sending of test packets with or without acknowledgement:

Picture 1.png

Most of this logic is the test code itself. The main interface calls are:

  • rf12_initialize() – call this one in setup()
  • rf12_recvDone() – returns 1 when a complete packet has been received
  • rf12_canSend() – call this to start sending when possible
  • rf12_sendStart(hdr,buf,len) – this starts actual transmission

All the interrupt stuff happens behind the scenes, the only requirements being that rf12_recvDone() should be called frequently and that rf12_sendStart() may only be called after rf12_recvDone() or rf12_canSend() return true, i.e. inside the above if statements.

The driver itself is under 200 lines of C code, it’ll be released as open source once the code settles a bit.

Home control shield

In AVR on Jan 22, 2009 at 16:37

The “home control” unit I mentioned recently was intended to have two shields, stacked as follows:


Unfortunately, the top shield with the I2C display turns out to either shield the underlying DCF77 receiver too much, or to generate too much interference, or both. So I’m going to leave it off:


As a result, this is just an Arduino Duemilanove with a “peripherals” proto-shield by Adafruit on top, containing:

  • an RFM12B 868 MHz radio module from HopeRF
  • a µSD socket with a 2 Gb card from Kingston
  • a DCF77 receiver from Pollin (

The resistors are used as level converters, since the SPI bus has to run at 3.3V. There’s also 3.3V regulator (look between the resistors and the pin header), because the µSD programming current can run up to 100 mA – more than the Arduino’s FTDI chip can supply.

All peripherals have been verified to work, separately as well as in combination.

So this unit now has all the pieces needed to log (and accurately timestamp) virtually unlimited amounts of data flying through RFM12B airspace… fully unattended, with just a USB or +9V power source.

Control via 433 MHz

In AVR on Jan 17, 2009 at 12:00

I’ve rewired and adjusted an earlier unit so it now receives and sends pulses on the 433 MHz band:


Both receiver and transmitter have been verified to work with the KlikAanKlikUit system, which is cheap but also quite limited. There are at most 12 codes in the simplest units and 256 codes in a slightly more elaborate version.

Both versions could be triggered by neighbors with similar units. And just as with IR remote controls for A/V equipment, it’s trivial to record and replay these signals so they provide no security. But for basic stuff such as turning on lamps it should be ok. And fun!

Graphic LED display

In AVR on Jan 16, 2009 at 11:45

Here’s another upcoming little project, tying an ATMega168 to two 8×8 LED displays:


The second chip is an A6279 constant current LED driver with serial in and 16 lines out. This removes the need for 16 LED current limiting resistors and ties up just 3 lines on the MPU. Another 8 lines are used to drive one column of dots. Less than a dozen components (including power regulator) are used in total.

The connectors are: 6-pin FTDI for programming, a combined 2×4-pin SPI/ISP connector, and a 4-pin extension connector with power and I2C signals. The latter could be used to tie multiple 16×8 display units together.

This is just a first impression. Wiring and software are still to-do’s.

LCD display

In AVR on Jan 15, 2009 at 11:32

With two signal wires connected to the Arduino’s I2C (analog pins 4 and 5), this shield can now display text:


The characters are generated by the display chip, with a bit of tweaking to map ASCII code to its somewhat odd character code allocation.

Shield progress

In AVR, Hardware on Jan 14, 2009 at 15:57

The Arduino shield stack is shaping up. Here’s the peripheral shield, with all modules installed:


This now contains the following peripherals:

  • a µSD card reader with 2 Gb card (top right)
  • an RFM12B 868 MHz transceiver (bottom right)
  • an 433 MHz AM receiver (top left, hidden)
  • an 868 MHz AM transmitter (bottom left)
  • a DCF77 time code receiver (middle, with ferrite antenna)

The header pins support a status shield on top with a small 3×12 LCD display (connected via I2C) and some leds & buttons:


The whole setup, when stacked on an Arduino Duemilanove, now becomes this:


What it does will depend on the software written for it, obviously.

Arduino + RFM12B + µSD

In Hardware on Jan 13, 2009 at 00:59

This is the first working version of the new shield mentioned yesterday:

Peripheral shield

It connects a RFM12B radio and a micro SD card to the SPI bus. They both work, i.e. the radio can send & receive packets and the 2Gb Kingston µSD card can successfully enter SPI mode. These two peripherals alone would be enough to set up a self-contained data logger, but this is just the start – less than half of the shield area has been used so far.

Shield stack

In AVR, Hardware on Jan 12, 2009 at 16:11

Here is the start of a new set of shields for the Arduino, based on Adafruit’s Proto Shield:


This little thing might one day become my “home monitoring & control server”, but that’s still a long way off. You can see a µSD card slot with 2 Gb of flash memory on the middle board, which will become the main peripheral shield. The top shield is for basic access and status info, and is optional. Additional shields could be inserted into this stack later.

A simple RF pulse scope

In AVR, Software on Jan 10, 2009 at 23:45

Here’s a simple way to analyze RF pulse trains, as emitted by simple 433/868 MHz remote controls. A receiver for the proper frequency band is required, as well as some Arduino board connected to USB.

The code is a sketch which picks up all 0/1 transitions (i.e. presence/absence of the radio carrier) and reports the elapsed time between each transition:

Picture 1.png

The radio signal is tied to the analog comparator (pin 7), and the timer is set to count in 8 µsec steps. This rate was chosen to allow for pulses up to 2 msec.

The data is sent as a stream of bytes. Values 2..255 correspond to pulse durations of 16..2040 µsec. A “0” is sent for longer breaks, a “1” is sent if the data was not transmitted fast enough over USB, i.e. an overrun. Note that “0” values are only sent once, i.e. when there is no signal no bytes are sent to the USB interface.

On the computer side, all sorts of software could be used/written to analyze these pulse trains. I used Tcl for a one-off analysis of KlikAanKlikUit remotes operating at 433 MHz, though it would be really neat to have some sort of logic analyzer GUI or web interface added to this.

Transmit via interrupts

In AVR, Software on Jan 8, 2009 at 16:37

Making the transmit logic of an ATMega MPU with RFM12B radio module interrupt-driven is not very hard, as it turns out. The idea is to use states to decide what to do when a new transmit interrupt comes in. These are the states I’m using:

Picture 1.png

And this is the interrupt handler:

Picture 2.png

Lastly, this code starts a new transmission (assuming txstate was TXIDLE):

Picture 3.png

The main trick used in the above is that the state usually increments on each interrupt and that negative states are used to send all the payload data bytes. So the choice of state values matters, i.e. TXCRC1 has to be zero.


In News on Jan 7, 2009 at 17:03

This weblog was moved from RapidWeaver (which doesn’t scale, sigh) to a hosted one using WordPress. Right now, I’m now using MarsEdit to manage this blog.

All older entries have been moved over, but not all links and source code listings have properly made it across the transition. The original blog is still archived here.