2022/03/30

Setting the Scene

Note: This post was written in 2014 but somehow got lost and was never finished or posted. After an enquiry about where we got the sound track from, I’ve dug it out, made sure the links still work, and here you go.

So now, about a week before the first Easter Trail run, we had a control system. Now what, exactly, was it going to show to the audience? To be fair, the sound track CD from Frodsham Churches Together had arrived well before this, so I knew that we had a sound track to play. There were a few questions however to sort out, and the little matter of the lighting.

On the sound front, I made only two changes:

  1. A longer, slower fade in at the start

  2. An extended soundscape and fade out at the end

The longer start was simply a question of looping the existing ambience of the Garden of Gethsemane to provide a subtle start whilst the audience were making their way into the garden and sitting down.

At the end, things were a little more complicated. The original sound track ends with the garden ambience fading into silence, then a cockerel crows three times in the silence, marking dawn and the moment when Peter realises he has denied Jesus, just as Jesus told him he would. This is an important point, but repeating the same recording of a single cockerel crowing three times in silence didn't really convey the point - it felt tacked on and artificial.

The first question was how to convey the passage of time, from the night of the main Gethsemane events to the dawn of the following day. The obvious cue seemed to be the chorus of birdsong that accompanies dawn. This may not be strictly authentic to first century Jerusalem, but is an audio cue that the audience should recognise. Many birdsong recordists are focused on one single bird, actively trying to exclude the wider wash of sound, which is what we are after. After a little searching, the internet turned up GT Weddig’s birdsong recording from Yuba Pass. Recorded in 2013, this is a wonderful soundscape of birdsong which goes on for 12 minutes – only a fraction is used in the final soundtrack. Thanks to Greg for releasing this recording under a Creative Commons license so it can be re-used in projects like this.

Then there was the cockerel. This proved to be easy, thanks to the amazing Freesound project, which hosts a huge amount of freely usable sound recordings. Definitely my first port of call for real sound recordings for any project. In this case I used a cockerel recording by user soundmary. The cockerel obligingly crows twice, waits a little, and crows twice again, just to drive the point home – no editing or duplication needed!

All the editing was done in Audacity, which also allowed me to mark up the key points in the "story" with labels to help me set out the lighting cues, which were done second.

This sound track has been used in the same version for Easter Trails in 2014, 2016, 2018 and now 2022 – it has held up very well, and always makes a big impact on participants.

2018/03/07

Fresh Pi Please

The Easter Trail will run again at St. David’s over the week 12th to 16th March 2018, with evening openings on Monday and Thursday evenings. So I am in the middle of setup week again. Not a huge amount is being changed, but one of the things which does need doing is an new microSD card image for the Raspberry Pi which controls the lights in Gethsemane. The previous card had been used for doing other development work and is now two years out of date, so we needed a clean start with up to date packages. Note I am still using a Pi 2 Model B, and there will be some differences if you have a Pi 3 because of the on-board wireless hardware.

Foundations: Operating System

I know that I want to run Raspbian, and that I won’t have a graphical user interface, so I opted to install Raspbian Lite directly. The download page has the links to the latest version of Raspbian Stretch Lite, at the time of writing 2017-11-29. It also links to the Installation Guide, which takes you through creating your card image.
As we won’t have a user interface, it would be nice to be able to go straight in using SSH, without having to worry about connecting up a keyboard and monitor. Helpfully the Raspberry Pi Foundation have documentation for that as well – see section 3. To find out what IP address your Pi has received, see here.
So at that point you should be able to get a shell session on your newly created Pi first time. Change the password like it tells you to! Next install all the updates since the image was created. This is somewhat tedious, but gives us an up to date starting point:
$ sudo apt update && sudo apt upgrade
After the updates have been installed, reboot the system before continuing.
You need to install some packages we need, all are in the Raspbian repositories and so can be installed with apt:
$ sudo apt install screen ola wiringpi mplayer vim
I have installed the vim editor here and will use it later on, but feel free to substitute whatever editor you can work and are comfortable driving, and amend the commands as required.
If you want to change the timezone, language support and so on, then you can do so using raspi-config  now.
Next we will use raspi-config to set up the serial port (which is a lot easier than editing configuration files by hand). So run:
$ sudo raspi-config
In the menus, use the arrow keys to move up and down, then press Enter to select and option. Go to Interfacing Options, then choose Serial. The answer to the questions are:
  • “Would you like a login shell to be accessible over serial?” No
  • “Would you like the serial port hardware to be enabled?” Yes
