Alan's Ramblings - led strip tag

As it says, "Beautiful light performance"

Fri, 11 Mar 2011 23:01:00 GMT

Well, we did our first performance with the LED strips on Wednesday at Islington Mill in Manchester,and I'm relieved to say they worked flawlessly, even after one of the wheels was dropped just before the performance started! The lighting in the venue was a bit too bright to make a good video, so Andy made a video of the strips in action at Thursday's Travelling Light Circus rehearsal which he's put up on YouTube. Even though I say it myself, I think it's rather good :-)

Seeing the strips in use by the talented TLC performers just gives them an entirely different dimension, and I think the video is really well done as well. For me, one of the best bits of the project has been the opportunity to work with people who have an artistic clue :-)

Connecting a HL1606 strip to an ATmega

Wed, 09 Mar 2011 23:29:00 GMT

I've been left a comment asking how the HL1606 strips are connected up to an Arduino. The wiring is really pretty simple, but depends on exactly which ATmega version you have, as the hardware SPI pins vary from MCU to MCU. The following assumes it's a ATmega328P as used on the more modern Duemilanoves, you'll need to refer to the MCU documentation and the board schematic to find the correct ports and pins for different Arduino versions.

The 328P uses the following pins for hardware SPI:

/CS    Port B Pin 2    (Arduino pin 10)
MOSI   Port B Pin 3    (Arduino pin 11)
MISO   Port B Pin 4    (Arduino pin 12)
SCK    Port B Pin 5    (Arduino pin 13)

I used Timer 2 to drive the fade clock on the strips. The output of Timer 2 uses the following pin:

TIMER2 Port B Pin 1    (Arduino pin 9)

The strips themselves have the following labelling on the inputs:

S-I    Fade clock input
D-I    Data input
CK-I   Data clock input
L-I    Data latch input

So you need to wire up the strip as follows:

ATmega      Strip
/CS     to  L-I
MOSI    to  D-I
SCK     to  CK-I
TIMER2  to  SI

Note that if you want to wire up more than one strip you'll need to work around the fact that the HL1601 strips don't implement the SPI protocol properly. The easiest way is to gate the SCK signal with the /CS line so that when a strip is not being accessed it doesn't see the data clock. I've detailed the problem and the solution more fully in this earlier post,

I'm wheely pleased...

Thu, 03 Mar 2011 08:46:00 GMT

Last night I met up with Andy and Colin of The Travelling Light Circus at MadLab to finally finish off some the LED strips that I've been working on for so long. The original plan was for them to be worn, which would have meant splitting the 4 20-LED strips connected to each strip driver in half, to allow for bending at knees and elbows. That would have meant doing an additional 32 joints, so when they said they'd come up with an alternative way of mounting the strips I was not at all unhappy :-)

Andy managed to source some translucent plastic tube that the strips slide neatly inside. The tube does two things, it protects the fairly fragile strip from damage and it also diffuses the light from the LEDs to increase the viewing angle and provide a nice glowy effect. Andy and Colin's plan was to mount a box to contain the strip driver on the hub of a bike wheel and to then attach the four tubes + LED strips to the wheel as if they were 'umbrella spokes' - the picture below makes the setup clear:

Will of TLC fabricated a really good mounting for the box, and the batteries and strips were simply attached to the bike wheel with cable ties. The wheel itself is mounted onto a large diameter aluminium pole, attached to the wheel where the gears would normally be. The really neat thing is that because Will used rear bike wheels he could keep the freewheel mechanism in place, so simply 'flicking' the aluminium pole sets the whole thing spinning. Of course having got them finished, we had to have a play :-) The first video was taken inside the MadLab building by Sam from Girl Geeks when we had the first wheel finished.

The second video is with two wheels and was taken outside MadLab on Edge Street, just across from the Common bar and we caused quite a commotion, with people coming out of the bar to see what we were up to. As you can see from the video, the patterns on both wheels are synchronised. The slightly wobbly video is because I was filming and operating the radio controller for the strips at the same time - you can hear the switch clicks on the audio as I'm changing the patterns. And I love the obligatory enthusiastic American on the video soundtrack - "Awesome!" :-)

Radio-controlled HL1606 strips

Sat, 15 Jan 2011 18:07:19 GMT

