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:

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.

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:

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.

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:

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.

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:

And this is the interrupt handler:

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

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.