Next we want to make sure that we don’t get stuck when there isn’t internet access in the venue. Go to Boot Options and select Wait for Network at Boot. The answer to
  • “Would you like boot to wait until a network connection is established?” is No.

Infrastructure: Power Control

My Raspberry Pi has a custom power supply setup which means it can do a proper shutdown to no power consumption, like a real PC. There is some extra configuration to do for this, which you will have to skip until I get round to writing up how the PSU works. If we do not configure the raspberry pi at all, the system will boot up, because the power control pin is configured as an input, and we have a pull-up which keeps the power supply on.
To switch the power supply off when the system has shut down, the power control GPIO pin must be set up in the Device Tree.
There are a bunch of device tree blobs for this in /boot/overlays/, documented in the README. The one you want is /boot/overlays/gpio-poweroff.dtb so we add a line in /boot/config.txt
dtoverlay=gpio-poweroff
but we also need to select which GPIO pin to use (4) with the gpiopin parameter, and choose active low operation, so the final line is
dtoverlay=gpio-poweroff,gpiopin=4,active_low=y
note the use of active_low=y is important – just active_low doesn't work here.
Now the system turns off the power supply at the bottom of the shutdown cycle, as we wanted it to.

User Interface: GPIO scripts.

I’m not going to bother installing git just to fetch one repository, so instead head over to my scripts repo on Github in a web browser on another computer. Click on the green “Clone or download” button, locate the “Download Zip” link copy the link. On your Pi, download it with wget, e.g.
$ wget https://github.com/richardash1981/pi-play-scripts/archive/master.zip
and rename it something more constructive
$ mv master.zip pi-play-scripts_master.zip
then unpack the archive. This will create the directory pi-play-scripts-master/ containing the files. This also needs to be renamed to match the internal paths (which also rely upon you using the pi user).
$ mv pi-play-scripts-master pi-play-scripts
Next we need to add the scripts to rc.local so that they are run on boot.
$ sudoedit /etc/rc.local
and add
# script to make power off button work
/home/pi/pi-play-scripts/shutdown.sh &
# scripts for lighting control
su pi -c '/home/pi/pi-play-scripts/stop.sh' &
su pi -c '/home/pi/pi-play-scripts/play.sh' &

Control: OLA

We have installed the Open Lighting Architecture package, but it will need some configuration. This can be done from the command line, or via the web interface on port 9090, e.g. http://192.168.0.147:9090
At the command line we list what plugins OLA has:
$ ola_plugin_info
Id Plugin Name
--------------------------------------
1 Dummy
2 ArtNet
3 ShowNet
4 ESP Net
5 Serial USB
6 Enttec Open DMX
7 SandNet
8 StageProfi
9 Pathport
11 E1.31 (sACN)
12 USB
13 FTDI USB DMX
14 OSC
15 SPI
16 KiNET
17 KarateLight
18 Milford Instruments
19 Renard
20 UART native DMX
21 Open Pixel Control
22 GPIO
This looks good, what is the status of the UART?
$ ola_plugin_state --plugin-id 20
UART native DMX
Enabled: False
Active: False
Conflicts with:
OK, enable it:
$ ola_plugin_state --plugin-id 20 --state enable
Whilst we are here, turn off the USB Serial plugin because it spams the logs and we do not use it.
$ ola_plugin_state --plugin-id 5 --state disable
Next we need some configuration. The configuration file for this plug-in lives at /etc/ola/ola-uartdmx.conf in the Raspbian package.
$ cat /etc/ola/ola-uartdmx.conf
device = /dev/ttyACM0
enabled = true
So we need to fix that, because the Pi serial port is showing up as /dev/ttyAMA0. It should read
device = /dev/ttyAMA0
enabled = true
Now we can patch universe zero to the UART output (see also OLA documentation)
There are quite a lot of interfaces showing (because we haven’t been round disabling them all)
$ ola_dev_info
Device 1: Dummy Device
port 0, OUT Dummy Port, RDM supported
Device 2: OSC Device
[…]
Device 10: UART native DMX
port 0, OUT /dev/ttyAMA0
So I must patch device 10, port 0, your numbers may differ. You should patch to universe zero as this is what the scripts use.
$ ola_patch -d 10 -p 0 -u 0
This should now have the output set up. To make sure these settings are saved, reboot the Pi as the shutdown will get OLA to save it’s settings.