Well, I've finally finished the design and implementation of the radio-controlled LED strips I've been asked to make for The Travelling Light Circus. It's taken far longer than I expected, but I've learned an immense amount in the process. The remaining tasks are to construct some more boards, put the boards into suitable enclosures and to sort out how best to package and connect the strips, so now seems like a good point to write up what was involved in the project. Some of the items are worthy of posts of their own, but first I'll give an overview of how everything fits together. The system is composed of two parts, a single controller and a number of LED strip drivers. The controller is used to select the required pattern and to synchronise the LED drivers, with the communication being done with 2.4GHz radio transceivers. I've put a video together to show everything in operation, and there are some annotated photos of the controller and LED strip drivers at the start.

Hardware

As I've said, the hardware consists of two parts, the controller and the LED strip driver. At the moment these are made using discrete parts on a hand-built breadboard, but version 2 will be a PCB with most of the components mounted directly on the PCB.

Controller

The controller consists of the following parts:

Arduino Pro Mini. This uses a ATMega328p microcontroller and runs the controller software.
4-digit 7-segment display, from SparkFun. Whilst this works, getting it to work cause me an inordinate amount of problems, as I documented in an earlier post.
Voltage regulator - a 7805, which I've discussed in an earlier post.
nRF24L01+ radio transceiver. This a a reasonably complicated SPI device, capable of working in several different modes. I'm using a breakout board from SparkFun, but in future revisions the radio chipset will probably be integrated onto the controller PCB.
A rotary encoder/switch used to select and activate the required pattern. I've already discussed this in an earlier post.
A simple voltage divider to sense external battery voltage and shut down when the battery is discharged.

LED strip driver

The LED strip drivers consist of the following parts:

An Arduino Pro Mini. This runs the software that drives the LED strips.
A nRF24L01+ radio transceiver, which receives the control and timing messages from the controller.
74125 glue logic to make the HL1606 strips behave like proper SPI devices. Despite the manufacturer's claims they aren't true SPI devices, a topic that I covered at length in an earlier post.
Voltage regulators - two 7805 linear regulators. Two are needed to provide the 4 amps that is required to drive the 4 LED strips. In future revisions this will probably be replaced by a switched-mode supply as the 7805s get very hot under high load and are quite inefficient, both of which are issues for portable use.
A simple voltage divider to sense external battery voltage and shut down when the battery is discharged.
A thermistor used to sense the temperature between the regulators. When it reaches 60C the strips are turned off to protect the hardware. When it drops back below 40C the patterns are resumed.

Software

The software is the most complicated part of the system, and it's divided into four main parts, described below. The various parts of both the controller and LED driver are implemented as tasks, implemented using the task manager described in the library section below.

Library code

This is code that is used in the LED strip project but that is used in other projects as well.

SPI master library

The nRF24L01+ radios, the 7-segment display and the LED strips are all SPI devices, so it seemed useful to abstract the core SPI master functionality into a separate library.

nRF24L01+ driver

This driver builds on top of the SPI master library and provides access to the low-level nRF24L01+ functionality such as device configuration and message transmit/receive.

Task library

This library has been described in an earlier post. It is a simple non-preemptive task scheduler with fixed priority scheduling and a 1 millisecond timer tick. It is available for download from here.

Common code

This is code that is specific to the LED strip project, but that's shared between both the controller and the LED strip drivers.

Global configuration and LED strip colours

Some aspects of the system such as the colour definitions for the HL1606 strips, timing intervals, radio channels etc are shared between the master controller and the slave LED strip drivers.

Radio message

This is a simple definition of the control messages that are sent from the master to the slaves.

Pattern animator

Both the master and the slave units run the same pattern animation code. In the case of the master, the output is a series of synchronisation radio messages that keep the slaves in synchronisation. In the case of the slaves, the output is a series of SPI commands that drive the LEDs. This means that if a slave temporarily loses the radio signal from the master, it will continue to display the pattern. The resonators used on the Arduino pro Mini boards are not very stable, so in early testing it became apparent that the slaves would have to be kept in synchronisation by the master. To achieve this, the master sends a constant stream of synchronisation messages no more than 13 milliseconds apart to ensure the pattern generators in the slave remain in step.

Animation output and animation fade clock base classes

As the master and the slave are both running the same animation code, the animation output and fade clock output code were implemented as empty base classes, with the master and slave providing implementations appropriate to their roles in the system.

Pattern definitions

