Dmx interface for raspberry pi

Introduction

DMX with case

The DMX interface for raspberry pi allows you to interface a raspberry pi with DMX hardware.

There is also a version "with FT245". That version adds the option to use your raspberry pi with our board as an Enttec USB Pro compatible device from another computer (raspberry pi or PC, Windows or Linux)

If you select "for pi zero" we give you an extra 40 pin male header and do not solder the matching female header onto our board. You can then chose several configurations yourself. The one I prefer is to have the male headers on the zero on the bottom, and the female on our board on the top. Keep in mind that if you arrange for the pi to stick out from under or above our board, the pinout is going to be wrong. So you can't put the connectors on both boards on top, and then flip one to make the connection.

Software

There are several software packages that can be used with your DMX interface for Raspberry pi.

First there are QLC+ and OLA. These are packages that run on Linux on the raspberry pi and allow you to control a DMX Universe.

Second, there are several packages by Arjan van Vught that use the raspberry pi "bare metal".

See: http://www.raspberrypi-dmx.com/

DMX input on Linux

The Unix-derived way of handling tty/uart makes it impossible to do DMX input from userspace. So this option has existed in the hardware for ages, but for Linux there was no software support for DMX input.

I have recently (september 2024) written a driver for the UART in userspace that will actually do DMX input and deliver the DMX universe as a memory mappable file. From there it is easy to export it say to OLA, and hopefully QLC+.

This is a hardware driver, so it depends on the hardware. I've tested it on raspberry pi 3, and that works. I expect minor changes for other versions. It is not worth my trouble if nobody uses it, so if you need it, please let me know. I'll then make sure it works on YOUR raspberry pi and write some more documentation.

QLC+ and OLA

Don't forget to remove the console and getty from the serial port that the DMX inteface is using.

See: http://elinux.org/RPi_Serial_Connection#Preventing_Linux_using_the_serial_port

QLC+

Harold van Hulten wrote a nice "howto". See: http://www.udenix.nl/2016/how_did_i/rpi2dmx/

QLC+ 's home is at: http://www.qlcplus.org

our tests

To build qlc+ on raspberry pi with support for our board, you need to follow the howto at:

 https://github.com/mcallegari/qlcplus/wiki/Linux-build-Qt5

but with one addition:

 apt-get install libqt5serialport5-dev

needs to be added after installing the prerequisites. Next, it seems the uart device is disabled by default: edit

 plugins/plugins.pro 

to remove the hash on the line with "uart" so that it reads:

 !macx:!win32:SUBDIRS += uart

Next, you can build and install. Also use raspi-config to disable console output on serial but to enable the hardware. One more thing is to add the disable-bt and uart_clock to config.txt. See elsewhere on this page for the precise instructions.

OLA

bullseye

It seems that once again the stock OLA distribution has a problem with the uartdmx plugin.

To simplify a few steps I recommend to just install ola from the distribution. We won't use the actual olad binary, but it arranges a few things that are useful.

First this installs the scripts to have ola start at system boot. Also this will add the olad user we need to run the daemon under. We do this before compiling and installing ola from source so that our freshly compiled ola will overwrite the system binaries with a working one.

To compile ola from scratch from the github current version first install the dependencies:

If you haven't already done so, edit /etc/apt/sources.list

sudo nano  /etc/apt/sources.list

and remove the # before deb-src, which is probably the third and last line. Then:

sudo apt build-dep ola 

then get the sources:

 git clone https://github.com/OpenLightingProject/ola.git

The ola deamon should run under user "olad". Adding that is simple enough:

 sudo adduser --system olad

Then configure, build and install:

 cd ola 
 autoreconf -i
 ./configure --prefix=/usr
 make -j4 
 sudo make install 

The build step will take about 20 minutes on a pi4 with a fast SD card. (at least, that's what happened on mine :-) )

Next I had to add the olad user to the group tty to allow it to write to the device:

 sudo adduser olad tty 

FYI: A non-working olad (the one in the bullseye distribution) will report

 plugins/uartdmx/UartWidget.cpp:180: Failed to set baud rate to 250k

while a working one will report:

 plugins/uartdmx/UartDmxThread.cpp:136: Granularity for UART thread is GOOD

Also FYI: The build in bullseye has defines and build flags that result in the baud-rate-setting code thinking that the calls needed to set the baud rate are not available. In the latest ola version the conditions that cause the code to think it isn't available have changed a bit and the "we can't change the baud rate because at compile time the calls weren't available" code now prints an error message instead of just returning: "couldn't change it for some reason" resulting in the above "failed to set baud rate" message without further explanation.

If I've missed a step when you try this, let me know. (also let me know if all this was not necessary on your system, and say your distribution's ola worked. This hopefully happens in a future debian/raspberry pi OS version).

stretch

The distribution ola works on Stretch. sudo apt-get install ola should do the trick.

Don't forget to disable login on the serial port (raspi-config) and to set init-uart-clock in /boot/config.txt. If you forget that last, you will notice that the "native-uart" option is not available when you try to add the universe.

Jessie

On raspbian jessie installing OLA is easy: sudo apt-get install ola should do the trick. The downside is however that it doesn't work :-( .

update: The simple option seems to work now. :-) update2: Some hints are that it still doesn't work. :-( Some have reported success by following the howto at: http://www.raspberrypi-dmx.com/raspberry-pi-dmx512-rdm/ola-on-the-raspberry-pi (which boils down to installing ola 0.10.5 instead of 0.10.1.

what does work however is:

#sudo apt-get install automake libtool bison flex libcppunit-dev libprotobuf-dev libprotoc-dev protobuf-compiler protobuf-c-compiler uuid-dev libmicrohttpd-dev
sudo apt-get build-dep ola
mkdir ola
cd ola
wget https://github.com/OpenLightingProject/ola/archive/0.10.1.tar.gz
tar xvfz 0.10.1.tar.gz
cd ola-0.10.1
#libtoolize
autoreconf -i
./configure 
make -j 5 all
sudo make install

There is one little thing about the first two commands here. The first should always work, but if I accidentally missed a package, well.. I missed a package and the build will fail. The second one (with "build-dep" should be more reliable. But before that works, you need to add the sources to your /etc/apt/sources.list file. It's already there, but commented out. Use your favorite editor to do that. (otherwise, try: sudo nano /etc/apt/sources.list )

wheezy

On Wheezy, adding

deb   http://apt.openlighting.org/raspbian  wheezy main

to /etc/apt/sources.list, and then the apt-get install ola should work.

There are some important hints at: http://opendmx.net/index.php/OLA_Device_Specific_Configuration#UART_native_DMX

raspberry pi 3 and pi 4

You need to disable bluetooth to free the "right" uart for use by DMX.

You need to add in /boot/config.txt:

dtoverlay=disable-bt

This has the consequence that we've stolen back the good UART from the bluetooth that's present on the PI3 and PI4.

For reference (in case you have an older installation), it used to be:

dtoverlay=pi3-disable-bt

Otherwise, the wrong UART will be used. The "wrong" uart (=ttyS0) will be connected to the pins that the DMX interface uses. This uart will:

• change baudrate unexpectedly when the CPU feels hot.
• I haven't figured out if it CAN do the required baud rate, and/or how to do that.

On the raspberry pi forums there is talk about re-enabling bluetooth at a lower performance level, so that might be possible, however you'll have to do your own research.

all raspberries

First you need to disable "other things" on the UART that the DMX board uses.

sudo systemctl disable serial-getty@ttyAMA0.service

and remove "ttyAMA" or "serial0" from /boot/config.txt. (you'll find something like console=ttyAMA0,115200 there, remove that whole console= entry. Try not to mess up the rest of that line.

Most importantly: add:

init_uart_clock=16000000

to your config.txt file in the /boot directory. In my tests today (2023) I had a different number on my screen when I was doing this. I used 3x more: 48000000. This works as well (on a rpi4).

Next, you need to configure ola to use the native-uart plugin. It should be as easy as clicking on "add universe" on the ola home page. Somehow we often do not see the plugin active. Sometimes clicking on reload plugins helps, other times we need to restart ola to get the plugin to show up.

Locate your ola-uartdmx.conf (on some systems I'm told it is in /etc/ola/conf/, on others /var/lib/ola/conf/, and in some cases: /root/.ola/ola-uartdmx.conf or /home/pi/.ola/ola-uartdmx.conf. One of the ways to find out is to look at the -c argument on your running olad.). Edit it and set enabled to true, set the correct device (ttyAMA0), and add /dev/ttyAMA0-break = 100 and /dev/ttyAMA0-malf = 100 . It should then look like:

/dev/ttyAMA0-break = 100
/dev/ttyAMA0-malf = 24000
device = /dev/ttyAMA0
enabled = true

Note that the "malf" (mark after last frame) is set to 24 miliseconds. This is due to a problem with OLA: it writes the data and after that waits for the time specified in "malf". It turns out that the kernel will return from the write before the buffer is flushed. So the malf is measured from close to the START of the frame. Thus if you would enter the normal MALF of 100 microseconds, the next break is attempted after only about three characters have been sent. When the kernel then tries to empty the buffer before issuing the BREAK, it waits way too long. We (bitwizard + ola developers) have not been able to figure out an easy fix. So until then saying "24000" gives reasonable performance. (but once the bug has been fixed, you'll need to adjust this configuration parameter)

output mode

Then set the board to output mode. I would recommend creating a small script (sudo nano /usr/bin/set_dmx_mode; sudo chmod 755 /usr/bin/set_dmx_mode) :

#!/bin/sh
# set_dmx_mode
pin=18
gpio=/sys/class/gpio/gpio$pin
if [ $# -lt 1 ] ; then 
  echo "$0 : on or off?"
  exit 1
fi

if [ ! -d $gpio ] ; then 
   echo $pin > /sys/class/gpio/export
fi
echo out > $gpio/direction
echo $1 > $gpio/value

then calling the script:

sudo /usr/bin/set_dmx_mode 1

I recommend putting that line in /etc/rc.local so that it gets executed at boot time so you don't have to worry about it. (there is an "exit 0" in there, so put it BEFORE that!)

Or you can install the gpio utility from wiringpi. However this now seems unmaintained and hard-to-get and possibly it doesn't even work on modern pi's. But if it works on your pi the following command allows you view the status of all the pins

gpio readall

and to set GPIO 18 (BCM) in output mode

gpio -g mode 18 out
gpio -g write 18 1

also, pin 14 & 15 need to be in the ALT0 mode, if this is not the case use

gpio -g mode 14 alt0
gpio -g mode 15 alt0

Note that the earlier versions of the DMX board have a bug that when the GPIO 18 pin is an input (not driven) it will configure the board as an output. This is not desirable. Newer versions (starting 1.4) will have this "fixed" and the "default" will be "DMX IN" mode.

This does mean that if you want the board to do output, you can get away with forgetting about this gpio18 business if you have an older version. (I just realized I was getting away with this.... :-) )

Hardware

used hardware pins

The DMX harware uses the 3.3V, 5V, GND, RX, TX and GPIO18 signals. Besides that the non-FTDI version breaks out the SPI bus and I2C bus.

jumper settings

The jumper block has three (sensible) jumper positions, they can be either on or off. (We used to deliver the jumpers on the jumper block in say 1-NC, 3-NC, 4-NC: each of the jumpers on just one pin, not connected to another jumper pin. Nowadays we deliver them loose in the bag.)

Officially the DMX wire is called a bus. Oficially a bus should be terminated at both ends. Most people think of the DMX bus as coming out of our board and then TO the lamps. So most often our board will be at one end of the bus. In that case you should terminate the bus on our board: Jumper 3-4 mounted. Termination at the SENDING side of the bus is less important than on the opposite end. So if you're just sending DMX data with our board, the termination at our board is not that important. Most people don't bother.

Another possible configuration is that you have a few fixtures and then connect to the DMX IN connector on our board, and then another few fixtures on the DMX out. Our board will be in the middle of the bus, and you are then NOT supposed to add a terminator on our board: Do NOT place the 3-4 jumper.

With "short" busses, the termination is less important than with longer busses. What is "short" and what is "long" depends on the dataspeed. For example, for "SATA" 30-50cm is normal, 1m would be long. For DMX a few tens of meters is still "short".

The other two jumper positions should be added and removed in tandem. They provide a pullup/pulldown on the DMX databus so that the signal level is defined even when there is noone driving the bus. This is important when you do RDM. I found documentation that specified pullup on one line and pulldown on the other, but also the other way around. If you have trouble with RDM, add the jumpers. If that doesn't make things better, try using a few jumper wires and wire 1-5 and 2-6. If that works better for you, let us know!

Case

There is a case for raspberry pi with DMX board.

The assembly instructions have a few pictures.

Assembling_the_DMX_case