Decision 4 – How will I control the lights?

Today’s post I’ll be answering the above question in very broad sense. What do I mean by this? Well, the question can be interpreted in a few ways, whether it relates to software, hardware, electronics, etc. So I will break down the various components of the system at a high level.

The exact hardware technology choices – will be up and coming in Decision #6 down the track – or have been discussed before in Decision #2.

We want to take some form of programming, and make lights blink to our instruction – so what comprises a Christmas Light system from end to end, in order to make that happen? Let’s start at the fun bit, the blinking lights, and work our way back to the source.

LED Pixel Lights

These are so called because they operate similarly to a pixel in a computer monitor. They have three coloured LEDs, red, green and blue, which when turned on to varying brightness can mix and create the full spectrum of colour. In Decision #2, I discussed the different physical types of pixels used, but not their operation.
Pixels are controlled by an Integrated Circuit, which takes in some format digital signal, and reads the red-green-blue (RGB) data from the data to switch on the three elements at an appropriate brightness. There are a numerous formats, but the most common is WS2811, discussed below.

The lights are daisy chained, and the first light is fed all the data for the entire string of LEDs. Every pixel chip grabs the first pixel worth of data from the stream, processes it and illuminates. It then strips that data from the stream, and passes on the remaining data. Because of this, there are no ‘addresses’ – each pixel just processes data in order. If pixels for a certain function are swapped, then the data stream needs to have the data swapped too.

The below diagram shows how the pixels are interlinked, each pixel has a data input (DIN) and data output (DO). They are connected serially. The second image shows the data at the 4 points between the interconnected pixels, where each is stripping the first data it sees and passing the rest down the line.

Interconnection between pixels
Data as it travels between pixels

Pixel Controllers

In order to generate the pixel data, we need a controller that understands the protocol used by our pixels. There are numerous controllers out there on the market, many developed for the Christmas Lighting hobby, and some professional designs as well.

These controllers will generally receive channel-based data in a standardised format over an ethernet network – typically E1.31 (sACN / DMX over IP) and decode this into RGB pixel format from triplets of channels. There are other protocols, such as ArtNet and DDP, which perform a very similar function to E1.31, but with minor protocol differences.

You can map the input data to the output pixels, as well as set global brightness levels, set up virtual strings, and set the pixel output formats.

Some controllers are stand-alone, meaning they run firmware in them, and operate as a complete unit, and some are expansions on top of Raspberry Pi or BeagleBone boards, utilising the GPIO connections and programmability of these platforms.

Controllers range from 1 to 48 pixel outputs, with anywhere up to 1500 pixels per output, as well as being able to drive differential outputs which allow long-range transmission of pixel data without signal quality loss.

Four examples are below, two firmware boards – the Falcon F16V4, Advatek Pixlite 16 mk2 – and two BeagleBone boards – the Kulp K32a-b and Hanson HE123mk2. Click the images to go to the manufacturer website to find out more.


Once a sequence has been programmed, there needs to be a way to generate the control data – Artnet, DDP or E1.31, and send this to the pixel controllers, for display on the lights.

This is where a playback platform is needed. There are three main ways to do this; 1. Use the controllers inbuilt player, if it has one, 2. use a PC running software, or 3. use a small-board computer running software.

When using the controllers player, the sequence is uploaded to the device, which generally controls its own outputs only. The controller would also need to support generating the sound, if your sequence is programmed to music. Currently the Falcon controllers are the ones best suited to this mode of operation.

On a PC, software called xSchedule can generate the required network output from the sequence files. The PC sound card can also generate the audio. xSchedule can run on Windows or Linux, so there is a choice of operation there. The disadvantage to this is that it requires your computer to be dedicated to the show, meaning you can’t use it for other purposes (well, you can, but it could cause show issues) – and the power consumption of a full-sized PC is not immaterial.

The third option is using a small-board PC, such as Raspberry Pi. A piece of software called “Falcon Player”, or FPP for short, was developed for this purpose. It is flexible enough to play audio (either via USB sound card or the boards sound output) – as well as control pixels via ethernet output, and local connections. It can also receive data from another player, or perform synchronisation of local playback to minimise network traffic. In fact, the small-board computer based controllers (such as the Kulp and Hanson above) use FPP as their software loaded on their computer.

This is a screenshot of what FPP looks like without anything loaded. It uses a web front end that’s straight-forward and easy to use.

Falcon Player running on a test machine that I’ve set up


Creating a sequence involves loading in your music track, configuring what your display looks like, and placing effects as you see fit. You can also import sequences that others have created (there are numerous vendors that sell sequences).
Three main packages are used within the hobby – those are xLights, Vixen 3 and Light-O-Rama.

The first two are open-source / free, and the third is a paid product, specifically designed to work with the Light-O-Rama software.

When looking at the pieces of software, I found xLights to be the most intuitive, and it has a massive community support group behind it, and loads of online videos. It also integrates well with the controller hardware, allowing remote configuration directly from the software.

xLights will run on Windows, MacOS and Linux, with cross-compatibility of files between all the platforms. Additionally, it can import files from other platforms and work as a go-between if needed.

xLights running on MacOS


Being a network engineer, dealing with real-time traffic such as voice, I cringe a little bit at some information that’s posted out there. Plenty of information will state that you should have a dedicated network, separate from your home network. This, I agree with 100%. This complicates things as your sequencing computer needs access to both networks to operate, which can be achieved a couple of different ways. This is where I think some of the suggestions are a little wild, but for the layman they might work well. But, I won’t get into the ins-and-outs of it here, suffice it to say, that I have read the advice with a grain of salt, and come up with my own network design.

My home network is not your standard home network. I run a bunch of enterprise network gear (Juniper, Cisco, Huawei, Mikrotik), have a few servers for virtual machines, development environments, and as well I host mail and files for the family business. As such, there are around 12 VLANs split across as many subnets, and dynamic routing linking my property to 5 others.

So I have added another VLAN, logically segregated from the rest of my environment, and there will be a dedicated switch running the show when it happens. The advantage of configuring it this way is that it gives me the flexibility to incorporate the subnet into my standardised networking, that IP routing ‘just works’, and that I can light up a show-network port anywhere on my network, such as in my workshop as required.


This is something that deserves a whole new post. Coming up next! 😉


So as you can see, plenty of pieces of hardware and software tie together, sitting on an underlying network, making all of this possible. I’m sure this all makes sense in my mind, and if anyone is reading this planning their own show, I hope it makes sense to you too.
If you are starting a show for yourself, please, feel free to reach out to me with any questions or comments; I’d love to help; alternatively (and maybe as well as!) – sign up to AusChristmasLighting – there are some fantastic resources in there and plenty of folk who have done this many times before.