My name is Barri.
This is me:
And this is a thing I did.
Occupation Status: It's Complicated
At the end of March this year I quit my job as a code monkey software engineer and started a personal sabbatical to concentrate on musical projects and anything else that took my fancy. The idea was simply to do things because they were interesting rather than because they made money. The unkind among you may think this is merely another way of saying 'I am unemployed'.
They would be wrong.
They would be wrong.
I have been employed, just not for money. Instead I've enjoyed the richer rewards of personal satisfaction, the expansion of knowledge, significant amounts of fun, one free ticket to this year's Glastonbury festival and two weeks of camping and being fed three vegetarian meals a day.
By my calculations next year I will owe the Inland Revenue fifty-three minutes of Kanye West and half a plate of tofu, to both of which they are more than welcome.
As is only natural for someone who had spent five years dreaming ever more strongly of quitting the day job and seeking my fortune as a piano player, I finally quit the day job, sat down at the piano and... started a coding project.
It wasn't my fault. Something interesting came along and I couldn't help myself.
Besides, I can now code wearing my dressing gown (if I'm expecting guests) and work until four in the morning with no expectation of being anywhere in particular before noon the next day.
It's much better this way.
Look What I Found!
I live in north London in a household of eight humans and two cats. One of the humans is Dan.
This is Dan:
Dan is freelance in the more traditional sense of quite often making money from what he does, and what he does is take electrical devices that were previously not working and making them work.
Dan does hardware, I do software, and we are both interested in those places where the two meet.
See where this is going?
Dan does hardware, I do software, and we are both interested in those places where the two meet.
See where this is going?
One day shortly before I quit work, Dan came home with this:
In fact, with four of them that joined together. It was an old LED display board that he'd... well, let's go with 'found'. Whether it once said 'Phones Unlocked While U Wait' or 'We are now approaching East Croydon' I really can't say.
But Dan also came home with an idea.
But Dan also came home with an idea.
He said: Let's put it up in the hallway and make it show local bus departures in real time.
So we did.
What Does This Bit Do?
Dan spent several days and nights sticking electrical probes into these (to me) bewildering assemblages of electronic components, marking out the circuit paths and downloading pin diagrams for the various chips. He figured out how the thing worked, and then we spent several days working together to figure out how we could control it.
The board is mostly a two-dimensional matrix of LEDs, 180 pixels wide and 16 tall when all four units are joined together. The display 'scans' down the screen, so only one row of lights is ever switched on at any one time.
The Address Decoder is the chip that selects which particular row will be illuminated, and the Shift Register is a set of chips connected in series that selects which LEDs in that row are on and which are off.
The display is controlled by putting either a HIGH voltage or a LOW voltage (which equate to a 1 or a 0 in computer-speak) onto the correct pins of these chips. While each chip has lots and lots of pins, there are only a few we need to worry about.
The Address Decoder's important bits are the OUTPUT pin and several ADDRESS pins. The OUTPUT pin switches the power to the LED matrix on or off (in this case a LOW voltage, or 0, means ON), while the voltages on the ADDRESS pins determine which row in the matrix gets the power.
The Shift Register, while actually a lot of chips wired together, is best thought of as a single long chip which contains a string of 1s and 0s determining which LEDs in the selected row are lit. In this case a 1 means ON. It's a 'Serial-In Parallel-Out' register, which means you put the bits into one end of the chip and shift them along one by one until it's full, and then the whole string can be read at once to illuminate the correct LEDs.
Don't worry, there's an animation coming.
The Shift Register is controlled using three pins: DATA, which holds the bit you are pushing in, CLOCK, which causes the bits to all shift along one place, and STORE, which makes the string of bits available on the parallel outputs (which connect to the LED matrix).
The CLOCK and STORE are 'edge triggered', which means they are activated by a change from 1 to 0 (or 0 to 1).
Imagine...
A very simple 4x4 LED display. The Shift Register is 4 bits wide and the Address Decoder has 2 address lines (a 2-bit number can represent four different states: 00, 01, 10, 11 equating to the decimal numbers 0, 1, 2, 3).
Now imagine you want it to display something that looks slightly like a cross between the letter 'A' and a ghost from Pac Man.
They say a picture is worth a thousand words, so surely an animation is even more expensive:
This is a very approximate diagram with over-simplified wiring. Also we spent a considerable amount of time experimenting with the precise order and timing of the pin changes to get a stable image on the display, so this isn't exactly how it really works. Consider the animation a guide to the general principles at play rather than instructions on how to build one*.
*I would not, for example, recommend connecting a 5V feed directly into a 3.3V Address Decoder. Try as you might, you will never get all the blue smoke back in.
In reality the board's Shift Register is 180 bits wide and the Address Decoder has four control lines (to address sixteen rows).
In fact, the real board works in two halves, each with its own 90-bit Shift Register. Although they share CLOCK and STORE they have separate DATA lines which are populated in parallel.
In fact, there are two 90-bit shift registers in each half because every pixel on the board has both a red and a green LED inside it.
But you get the idea.
And these chips are (mostly) part of a Shift Register:
We decided to use a Raspberry Pi to control the board. This is a credit-card-sized computer with exposed GPIO (General Purpose Input/Output) pins for controlling low-level hardware and so was ideal for our purposes.
Also, we happened to have one.
Here it is:
The board is mostly a two-dimensional matrix of LEDs, 180 pixels wide and 16 tall when all four units are joined together. The display 'scans' down the screen, so only one row of lights is ever switched on at any one time.
The Address Decoder is the chip that selects which particular row will be illuminated, and the Shift Register is a set of chips connected in series that selects which LEDs in that row are on and which are off.
The display is controlled by putting either a HIGH voltage or a LOW voltage (which equate to a 1 or a 0 in computer-speak) onto the correct pins of these chips. While each chip has lots and lots of pins, there are only a few we need to worry about.
The Address Decoder's important bits are the OUTPUT pin and several ADDRESS pins. The OUTPUT pin switches the power to the LED matrix on or off (in this case a LOW voltage, or 0, means ON), while the voltages on the ADDRESS pins determine which row in the matrix gets the power.
The Shift Register, while actually a lot of chips wired together, is best thought of as a single long chip which contains a string of 1s and 0s determining which LEDs in the selected row are lit. In this case a 1 means ON. It's a 'Serial-In Parallel-Out' register, which means you put the bits into one end of the chip and shift them along one by one until it's full, and then the whole string can be read at once to illuminate the correct LEDs.
Don't worry, there's an animation coming.
The Shift Register is controlled using three pins: DATA, which holds the bit you are pushing in, CLOCK, which causes the bits to all shift along one place, and STORE, which makes the string of bits available on the parallel outputs (which connect to the LED matrix).
The CLOCK and STORE are 'edge triggered', which means they are activated by a change from 1 to 0 (or 0 to 1).
Imagine...
A very simple 4x4 LED display. The Shift Register is 4 bits wide and the Address Decoder has 2 address lines (a 2-bit number can represent four different states: 00, 01, 10, 11 equating to the decimal numbers 0, 1, 2, 3).
Now imagine you want it to display something that looks slightly like a cross between the letter 'A' and a ghost from Pac Man.
They say a picture is worth a thousand words, so surely an animation is even more expensive:
*I would not, for example, recommend connecting a 5V feed directly into a 3.3V Address Decoder. Try as you might, you will never get all the blue smoke back in.
In reality the board's Shift Register is 180 bits wide and the Address Decoder has four control lines (to address sixteen rows).
In fact, the real board works in two halves, each with its own 90-bit Shift Register. Although they share CLOCK and STORE they have separate DATA lines which are populated in parallel.
In fact, there are two 90-bit shift registers in each half because every pixel on the board has both a red and a green LED inside it.
But you get the idea.
Originally this whole process was carried out by a pair of central processors (one for each half), but Dan bypassed* these and soldered wires into the circuit paths so we could control the process ourselves. This was not only easier than trying to reprogram the central processors, but also more fun.
*Technical term for 'removed with a hacksaw'.
This is the Address Decoder:*Technical term for 'removed with a hacksaw'.
And these chips are (mostly) part of a Shift Register:
We decided to use a Raspberry Pi to control the board. This is a credit-card-sized computer with exposed GPIO (General Purpose Input/Output) pins for controlling low-level hardware and so was ideal for our purposes.
Also, we happened to have one.
Here it is:
And here it is wired into the LED board, with a USB WiFi adapter:
Here is a single row illuminated:
At this moment the ADDRESS pins are set 0100 (row 4, starting from 0 at the top), the Shift Register contains the string 00111000000110010... etc. and the OUTPUT pin is set to 0.
Here is the spotlessly-clean, space-age workshop where all thebafflement drinking magic happened:
Here is the spotlessly-clean, space-age workshop where all the
Softly Does It
I suppose before I go any further I should try to justify choosing Java for this project rather than the obvious alternative of C.
I like Java.
I was a professional Java developer for five years and have used it for a lot longer than that. It's a language I know very well, whereas my last serious experience of C was writing a game of Pong at university using an oscilloscope, two variable resistors and a microprocessor that probably couldn't run a washing machine.
C would have made the hardware-control parts of this project much more efficient, true, but I would have had to do a lot of reading before I could write the high-level bits like calling HTTP services and parsing XML and this project was, or at least started out as, something done just for the fun of it.
That said, I will (probably) rewrite part of this application in C to improve performance when I have time.
That said, I will (probably) rewrite part of this application in C to improve performance when I have time.
Anyway.
Software people tend to divide systems into 'layers of abstraction' with the metal (hardware) very firmly at the bottom. Hardware people, bless 'em, often draw these sorts of diagram upside-down.
The lightboard software (everything inside the dotted grey line) is a standalone Java application, developed using IntelliJ and built using Maven. The source code is available on my GitHub profile, and you can find it here.
Transport for London, the company who run most of the city's local transport network, very kindly share their real-time data (about arrival times, service disruptions, etc.) with the internet via a collection of web services. Anyone can make a HTTP request to one of these services, and get back essentially the same data that the displays at bus stops and on tube platforms receive.
You can try one by clicking this link.
The Updaters are objects that make HTTP requests to TfL and turn the response into an intelligible piece of text. One of the Updaters, for example, obtains information about the Tube network using the link above. The link returns data in XML format, and a response like this:
<LineStatus ID="5" StatusDetails="">
<BranchDisruptions/>
<Line ID="5" Name="Northern"/>
<Status ID="GS" CssClass="GoodService" Description="Good Service" IsActive="true">
<StatusType ID="1" Description="Line"/>
<Line ID="5" Name="Northern"/>
<Status ID="GS" CssClass="GoodService" Description="Good Service" IsActive="true">
<StatusType ID="1" Description="Line"/>
</LineStatus>
Will become the rather more friendly:
Northern: Good Service
Northern: Good Service
The TextZones are objects that take that text, turn it into a pattern of dots and scroll the pattern over a specified region of the board, usually right-to-left (in the case of tube information) or bottom-to-top (for buses).
The dots are 'drawn' onto the LightBoardSurface, which stores the current state (ie. which lights are on and which are off) of the entire board. It periodically dumps this state to the LightBoard.
Nothing I've described so far directly touches the hardware. In fact most of it was originally written before the hardware was ready.
I'm not going to talk about classes, interfaces, inheritance, dependency injection or polymorphism because I don't want to get you too excited, but one advantage of this kind of separation is that you can write more than one version of a particular layer without affecting any of the other layers.
So, the first version of the LightBoard layer didn't try talking to a board that wasn't there, but instead displayed this window on a screen:
And so I could build, test and improve all the higher-level aspects of the software while the hardware was still being put together.
After that, for no particular reason, I turned the application into a HTTP server using the Jersey framework so that it could be controlled over the house WiFi.
I tell a lie, there was a reason: I wanted to send messages to the board from my phone.
There was just no real reason for that.
Not at the time, anyway.
So Now It'll Just Work, Right?
The software was working nicely on its pretend board, and the hardware was thoroughly mapped out and wired into the Raspberry Pi. We had already experimented with controlling the hardware from Java using the excellent Pi4j library, and found it to be relatively painless after some initial setting up and configuring.
When we plugged it all in and fired up the software, this happened:
Some lights came on! Nothing caught fire! Result!
Almost.
The only reason you can make out the word 'Tubes' in this picture is that the camera shutter was open long enough to capture it. In fact it was taking almost half a second to refresh the entire board, which to the naked eye looked like a line scanning down the screen. Also, the text was blurred even when you could make it out.
Dan and I disagreed over whether this was a hardware problem or a software one (I'll leave you to guess who thought what) but in the end it turned out to be a bit of both.
Firstly, we were using an old Model B Pi, which didn't have enough GPIOs to poke all the pins we needed to address. To get round this we were using an I2C serial interface. This is a plug-on circuit board which can turn two GPIOs on the Pi itself into sixteen 'virtual' GPIOs. Sadly, it slows things right down.
Even in the single panel shown in the picture above the CLOCK pin, for example, has to be poked 1,440 times for each screen refresh. The serial interface just couldn't do that fast enough to get a reasonable refresh rate.
Even in the single panel shown in the picture above the CLOCK pin, for example, has to be poked 1,440 times for each screen refresh. The serial interface just couldn't do that fast enough to get a reasonable refresh rate.
Secondly, the Pi4j library exposes the GPIO system in a nicely abstracted Object-Orientated way that appeals to my sense of coding elegance, but unfortunately adds a significant time overhead to controlling the pins.
Dan solved the hardware problem by moving as many of the connections as possible to the native GPIOs and only using the I2C for pins that weren't poked quite so often (such as the address pins, which only change once per row).
He also, embarrassingly for me, found the solution to the software problem on a forum. Underneath all the nice OO abstraction, the Pi4j library actually controls the pins via a set of static methods. By accessing these methods directly I managed to improve the refresh rate of the individual pins by a factor of about 100.
We now had a just-about-acceptable refresh rate but, of course, there were many additional problems. The image was tearing thanks to some multi-threading issues (easily solved) and it took some experimentation with the precise ordering of the pin changes to get a sharp image, but eventually we ironed these issues out.
Now it worked!
And looked very cool at night...
And finally took its place above our front door...
Job done!
But not quite the end of the story...
Glastonbury 2015
Another human in the house is called Ben.
This is Ben:
Ben owns a lighting company called Oculux, and for the past few years he and Dan have designed, installed and managed all the lighting for the Greenpeace field at the Glastonbury festival. Ben helped us out many times during our little project, and when we'd finally made it work he gave us a chance to put the result to a different use.
Among the many lovely features of the Greenpeace field is a set of free hot showers. These draw quite a crowd at a festival renowned for its unwelcome mud-baths, and naturally this leads to some horrendous queues. In previous years a ticketing system improved things, and this year they wanted a slightly 'slicker' way of broadcasting the latest ticket numbers out to the field.
We had just the thing.
Doing It For Real
Obviously our LED board wasn't suitable to be used at Glastonbury, partly because it was cobbled together from salvaged bits and pieces and partly because there was only one of it. Greenpeace wanted three boards around the field - two in the cafe and one above the entrance to the showers - to display the next ticket numbers for the showers as well as customisable campaign and information messages. The whole thing had to easily controllable from a single tablet.Finally we could actually buy stuff!
We used four of the latest model of Raspberry Pi - one for each board and one to act as a central server. The 'Pi 2' has more than enough GPIOs for our needs, more RAM and a much faster processor than its predecessor. The slight flickering the old board had suffered from disappeared once I increased the JVM's heap size to take advantage of the new platform, a simple step which really should have occurred to me much earlier than it did.
NOTE: The fifth Pi, as well as the device they're all sitting on, was for the other project we did at Glastonbury.
The LED boards themselves were each made up of three 64x32 panels connected horizontally in series. The general principles of control were the same - only this time we had a nice header to solder onto instead of having to find accessible points to jump into the circuit paths as we had with our more bespoke unit.
There were differences. Rather than being addressed as two 90x16 sections (being the left and right of the board) these new ones were addressed as two 192x16 sections (being the top and bottom). Also the DATA line was inverted so that a '1' switched the LED off.
But after some tinkering, it worked perfectly:
Code! More Code!
The LightBoard software already did most of what was needed for the job. It already supported message queues, scrolling text zones and scrolling JPEGs, and could be monitored and controlled using HTTP. I added a Scene to display ticket numbers and a set of scrolling messages, and added the relevant endpoints to the web service API.I then created a simple Java application to store the ticket numbers and messages and post them to the individual boards, and to process commands from the tablet. You can find the source code for that here.
In the same repository you'll find the web interfaces used on the tablet, which are simple HTML and JavaScript pages that were mostly written onsite during the festival build*. These were served from the same Pi as the Ticket Server application, using a simple Python module.
*The third strangest place I've ever written code.
Getting It Together
The boards were housed in cases made by Ian the Super-Chippy, one of the carpenters onsite, each along with a Raspberry Pi and a power supply. They were all CAT-5'd, along with the server, into a WiFi router so we could include the Android tablet we provided for the shower stewards.Big thanks to all of the fabulous Lighting Crew for installing the things!
Plug and... Play?
The whole system was designed to start without any human intervention beyond physically plugging the units in. Plug it all in, in any order, and in about forty seconds the whole system comes on-line, ready to use...It was a tense forty seconds.
...
And...
...
It didn't work!
...
There was a fault in the Ethernet cabling. Soon fixed.
Then...
...
It was another tense forty seconds.
...
...
...
And...
...
...
...
...
...
...
Forty seconds is a really long time!
...
...
...
...
...
...
...
Happy Days :-)
Though maybe next year we should make a bigger sign for the shower block itself...
Don't Forget The 'Finally' Clause
Working on the Greenpeace build at Glastonbury was a fantastic experience. It was a pleasure to work with so many creative, talented and passionate individuals. I'm glad to have made my own small contribution to a field that looked, in the end, breathtakingly good.And I was then free to enjoy the festival, of course...
It was also quite life-affirming, in a way. I put time and effort into this project for no other reason than it seemed interesting, and it earned me an amazing experience that I'll never forget.
Leap, and the net will appear?
Maybe.
So... anyone want to buy a Light Board?
Acknowledgements
Big thanks to Dan and Ben, of course, and thanks once again to the rest of the Lighting Crew: Angelika, Chester, Eva, James, Joe, Keith, Lisa, Other Ben, Sarah, Toby, Tom (hopefully I haven't missed anyone there) as well as everyone else who made the festival so great. See you next year!
Thanks to Ben and some internet random for a couple of additional photos of the units in situ. All other photos and diagrams are my own.
All the words in this piece are freely available via the English language, though I take full credit for their precise ordering here.