Content: Show Files

Load up the audio file, default lighting state file and lighting show file into the home directory (or change buttonsets.sh to reflect where they are).
$ scp gethsemene2.flac gethsemene2v4.olar default.olar lpi:
You should now be good to go – press the buttons and see what happens!

Epilogue: Notes

Depending on how your sound is connected you may have to use raspi-config to direct default ALSA output audio to your output device – it worked for me first time, so I haven’t included it in the instructions here, but you can force either the analogue output connector or the HDMI port as default audio destination.
It’s worth noting that I didn’t have to mess around changing the UART clock (which was originally needed) on this install – either the driver takes care of it, or the default is now high enough to make it work out of the box.

2016/03/19

The Easter Trail at night

This year, for the first time, we ran an evening session open to anyone, as well as the booked school groups. This took place on Thursday evening at 7:30 pm (because our Brownie group meets earlier on a Thursday evening), so was the first time we have run the trail after dark. It was quite an experience for us all! Although there are street-lit roads on two sides of the church building, neither brings very much light into the building once the blank fabric walkways are up, making the building very dark at night.

The Upper Room was mainly lit by a collection of battery LED 'candles' on the low table, to keep the atmosphere consistent with 2000 years ago. We did have to add one battery LED light on the far wall to provide general light - maybe next time we can come up with some LED 'oil lamps' to hang from the ceiling!


To give people enough light to move safely, we brought some more blue moonlight into the back streets of Jerusalem using another LED Par can fixture. The used was a 108W light, and actually much larger than it needed to be at night - it was turned most of the way down to avoid blinding people.


Gethsemane, having a full blackout, was unaffected by the light levels outside, so ran as normal. The most dramatic changes were in Golgotha, where loosing the ambient light spilling in gave the red flood-washing of the white wall hugely more impact. The spot lighting onto Peter was critical here, to avoid him ending up hidden in darkness where the participants could not see him. This worked well (the dark backdrop behind Peter absorbs most of the spill from the spots) and emphasised the situation of Peter hiding from the authorities, too scared to come to the foot of the cross.


Finally, through the darkness to the Resurrection Garden at dawn. Given the big change from the darkened walkway to the light of the Garden, I kept the lights (all on a single channel) dimmed down until people started to approach the Garden, then brought them up slowly to give a visual "dawn" as they encountered Mary in the Garden.

The response from the participants was excellent. We had a group of all ages, from a young baby with it's parents to several older people (including one in a wheel chair!) and one of our local councillors. One of the children who had been to the trail earlier in the week with her school came back, bringing the family, which was very pleasing to see.

There are some more photographs of the trail at night on flikr - including some the participants don't get to see.

2016/03/07

Doing it all again

On Monday the first school group will visit the Easter Trail for 2016, as we gear up to do it all over again. The feedback from local primary schools on the first trail was very positive, so we are re-running with more groups coming, and more people involved. So on Sunday after morning service, we moved all the furniture around:
Today we have been starting on the setting, which will carry on throughout this week, ready for the Dress Rehearsal run on Sunday afternoon. School groups will run through the following week, with Messy Church on Tuesday evening, an open event on Thursday and then our Palm Sunday service to end the week. Pray for us!

2014/04/21

A Journey through the Easter Trail

In this Easter season (I started writing this yesterday!) I thought I ought to take a break from the technical “how” of the trail, and remember the reason we did all of this – to share our faith in Jesus Christ with the primary school children audience in a relevant and engaging way. So here is a short impression of what the trail was like to experience, illustrated with some photographs from the Sunday morning when we ran the Trail for the regular St. David's Sunday congregation and Messy Church attendees to experience.

The journey started in the church hall (with a notice on the church door to re-direct anyone we didn't manage to catch!), where tables and chairs were set out for people to sit down and tea and coffee were served as people assembled. Whilst not the normal Sunday service, this is something we have done in the past (and had done the previous week in order to be able to set up in the church!).

Once most of the congregation had arrived, the Storyteller, in period Middle Eastern costume, introduced the event, explaining that the congregation would split into two groups and travel on a journey back two thousand years in time and to the streets of Jerusalem, a Jewish city under Roman occupation. The group assembled and headed off, out of the hall and outside to reach the main door of the church.


Entering the church from the porch, the group found themselves in the streets of Jerusalem 2000 years ago, outside a large Upper Room where a celebration of the Jewish Passover feast was just winding down. But, as the wife of the owner of the room told us we when got inside, this had not been quite the ordinary Passover meal. All the usual elements of the Passover celebration had been there, but Jesus had jolted everyone by adding to them – things that no-one expected. He had taken the bread, the ordinary flat unleavened bread of the Passover celebration, and had broken it, saying it was his body, broken for them. Not at all what was supposed to be done at a Passover meal.


Later on, Jesus had taken the jug of wine served with the meal, but he called it his Blood, shed for all for the forgiveness of Sins. Then he insisted everyone drank some, although no-one was very clear why, or what he was on about.

About this time, one of the Disciples slipped out, but without saying goodbye to anyone at the feast – which was a bit odd. Anyway, Jesus had said he wanted to pray, and took his Disciples off with him into the night. The wife of the owner of the room thought the most likely place they could have gone was the garden called Gethsemane, and suggested we try and find them there.


So we were lead out by the storyteller into the dark, narrow streets of Jerusalem, to make our way out of the City and into the moonlit garden of Gethsemane. We must have arrived quicker than Jesus and his friends, because no sooner had we arrived then we heard them coming through the trees and bushes, so we had to hide out of their way to see what would happen next.

Jesus left Disciples in a group and moved a little way away – directly towards us. I don't think he knew we were there, because he was praying very earnestly – in deep turmoil. He was begging to not have to do something, to have it taken away, if there was any other way. But he couldn't insist – God's will must be done, he kept saying. It was very dark, and a bit spooky. The disciples, meanwhile, were asleep – we could hear them snoring!
But that was nothing to what happened yet. There was a red glow of torches, and a noise of marching. Suddenly there were soldiers in the garden – we were definitely hiding now! They went to where the Disciples were, and there was some sort of scuffle. Everyone seemed to run off at that point, and the soldiers marched back away with their torches, taking with them whoever they had come for. We weren't that sure the soldiers had gone though, so we sat tight.

Next we knew, it was coming up dawn with the yellow glow of dawn coming up and birdsong. Then a cockerel must have woken up, because it crowed, two times together. Someone said that was a sign, although what of no-one seemed to know. The soldiers really did seem to have gone, so we sorted ourselves out and headed back into the City.
As we went, we came in sight of the place called Golgotha. It's a horrible place – we didn't go any closer than we had to, because the Roman Soldiers were executing someone there, hanging them on a cross of wood until they suffocated. We had had quite enough of soldiers so kept away, but there was someone else watching what was going on from a distance.

He was a man named Peter, and he was scared – really, really scared. He was one of Jesus' disciples and had been there in the Garden of Gethsemane, he told us, and the man the soldiers had taken away was Jesus – who had been in the Upper Room, and that Passover feast we visited. And now it was Jesus who the Roman Soldiers on Golgotha were crucifying. It didn't make any sense, to Peter (who was to scared to make sense of much) or to us. Jesus was a teacher, a good man, someone people looked up to. So how had he been sentenced to death so quickly, in just one night? Peter was all upset he had denied Jesus, three times before the cockerel crowed, he said. That same cockerel we heard crowing twice in the Garden. But someone else must have betrayed Jesus, must have done him in in a dirty little deal behind closed doors. Peter was off, back to his fishing boat, worried the soldiers would be on his tail next if stuck around.

So we moved on, back into the streets. Time was getting on, and the Jewish Sabbath was fast approaching, and no-one would be doing anything then. They kept their holy day very strictly, and with the way the Jewish High Priests enforced things you would have two. So to learn anything we would have to slip forward past the Sabbath day to the next day, Sunday, when the world would have to come to terms with what it had done in putting Jesus to death.

So we started early, heading off to another garden, not to far from Golgotha, where the grapevine said that they had buried Jesus, two days before after he was crucified. We weren't sure what we would find there, but we certainly didn't expect what did happen.

We were met in the garden near the tomb by Mary Magdalene, one of the women who had been in the group with Jesus. Not who we might have chosen to hang out with, but Jesus was like that – always accepting people most of use would have avoided. Anyway, Mary had obviously been crying – but she wasn't crying now. She was full of joy, laughing and talking. Apparently Jesus was alive! She had seen him die, like us, but there, that morning, she had seen him alive again! And sure enough, the tomb was open, his body was gone, leaving only the grave clothes behind. Suddenly the day seemed lighter, the garden full of flower and new life sprouting. Jesus had gone on to Galilee, his home turf, Mary said, and she had to go and find the Disciples to tell them to meet him there.
So off she went, leaving us to find our way back, back 2000 years and into the daylight outside the Church, but with a host of memories and experiences of those few days in Jerusalem, and what Jesus did for all of us, dying on that cross for all our Sins.

Christ is Risen! He is Risen Indeed!


More pictures are on St. David's website and my Flickr account.

Credits


An event like the Easter Trail is only possible through the hard work of a huge number of people, both on the days and over weeks either side setting up the church for the event and clearing up afterwards. There are no doubt people missing from this list, for which I apologise (if you know of anyone, please let me know).

Cast:

Storyteller – Reverend Trish Davis
Host at the Upper Room – Marjorie Ford
Peter – Richard Davis
Mary Magdalene – Bethan Case

Crew:

Technical Operators: Brian Pringle, Marion Clough, Hilary Ash
Off-stage Cues: Robert Pettigrew, Brian Hill, Bob Reynolds
Group Helpers: Hilary Ash, Elizabeth Pettigrew, Val Williams
Refreshments: Shelia Pugh, Pat Jolley, Barbara Owen
Craft Team: Enid Large, Jeanette Owens, Irene Wadeson, Lisa Gati
Technical Supervisor: Richard Ash
Photographs: Hilary Ash, Richard Ash

Set Up and Clear Down:

John Evans, Brian Hill, Judith Hill, Dot and Trevor, Irene Binns, Ray Sproston, Brian Jones, Val and Bob Williams
Production Co-ordinator: Judith Hill

2014/04/15

Command and Control II

On to lighting control. Implementing a full stage lighting control system would have been a huge project, but thanks to open source software it is rarely necessary to start anything from scratch. This was very much the case for this project, thanks to the Open Lighting Architecture project (OLA). This provides an open source set of tools for generating control signals, recording and playing them back, and interfacing them out to vast array of lighting control hardware. One of the developers (Simon Newton) even has ready-built Raspberry Pi images with the software installed and ready to go. The only missing piece was getting the DMX-512 control signals out of the Pi and into the right electrical format, via the Pi's on-board UART.

A search on the associated open-lighting discussion group indicated that various people had talked about this, been told it wouldn't work, and not actually tried it. Given that quite a lot of similar adaptors using the FTDI USB-serial chip to send DMX exist (and are supported in OLA), this didn't seem a logical position. The fact that the Raspberry Pi UART is integrated at a much lower level than a USB converter (with hardware interrupts and DMA available) should give it much better performance. So I decided to carry on and build such a system so the actual results could be measured.

Why DMX-512 is Hard

There are a number of reasons why producing direct DMX-512 output from a computer is considered hard, and software developers want to hand the task off to an external microcontroller running bare metal code. The key ones seem to be:
  • DMX-512 runs a a non-standard (for PC) baud rate of 250kbaud. Many computer UARTs cannot run at this speed, which makes them a non-starter.
  • DMX-512 uses serial break signals (periods when the line is held continuously in the '1' (non-idle state) to demarcate successive frames of data. These cannot be sent by just writing characters out of the serial port.
  • DMX-512 has relative tight timing requirements for various elements of the signal – if your computer suddenly stops sending data for a while, then the lights you are controlling may go out or flicker randomly.

Hardware DMX Output

The hardware side of sending DMX-512 is relatively simple – it uses simplex RS-485 (I am ignoring optional extensions like RDM). Simplex means that data only goes one way – the controller sends data, and everything else in the system just listens to it, with no answering back! RS-485 is a common standard for industrial serial communications, using a screened, twisted, pair of wires. Because RS-485 is common industrially, there are lots of integrated circuits which can translate from the transmit pin coming out of the Raspberry Pi (at 3.3V TTL levels) to the standard (higher) RS-485 levels. I used a Maxim MAX3158 line driver, because it provides isolation between the DMX control line (which will be connected to lighting ground) and the Pi (which will be connected to audio ground). For a simple project like this, isolation isn't required, but it can be very useful in avoiding humming audio and flickering lights on larger projects. I also had got hold of some at a good price!
RS-485 output schematic (pdf | svg)
The schematic is mostly just taken from the data sheet. Power is supplied from the Pi's 5V power supply, which is converted into an isolated power rail within the chip, and used to feed the output stage. R1 “softens” the connection between the output cable ground and the line driver, as recommended in the data sheet. R2 and C4 link the Pi ground to the DMX ground at high frequencies (to minimise interference) and provide a backup ground path if no other ground exists.
R3 is the DMX line terminator, to minimise reflections on the DMX cable, and needs to be the ½ W part because it gets quite a lot of current through it when the full output voltage is being driven.
Part Value
C1, C2 100 nF 100 V
C31 µF
C410 nF
C5 100 nF
R1 100 Ω ¼ W
R2 47 kΩ ¼ W
R3 120 Ω ½ W

This all worked straightforwardly – each byte sent out of the Pi's serial port was translated through to RS-485 levels on the DMX output connector, with no sign of ringing or waveform distortion.

DMX Output Plug-in

So back to those things which make software developers avoid direct DMX output. Before we try to start, we need to stop the default Raspbian image from using the serial port as a text mode login screen, by following these instructions. With that done and rebooted, I no longer got random data coming out of the UART.
The first software challenge was to get the UART outputting data at 250kbaud. The maximum speed seemed to be limited to 115.2kbaud, until I found a post on how to run the Pi UART at 1Mbaud which explained how to increase the clock speed of the UART. So do as it says, and add the line
init_uart_clock=16000000
to /boot/config.txt and reboot your Pi (again). This raises the clock limit, but we can still only get the “standard” speeds of 230.4kbaud, 460.8k, 500k and 576k – no joy at 250k. The setserial utility seems to support custom rates, but they don't work in practice. There is a plaintive little message in
the system log
Feb 22 18:55:02 lightingpi kernel: [ 4519.973048] seterial sets custom speed on ttyAMA0. This is deprecated.
What it doesn't say is that setting the custom speed also doesn't work on the Pi UART! After much puzzling, I found a stack overflow post describing how to use the Linux-only termios2 interface to set arbitrary baud rates (this is what you are supposed to use in place of the depreciated setserial method, if you can find out about it). This works, although writing a C program to use the termios2 API has several more “surprises” in store for the unwary.

With the proof of concept in place, on to using it in OLA. OLA has pretty good developer documentation and a detailed log of creating another OLA output plug-in. Between these, it was fairly easy to work out that most of what I was doing could be copied from the existing plug-ins, mostly that FTDIchip output driver I found near the start.
After all messing to get the correct speed, integration into OLA was very smooth, once I did all the things listed in the instructions to register my new plug-in, there it was in the output of the ola_plugin_info command:
Id Plugin Name
--------------------------------------
1 Dummy
11 E1.31 (sACN)
15 SPI
10000 UART native DMX
--------------------------------------
(10000 is the dummy ID for testing, it will only get a “proper” ID when the code is accepted back into upstream OLA development). The source code to my forked copy of OLA with the Pi UART plug-in added can be found on Github here. commit a4959cc46d is the version which was used at the trail, although there has subsequently been a new version of OLA released upstream (which I need to update to).
Once OLA was compiled with the Pi output plug-in, it needed to be enabled (the plug-in is deliberately disabled by default), by creating the configuration file /var/lib/ola/conf/ola-uartdmx.conf
which contains just two lines:
device = /dev/ttyAMA0
enabled = true
(there are some other advanced options, but you probably don't need them).

Moment of Truth

You should now have the UART native DMX output device visible in the OLA web GUI, so you can connect it to Universe 0, and use the web DMX console to start sending some output. With any luck, you should be able to fade up your light(s)! The fade won't be very smooth, because the faders only update from the browser a few times per second, but it proves you have control. You can get more detailed control (and timed fades) with the ola_dmxconsole command line tool which is included with OLA.
Next time, I will look at the how I created audio and lighting files to play back through this system.

2014/04/14

Command and Control I

The Design Journey

Having decided what we wanted to do in Gethsemane, the next questions were practical. How was this array of technology going to be controlled? Who was going to be available to work it? Where was it all going to be put?

The latter two factors fairly rapidly ruled out several options. The control and sound equipment (other than the loudspeakers) had to go in the bottom of a fitted wardrobe at the back of the room. This, together with volunteer availability, ruled out a full-time human operator. The volunteers available to run the trail (6 classes spread across 3 week days, plus an additional Sunday run) were not theatre or computer technology experts – perfectly happy using their computers and phones for email, but not going to be happy with a copy of MagicQ. So conventional computer control was not a good idea either. What was needed was something much simpler – one button to start things happening, and an emergency stop if needed. This would let one of the helpers press start at the right moment, and not require a dedicated lighting / sound operator.
Sound and Light control equipment in the cupboard
Given this, how? Designed-for-purpose lighting control equipment is a niche market, with correspondingly high prices (even on ebay!). But DMX-512 is ultimately just an RS-485 serial bitstream. How hard could it be to produce this, along with sound playback? Connecting up physical buttons for control of computers has been a rather expensive and difficult business, but the Raspberry Pi single board computer has changed all that – easily accessible pins for connecting buttons and lights to, and lots of help for writing the programs to link it all together. Better still, the Raspberry Pi has a built-in serial port, so we wouldn't even need a USB adaptor to connect the DMX output up!

So the “plan” took shape. All that was left now was to design and build the various bits of hardware and software needed to make it all work. As usual, some things went easily, and others took more work, but in the end it all worked – as seen in the previous Blog post.

Push Button Control

This was actually the second area to be tackled, but it was much simpler so I will describe it first. It is also probably more widely re-usable! The design ended up with two sets of controls and indicators: one set to switch the Raspberry Pi on and off safely (it is still a computer underneath!) and a second one to control the lightning and sound playback. Switching on is easy – because the Pi switches on and boots up a soon as power is applied to the board. So the only control needed was a way to tell it to shut down, and then indicate to the operator that it was safe to turn it off at the mains. The latter is important, because we did not have a monitor or screen, so there was no direct way to tell if the Pi was still running or not.

Power Button
This was relatively easy to solve however, with an LED (and resistor) connected from one of the GPIO pins to ground. These pins default to being inputs when the Pi starts up, so the LED is off. When the Pi is shut down, they go back to being inputs, so the LED is also switched off then. So all our program has to do is make sure that the LED is switched on when the Pi has started up and is ready for action. As we don't need to switch the Pi on with it's power button, our program just needs to start when the Pi is ready and watch the power button. When the button is pressed, it tells the Pi to shut down, and exists. There is no need to go back to watching the power button, because the system is about to shut down!
Lift the lid and press to shut down
The power button I used was a reset switch salvaged from a piece of scrap equipment, hence the transparent hinged cover to prevent it being accidentally pressed (useful!). It was too awkward to cut the large square hole required for the switch in the (temporary) case, which is why it is fixed to the outside of the box (it only has 3.3v across it, so safety is not an issue). The ready LED was fitted through a hole in the case and fixed with some hot glue on the inside. This main box lived in the cupboard with the other equipment, because it only needed switching on at the start of the day and off at the end.
Playback control unit

The rest of the controls (for playback) were fitted to an smaller box, which was hung on the wall in the room (where the helpers could find it) and connected by a length of 4-core cable back to the main Pi controller unit. This box was also made from the available bits, hence the extra holes in the front panel. To make it more user friendly it was re-painted with a left over can of car touch up paint, then rub-down dry transfer lettering (“Letraset”) used for the labels (my packet is not genuine, it came from a clear out, and was originally from RS). The shiny ring round the “Running” LED is simply a washer used because the hole is too big for the LED otherwise! Once the lettering was on and before the components are fitted, a coat of clear spray lacquer (again for car touch-up) stops it rubbing off. The result looks quite retro, but is serviceable.

The Circuit

The circuit diagram shows the connections for both the power control and the remote playback controls. The DIN connector linking the two was chosen simply because I had plenty of them around, and they don't fit anything else, so cross-connection was unlikely!
Circuit diagram for control buttons (pdf | svg)

 
The component values are in the table below:

Part Value
R1, R2, R3, R5 1 kΩ ¼ W
R4 100 Ω ¼ W
R6 10 kΩ ¼ W
D1 5mm Yellow LED “Ready”
D2 5mm Green LED “Running”
S1 Momentary push switch “Shutdown”
S2 Momentary push switch “Start”
S3 Momentary push switch “Stop”
T1 BC184L transistor
C1, C2, C3 100nF ceramic capacitors

The GPIO pins used are summarised in the table below. They are chosen to avoid using any pins which might be wanted for peripherals in the future (UART, I2C and so on) and to stick to the ones which didn't change between the original model B and subsequent versions of the Raspberry Pi (because I have one of each!).
Broadcom GPIO Header Pin Function
GPIO 23 16 Shutdown Button (pulled low)
GPIO 24 18 Start Button (pulled low)
GPIO 25 22 Stop Button (pulled low)
GPIO 4 7 Play LED
GPIO 22 15 Ready LED

Basic Pi


I'm assuming you can get your Raspberry Pi powered up and running without help from me – there are lots of much better guides out there on the web.

I used the standard Raspbian distribution for the Raspberry Pi because it was the easiest route to get things working. This had pretty much everything I needed, and it was easy to install the extras: WiringPi (following Gordon's instructions) and mplayer (with apt-get). I plugged in a WiFi dongle to connect the Pi to my home network and then logged in that way, but you could equally use a screen and keyboard, or a wired network connection.

Programming the Buttons

With the hardware design in place (or at least on solder-less breadboard!) we need some software to make it work. The path of least effort seemed to be to adopt the gpio program from Gordon Henderson's WiringPi project, and write some simple shell scripts to go with it, as I don't really do Python and C is far too much like hard work for such simple tasks.

The resulting scripts are on my Github. They are all intended to be put into /home/pi/. Just doing this won't make anything work, because they aren't running. As each of the scripts waits for a single button to be pressed, they all need to be started when the Pi boots up, and stay running in the background until you press a button. Because they use the “Wait for Interrupt” mode to wait for the button to be pressed, they very very little resources (unlike many of the examples, which keep checking (“polling”) the button, which can make everything else on the Pi go sluggish – which we can't afford).

To start the scripts when the Pi starts up, we add some lines to the /etc/rc.local script. This is a script which is included in the standard Raspbian distribution specifically for end users to customise with commands that they want to run when the system starts. Note they run before anyone is logged in to the system, which is good for what we are doing, but means there will not necessarily be anyone around to see what they do. If something here doesn't run correctly, there isn't an easy way to stop it running next time you start you Pi, so you might have to do some complex tricks to get your Pi back. Be careful!

First off, we want to run our shutdown.sh script, and we need to do it as the root user, so it has the permissions to be able to shut down the Pi (so we don't need to use sudo). This is easy, because the rc.local script is run as root. Any commands added to this script must complete before the system is considered ready, so we have to put our shutdown.sh script in the background, where it can keep running. So we add a line to /etc/rc.local like this:

/home/pi/shutdown.sh &

The & character is important – it makes the script run in the background, like we need it to.

The other scripts, for playing and stopping, need to run as the pi user (the default login), so we need to switch user before running them, so their lines go:
su pi -c '/home/pi/stop.sh' &
su pi -c '/home/pi/play.sh' &
The su command switches user (to the pi user) before executing the specified command. Again, the & makes them run in the background.

The other file is buttonsets.sh. This is important because it contains the settings (like which GPIO has which button connected to it) and file names (what sound file should we be playing) which all the scripts need to know about. This file needs to be put at /home/pi/buttonsets.sh so that the other scripts can find it.

Anything you are likely to need to change, should be in here, so you only have to edit one file to customise your Pi controller. The thing you are most likely to need to change is the soundtrack file, which needs to be the name of a sound file stored on your Pi so that it can be played back. You can ignore the rest for the moment.

Try it out

Hopefully you have already got mplayer to play some sound back, and set up some way to hear it (like some speakers plugged in to the audio out jack on your Pi). With this done, shut down your Pi, turn it off, and switch it back on again. After 30 seconds or so (which will seem like much longer!) it should have started back up, and you will see D1, the yellow “Ready” LED, flashing. Why is it flashing? Because some of the files listed in the buttonsets.sh file are not available on your controller, and the lighting control won't work. We will deal with that in a little while.

The sound should be ready to go (assuming you loaded a sound file and put it's name in the right place), so press the “Start” button. The green “Running” LED will come on, and you should hear the sound playing! You can let it play to the end (when the “Running” light will go out), or you can press “Stop”, which will cut the sound off, and put the “Running” light out straight away. Once playback has stopped, you can start it again, but you can't start playback more than once at the same time – the scripts have a lock to make sure that doesn't happen by accident.

The next post will look at how the DMX-512 lighting control was achieved.