As has been noted, both the master and the slave run the same pattern animation code, so they both need access to the pattern definitions. Each of the 4 strips on the slave are animated separately, so the pattern definitions are a reasonably complex tree of data structures containing colour, movement and timing information that are interpreted at run-time. The pattern definitions are too large to fit in the ATmega's limited 2Kb of SRAM, so they are stored in program memory and the subset necessary for the current pattern step is extracted into SRAM and interpreted at run time.

Master controller

The software in the master is implemented as a set of tasks, implemented using the library descried above. The main program simply initialises the tasks before transferring control to the task scheduler. The tasks are as follows:

Display driver task

This manages the 7-segment display described in the hardware section above. Updating the display is not time-critical, so updates are made by saving the new display contents and scheduling the display update when no other high-priority tasks need to run.

Radio transmitter task

The radio task is responsible for transmitting the synchronisation messages via the nRF24L01+. Transmitting a message consists of storing the message details and scheduling the transmitter task to run. When it runs the message is transferred to the radio via SPI and transmitted. As synchronisation is key to the correct operation of the slaves, this is the highest-priority task.

Four animation synchroniser tasks, one per strip

These are derived from the Animation output base class that is defined in the shared code section. They are called by the pattern animators when the next step for an animation pattern needs to be output, at which point they queue a synchronisation message that is subsequently send by the transmitter task to the slaves.

Four pattern animator tasks, one per strip

Each strip is animated separately, so each requires its own animator instance. The animators extract the pattern definitions from PROGMEM and interpret them. At each new step the animators call the synchronisation tasks to output the appropriate synchronisation message.

Encoder/switch handler task

The rotary encoder and switch need to be read and debounced as described in this post. This task is responsible for doing that.

Voltage monitor task

The voltage monitor task samples the battery voltage every second via a voltage divider. Once the battery voltage drops below a certain level, the subcomponents of the master are powered down and the ATMega is put into suspend mode.

Interaction and pattern switching objects

These objects simply marshal and redirect the internal messages between the various tasks. They are called directly by tasks and call non-blocking operations on other tasks, although they themselves are not implemented as tasks.

Slave LED strip driver

As in the master, the software in the slave is implemented as a set of tasks, implemented using the library descried above. Again, the main program simply initialises the tasks before transferring control to the task scheduler. The tasks are as follows:

Four LED strip driver objects, one per strip

These are called by the pattern animators when the next step for an animation pattern needs to be output, at which point they output the new LED settings to the strips via SPI. They aren't tasks as they merely transmit the LED setting bytes to the strips.

LED clock object

The LED strips need a fade clock to drive the pattern fades as described in this post. This object manages the internal ATMega timer that is used to generate the fade timing clock pulses.

Four pattern animator tasks, one per strip

Each strip is animated separately, so each requires its own animator instance. The animators extract the pattern definitions from PROGMEM and interpret them. At each new step the animators call the LED strip driver objects and the LED clock object to output the appropriate synchronisation message.

Radio receiver task

This task receives the incoming radio messages from the master, decides which strip they refer to and makes any necessary adjustments. This could be to switch to a new pattern, to adjust the current pattern step of a strip if it leads or lags the controller, or to adjust the delay until the next pattern step if the clocks on the master and the slave have drifted.

Voltage and temperature monitor task

This task samples the battery voltage and temperature every second via a voltage divider and a thermistor. Once the battery voltage drops below a certain level, the subcomponents of the slave are powered down and the ATMega is put into suspend mode. If the temperature exceeds 60C the strips are turned off until the temperature drops below 40C, at which point the pattern output will be resumed.

Summary

This project is reasonably complex for a microcontroller - about 5000 lines of code with the master and slave binaries both being 13K in size. There are a number of non-obvious design constraints and decisions that I haven't had space to fully explain in this post, I'm intending to write some follow-ups to explore those areas in more depth.

Waiting for O(1)

Tue, 19 Oct 2010 17:14:11 GMT

Due to a misconfiguration the notification emails from my blog weren't reaching me, so I missed a couple of interesting comments on my earlier HL1606-related posts. The ones from Dan from over at Waiting for O(1) were particularly interesting, and he's written a SPI library for driving the HL1606 as well as other similar LED drivers such as the LPD6803 and WSC2801 - if you are looking for alternatives to the HL1606 he has some links on the googlecode page for his project. Dan is actually doing PMW fading of the strips, so he's driving them via timer-generated hardware interrupts. Dan has a lot of useful tips and observations about speed and power limitations he's run into and how he's solved them that are well worth checking out, check out his blog.