The Starway to Reno

May 26, 2016 at 2:10 pm 1 comment


In my quest to try and understand IoT better I decided to help my friend Deborah Davies with her project ‘Starway‘.

Starway is an interactive sculpture which progressively gets brighter as people interact with it.

A non-interactive version was exhibited at BurningMan in 2014 cropped-starway_duncanshot1

The challenge for this year’s Reno Sculpture fest was to add the interaction. We needed to make the stars twinkle – and ideally make it possible for passers-by to brighten a star (and possibly make a wish).
This involved adding more than 700 RGB controllable LEDs – 3 per star on a hand made mount screwed into place. (timescales were so tight we couldn’t risk the delay of designing a proper PCB).


A 3 LED board

Each of the 5 diamond shaped legs of the star had a chain of 144 (fewer in the ‘buried’ legs)


Starway wiring

Fortunately I arrived in Reno too late to do much of the carpentry Dan (above) and Debbie did most of that. (As my woodwork teacher would attest, I’m a liability with a saw). I did help with some soldering. The LEDs are a cool design. Each has an individual embedded controller. They have 4 wires, +5v, 0v, Data_in and Data_out. The way you control them is to send 24bits of RGB data (8 bits for each colour) at exactly 800kHz on Data_in the LED then displays and remembers this colour. The clever bit is that after the first 24 clock cycles the LED passes all the excess data straight through to Data_out. If you connect a second LED’s data_in to the first’s data_out then it receives this data strips off the first 24 bits and passes on any excess.  So in theory you can control an infinitely long string of LEDs with just one data pin.



At which point physics and engineering kick in to make life more difficult.

1) Generating an exact 800kHz string of data isn’t trivial, you can’t do it on a normal computer like a laptop or even RaspberryPi. If the processor is interrupted  while clocking out that data, there will be a gap in the data stream – which will get mis-interpreted by the LEDs. You need something that can do exact real-time down to the microsecond.

There are 3 ways around this :
i) Build a (big) hardware shift register, load it from a Pi and have it clock out the data.

ii) Use a microcontroller (like an arduino or a TI Launchpad), write a sketch that takes data from a serial port and puts it in memory and at the same time loops through memory at exactly 800kHz clocking the data out on a pin. My friend Peter Stuge had built a set of devices along this model for BurningMan 2014 but unfortunately didn’t get time to deploy them.

iii) Use a device that has a realtime processor and a general purpose CPU on the same board. After some discussion with Peter I opted for this, selecting the BeagleBoneBlack, which has an ARM CPU and 2 real-time PRUs (Programmable Realtime Units). This was in large part because I found the LEDscape project which did exactly what I needed.



2) Although each of the LEDs only draws 60mA at 5v, when you have 700 LEDs that adds up to 42Amps at worst case, which would melt the ribbon cables show above. The LEDs stop working at about 4 volts – so we couldn’t afford a significant voltage drop either.

To solve this we put an 8A 5v USB charger (white boxes above) in the center of each diamond and ran 4 power feeders (Black wires above) out to groups of LEDs.

The interaction called for Starway to respond when a viewer presents a small star to the sculpture. The plan in 2014 was to have an RFID reader on a USB and put RFID tags on a couple of hundred small wooden stars that could be handed out.

For Reno we largely stuck to that plan, just substituting an Arduino with an RFID shield for the USB reader and plugging this into the Beaglebone’s USB port.



RFID reader

 This was fine until the artistic decision was made that the RFID reader needed to be some 16M from Starway so as to give the user the best possible view of the star. Unfortunately USB has a hard limit at 5M of cable. A quick re-think had me adding a second BeagleBoneBlack, an ethernet hub and a 25M ethernet cable between the 2 devices.


RFID reader at the correct distance from Starway

The rest (as they say) is software – I wrote some Java that would generate the appropriate data and send it to LEDscape which then formats it and loads it onto a PRU for clocking out to the LEDs.

The twinkling was interesting to write – fortunately I have one of the early Starway prototypes on my wall at home (a 12 star baby version) – so I was able to experiment with the randomization of the twinkles until I got an effect I liked. (excuse the shaky animated gif). The brighter stars have already been wished-upon by visitors and so remain brighter than their attention-seeking co-stars!


Starway Twinkling

The current software is on github with a rough description of how it works and how to install it. (although without a Starway, I’m not sure what you can do with it).

I’ve learnt an enormous amount about the practicalities of IoT in a short space of time – from power distribution, realtime data, what happens when circuitboards get wet, that BeagleBones die when you apply 5v in the wrong place and the many, many ways users misunderstand seemingly clear instructions. (Being across the road from a bar can’t have helped in the latter!).

Thanks to all for letting me learn on such a beautiful project!


Entry filed under: Art, Iot, startup. Tags: , , .

The problem with legal intercept and backdoors. The solar battery monitor

1 Comment Add your own

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Trackback this post  |  Subscribe to the comments via RSS Feed

Follow me on Twitter

%d bloggers like this: