wiki.openlighting.org - User contributions [en]

Help:Contents

2011-07-01T06:36:38Z

Beier: Undo revision 3864 by Zhangpan (Talk) to remove spame

Consult the [http://meta.wikimedia.org/wiki/Help:Editing Editing Guide] for information on using the wiki software.

Category:Articles

2011-07-01T06:34:14Z

Beier: Undo revision 3863 by Zhangpan (Talk) to remove spam

OpenDMX.net

2011-07-01T06:32:42Z

Beier: Undo revision 3862 by Zhangpan (Talk) to remove spam

{{News}}
Welcome to opendmx.net. This site is part of the [[Open Lighting Project]] and aims to be a resource for those involved in the lighting industry looking for DMX software and associated control systems. It's also home to documentation for various open source and free lighting software.

If you're new to the world of lighting check out the [[:Category:Definitions|Definitions]] page, or have a look at the list of [[:Category:USB | USB interfaces]] or [[:Category:Controllers|Software Controllers]].

Do you know of non-conforming or fussy DMX equipment? If so, please add it to the [[NonConformDMX]] page. Are you interesting in seeing what equipment and solutions are available? See the list of upcoming [[Conferences & Exhibitions]].

The [[Open Lighting Projects List]] contains a list of installations from around the world where software from the Open Lighting Project has been used. If you know of something cool or are planning a new installation please add it to the list.

For questions about the site, contact admin <AT> opendmx.net

__NOTOC__

User:Zhangpan

2011-07-01T06:29:50Z

Beier: Deleted spam content

Misc. projects

2010-01-31T13:15:54Z

Beier:

This listing page is for project that don't need a separe wiki page (yet).

'''USB to DMX hardware'''

Using same protocol as Enttec DMX USB Pro
http://doityourselfchristmas.com/forums/showthread.php?t=7009
schematic and source code available to board members.

The "lynx USB DMX dongle" interface:
* FAQ: http://diylightanimation.com/index.php?topic=197.0
* Manual etc.: http://diylightanimation.com/wiki/index.php?title=Equipment#DMX_Devices
At least with one PC application this interface can emulate the Enttec Pro for tramission.

'''Other'''

Many notes and designs on http://members.westnet.com.au/rowanmac/

[http://www.brycecorkins.com/resources/bdmx/ Instructions to build a dongle] Input is command data from a RS232 port, a PIC with assembler code is used to clock out DMX.

'''DMX receivers'''
Software to AVR microcontrollers to receive or transmit DMX and control LED's, dimmers etc. and FTDI chip dongles:
http://www.hoelscher-hi.de/hendrik/english/ressources.htm

Microchip has application notes for DMX reception on their PIC microcontrollers.

OLA on Linux

2010-01-22T16:56:09Z

Beier: /* Install libraries */

=Installing OLA on Linux From GIT/Archive=

This describes how to get OLA working on a Linux system.

==Checkout or Download an Archive==

git clone http://www.nomis52.net/git/lla

If you don't have it yet, install '''git''' using your distro's package manager.

==Install libraries==

You need a couple of libraries installed for everything to work correctly. Some of these are available as packages in most distros but others need to be downloaded.

First up we'll need '''microhttpd''' for the embedded web server (Note: you'll need version >= 0.4.0):

-> [ftp://ftp.gnu.org/gnu/libmicrohttpd/ ftp://ftp.gnu.org/gnu/libmicrohttpd/]

Then you will need '''libcppunit-dev''' and '''libcppunit'''.

Debian users can install them with apt:

apt-get install libcppunit-dev libcppunit-1.12-1 uuid-dev

Next, you need the '''Protocol Buffers''' from Google (BSD license). Most likely, you will need to download and build them yourself:

-> [http://code.google.com/p/protobuf/ http://code.google.com/p/protobuf/]

Debian (and Ubuntu) users can, in some cases, use the following packets (not yet in stable):
libprotobuf2 (libprotobuf3), libprotobuf-dev, protobuf-compiler
For OLA 0.6.0, protoc v. 2.1.0 or higher is required.

Then, build '''CTemplate''' (another Google goodie):

-> [http://code.google.com/p/google-ctemplate/ http://code.google.com/p/google-ctemplate/]

Finally run ldconfig as root to pick up the new libraries

ldconfig

==Configure==

If you checked out the sources from git, you'll need to run

autoreconf -i

After that run

./configure

==Building & Testing==

Build
make

If you get an error like the following:

/bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I/opt/local/var/macports/software/protobuf-cpp/2.0.3_0/opt/local/include/ -g -O2 -c -o ltdl.lo ltdl.c
./libtool: line 464: CDPATH: command not found
/Users/simonn/lighting/lla/libltdl/libtool: line 464: CDPATH: command not found
/Users/simonn/lighting/lla/libltdl/libtool: line 1142: func_opt_split: command not found
libtool: Version mismatch error. This is libtool 2.2.6, but the
libtool: definition of this LT_INIT comes from an older release.
libtool: You should recreate aclocal.m4 with macros from libtool 2.2.6
libtool: and run autoconf again.

Your system uses a different version of libtool. Run:

libtoolize --ltdl -c -f

and then start from the autoreconf step again.

Run the tests
make check

And install OLA
sudo make install
sudo ldconfig

Q Light Controller (QLC)

2010-01-22T11:56:07Z

Beier: fix typo, add link to plugin page

Link: https://sourceforge.net/projects/qlc/ (for download) 
Link: http://sourceforge.net/apps/trac/qlc/ (for documentation, bugs) 
{{Features|linux=yes|osx=yes|win=yes|tx=yes|free=yes}}
[[Image:Qlc-2.4.png|right]]

QLC is a lighting controller for Linux. Started as a university project by Heikki Junnila, it has now evolved with an active development community.
In 2009 it was released for Mac Os and Windows also.

'''Features:'''
* Fixture-oriented interface.
* Four DMX universes, 512 channels each
* Fast changing and smoothly fading scenes and chasers
* Easy creation of complex patterns for moving lights with EFX
* Conjure/design your favourite lighting desk layout with the virtual console™
* Support for external fader devices such as the [http://www.behringer.com/EN/Products/BCF2000.aspx Behringer BCF-2000]

'''DMX output''' is provided using:
* the driver system [[OLA]] (via a plugin to QLC), allowing DMX output using various DMX over IP protocols and [[Enttec]] [[DMX USB Pro]]. (for Linux, Mac OS and Windows, not all drivers work on all platforms)
* the Peperoni [[Rodin1]] (well tested) interface, plugin named peperoni-output (Linux (requires kernel driver) and Windows)
* the Enttec [[DMX USB Pro]] and [[Open DMX USB]] (Windows and Linux, Mac OS, tested rather well)
* [[Anyma uDMX]] (Windows, Linux and probably Mac OS but not well tested)

At the moment there are most drivers for Linux and fewest for Windows. In v. 3.0 the plugin for [[OLA]] (formerly LLA) is not included/enabled per default.

'''Inputs'''

QLC can be controlled by [[MIDI]] eg. from [http://www.behringer.com/EN/Products/BCF2000.aspx Behringer BCF-2000] and support for a [[Enttec]] wing may be added.
Sound synchronization is not supported [http://sourceforge.net/mailarchive/message.php?msg_name=5d3d60e90904131158r29d01e65i9e7a7ea7f61db8d%40mail.gmail.com]

'''Plugins'''

Inputs and outputs are provided through plugins to QLC, see the the details at [[QLC plugins]].

'''Fixtures'''

Fixture definitions are used to map generic functions of a fixture like intensity, pan, tilt etc. to the specific DMX channels and values.
You can create your own fixture definitions to suit your needs, but there are a number of ready-made definitions [http://qlc.svn.sourceforge.net/viewvc/qlc/trunk/fixtures/ listed here]! QLC has a graphical "fixture creator" program.

'''Bugs'''

If you find a bug, you can report it [https://sourceforge.net/apps/trac/qlc/report here], or alternatively send an email to the [https://sourceforge.net/mailarchive/forum.php?forum_name=qlc-devel qlc-devel mailing list].

Related Tutorials:
* [[LLA and Q Light Controller Ubuntu Tutorial]]

Related Products:
* Peperoni [[Rodin1]] and [[USBDMX21]]
* [[Enttec]] [[DMX USB Pro]], [[Open DMX USB]]
* [[Anyma uDMX]]
* [[OLA]]
* [[DMX 4 Linux]]

[[Category:Controllers]]

QLC plugins

2010-01-22T11:55:15Z

Beier: Placeholder for the needed plugin documentation

== Output plugins ==
They are used for DMX output

{| border='1px'
! Name in GUI !! Name in source code !! Supported hardware !! OS supported !! Notes
|-
|
|
| Rodin1
|
|
|-
|
|
| Enttec Open DMX USB
|
| ? remove VCP driver ?
|-
|
|
| Enttec DMX USB Pro
| Windows, Linux
|
|-
|
|
| [[Anyma uDMX]]
|
|
|-
|
|
| [[OLA]] system
|
|
|-
|}

== Input plugins ==
They are used for control input to trigger and adjust things inside QLC.

[[MIDI]]

Special support for control surfaces

Misc. projects

2010-01-16T15:42:13Z

Beier:

This listing page is for project that don't need a separe wiki page (yet).

'''USB to DMX hardware'''

Using same protocol as Enttec DMX USB Pro
http://doityourselfchristmas.com/forums/showthread.php?t=7009
schematic and source code available to board members.

The "lynx USB DMX dongle" interface:
* FAQ: http://diylightanimation.com/index.php?topic=197.0
* Manual etc.: http://diylightanimation.com/wiki/index.php?title=Equipment#DMX_Devices
At least with one PC application this interface can emulate the Enttec Pro for tramission.

'''Other'''

Many notes and designs on http://members.westnet.com.au/rowanmac/

Software to microcontrollers to receive or transmit DMX and control LED's, dimmers etc. and FTDI chip dongles:
http://www.hoelscher-hi.de/hendrik/english/ressources.htm

[http://www.brycecorkins.com/resources/bdmx/ Instructions to build a dongle] Input is command data from a RS232 port, a PIC with assembler code is used to clock out DMX.

Open DMX USB

2010-01-13T11:56:54Z

Beier: /* Driver Support */ LLA --> OLA

[[Category:USB]]
[[Image:Opendmxusb.JPG|right]]

Link: http://www.enttec.com/index.php?main_menu=Products&prod=70303&show=description&name=opendmxusb 
Made by: [[Enttec]] 
{{Features|win=yes|linux=yes|osx=yes|tx=yes|rx=yes}}

The OpenDMX USB is based on a FT232BM chip, a USB to Serial converter produced by FTDI.
The widget is capable of DMX transmission and reception, but is totally reliant on the CPU to produce (or capture) the DMX signal, so this type of device is called 'unbuffered'. It works quite well, but if for example your PC froze for a second, so would the DMX. The design is GPL (you can build your own!) and is quite basic, and does not offer any protection for your equipment.

Note that receiving DMX does not currently work under Linux.

==Driver Support==

Linux Kernel 2.4: via [[DMX 4 Linux]]

Linux Kernel 2.6: via [[OLA]] as detailed in [[LLA, OpenDMX USB and Q Light Controller Tutorial]]

In [[QLC]] on Linux, Mac OS and Windows.

Related Products:

* [[DMX USB Pro]]

LLA, OpenDMX USB and Q Light Controller Tutorial

2010-01-13T11:49:39Z

Beier: historic update

[[Category:Tutorials]]

=== Old tutorial, look for new methods ===

Since this tutorial was made, [[QLC]] from v. 3.0.4 comes with a driver for Enttec Open DMX USB (in a plugin called FTDI), and LLA changed name to [[OLA]].
See the mailing list archive of "QLC-devel" for more info for now (January 2010).

It should no longer be necessary to use [[OLA]] together with a Linux kernel driver, if you just want DMX output from [[QLC]] to an OpenDMX USB dongle attached to the same computer that runs QLC.

== Purpose ==
To show the steps to get the Enttec Open DMX USB interface working with the Linux Lighting Architecture, a general framework for lighting applications in Linux(LLA), via Erwin Rol's driver. Also getting the Q Lighting Controller (QLC) to work with LLA. This allows QLC to be used with the Enttec OpenDMX USB interfaces on a 2.6 kernel, for which dmx4linux is not yet fully working.

This may also be useful for people with a different interface supported by LLA who need some pointers on how to get LLA working with QLC, in which case you need only read from "Download and install LLA" onwards.

==Introduction==

I got very excited when I first saw QLC (http://qlc.sourceforge.net/). Then I got slightly annoyed, then very frustrated trying to get it to work. I ended up using Slackware so that I could have a relatively modern distro with Linux 2.4 in order to use dmx4linux. But it's a hassle to reboot every time I want to play with DMX. The other alternative is to use LLA, but this requires a separate computer for the Live CD.

LLA is available as packages for a standard distro, but needs an extra driver to work with Enttec OpenDMX USB, which is included on the Live CD but not in the standard packages.

This tutorial assumes you're using Ubuntu 7.04 (Fiesty Fawn), but should be usable for any apt-based distro. Could probably be adapted for rpm-based too.

This tutorial is deliberately quite verbose: although it could have been presented as one long cut'n'paste or a shell script, a walkthrough is more helpful for actually learning what's going on and will get out of date more slowly.

It would be really useful if users of other distros could modify this tutorial to make it more universal, or create other pages for distro-specific information.

==Operating System==

Install one of the supported linux distributions onto your machine: Ubuntu [http://www.ubuntu.com], Fedora [http://www.fedoraproject.org] or CentOS [http://www.centos.org]

==Prerequisite packages==
===GIT and Cogito===
These are used to download source code.

Ubuntu:
<code><pre>
sudo apt-get install git-core cogito curl
</pre></code>

Centos/Fedora:
<code><pre>
yum install git-core cogito curl
</pre></code>

===Kernel===
We need this in order to be able to compile the modules

Ubuntu:
<code><pre>
sudo apt-get install linux-source
</pre></code>

Centos/Fedora:
<code><pre>
yum install kernel-devel
</pre></code>

===Alien (Ubuntu only)===
We will need to install some RPM files at some point (bah!)

<code><pre>
sudo apt-get install alien
</pre></code>

===Build essentials===
We're going to be building source, so we need the standard libraries:

Ubuntu:
<code><pre>
sudo apt-get install build-essential
</pre></code>

Centos/Fedora:
<code><pre>
yum install buildsys-build
</pre></code>

(if you're following this on a non-debian-style distibution, you need the libc, libstcd++ development files, C compiler etc.)

==Build and install the usb kernel module==

Erwil Rol's driver allows the Enttec OpenDMX USB driver to work with LLA.

It's best to make sure that you're running the kernel that you're intending to use - if you've upgraded from previous versions of Ubuntu you may have several versions hanging around. Removing old ones using Synaptic is probably a good idea.

===Compile and install driver===

<code><pre>
cd ~
mkdir dmx-software
cd dmx-software
git-clone http://www.erwinrol.com/git/dmx_usb_module/
cd dmx_usb_module
make
sudo cp ./dmx_usb.ko /lib/modules/$(uname -r)/kernel/drivers/usb/serial
sudo depmod
</pre></code>

===Blacklist the other serial drivers===
Because this dongle uses a usb to serial converter chip, it's recognised by the hotplug/udev/hal system and drivers are loaded - unfortunately not ones that work with QLC. The workaround is to blacklist the alternative drivers. If you have other usb to serial converters then they will stop working - if you need these then you will have to delve into the source and change the USB device IDs that the drivers detect... here we will go for the quick and dirty solution.

====Ubuntu====
With your favourite text editor, as root/sudo, edit /etc/modprobe.d/blacklist e.g.:

<code><pre>
sudo gedit /etc/modprobe.d/blacklist
</pre></code>

add the following lines:

<code><pre>
blacklist usbserial
blacklist usb-serial
blacklist ftdi_sio
</pre></code>

====Centos/Fedora====
I do not know of any blacklisting in redhat based distros so just delete the offending module

<code><pre>
mv /lib/modules/`uname -r`/kernel/drivers/usb/serial/ftdi_sio.ko /lib/modules/`uname -r`/kernel/drivers/usb/serial/ftdi_sio.ko.disabled
depmod -a
</pre></code>

===Remove the brltty package (Ubuntu only)===
According to Synaptic, "BRLTTY is a daemon which provides access to the Linux console (text mode) for a blind person using a soft braille display". Unfortunately it has a habit of interfering with anything that looks like it might be a serial console, USB to serial devices included. There's probably a more elegant workaround, but we'll go for the quick and dirty again, and remove it:

<code><pre>
sudo apt-get remove brltty
</pre></code>

===Test the driver===
Plug in your dongle!! Hopefully all will go well, and if you type:

<code><pre>
dmesg
</pre></code>

you should see:

<pre>
DMX USB device now attached to dmx192
</pre>

If you've got other modules loading, ftdi serial drivers, etc. then something's wrong.

==Download and install LLA==
LLA is Linux Lighting Architecture, a general framework for lighting applications in Linux. It's available as a live CD, but we're just using the package as a way to interface QLC with the USB driver. More info about LLA on its webpage.

===Install the packages===
====Ubuntu====
There are debian packages available at the time of writing. Add the packages to your sources file:

<code><pre>
sudo gedit /etc/apt/sources.list
</pre></code>

Add the following line at the end:

<code><pre>
deb http://www.nomis52.net/data/debian ./
</pre></code>

Install the packages:

<code><pre>
sudo apt-get update
sudo apt-get install liblla0 llad llad-console lla-examples
</pre></code>

====Centos/Fedora====
There are packages available for CentOS 4 and 5 and Fedora 5,6,7 & 8 at the time of writing. You need to add the netmindz.net repo to yum

<code><pre>
yum install http://rpms.netmindz.net/all/noarch/RPMS.netmindz/netmindz-repo-1.1.3-1.noarch.rpm
</pre></code>

This will create a new file in /etc/yum.repos.d/netmindz.repo and register the GPG key used to sign netmindz.net packages

Install the packages:

<code><pre>
yum install lla llad-console lla-examples
</pre></code>

===Test the installation===
With your dongle connected as in section 3, you're now ready to test. Connect a DMX device up to your dongle, make sure you know the channel number it's on, make sure it's working correctly, make sure you got the polarity in your DMX lead right, etc. etc. Being sure that the dongle/hardware/software combination is the only weak link will save a lot of hair-pulling...

Fix the permissions on /dev/dmx:

chmod a+rw /dev/dmx

First, start the daemon with debug mode on:

llad -d 3 -f -s

Next, in another terminal find out what number the OpenDMX device is:

<code><pre>
lla_dev_info
</pre></code>

you should get something like:

<pre>
Device 2: Open DMX USB Device
</pre>

If you can't see 'Open DMX USB Device' in there somewhere, then you haven't got the kernel driver installed properly. Go straight to jail, do not pass go.

Assuming everything is OK, you need to patch this device so we can use it:

<code><pre>
lla_patch -d2 -p0 -u0
</pre></code>

(replace -d2 with whichever device number is your Open DMX USB)

now do:

<code><pre>
lla_dev_info
</pre></code>

and it should say

<code><pre>
Device 2: Open DMX USB Device
port 0, cap OUT, universe 1
</pre></code>

Finally:

<code><pre>
lla_dmxconsole
</pre></code>

and play with the console!

Don't forget to remove your test patch afterwards:

<code><pre>
lla_patch -r -d2 -p0 -u0
</pre></code>

==Download and install the latest build of QLC==
====Ubuntu====
Finally! There are Ubuntu/Debian packages, but at the time of writing they're not the most up-to-date and don't include the LLA plugin. You could compile from source, but the most recent RPM packages work fine and save time and hassle.

<code><pre>
cd ~/dmx-software
wget http://rpms.netmindz.net/FC6/i386/RPMS.netmindz/qlc-2.6.1-2.fc6.i386.rpm
</pre></code>

'''Update:''' the above source is currently not working. You will need to find a version of QLC with the LLA patches, try http://www.lpcollier.net/QLC_OpenDMX.html or contacting the QLC development mailing list https://lists.sourceforge.net/lists/listinfo/qlc-devel

'''Update update:''' the source above is back online, so if you prefer to download the rpm and use alien you can, or else download the deb file from Lee Collier's site http://www.lpcollier.net/QLC_OpenDMX.html and skip the next step.

<code><pre>
sudo alien qlc-2.6.1-2.fc6.i386.rpm
</pre></code>

wait a long time... (don't worry about the warnings)... then:

<code><pre>
sudo dpkg -i qlc-2.6.1-2.fc6.i386.deb
sudo apt-get install libqt3-mt
</pre></code>

====Centos/Fedora====

<code><pre>
yum install qlc
</pre></code>

Now try it:

<code><pre>
sudo qlc &
</pre></code>

QLC should run OK. Don't get too excited yet, there's one more step...

==Put it all together==
We now need a script that will start the lla daemon, patch the adaptor to the DMX universe (QLC uses 1 by default, LLA uses 0) and start QLC. This should do it:

<code><pre>
#!/bin/bash
gksudo killall llad
sleep 2s
sudo llad
sleep 5s
sudo lla_patch -d2 -p0 -u1
sleep 2s
sudo qlc &
</pre></code>

save it as something memorable (I use qlc-start) and make sure it's executable:

<code><pre>
chmod u+x qlc-start
</pre></code>

and you're away!

Talk:Velleman K8062

2010-01-03T17:59:35Z

Beier: Discussion is now needed

The two edits of December 22. 2009 seems unclear.

The text that mentions the Linux driver/daemon/(library) has been strike-through deleted, without reason and argument.
The new text suggests that previous timing measurements (which were very bad), can be better. This is of course nice to know about.

What does it mean to "insert timing information"? Is it referring to a way to measure how long it takes to transfer data?

Which information is it exactly that is believed to be false? Only the slow update time of nonzero DMX data?

The lack of references, arguments or proofs makes it hard to guess what to expect of the interface, or what the potential speed can be given optimized software.

My opinion is that visual changes that must seem step-less needs at least 16 Hz update rate of [[DMX]] packets, which means shorter update interval than about 60 ms, or less than 40 DMX values (relative to 512 data values in 0.8 seconds). So, even with the numbers written here 2009/12/22, which are twice a fast as the values found in the Velleman discussion forum, 800 ms are still very slow.

An article with a conflicting text, where it is hard to see who wrote what, just brings confusion. So don't write article text as a personal argument when a discussion can take place at this discussion page.
--[[User:Beier|Beier]] 17:59, 3 January 2010 (UTC)

DMX512-A

2010-01-03T17:16:05Z

Beier: /* Timings */ : added parenthesis

The last version of the standard is called [http://usitt.org/ USITT] DMX512-A and it is maintained by [http://esta.org ESTA] since 1998. In 2004 it was made an ANSI standard too, named "E1.11, USITT DMX512-A" or "ANSI E1.11-2004". In 2008 it was revised [http://www.esta.org/tsp/news/newsdetails.php?newsID=291] .

IF you are looking for info about connecting DMX equipment and setting addresses, look at this [http://www.youtube.com/view_play_list?p=F66259177229499F&search_query=martin+training+dvd+dmx video tutorial from Martin].
So far, the rest of this article is about technicalities.

DMX is characterized by its '''simplicity''' in how data are transferred from a controller to receiving equipment.

== Electrical ==
DMX is based on the balanced serial connection standard [http://en.wikipedia.org/wiki/EIA-485 EIA-485-A] (a.k.a RS485).
Only 5-pin [http://en.wikipedia.org/wiki/XLR_connector XLR] meets the standard (and products may meet the requirement by supplying adapters).
Since the revision in 1998 the cables itself are not specified in DMX512-A (so it can be specified in separate standards?)
In general the cable must fulfill the [http://en.wikipedia.org/wiki/EIA-485 EIA-485] requirements of 120 Ohms (around 250 kHz) shielded twisted pair. One transmitter must be connected to maximum 32 receivers.
* Termination resistor tolerance is 120 Ohm +5 % / -10 % (108 – 126 Ohm).
* Each receiver must not load the differential line with more than 125 pF.

=== Use of category 5 UTP or STP ===
Other cable types have been examined to determine how well they are for DMX usage (as loose cables or in fixed building installations). The last report more or less concludes that for fixed installations, unshielded twisted pair in [http://en.wikipedia.org/wiki/Category_5_cable CAT 5] is good enough, even when it is mixed with 120 Ohm cable meant for EIA-485. The pulses from reflections and general degradation is not significant and harmless. See the three parts at http://www.esta.org/tsp/working_groups/CP/DMXoverCat5.htm .

See also this point in USITT's DMX faq:
http://www.usitt.org/DMX512FAQ.aspx#a9
(old link is [http://www.usitt.org/standards/DMX512_FAQ.html#FAQ_08]).

The cabling for DMX512-A should be described in the document called "BSR E1.27-1 -- Portable Control Cables for Use with USITT DMX512/1990 and E1.11 [DMX512-A]"

The [http://en.wikipedia.org/wiki/8P8C 8-position modular connector] is allowed in the DMX512-A as an alternate connector if there is not space enough for XLR5 or for fixed installations in "controlled access areas".
Pin-out:
{|border=1
||Pin || Function
|-
|1 || data 1+
|-
|2 || data 1-
|-
|3 || data 2+
|-
|6 || data 2-
|-
|4 || Not assigned
|-
|5 || Not assigned
|-
|7 || Data link common for data 1
|-
|8 || Data link common for data 1
|}

Both common wires are mandatory, and must have same potential in equipment sockets.

=== Voltages and power dissipation===

The power dissipation in the 120 Ohm terminating resistors depends on the differential voltage between the two data wires.
If the transmitter only makes a 5 V differential voltage (which is common), the power dissipation is P= U*U/R= 5*5/120 = 208 mW.

According to [http://focus.ti.com/lit/an/slla070c/slla070c.pdf] and the DMX512-A standard, the maximum absolute differential voltage allowed by the EIA485 standard is 6 V.
This gives the maximum power dissipation is P= U*U/R= 6*6/120 = 300 mW. So it is best to use 1/2 W resistors, to keep them cool enough not to damage itself or weakening the solderings.

Transceiver chips made for 5 V (they seem to be widely used):
Linear Technology LTC485: [http://www.linear.com/pc/productDetail.jsp?navId=H0,C1,C1007,C1017,P2064]
National semiconductor LMS485: [http://www.national.com/mpf/LM/LMS485.html]
National semiconductor DS75176B (used in Martin PAL 1200, Lite-Puter DX-625 and a cheap Eurolite DMX console) [http://www.national.com/mpf/DS/DS75176B.html]

=== Transmitter/receiver topologies ===
To avoid ground loops between equipment and improve reception performance, the transmitters and receivers for the DMX line must use a good combination of transmitter/receiver topologies. Some are not allowed, some are accepted with warning labels and some are preferred. See http://www.usitt.org/standards/DMX512_FAQ.html#FAQ_15 .

Transmitters should use "earth ground" as a reference for the positive/negative voltages that is put on the two data lines.
Receivers should be "isolated".

==The protocol==
'''A Universe''' contains 512 addresses and a single DMX line (cable) can only transmit one universe. I.e. a controller with two universes need two DMX lines (daisy chains including splitters). A universe is normally thought of as an address space (in the controller), the cables that transmits it and the equipment that receives it.

* The DMX signal is made up of a sequence - called a ''packet'' - which is sent over and over again (to increase robustness).
* It is up to the controller/transmitter to decide how many of the 512 values is sent. A shorter packet means faster cycles.
* A receiver must be set or programmed to an address it listens to. If a receiver listens to multiple addresses, the set one is the first. (It depends on implementation.)
* Multiple receiver can listen to the same address - the DMX system does not care.

'''A packet''' has the following sequence:
* Break
* Mark After Break (MAB)
* The ''"start code"'' frame (Sometimes called address 0) [http://www.esta.org/tsp/working_groups/CP/DMXAlternateCodes.php Alternate start codes]
* 1-512 ''slots/frames'' with the values of the channels. The first value is for address "1", the next for address 2 etc.
(Note: A packet must have a minimum length in time)

* A slot/frame contains the value for one address, has one start bit and two stop bits.
* The address number is not sent over the lines, so the receiver must count the received slots from the start of the sequence to find the wanted value.
* The ''start code'' is used to alter the meaning of the data bytes in the rest of the packet. The default is 0, and the remaining 255 values is rarely used (by definition 0 means dimmers, but is used for intelligent light as well).

''Note that some people and texts use the words frame and packet in the opposite sense than stated here.''

== Timings ==
The clock rate is 250 kHz so each symbol bit on the wire is 4 microseconds long (period time).

Symbol length is 4 +/- 0.08us for 245 - 255 k baud/s, with non-return-zero between symbol bits. To transmit 8 data bits it take 11 symbols because the use of one start bit and two stop bits around each data byte. Slot/address number is known by counting slots from the long packet break in the beginning of each packet.

The maximum packet rate is 44 updates/s if all 513 slots are transmitted (start code + 512 values), but can be higher if fewer slots are transmitted. If only packets only consists of a start code + 24 values, up to 830 updates/s can be made.

{|border=1
||'''Name''' || '''Tx requirement''' || '''Typical/suggested Tx''' || '''Rx requirement'''
|-
||Break (a space) (the packet start) || >= 92 us || 100-120 us (Ujjal) 176 us (DMX512-A-2004)|| >= 88 us
|-
||Mark after break (in packet start) || >= 8 us || 12 us (Ujjal) || 4 us – < 1 s backward compatible 8 us – < 1 s DMX512-A-2004
|-
||Slot/frame width || 44 us || 44 us || 44 us
|-
||Inter-slot/frame time Mark time between slots|| < 1 s || minimal || < 1 s
|-
||Mark before break (Idle time after packet)|| < 1 s || minimal || < 1 s
|-
||Break to Break time (DMX2512 packet length) || 1204 us – 1 s|| minimal|| 1196 us – 1.25 s
|}
The Rx req. column shows what a receiver must be able to handle of valid timings.

Note that the minimum length of "Mark after break" was doubled from 4 to 8 us in 1990, and receivers can be backward compatible by accepting the shortest time.

The slot time must be precise, or else the receiver should discard the whole packet, e.g. if the second stop bit is missing.

There must be at least one packet with start code=0 per second, and a receiving product must specify what happens when this time is exceeded.

Here is a nice overview of the different parts of a DMX packet with timings etc.: http://www.erwinrol.com/index.php?stagecraft/dmx.php.
These timing values matches the ones in the DMX standard from 2004.

Idle must be high level (mark level, "Mark before break").

As a receiver must handle varying "mark time between slots", it needs to synchronize to each start bit in each slot.

==Sources and additional reading==

[http://en.wikipedia.org/wiki/DMX_(lighting) Wikipedia article]

[http://www.rocketsciencecanada.com/rocketsciencecanada/Lighting/ControlProtocols.asp#dmx512 Thorough DMX description and a long list of good references to other sites and projects]. Much better than a Google search!

[http://www.epanorama.net/links/lights.html#dmx512 ePanorama] (thorough descriptions of most details, lots of links) 

[http://www.usitt.org/standards/DMX512.html USITT ] 
[http://www.dmx512-online.com/packt.html Ujjal's DMX512 Pages] (down-to-earth walk-through, also a good historical overview from before DMX ) 
[http://www.euro-pa.be/dmx.html The anatomy of DMX512] (a nice, short overview)

[http://www.erwinrol.com/index.php?stagecraft/dmx.php DMX timings by Erwin Rol] 
[http://www.theater-technisch-lab.nl/infrdmxe.htm An other DMX signal/cable description]

[http://www.alia.com.au/features/dmx.pdf History from mechanical dimming over analog lines, multiplexing, DMX and to ACN] in three pages.

See also:

* [[E1.31 | E1.31 - DMX over ACN]]
* [[RDM | RDM - Remote Device Management]]

[[Category:Definitions]]

ESTA

2010-01-03T16:41:49Z

Beier: added wiki link

[[Image:Esta.gif|right]]

ESTA or The Entertainment Services & Technology Association, is a non-profit North American association which represents professionals in the Entertainment technology industry. ESTA runs various technical standards programs which have resulted in standards such as [[E1.31]].

In October 2009 ESTA and [[PLASA]] announced a merger which should occur sometime in 2010.

More Information: http://www.esta.org/

[[Category:Definitions]]

Talk:Q Light Controller (QLC)

2009-10-12T08:29:45Z

Beier: More ideas

The page could mention interesting features.

Or how to operate QLC and its features.

E.g how to modify (move or squeeze) a pattern of pan/tilt, adjust intensity or colors with a offset to intensity or CMY/RGB values.

== Additional ideas for written info ==

The [[DMX]] start code is fixed to 0, I think (stated on the mailing list?).

No support for [[RDM]], but it is possible to code that functionality?

Can QLC be remote controlled from hand-held devices, i.e. to turn lamps on/off while being on stage, a ladder, out of reach of the computer running QLC?

How well does it work with a touch screen?

Can keyboard buttons and shortcuts be assigned to functions?

Can steps/scenes be changed, like proceed to next step by MIDI commands?

How can chase speed be controlled? Is there a tap sync for global speed and/or selected chases?

Can colour/intensity/iris function values be assigned to sine/cosine/triangle/sawtooth time functions?

Is it possible to offset DMX values just before the output, or to offset colour/position/etc. values?

If I make many scenes/steps that uses certain positions over and over again, is it possible to store e.g. x/y positions as a pre-set (or variable) instead of a hard-coded value in each step, in a way that the pre-set is a position (set of values), that can be changed and affect all steps that use that pre-set?

Perhaps the answers to these questions should go in a different page than the page with the QLC overview, perhaps name "QLC Usage details".

Q Light Controller (QLC)

2009-10-12T08:19:16Z

Beier: links to trac and mailing list

Link: https://sourceforge.net/projects/qlc/ (for download) 
Link: http://sourceforge.net/apps/trac/qlc/ (for documentation, bugs) 
{{Features|linux=yes|osx=yes|win=yes|tx=yes|free=yes}}
[[Image:Qlc-2.4.png|right]]

QLC is a lighting controller for Linux. Started as a university project by Heikki Junnila, it has now evolved with an active development community.
In 2009 it was released for Mac Os and Windows also.

'''Features:'''
* Fixture-oriented interface.
* Four DMX universes, 512 channels each
* Fast changing and smoothly fading scenes and chasers
* Easy creation of complex patterns for moving lights with EFX
* Conjure/design your favourite lighting desk layout with the virtual console™
* Support for external fader devices such as the [http://www.behringer.com/EN/Products/BCF2000.aspx Behringer BCF-2000]

'''DMX output''' is provided using:
* the driver system [[OLA]] (via a plugin to QLC), allowing DMX ouput using various DMX over IP protocols and [[Enttec]] [[DMX USB Pro]]. (for Linux, Mac OS and Windows, not all drivers work on all platforms)
* the Peperoni [[Rodin1]] (well tested) interface, plugin named peperoni-output (Linux (requires kernel driver) and Windows)
* the Enttec [[DMX USB Pro]] and [[Open DMX USB]] (Windows and Linux, Mac OS, tested rather well)
* [[Anyma uDMX]] (Windows, Linux and probably Mac OS but not well tested)

At the moment there are most drivers for Linux and fewest for Windows. In v. 3.0 the plugin for [[OLA]] (formerly LLA) is not included/enabled per default.

'''Inputs'''

QLC can be controlled by [[MIDI]] eg. from [http://www.behringer.com/EN/Products/BCF2000.aspx Behringer BCF-2000] and support for a [[Enttec]] wing may be added.
Sound synchronization is not supported [http://sourceforge.net/mailarchive/message.php?msg_name=5d3d60e90904131158r29d01e65i9e7a7ea7f61db8d%40mail.gmail.com]

'''Fixtures'''

Fixture definitions are used to map generic functions of a fixture like intensity, pan, tilt etc. to the specific DMX channels and values.
You can create your own fixture definitions to suit your needs, but there are a number of ready-made definitions [http://qlc.svn.sourceforge.net/viewvc/qlc/trunk/fixtures/ listed here]! QLC has a graphical "fixture creator" program.

'''Bugs'''

If you find a bug, you can report it [https://sourceforge.net/apps/trac/qlc/report here], or alternatively send an email to the [https://sourceforge.net/mailarchive/forum.php?forum_name=qlc-devel qlc-devel mailing list].

Related Tutorials:
* [[LLA and Q Light Controller Ubuntu Tutorial]]

Related Products:
* Peperoni [[Rodin1]] and [[USBDMX21]]
* [[Enttec]] [[DMX USB Pro]], [[Open DMX USB]]
* [[Anyma uDMX]]
* [[OLA]]
* [[DMX 4 Linux]]

[[Category:Controllers]]

Talk:Q Light Controller (QLC)

2009-10-11T23:21:38Z

Beier: /* Additional info */ new section

The page could mention interesting features.

Or how to operate QLC and its features.

E.g how to modify (move or squeeze) a pattern of pan/tilt, adjust intensity or colors with a offset to intensity or CMY/RGB values.

== Additional info ==

The [[DMX]] start code is fixed to 0, I think (stated on the mailing list?).

No support for [[RDM]], but it is possible to code that functionality?

Can QLC be remote controlled from hand-held devices, i.e. to turn lamps on/off while being on stage, a ladder, out of reach of the computer running QLC?

How well does it work with a touch screen?

Can keyboard buttons and shortcuts be assigned to functions?

How can chase speed be controlled? Is there a tap sync for global speed and/or selected chases?

It is not mentioned if there are an intuitive way to create fixture definition, like a graphical fixture creator application.

Is it possible to offset DMX values just before the output, or to offset colour/position/etc. values?

If I make many scenes/steps that uses certain positions over and over again, is it possible to store e.g. x/y positions as a pre-set (or variable) instead of a hard-coded value in each step, in a way that the pre-set is a position (set of values), that can be changed and affect all steps that use that pre-set?

Perhaps the answers to these questions should go in a different page than the page with the QLC overview, perhaps name "QLC Usage details".

User:Beier

2009-10-06T08:04:53Z

Beier: updated, corrected translation from Danish to English

My name is Nikolai Beier, I'm from Aalborg, Denmark.

I am educated "electronics technician" with an apprenticeship at Bang & Olufsen.
Now I study engineering in electronics at Aalborg university (9. semester starts September 2009, meaning that I am a bachelor of science in electronic engineering, taking a master/candidate in Radio Frequency electronics)
Here at the uni, I got involved in the Student Society where I take care of the sound and light gear.

My interest in DMX started when "we" needed at better DMX controller to ease the use of our four moving heads.

My main interest is Linux software (controller and drivers) and USB->DMX interfaces with buffered outputs and galvanic isolation.

Open Lighting Architecture

2009-09-24T08:54:18Z

Beier: Windows update

Link: http://code.google.com/p/linux-lighting/ 
{{Features|free=yes|tx=yes|rx=yes|linux=yes|osx=yes|http=yes}}
[[Image:Llad_home.png|right]]

OLA (Open Lighting Architecture) is a framework that allows applications to send and receive DMX, using various hardware devices and 'DMX over IP' protocols. It can make [[:Category:Controllers | software controllers]] talk to DMX hardware. It was formerly known as LLA.

OLA allows DMX sent using various DMX over IP protocols to be converted from one format to another. This enables devices from different manufacturers to talk to each another (for example a [[Strand_Lighting|Strand]] Console can send DMX to an [[Enttec]] [[DmxEtherGate MKII|EtherGate]]).

[[OLA Live]] is a stand-alone bootable CD containing software from the Open Lighting Architecture project.

When combined with a physical DMX interface such as the [[DMX USB Pro]], OLA Live can send and receive data from traditional wired DMX networks.

OLA can run on '''Linux''' with all its plugins, and on '''Mac OS X''' (but at the moment not all the plugins have been ported). A port to '''Windows''' is partly done, but more help/work is needed, if someone wants to add the necessary code for plug-ins and a installer.

Bugs: Check the bug tracker at http://code.google.com/p/linux-lighting/issues/list

Questions: See the news group at http://groups.google.com/group/open-lighting

Supported Devices/Protocols:

{| border=1
! '''Driver'''!! Linux !! '''Mac OS X'''
|-
|| [[:Category:ArtNet|ArtNet]] || Yes || Yes
|-
|| [[:Category:ShowNet|ShowNet]] || Yes || Yes
|-
|| [[:Category:ESP Net|ESP Net]] || Yes || Yes
|-
|| [[:Category:Sandnet|Sandnet]] || Yes || ??
|-
|| [[E1.31]] / [[ACN]] || underway || ??
|-
|| [[DMX USB Pro]] || Yes || Yes
|-
|| [[Open DMX USB]] || Yes || ??
|-
|| [[StageProfi]] || Yes || ??
|-
|| [[:Category:Pathport|Pathport]] || in testing || ??
|-
|| [[DMX 4 Linux]] || Yes || -
|}

Getting Started

Start here if you've never used OLA before and read these in order.
* [[Download OLA]]
* [[OLA 0.3]] - The latest release
* [[OLA on OS X]] or [[OLA on Linux]] - How to get it compiled.
* [[Using OLA]] - A basic introduction
* [[OLA Command Line Tools]] - Documentation for the tools in ola-examples
* [[OLA Device Specific Configuration]]
* [[OLA Tips & Tricks]]

Developer Documentation:
* [[OLA developer info]] - about the source code and structure
* [[OLA Client API]] - the C++ API
* [[OLA Python API]] - easy DMX programming

Tutorials, these refer to the previous release but parts of them are still relevant.
* [[LLA Sandnet Tutorial]] - Setup Horizon using Sandnet and LLA
* [[LLA and Q Light Controller Ubuntu Tutorial]] - Setup LLA on Ubuntu/Debian-type distro with QLC
* [[LLA and Q Light Controller OSX Tutorial]] - Setup LLA on Mac OS X with QLC

OLA can also run on a wireless access point. [http://nomis52.net/?section=projects&sect2=artnet&page=node]

There is a project underway to build packages for OpenWrt. See http://lists.culturebase.org/cgi-bin/mailman/listinfo/lla-openwrt for more details.

[[Category:ArtNet]]
[[Category:ESP Net]]
[[Category:Sandnet]]
[[Category:ShowNet]]
[[Category:Utilities]]

OLA on OS X

2009-09-24T08:26:39Z

Beier: add link for binary distribution

This page describes how to get OLA 0.3 working on OS X, by downloading and compiling the source code.

There is also a "Installer" (.dmg file) to install a pre-compiled version [http://code.google.com/p/linux-lighting/ available here].

== Basic setup ==

* Install xcode [[http://developer.apple.com/technology/xcode.html]]
* install git [[http://code.google.com/p/git-osx-installer/]]
* install mac ports [[http://www.macports.org/]]

== Use Mac Ports to install stuff==

$ port install pkgconfig cppunit unittest-cpp protobuf-cpp

== Set some env vars==

set $PATH to point to something sane (you should also make sure you point it at your ctemplate and libmicrohttpd)

export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/usr/local/lib/pkgconfig
export CPPFLAGS="-I/opt/local/include/"
export LDFLAGS="-L/opt/local/lib/"

== Optionally install microhttpd and ctemplate==

If you want the http interface you need these

* http://www.gnu.org/software/libmicrohttpd/ [>= 0.4] (Currently you need to install libgcrypt too for this library to work)
sudo port install libgcrypt
or you can disable https support (which works with OLA) by using the configure line "./configure --enable-https=no"
* http://code.google.com/p/google-ctemplate/

* Make sure both of these are made AND installed before running "./configure" on OLA otherwise it will not detect the libraries and ignore all the HTTP server code

== Checkout OLA or Download the tarball ==

git clone http://www.nomis52.net/git/lla
cd lla

or

wget $ola_url
tar -zxf $ola_file
cd lla

== Run autoreconf==

If this is the first time run with -i to install the missing files

autoreconf -i

== Do the usual steps==

./configure
make
make check
sudo make install

If you get an error like the following:

/bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I/opt/local/var/macports/software/protobuf-cpp/2.0.3_0/opt/local/include/ -g -O2 -c -o ltdl.lo ltdl.c
./libtool: line 464: CDPATH: command not found
/Users/simonn/lighting/lla/libltdl/libtool: line 464: CDPATH: command not found
/Users/simonn/lighting/lla/libltdl/libtool: line 1142: func_opt_split: command not found
libtool: Version mismatch error. This is libtool 2.2.6, but the
libtool: definition of this LT_INIT comes from an older release.
libtool: You should recreate aclocal.m4 with macros from libtool 2.2.6
libtool: and run autoconf again.

Your system uses a different version of libtool. Run:

glibtoolize --ltdl -c -f

and then start from the autoreconf step again.

Q Light Controller (QLC)

2009-09-11T08:01:38Z

Beier: LLA->OLA name change

Link: https://sourceforge.net/projects/qlc/ 
{{Features|linux=yes|osx=yes|win=yes|tx=yes|free=yes}}
[[Image:Qlc-2.4.png|right]]

QLC is a lighting controller for Linux. Started as a university project by Heikki Junnila, it has now evolved with an active development community.
In 2009 it was released for Mac Os and Windows also.

'''Features:'''
* Fixture-oriented interface.
* Four DMX universes, 512 channels each
* Fast changing and smoothly fading scenes and chasers
* Easy creation of complex patterns for moving lights with EFX
* Conjure your favourite lighting desk layout with the virtual console™
* Support for external fader devices such as the [http://www.behringer.com/EN/Products/BCF2000.aspx Behringer BCF-2000]

'''DMX output''' is provided using:
* the driver system [[OLA]] (via a plugin to QLC), allowing DMX ouput using various DMX over IP protocols and [[Enttec]] [[DMX USB Pro]]. (for Linux, Mac OS and Windows, not all drivers work on all platforms)
* the Peperoni [[USBDMX21]] (not tested) and [[Rodin1]] (well tested) interface, plugin named usbdmx (Linux (requires kernel driver) and Windows)
* the Enttec [[Open DMX USB]] (or other hardware with just a FTDI chip), plugin name is FTDI DMX (Mac OS, Windows and Linux, perhaps not widely tested by June 2009)
* [[Anyma uDMX]] (Windows and probably Linux and Mac OS but not well tested)
* the DMX 4 Linux library (Linux Only, stopped working from QLC 3.0?)

At the moment there are most drivers for Linux and fewest for Windows. In v. 3.0 the plugin for [[OLA]] (formerly LLA) is not included/enabled per default.

'''Inputs'''

QLC can be controlled by [[MIDI]] eg. from [http://www.behringer.com/EN/Products/BCF2000.aspx Behringer BCF-2000] and support for a [[Enttec]] wing may be added.
Sound synchronization is not supported [http://sourceforge.net/mailarchive/message.php?msg_name=5d3d60e90904131158r29d01e65i9e7a7ea7f61db8d%40mail.gmail.com]

'''Fixtures'''

Fixture definitions are used to map generic functions of a fixture like intensity, pan, tilt etc. to the specific DMX channels and values.
You can create your own fixture definitions to suit your needs, but there are a number of ready-made definitions [http://qlc.svn.sourceforge.net/viewvc/qlc/trunk/fixtures/ listed here]!

Related Tutorials:
* [[LLA and Q Light Controller Ubuntu Tutorial]]

Related Products:
* Peperoni [[Rodin1]] and [[USBDMX21]]
* [[Enttec]] [[Open DMX USB]]
* [[Anyma uDMX]]
* [[OLA]]
* [[DMX 4 Linux]]

[[Category:Controllers]]

Other web sites

2009-07-09T23:26:04Z

Beier: If it is a useful ressource, related to lighting tech, put it here!

= Forums or other information resources on the net =

http://www.blue-room.org.uk/wiki/Main_Page

http://thedmxwiki.com/ Has started, misc. terms explained, like CMY and RGB color mixing.

http://stagecraft.theprices.net/ The stagecraft mailing list, thousands of email threads per year! All technical stuff is discussed, from safety to cabling.

''If you know a useful ressource, related to lighting tech, put it here!''

[[Category:Articles]]

Other web sites

2009-07-09T23:23:45Z

Beier: New page: = Forums or other information resources on the net = http://www.blue-room.org.uk/wiki/Main_Page http://thedmxwiki.com/ Has started, misc. terms explained, like CMY and RGB color mixing....

Talk:OpenDMX.net

2009-07-09T23:05:53Z

Beier: /* Introduce the site! */ new section

== Introduce the site! ==

Instead of just news on the front page, there could be a few paragraphs about what this wiki is best at informing the viewer about (what kind of info are the main assets?).

If you are looking for light show design, color mixing and the difference between foggers and hazers and their fluids, go to http://thedmxwiki.com/ .

But if you are looking for lists of hardware interfaces ( e.g. adapters between USB and DMX), epsecially the cheap ones or those with a free design, og controller software, then look here!

At the moment, the main documentation for LLA and QLC also resides here.

OLA on Linux

2009-07-07T18:32:43Z

Beier: added ldconfig after LLA install

=Installing LLA on Linux From GIT/Archive=

This describes how to get LLA working on a Linux system.

==Checkout or Download an Archive==

git clone http://www.nomis52.net/git/lla

If you don't have it yet, install '''git''' using your distro's package manager.

==Install libraries==

You need a couple of libraries installed for everything to work correctly. Some of these are available as packages in most distros but others need to be downloaded.

First up we'll need '''microhttpd''' for the embedded web server (Note: you'll need version >= 0.4.0):

-> [ftp://ftp.gnu.org/gnu/libmicrohttpd/ ftp://ftp.gnu.org/gnu/libmicrohttpd/]

Then you will need '''libcppunit-dev''' and '''libcppunit'''.

Debian users can install them with apt:

apt-get install libcppunit-dev libcppunit-1.12-1

Next, you need the '''Protocol Buffers''' from Google (BSD license). Most likely, you will need to download and build them yourself:

-> [http://code.google.com/p/protobuf/ http://code.google.com/p/protobuf/]

Debian users will can use the following packets (not yet in stable):
libprotobuf2, libprotobuf-dev, protobuf-compiler

Then, build '''CTemplate''' (another Google goodie):

-> [http://code.google.com/p/google-ctemplate/ http://code.google.com/p/google-ctemplate/]

Finally run ldconfig as root to pick up the new libraries

ldconfig

==Configure==

If you checked out the sources from git, you'll need to run

autoreconf -i

After that run

./configure

==Building & Testing==

Build
make

If you get an error like the following:

/bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I/opt/local/var/macports/software/protobuf-cpp/2.0.3_0/opt/local/include/ -g -O2 -c -o ltdl.lo ltdl.c
./libtool: line 464: CDPATH: command not found
/Users/simonn/lighting/lla/libltdl/libtool: line 464: CDPATH: command not found
/Users/simonn/lighting/lla/libltdl/libtool: line 1142: func_opt_split: command not found
libtool: Version mismatch error. This is libtool 2.2.6, but the
libtool: definition of this LT_INIT comes from an older release.
libtool: You should recreate aclocal.m4 with macros from libtool 2.2.6
libtool: and run autoconf again.

Your system uses a different version of libtool. Run:

libtoolize --ltdl -c -f

and then start from the autoreconf step again.

Run the tests
make check

And install LLA
sudo make install
sudo ldconfig

Drivers and software

2009-06-30T09:24:22Z

Beier: corrected links

==Drivers and software==
''This is some old general notes, that was kind of hidden in the wiki''

'''Advice:''' If your are looking for a interface to buy, then start with finding your favorite [[:Category:Controllers |controller app]], and find out which drivers and thereby which hardware is supported.

There is a number of ways to get a controller application to send [[DMX]] data to a hardware interface (that can send the data out on your [[DMX]] wire).

Sometime the driver is split up into:
* Hardware driver for sending raw data to and from the hardware.
* Protocol driver for translating data/instructions between the controller app and the hardware (which uses some kind of protocol).

Most USB interfaces works as a "virtual com port", which means that there is a real com port in the hardware, and a driver makes a com interface available i the operating system. Most USB com ports are supported 'out of the box' on both Windows and Linux (nice!), so most USB-to-DMX interfaces just need a protocol driver (easy to make and use)

On Windows it seems that (almost) all controller apps have their own drivers. Probably because no good framework existed.

On Linux there exists a system for hardware drivers, which is a kernel module with a common interface to the controller software that is independent of which hardware you choose to use. This is called [[DMX 4 Linux]].
Many drivers don't need to be in the kernel, and for that, there is a driver framework called [[LLA]].

Remember that it is possible to send DMX data over a network to an other computer or an Ethernet-to-DMX hardware interface. [[LLA]] is particularly good at this and in routing the signals between different systems and hardware.

[[Category:Articles]]

Misc. projects

2009-06-13T11:51:06Z

Beier:

DMX512-A

2009-06-13T10:50:22Z

Beier: Yet an other link that I discovered

''This information is not complete.'' The purpose is to introduce the protocol and the details of a packet and maybe explain the required timing of the signal. --[[User:Beier|Beier]] 06:21, 28 January 2007 (PST)

The last version of the standard is called [http://usitt.org/ USITT] DMX512-A and it is maintained by [http://esta.org ESTA] since 1998. In 2004 it was made an ANSI standard too, named "E1.11, USITT DMX512-A" or "ANSI E1.11-2004". In 2008 it was revised [http://www.esta.org/tsp/news/newsdetails.php?newsID=291] .

DMX is characterized by its simplicity in how data are transferred from a controller to receiving equipment.

== Electrical ==
DMX is based on the balanced serial connection standard [http://en.wikipedia.org/wiki/EIA-485 EIA-485-A] (a.k.a RS485).
Only 5-pin XLR meets the standard (and products may meet the requirement by supplying adapters).
Since the revision in 1998 the cables itself are not specified in DMX512-A (so it can be specified in separate standards?), so in general the cable must fulfill the [http://en.wikipedia.org/wiki/EIA-485 EIA-485] requirements of 120 Ohms (around 250 kHz) shielded twisted pair. One transmitter must be connected to maximum 32 receivers.

Other cable types have been examined to determine how well they are for DMX usage (as loose cables or in fixed building installations). The last report more or less concludes that for fixed installations, unshielded twisted pair in [http://en.wikipedia.org/wiki/Category_5_cable CAT 5] is good enough, even when it is mixed with 120 Ohm cable meant for EIA-485. The pulses from reflections and general degradation is not significant and harmless. See the three parts at http://www.esta.org/tsp/working_groups/CP/DMXoverCat5.htm .

=== Transmitter/receiver topologies ===
To avoid ground loops between equipment and improve reception performance, the transmitters and receivers for the DMX line must use a good combination of transmitter/receiver topologies. Some are not allowed, some are accepted with warning labels and some are preferred. See http://www.usitt.org/standards/DMX512_FAQ.html#FAQ_15 .

Transmitters should use "earth ground" as a reference for the positive/negative voltages that is put on the two data lines.
Receivers should be "isolated".

==The protocol==
'''A Universe''' contains 512 addresses and a single DMX line (cable) can only transmit one universe. I.e. a controller with two universes need two DMX lines (daisy chains including splitters). A universe is normally thought of as an address space (in the controller), the cables that transmits it and the equipment that receives it.

* The DMX signal is made up of a sequence - called a ''packet'' - which is sent over and over again (to increase robustness).
* It is up to the controller/transmitter to decide how many of the 512 values is sent. A shorter packet means faster cycles.
* A receiver must be set or programmed to an address it listens to. If a receiver listens to multiple addresses, the set one is the first. (It depends on implementation.)
* Multiple receiver can listen to the same address - the DMX system does not care.

'''A packet''' has the following sequence:
* Break
* Mark After Break (MAB)
* The ''"start code"'' frame (Sometimes called address 0) [http://www.esta.org/tsp/working_groups/CP/DMXAlternateCodes.php Alternate start codes]
* 1-512 ''slots/frames'' with the values of the channels. The first value is for address "1", the next for address 2 etc.
(Note: A packet must have a minimum length in time)

* A slot/frame contains the value for one address, has one start bit and two stop bits.
* The address number is not sent over the lines, so the receiver must count the received slots from the start of the sequence to find the wanted value.
* The ''start code'' is used to alter the meaning of the data bytes in the rest of the packet. The default is 0, and the remaining 255 values is rarely used (by definition 0 means dimmers, but is used for intelligent light as well).

Note that some people and texts use the words frame and packet in the opposite sense than stated here.

 
'''Sources and additional reading:''' 

[http://en.wikipedia.org/wiki/DMX_(lighting) Wikipedia] 
[http://www.usitt.org/standards/DMX512.html USITT ] 
[http://www.dmx512-online.com/packt.html Ujjal's DMX512 Pages] (down-to-earth walk-through, also a good historical overview from before DMX ) 
[http://www.epanorama.net/links/lights.html#dmx512 ePanorama] (thorough descriptions of most details, lots of links) 
[http://www.euro-pa.be/dmx.html The anatomy of DMX512] (a nice, short overview) 
[http://www.erwinrol.com/index.php?stagecraft/dmx.php DMX timings by Erwin Rol]

[http://www.alia.com.au/features/dmx.pdf History from mechanical dimming over analog lines, multiplexing, DMX and to ACN] in three pages.

[http://www.theater-technisch-lab.nl/infrdmxe.htm An other DMX signal/cable description]

[http://www.rocketsciencecanada.com/rocketsciencecanada/Lighting/ControlProtocols.asp#dmx512 Thorough DMX description and a long list of good references to other sites and projects]. Much better than a google search!

See also [[E1.31 | E1.31 - DMX over ACN]] and [[RDM | RDM - Remote Device Management]]

[[Category:Articles]]

DMX512-A

2009-06-13T10:41:11Z

Beier: 2 links to interesting pages

''This information is not complete.'' The purpose is to introduce the protocol and the details of a packet and maybe explain the required timing of the signal. --[[User:Beier|Beier]] 06:21, 28 January 2007 (PST)

The last version of the standard is called [http://usitt.org/ USITT] DMX512-A and it is maintained by [http://esta.org ESTA] since 1998. In 2004 it was made an ANSI standard too, named "E1.11, USITT DMX512-A" or "ANSI E1.11-2004". In 2008 it was revised [http://www.esta.org/tsp/news/newsdetails.php?newsID=291] .

DMX is characterized by its simplicity in how data are transferred from a controller to receiving equipment.

== Electrical ==
DMX is based on the balanced serial connection standard [http://en.wikipedia.org/wiki/EIA-485 EIA-485-A] (a.k.a RS485).
Only 5-pin XLR meets the standard (and products may meet the requirement by supplying adapters).
Since the revision in 1998 the cables itself are not specified in DMX512-A (so it can be specified in separate standards?), so in general the cable must fulfill the [http://en.wikipedia.org/wiki/EIA-485 EIA-485] requirements of 120 Ohms (around 250 kHz) shielded twisted pair. One transmitter must be connected to maximum 32 receivers.

Other cable types have been examined to determine how well they are for DMX usage (as loose cables or in fixed building installations). The last report more or less concludes that for fixed installations, unshielded twisted pair in [http://en.wikipedia.org/wiki/Category_5_cable CAT 5] is good enough, even when it is mixed with 120 Ohm cable meant for EIA-485. The pulses from reflections and general degradation is not significant and harmless. See the three parts at http://www.esta.org/tsp/working_groups/CP/DMXoverCat5.htm .

=== Transmitter/receiver topologies ===
To avoid ground loops between equipment and improve reception performance, the transmitters and receivers for the DMX line must use a good combination of transmitter/receiver topologies. Some are not allowed, some are accepted with warning labels and some are preferred. See http://www.usitt.org/standards/DMX512_FAQ.html#FAQ_15 .

Transmitters should use "earth ground" as a reference for the positive/negative voltages that is put on the two data lines.
Receivers should be "isolated".

==The protocol==
'''A Universe''' contains 512 addresses and a single DMX line (cable) can only transmit one universe. I.e. a controller with two universes need two DMX lines (daisy chains including splitters). A universe is normally thought of as an address space (in the controller), the cables that transmits it and the equipment that receives it.

* The DMX signal is made up of a sequence - called a ''packet'' - which is sent over and over again (to increase robustness).
* It is up to the controller/transmitter to decide how many of the 512 values is sent. A shorter packet means faster cycles.
* A receiver must be set or programmed to an address it listens to. If a receiver listens to multiple addresses, the set one is the first. (It depends on implementation.)
* Multiple receiver can listen to the same address - the DMX system does not care.

'''A packet''' has the following sequence:
* Break
* Mark After Break (MAB)
* The ''"start code"'' frame (Sometimes called address 0) [http://www.esta.org/tsp/working_groups/CP/DMXAlternateCodes.php Alternate start codes]
* 1-512 ''slots/frames'' with the values of the channels. The first value is for address "1", the next for address 2 etc.
(Note: A packet must have a minimum length in time)

* A slot/frame contains the value for one address, has one start bit and two stop bits.
* The address number is not sent over the lines, so the receiver must count the received slots from the start of the sequence to find the wanted value.
* The ''start code'' is used to alter the meaning of the data bytes in the rest of the packet. The default is 0, and the remaining 255 values is rarely used (by definition 0 means dimmers, but is used for intelligent light as well).

Note that some people and texts use the words frame and packet in the opposite sense than stated here.

 
'''Sources and additional reading:''' 

[http://en.wikipedia.org/wiki/DMX_(lighting) Wikipedia] 
[http://www.usitt.org/standards/DMX512.html USITT ] 
[http://www.dmx512-online.com/packt.html Ujjal's DMX512 Pages] (down-to-earth walk-through, also a good historical overview from before DMX ) 
[http://www.epanorama.net/links/lights.html#dmx512 ePanorama] (thorough descriptions of most details, lots of links) 
[http://www.euro-pa.be/dmx.html The anatomy of DMX512] (a nice, short overview) 
[http://www.erwinrol.com/index.php?stagecraft/dmx.php DMX timings by Erwin Rol]

[http://www.alia.com.au/features/dmx.pdf History from mechanical dimming over analog lines, multiplexing, DMX and to ACN] in three pages.

[http://www.theater-technisch-lab.nl/infrdmxe.htm An other DMX signal/cable description]

See also [[E1.31 | E1.31 - DMX over ACN]] and [[RDM | RDM - Remote Device Management]]

[[Category:Articles]]

Misc. projects

2009-06-13T10:30:54Z

Beier:

ACN

2009-06-13T10:10:45Z

Beier:

[[Category:Articles]]
===ACN - Architecture for Control Networks===

Wikipedia article on ACN: http://en.wikipedia.org/wiki/Architecture_for_Control_Networks

ACN is a suite of documents that specifies an architecture, including protocols and language, which may be configured and combined with other standard protocols to form flexible, networked audio, lighting, or other control systems. It can be implemented on networks that support UDP, IP, and related protocols. It is not bound to Ethernet as a transport medium, but Ethernet is an obvious choice.

The ACN specification is being distributed via download as a 5MB archive of 17 PDF and two DDL files. The "hardcopy" is a CDROM; there is no paper version offered.

Article on ACN in PLSN magazine: http://www.plsn.com/index.php?option=com_content&task=view&id=1437&Itemid=101

The [http://www.openacn.org Open ACN Project] Wants to make an open source implementation.

This is their wiki:http://openacn.wiki.sourceforge.net/ .

The way to transfer [[DMX]] data over ACN is specified in the standard [[E1.31]] . An implementation has begun in [[LLA]] .

Misc. projects

2009-06-13T09:41:28Z

Beier: Where else should these small bits go?

DMX USB Pro

2009-06-11T15:47:10Z

Beier: link to blog about firmware

[[Category:USB]]

[[Image:Dmxusb_pro.jpg|right]]

Link: http://www.enttec.com/index.php?main_menu=Products&prod=70304&show=description&name=dmxusbpro 
Made by: [[Enttec]] 
{{Features|win=yes|osx=yes|linux=yes|tx=yes|rx=yes|rdm=yes}}

The pro widget unlike it's little brother (The Open DMX USB) contains a microprocessor (ATMEGA88) responsible for framing and transmission, or reception of dmx. Also it's USB interface is a FTDI FT245BM, so VCP (virtual com port) drivers make programming easy as opening a serial port and sending/receiving!

It has 1500v dmx line isolation, A green LED which indicates RX or TX activity, and gold plated Neutrik XLR's (1xmale, 1xfemale wired in parallel).
The timings of the transmitted DMX signal can be adjusted.
According the [[Enttec]] [http://enttec.com web site], it has limited [[RDM]] support, and only in some firmware versions, see [http://www.enttec.com/index.php?main_menu=Products&prod=70304&show=firmware] for details.

The firmware can be updated with Enttecs applications but also with [http://kev.coolcavemen.com/2009/05/enttec-dmx-usb-firmware-upgrade-with-qemu/ qemu on Linux].

Related Products:

* [[RDM USB Pro]]
* [[Open DMX USB]]
* [[Pro Toolkit]]
* [[StageConsole]]
* [[MiniStageConsole]]

Old News

2009-06-11T10:35:03Z

Beier: Undo revision 2297 by 202.70.201.34 (Talk) This was spam!

==== ACN Finally Approved ! ====

On the 19th of October, the ANSI Board of Standards approved E1.17-2006, Entertainment Technology - Multipurpose Network Control Protocol Suite or simply known as ACN. No major changes have been made since the last public review and the document should be available for purchase in the next few weeks.

More than 5 years after ACN was first proposed, this marks the final step before manufactures can start shipping true ACN Compatible devices.

----

==== Unofficial DMX 4 Linux 2.6 Release ====

Bastien Andres has made an unofficial release of [[DMX 4 Linux]] for the 2.6 series of kernels. A number of drivers have been modified to compile cleanly on 2.6 and the build system has also been cleaned.

Some drivers do not compile or are incomplete, see the STATUS_BA file in the archive for more details. Sources available [http://www.nomis52.net/data/sources/dmx4linux-2.9-ba-061001.tgz here]

----

=== Enttec Releases RDM Tools ===

[[Enttec]] have released two new programs for the [[DMX USB Pro]] that demonstrates the device's RDM capabilities. RDM Controller and RDM Responder allow the device to be used as a RDM control and response node respectively.

Both programs require that the device be upgraded to the latest firmware (v2). It seems however that support for RDM comes at a price, the send DMX on change feature no longer exists in the latest version. This appears to be due to memory restrictions within the device.

Both programs are currently in beta, and Enttec would appreciate feedback especially when used with other RDM enabled devices.

See http://www.enttec.com/rdm.php for more details.

----

=== Updated LLA Live Released ===

An updated version of the [[LLA]] Live CD was released today. Version 0.1.1 fixes issues encountered when using the Strand ShowNet protocol.

LLA Live enables any computer to function as a DMX to Ethernet gateway, converting between protocols such as ArtNet, ESPNet and Strand's ShowNet. When combined with a DMX interface such as the [[Enttec]] [[DMX USB Pro]], data can be sent to and from traditional DMX devices. By running entirely off a CD, no changes are required to the host machine removing the need for a hard drive.

LLA Live is available from [https://sourceforge.net/project/showfiles.php?group_id=126566&package_id=192352 Sourceforge]

----

=== DMX traverses the world! ===

Late last week an experiment was set up to send DMX data over the Internet. The result was the successful control of DMX fixtures over a distance of almost 15000 km.

Using a modified version of the [[:Category:ArtNet|ArtNet]] protocol integrated with the new Linux Lighting Architecture ([[LLA]]), the DMX data was generated on a laptop in San Francisco and used to control lights in Perth, Western Australia.

With the majority of DMX over IP protocols using broadcasting or multicasting, sending DMX over large networks such as the Internet normally requires the use of tunnels between endpoints. However this new solution requires no such configuration changes, and works with the majority of routers available on the market.

The delay experienced was approximately 140ms. While not fantastic, this is reasonable considering the DMX data was traveling half way around the world. By upgrading the Internet connections on each end this delay could be reduced further (the tests were conducted using standard ADSL and Cable connections).

While control of lighting equipment at a remote location is currently a solution in search of a problem, this experiment certainly demonstrates the potential for DMX over IP.

Large Setups, like OpenAir Concerts now can use Firewire via Optical Fibre instead of classic Multicore for DMX and Audio. 19" Multicannel-Audio<>Firewire has allready reached Homestudio Prices and DMX has reached IP, which can travel over Firewire.

----

=== RDM (Remote Device Management over DMX512 Networks) Standard Now Available ===

The RDM Task Group today proudly announced that the ANSI E1.20 RDM (Remote Device Management over DMX512 Networks) Standard is now published and available for purchase (US$40) from the ESTA Foundation Website at http://www.estafoundation.org
ANSI E1.20-2006, Entertainment Technology--Remote Device Management over USITT DMX512, describes a method of bi-directional communications over a USITT DMX512/1990 data link between an entertainment lighting controller and one or more remotely controlled lighting devices. The protocol also is intended to work with the ANSI E1.11-2004 control protocol. It allows discovery of devices on a DMX512/E1.11 network and the remote setting of DMX starting addresses, as well as status and fault reporting back to the control console.

The official START Code is published with this document, which now lets manufacturers build interoperable devices that can be discovered and provide bi-directional communication for remote configuration and monitoring across a DMX512 link. [Source: ESTA Control Protocols Working Group]

__NOTOC__

Anyma uDMX

2009-06-11T10:13:35Z

Beier: Added QLC/Mac/windows/linux info

Link: http://anyma.ch/research/udmx/ 
{{Features|tx=yes|win=yes|osx=yes|linux=yes}}
[[Image:udmx5pin.jpg|right]]

'''Anyma uDMX''' comes with a open firmware, which is rare. The USB communication is handled by the firmware instead of a separate chip. This must be very cheap to build!

Hardware:
* From USB to [[DMX]] (one way DMX)
* All the electronics is inside the XLR - two smd IC's: An AVR microcontroller and a RS485 driver
* The DMX data is buffered and the transmission is timed by the microcontroller
* USB powered
* No galvanic isolation
 
Software:
* Supported by [[QLC]] (on Windows and probably also Linux and Mac OS, but not well tested)
* An external object for [http://www.cycling74.com/ Max/MSP] (OSX)
* A console app for Linux/OSX
* MIDI control via a OSX app
* There's an example how to control the console app from php scripts (seems easy)
* Gratis firmware. The DMX part is GPL, the USB part from [http://www.obdev.at Objective Development] is "open" but all changes belongs to them.

[http://anyma.ch/research/udmx/ Anyma uDMX] 
[http://www.obdev.at/products/avrusb/index.html Objective Development's "AVR-USB]

[[Category:USB]]

Q Light Controller (QLC)

2009-06-11T10:03:30Z

Beier: link to list of pre-made fixture definitions

Link: https://sourceforge.net/projects/qlc/ 
{{Features|linux=yes|osx=yes|win=yes|tx=yes|free=yes}}
[[Image:Qlc-2.4.png|right]]

QLC is a lighting controller for Linux. Started as a university project by Heikki Junnila, it has now evolved with an active development community.
In 2009 it was released for Mac Os and Windows also.

'''Features:'''
* Fixture-oriented interface.
* Four DMX universes, 512 channels each
* Fast changing and smoothly fading scenes and chasers
* Easy creation of complex patterns for moving lights with EFX
* Conjure your favourite lighting desk layout with the virtual console™
* Support for external fader devices such as the [http://www.behringer.com/EN/Products/BCF2000.aspx Behringer BCF-2000]

'''DMX output''' is provided using:
* the driver system [[LLA]] (via a plugin to QLC), allowing DMX ouput using various DMX over IP protocols and [[Enttec]] [[DMX USB Pro]]. (for Linux and Mac OS, not yet ported to windows)
* the Peperoni [[USBDMX21]] (not tested) and [[Rodin1]] (well tested) interface, plugin named usbdmx (Linux (requires kernel driver) and Windows)
* the Enttec [[Open DMX USB]] (or other hardware with just a FTDI chip), plugin name is FTDI DMX (Mac OS, Windows and Linux, perhaps not widely tested by June 2009)
* [[Anyma uDMX]] (Windows and probably Linux and Mac OS but not well tested)
* the DMX 4 Linux library (Linux Only, stopped working from QLC 3.0?)

At the moment there are most drivers for Linux and fewest for Windows. In v. 3.0 the plugin for LLA is not included/enabled per default.

'''Inputs'''

QLC can be controlled by MIDI,e.g. from [http://www.behringer.com/EN/Products/BCF2000.aspx Behringer BCF-2000] and support for a [[Enttec]] wing may be added.
Sound synchronization is not supported [http://sourceforge.net/mailarchive/message.php?msg_name=5d3d60e90904131158r29d01e65i9e7a7ea7f61db8d%40mail.gmail.com]

'''Fixtures'''

Fixture definitions are used to map generic functions of a fixture like intensity, pan, tilt etc. to the specific DMX channels and values.
You can create your own fixture definitions to suit your needs, but there are a number of ready-made definitions [http://qlc.svn.sourceforge.net/viewvc/qlc/trunk/fixtures/ listed here]!

Related Tutorials:
* [[LLA and Q Light Controller Ubuntu Tutorial]]

Related Products:
* Peperoni [[Rodin1]] and [[USBDMX21]]
* [[Enttec]] [[Open DMX USB]]
* [[Anyma uDMX]]
* [[LLA]]
* [[DMX 4 Linux]]

[[Category:Controllers]]

Rodin1

2009-06-11T09:29:14Z

Beier: Added QLC/windows/linux info and wiki links

Link: http://www.peperoni-light.de/products1.htm 
Made by: [[Peperoni Light]] 
{{Features|win=yes|linux=yes|tx=yes|rx=yes}}
[[Image:USB2DMXRodin1.jpg|right]]

USB DMX512 transmitter interface.

The electronic fits completely into an original Neutrik plug without any extension. The Rodin1 communicates via USB2.0 and is fully compatible with the [[DMX | DMX512]], DMX512/1990 DMX512-A and [[RDM]].

The Rodin1 is open to all developers for use in their own software. All interfacing and driver specifications are provided on request.

It is supported by [[QLC]] on Linux and Windows, and uses the same protocol as [[Peperoni Light | Peperoni]] [[USBDMX21]].

[[Category:USB]]

Talk:Q Light Controller (QLC)

2009-06-11T09:21:50Z

Beier: Ipdatede to reflect page changes

Q Light Controller (QLC)

2009-06-11T09:16:08Z

Beier: Feature list and driver support update

Link: https://sourceforge.net/projects/qlc/ 
{{Features|linux=yes|osx=yes|win=yes|tx=yes|free=yes}}
[[Image:Qlc-2.4.png|right]]

QLC is a lighting controller for Linux. Started as a university project by Heikki Junnila, it has now evolved with an active development community.
In 2009 it was released for Mac Os and Windows also.

'''Features:'''
* Fixture-oriented interface.
* Four DMX universes, 512 channels each
* Fast changing and smoothly fading scenes and chasers
* Easy creation of complex patterns for moving lights with EFX
* Conjure your favourite lighting desk layout with the virtual console™
* Support for external fader devices such as the [http://www.behringer.com/EN/Products/BCF2000.aspx Behringer BCF-2000]

'''DMX output''' is provided using:
* the driver system [[LLA]] (via a plugin to QLC), allowing DMX ouput using various DMX over IP protocols and [[Enttec]] [[DMX USB Pro]]. (for Linux and Mac OS, not yet ported to windows)
* the Peperoni [[USBDMX21]] (not tested) and [[Rodin1]] (well tested) interface, plugin named usbdmx (Linux (requires kernel driver) and Windows)
* the Enttec [[Open DMX USB]] (or other hardware with just a FTDI chip), plugin name is FTDI DMX (Mac OS, Windows and Linux, perhaps not widely tested by June 2009)
* [[Anyma uDMX]] (Windows and probably Linux and Mac OS but not well tested)
* the DMX 4 Linux library (Linux Only, stopped working from QLC 3.0?)

At the moment there are most drivers for Linux and fewest for Windows. In v. 3.0 the plugin for LLA is not included/enabled per default.

'''Inputs'''

QLC can be controlled by MIDI,e.g. from [http://www.behringer.com/EN/Products/BCF2000.aspx Behringer BCF-2000] and support for a [[Enttec]] wing may be added.
Sound synchronization is not supported [http://sourceforge.net/mailarchive/message.php?msg_name=5d3d60e90904131158r29d01e65i9e7a7ea7f61db8d%40mail.gmail.com]

Related Tutorials:
* [[LLA and Q Light Controller Ubuntu Tutorial]]

Related Products:
* Peperoni [[Rodin1]] and [[USBDMX21]]
* [[Enttec]] [[Open DMX USB]]
* [[Anyma uDMX]]
* [[LLA]]
* [[DMX 4 Linux]]

[[Category:Controllers]]

Q Light Controller (QLC)

2009-06-10T19:55:11Z

Beier: corrected wrong note about sound2light

Q Light Controller (QLC)

2009-06-10T19:29:27Z

Beier: Notes on input

Q Light Controller (QLC)

2009-06-10T19:16:56Z

Beier: added note about Anyma

Anyma uDMX

2009-06-10T19:16:01Z

Beier: QLC note

Link: http://anyma.ch/research/udmx/ 
{{Features|tx=yes|win=yes|osx=yes|linux=yes}}
[[Image:udmx5pin.jpg|right]]

'''Anyma uDMX''' comes with a open firmware, which is rare. The USB communication is handled by the firmware instead of a separate chip. This must be very cheap to build!

Hardware:
* From USB to DMX (one way DMX)
* All the electronics is inside the XLR - two smd IC's: An AVR microcontroller and a RS485 driver
* The DMX data is buffered and the transmission is timed by the microcontroller
* USB powered
* No galvanic isolation
 
Software:
* An external object for [http://www.cycling74.com/ Max/MSP] (OSX)
* A console app for Linux/OSX
* MIDI control via a OSX app
* There's an example how to control the console app from php scripts (seems easy)
* Gratis firmware. The DMX part is GPL, the USB part from [http://www.obdev.at Objective Development] is "open" but all changes belongs to them.
* Supported by [[QLC]] (which platforms?)

[http://anyma.ch/research/udmx/ Anyma uDMX] 
[http://www.obdev.at/products/avrusb/index.html Objective Development's "AVR-USB]

[[Category:USB]]

USB DMX

2009-06-10T18:04:45Z

Beier: Added links

Link: http://www.usbdmx.com/usb_dmx_interface.html 
{{Features|tx=yes|rx=yes|win=yes}}
[[Image:USBDmx.gif|right]]

The interface has the following key features.

* USB Bus powered
* DMX lines galvanic opto-isolated from the USB bus
* DMX lines over voltage protected, and current limited
* Simultaneously send and receive up to 512 channels
* Minimal host computer resource needed
* Firmware updatable over USB
* High quality resilient line drivers
* Heavy duty powder coated steel case
* Affordable and easy to build
* Compatible with all major O/S (refers to driver for USB to serial interface)

* The data is buffered in the device, and the device handles the timings itself

LLA and DMX4Linu has no driver for this device (8/1 2007), but the [http://www.usbdmx.com/downloads/protocol.pdf protocol is documented].

The interface can be used from a number of DMX controller apps for Windows and Mac OS.

There is a [http://www.usbdmx.com/downloads/schematic_1_2.pdf schematic] for this device.

[[Category:USB]]

Talk:DMX512-A

2009-06-10T16:21:49Z

Beier: Added timing table, extra voltage note

== Timings ==
The clock rate is 250 kHz so each symbol bit on the wire is 4 microseconds long (period time).

Frame rate is ??
Packet rate is typically around 44 Hz when all frames are sent.

== RDM protocol additions ==
The name of the standard is: ANSI/ESTA 1.20, Entertainment Technology - Remote Device Management over USITT DMX512
???
Mark (beginning of frames)
Mark After Break (beginning of frames)

Mark time between packet
Mark time between frames

DMX Timing table

Symbol length is 4 +/- 0.08us for 245 - 255 k baud/s, with non-return-zero between symbol bits. To transmit 8 data bits it take 11 symbols because the use of one start bit and two stop bits around each data byte.

{|border=1
||'''Name''' || '''Tx requirement''' || '''Typical/suggested Tx''' || '''Rx requirement'''
|-
||Break (the packet start) || >= 92 us || 100-120 us (Ujjal) 176 us (DMX512-A-2004)|| >= 88 us
|-
||Mark after break (in packet start) || >= 8 us || 12 us (Ujjal) || 4 us - < 1 s backward compatible 8 us - < 1 s DMX512-A-2004
|-
||Slot/frame width || 44 us || 44 us || 44 us
|-
||Inter-slot/frame time || < 1 s || minimal || < 1 s ?
|-
||Mark before break (Idle time after packet)|| < 1 s || 0 - 1 s ? || < 1 s ?
|-
||Break to Break time, also (DMX2512 packet length) || 1204 us -1 s || || 1196 us - 1.25 s
|}

Idle must be high level
Note that "Mark after break" was changed from 4 to 8 us minimum length in 1990, and receivers can be backward compatible.
The slot time must be precise, or else the receiver should discard the whole packet, e.g. if the second stop bit is missing.

There must be at least one packet with start code=0 per second, and a receiving product must specify what happens when this time is exceeded.

Ervin Rol has shown the timing values from the DMX standard.

== Use of category 5 UTP or STP ==
New cable types is used, and may be officially accepted.
http://www.usitt.org/standards/DMX512_FAQ.html#FAQ_08

The use of modular plugs like 8P8C (RJ45) or 6P4C (RJ11)

The cabling for DMX512-A should be described in the document called "BSR E1.27-1 -- Portable Control Cables for Use with USITT DMX512/1990 and E1.11 [DMX512-A]"

== Sender/receiver topologiess ==
To avoid ground loops and improve reception performance, transmitters and/or receivers can be grounded/floating/non-isolated ???
http://www.usitt.org/standards/DMX512_FAQ.html#FAQ_15
There are different topologies, and not all will work together. There are no requirement for what topology to use in the DMX specification from 1990, so it was added to DMX512-A.

Transmitters should use "earth ground" as a reference for the positive/negative voltages that is put on the two data lines. If they don't, it must be clearly marked on the product and in the manual.
Receivers should be ...?

== More suggestions and info ==

Here is also a nice overview of the different parts of a DMX packet with timings etc.:
http://www.erwinrol.com/index.php?stagecraft/dmx.php

== Voltages ==

The power dissipation in the 120 Ohm terminating resistors depends on the differential voltage between the two data wires.
If the transmitter only makes a 5 V differential voltage, the power dissipation is P= U*U/R= 5*5/120 = 208 mW.

According to http://focus.ti.com/lit/an/slla070c/slla070c.pdf the maximum absolute differential voltage allowed by the EIA485 standard is 6 V.
This give the maximum power dissipation is P= U*U/R= 6*6/120 = 300 mW. So it is best to use 1/2 W resistors.

At http://www.dmx512-online.com/physl.html there is an example wit D1+ at +5V and D1- at -5V, and considering [http://focus.ti.com/lit/an/slla070c/slla070c.pdf page 12 in this document from TI] it is presumably a wrong interpretation.

[http://www.dmx512-online.com/physl.html This web page] cites RS485 as having a upper limit of +12/-7 V with respect to ground. This probably refers to common mode loading voltages that receivers must work with. I.e. one of the data wires is allowed to reach +12 or -7 V but the opposite wire must not be at the other extreme, but only differ by 6 V maximum.

Transciever chips made for 5 V:
Linear Technology LTC485: http://www.linear.com/pc/productDetail.jsp?navId=H0,C1,C1007,C1017,P2064
National semiconductor LMS485: http://www.national.com/mpf/LM/LMS485.html
National semiconductor DS75176B (used in Martin PAL 1200, Lite-Puter DX-625 and a cheap Eurolite DMX console) http://www.national.com/mpf/DS/DS75176B.html

a but the spec says that the differential maximum from transmitters is 6 V, according to

== Debugging tips ==

Links to simple testers?

How can reverse polarity be detected?
* The break at the very beginning of a packet must be low
* If all transmitted data bytes have value zero, the DMX line should be low about 80 % of the time if there are no extra idle time between slots/frames or packets.

DMX512-A

2009-06-10T11:02:06Z

Beier:

''This information is not complete.'' The purpose is to introduce the protocol and the details of a packet and maybe explain the required timing of the signal. --[[User:Beier|Beier]] 06:21, 28 January 2007 (PST)

The last version of the standard is called [http://usitt.org/ USITT] DMX512-A and it is maintained by [http://esta.org ESTA] since 1998. In 2004 it was made an ANSI standard too, named "E1.11, USITT DMX512-A" or "ANSI E1.11-2004". In 2008 it was revised [http://www.esta.org/tsp/news/newsdetails.php?newsID=291] .

DMX is characterized by its simplicity in how data are transferred from a controller to receiving equipment.

== Electrical ==
DMX is based on the balanced serial connection standard [http://en.wikipedia.org/wiki/EIA-485 EIA-485-A] (a.k.a RS485).
Only 5-pin XLR meets the standard (and products may meet the requirement by supplying adapters).
Since the revision in 1998 the cables itself are not specified in DMX512-A (so it can be specified in separate standards?), so in general the cable must fulfill the [http://en.wikipedia.org/wiki/EIA-485 EIA-485] requirements of 120 Ohms (around 250 kHz) shielded twisted pair. One transmitter must be connected to maximum 32 receivers.

Other cable types have been examined to determine how well they are for DMX usage (as loose cables or in fixed building installations). The last report more or less concludes that for fixed installations, unshielded twisted pair in [http://en.wikipedia.org/wiki/Category_5_cable CAT 5] is good enough, even when it is mixed with 120 Ohm cable meant for EIA-485. The pulses from reflections and general degradation is not significant and harmless. See the three parts at http://www.esta.org/tsp/working_groups/CP/DMXoverCat5.htm .

=== Transmitter/receiver topologies ===
To avoid ground loops between equipment and improve reception performance, the transmitters and receivers for the DMX line must use a good combination of transmitter/receiver topologies. Some are not allowed, some are accepted with warning labels and some are preferred. See http://www.usitt.org/standards/DMX512_FAQ.html#FAQ_15 .

Transmitters should use "earth ground" as a reference for the positive/negative voltages that is put on the two data lines.
Receivers should be "isolated".

==The protocol==
'''A Universe''' contains 512 addresses and a single DMX line (cable) can only transmit one universe. I.e. a controller with two universes need two DMX lines (daisy chains including splitters). A universe is normally thought of as an address space (in the controller), the cables that transmits it and the equipment that receives it.

* The DMX signal is made up of a sequence - called a ''packet'' - which is sent over and over again (to increase robustness).
* It is up to the controller/transmitter to decide how many of the 512 values is sent. A shorter packet means faster cycles.
* A receiver must be set or programmed to an address it listens to. If a receiver listens to multiple addresses, the set one is the first. (It depends on implementation.)
* Multiple receiver can listen to the same address - the DMX system does not care.

'''A packet''' has the following sequence:
* Break
* Mark After Break (MAB)
* The ''"start code"'' frame (Sometimes called address 0) [http://www.esta.org/tsp/working_groups/CP/DMXAlternateCodes.php Alternate start codes]
* 1-512 ''frames'' with the values of the channels. The first value is for address "1", the next for address 2 etc.
(Note: A packet must have a minimum length in time)

* A frame contains the value for one address, has one start bit and two stop bits.
* The address number is not sent over the lines, so the receiver must count the values from the start of the sequence to find the wanted value.
* The ''start code'' is used to alter the meaning of the data bytes in the rest of the packet. The default is 0, and the remaining 255 values is rarely used (by definition 0 means dimmers, but is used for intelligent light as well).

Note that some people and texts use the words frame and packet in the opposite sense than stated here.

 
'''Sources and additional reading:''' 
[http://www.dmx512-online.com/packt.html Ujjal's DMX512 Pages] (down-to-earth walk-through) 
[http://www.epanorama.net/links/lights.html#dmx512 ePanorama] (thorough descriptions of most details, lots of links) 
[http://en.wikipedia.org/wiki/DMX_(lighting) Wikipedia] 
[http://www.usitt.org/standards/DMX512.html USITT ]
 
[http://www.euro-pa.be/dmx.html The anatomy of DMX512] (a nice, short overview)

[[Category:Articles]]

Open DMX USB

2009-06-07T23:09:30Z

Beier: Added QLC/Mac/windows/linux info

[[Category:USB]]
[[Image:Opendmxusb.JPG|right]]

Link: http://www.enttec.com/index.php?main_menu=Products&prod=70303&show=description&name=opendmxusb 
Made by: [[Enttec]] 
{{Features|win=yes|linux=yes|osx=yes|tx=yes|rx=yes}}

The OpenDMX USB is based on a FT232BM chip, a USB to Serial converter produced by FTDI.
The widget is capable of DMX transmission and reception, but is totally reliant on the CPU to produce (or capture) the DMX signal, so this type of device is called 'unbuffered'. It works quite well, but if for example your PC froze for a second, so would the DMX. The design is GPL (you can build your own!) and is quite basic, and does not offer any protection for your equipment.

Note that receiving DMX does not currently work under Linux.

==Driver Support==

Linux Kernel 2.4: via [[DMX 4 Linux]]

Linux Kernel 2.6: via [[LLA]] as detailed in [[LLA, OpenDMX USB and Q Light Controller Tutorial]]

In [[QLC]] on Linux, Mac OS and Windows.

Related Products:

* [[DMX USB Pro]]

Q Light Controller (QLC)

2009-06-07T23:08:11Z

Beier: Driver info, Enttec Open DMX USB

E1.31

2009-06-06T10:18:28Z

Beier:

= BSR E1.31 =
From ESTA.org and supported by http://www.esta.org/tsp/working_groups/CP/projs.html and http://www.sandsys.com/acn/sandnet_acn.htm :

BSR E1.31, Lightweight streaming protocol for transport of DMX512 using [[ACN]].

But on http://en.wikipedia.org/wiki/DMX512-A there are an other description under the heading "Development":

''ESTA has initiated a project numbered E1.31 to define an interoperable CAT5 transport for DMX512.''

This probably should not refer to transferring the data bytes of DMX over IP networks, not EIA485 electrical signals over twisted pair of CAT 5 quality.

= ANSI numbers =
Many [[DMX]] related standards have been numbered/revised by the [http://www.ansi.org/ American National Standards Institute].

* [http://webstore.ansi.org/RecordDetail.aspx?sku=ANSI+E1.11-2008 ANSI E1.11-2008]
Entertainment Technology -- USITT DMX512-A -- Asynchronous Serial Digital Data Transmission Standard for Controlling Lighting Equipment and Accessories .
''See [[DMX]]''
* [http://webstore.ansi.org/RecordDetail.aspx?sku=ANSI+E1.17%3a2006 ANSI E1.17:2006]
ANSI E1.17 2006 - Entertainment Technology - Architecture for Control Networks .
''[[DMX]] over [[ACN]]''
* [http://webstore.ansi.org/RecordDetail.aspx?sku=ANSI+E1.20-2006 ANSI E1.20-2006]
Entertainment Technology--Remote Device Management over USITT DMX512 .
''[[RDM]] over [[DMX]]''

The above is found via http://webstore.ansi.org/

Note that DMX512-A was updated in 2004 and again in 2008: http://www.esta.org/tsp/news/newsdetails.php?newsID=291 (regarding text mesasges in UTF-8, update rate almost up to 20*44 Hz, corrections of errors and clarifications)

'''Current drafts'''

The drafts for new standards seems to be made by ESTA who has this list currently:

http://www.esta.org/tsp/working_groups/CP/projs.html

E1.31 covers basic DMX through ACN, and E1.33 will extend E1.31 to include RDM data transmissions.
Ref: News from USITT http://www.usitt.org/sightlines/v46/n10/stories/EstaNewStandards.html#dmx which is also cited here
[http://livedesignonline.com/news/esta_announces_four_new_standards_drafting_projects/]

The [[RDM]] protocol is to be extended with BSR E1.37 e.g. for bulk data transfer.

Talk:Open DMX USB

2009-05-30T18:52:32Z

Beier: how to build it?

According to the Enttec page this unit doesn't support receiving DMX and there are no OS X drivers available from Enttec.

== Electrical design ==

As pin 4 and 5 in the XLR5 plug is not connected to the RXD input pin of the chip, it cannot be used for the RDM protocol. But if DMX signals are fed into pin 1 and 2 (with the help of a plug gender changer), the software should be able to set the RTS line low and poll the chip for incoming serial data.

I wonder if some DMX-serial drivers for this interface requires this exact FTDI 232BM chip (e.g. the one in Freestyler, that I could not get to work with other USB-to-serial converters.

In general this system only requires that the app can set the serial clock speed to 250 000 baud, and be able to control the RTS line (is relatively good timing required?). The data are transferred and buffered in the chip one byte at a time, I assume (so here the timing is not as critical, if the bytes are delivered within time).

== Building instructions where? ==
The schematic diagram is available.

But the interfaces that Enttec build comes with some code in the EEPROM.
* Is this code necessary? Or does it depend on how critical the device drivers are?
* What is the code, what does it tell?
* newer versions of the FTDIchip 232 have built-in EEPROM. Do they work just as well?

Are there device drivers that can use any serial port, given that the speed can be set correctly?