Home › Open Lighting Architecture › Get Help › FAQ
Home › Open Lighting Architecture › Get Help › FAQ

FAQ

General

Can I use OLA in my project?

That depends on the project. libola is licensed under LGPL which means it can be used from commercial software. olad is licensed under the GPL which means any plugins added to olad must be GPL compatible.

Why aren’t my settings saved when I disconnect power from the Raspberry Pi?

olad only saves the settings during when the daemon is stopped. There is a long standing feature request to save settings whenever an attribute is changed. To work around this, configure olad with the settings you want, then stop olad (either from the web UI or the command line). At this point you can power cycle the Pi and the settings will be restored.

To stop olad from the command line, one of the following commands should work depending on your operating system:

  1. To find out if olad is currently running, run ps aux | grep -i olad | grep -v grep . If you see anything listed then it is.
  2. Try the commands below in order, running the ps aux above after each one to see if it’s worked
    1. sudo service olad stop
    2. sudo /etc/init.d/olad stop
    3. sudo kill <the number in the second column from the ps aux command above>
    4. sudo kill -9 <the number in the second column from the ps aux command above>

How do I get olad -l 4 logs?

  1. If olad is already running via your system installation, run ps aux | grep -i olad | grep -v grep to find the current command line (if you started olad directly from the command line yourself you can skip to the last two stages)
  2. You’ll need to stop olad or kill that process if it’s already running, try the commands below in order, running the ps aux above after each one to see if it’s worked
    1. sudo service olad stop
    2. sudo /etc/init.d/olad stop
    3. sudo kill <the number in the second column from the ps aux command above>
    4. sudo kill -9 <the number in the second column from the ps aux command above>
  3. Run the command line you found earlier, with the following changes (if you’re interested in what they’re doing see the olad man pag (man olad))
    1. Change the number after --log-level or -l to 4
    2. Remove --syslog, -f or --daemon if present
  4. olad should output lots of logs, copy and paste them into your question/issue to help diagnose what is happening

If you’ve succeeded, olad should keep logging things quite frequently, and these lines won’t be present as the last few lines of output:

common/network/TCPSocket.cpp:235: bind to 127.0.0.1:9010 failed, Address already in use
common/rpc/RpcServer.cpp:102: Could not listen on the RPC port 9010, you probably have another instance of running.
olad/OlaServer.cpp:252: Failed to init RPC server

If they are, try the steps above again, and then ask for more help.

Universes

Can I use Universe 0?

olad universes can range from 0 to 65535. That said, some plugins like sACN don’t support universe 0. We suggest starting from Universe 1.

Plugins

ArtNet

ArtNet uses a very complicated addressing scheme. ArtNet universes are described in the Net:Subnet:Port notation.

  • Port addresses are 4 bits (0-15). Artistic License gear usually has a 8 position rotary switch that sets the port address for each port.
  • Subnet address are 4 bits (0-15). Artistic License gear usually has a 8 position rotary switch that sets the subnet address for the node.
  • Net addresses are 7 bits (0-127) but are only found on ArtNet3 devices. Pre-ArtNet3 the net address is treated as 0.

Putting this together, the address 0:1:2 means Net 0, SubNet 1, Port 2.

In OLA, the net & subnet values are set in the ola-artnet.conf file. The Port Address is determined for the universe that the ArtNet port is patched to, universe 0 -> port address 0, universe 1 -> port address 1, universe 15 -> port address 15, universe 16 -> port address 0 and so on.

OSC

What OSC formats are supported?

For sending:

  • blob: a OSC-blob
  • float_array: an array of float values. 0.0 – 1.0
  • individual_float: one float message for each slot (channel). 0.0 – 1.0
  • individual_int: one int message for each slot (channel). 0 – 255.
  • int_array: an array of int values. 0 – 255.

For receiving:

  • OSC-blob
  • Single channel ints & floats

SPI

Why is the output delayed with OLA version 0.8.33?

The 0.8.33 release had a bug the defaulted the SPI speed to 100kHz instead of 1MHz. To fix this change  the <device>-spi-speed setting in ola-spi.conf.

USB

What is the difference between the different USB plugins?

Serial USB (ola-usbserial.conf) is used for USB devices that appear as a FTDI serial port and use a external micro processor to generate the DMX signals. This includes USB devices that implement the Enttec USB Pro messages.

USB DMX (ola-usbdmx.conf) is used for USB devices that do not appear as serial ports and instead use custom USB protocols between the host (PC) and the device. The plugin uses libusb to communicate with the device.

FTDI USB DMX (ola-ftdidmx.conf)  is for the ‘dumb’ FTDI devices. These have no external microprocessor and rely on the host to control the DMX timing. Examples of this type of device are the Enttec Open DMX USB.

Enttec Open DMX (ola-opendmx.conf) is similar to FTDI USB DMX, but it uses the Open DMX kernel module.  Since this uses a kernel module it’s only used on Linux.

Hardware

Can you add support for the <insert-name-here> device?

Adding support for new devices generally requires:

  1. Someone with C++ programming skills
  2. Someone with access to the new device.

Over the years, we’ve found that the process works best if 1) and 2) are the same person. Even though the Internet makes things easier, trying to debug problems remotely consumes an inordinate amount of time, and requires scheduling around day-jobs, family, etc. often across different timezones.

Often tools like logic analyzers, DMX / RDM sniffers, DMX / RDM test devices, and USB sniffers are required during development. Without these the experience is frustrating for everyone involved.

With that in mind, if you think you have the skills & equipment to add support for a device, by all means write the code and open a pull request. Otherwise the recommended way is to donate a device to one of the main contributors and have them work on it.

What are the recommended USB Device to use with OLA?

The following is entirely Simon’s opinion, the Open Lighting Project doesn’t endorse products.

For each category I list my top picks and all devices within the category can be considered equal. This list only considers using the device with OLA, rather than the full suite of software available for each interface. Since manufacturers send me hardware for free, I don’t consider price in my recommendations. YMMV.

For Sending DMX:

For receiving DMX:

For acting as an RDM controller:

Interfaces I definitely wouldn’t use:

  • Open DMX USB, no microprocessor, the host is responsible for signal timing.
  • Velleman K8062, the design severely limits the update rate.
  • Almost anything you find on eBay / Amazon.

Extending

How should I add support for a new Protocol / Device?

If you’re looking to add support for a new protocol or device, the easiest way to get started to to write an OLA Client. By keeping the logic separate from olad, it means you can focus on the new protocol / device without having to worry about integrating with olad.

Once the code is working correctly, it can be added as a OLA Plugin.

Some things to consider when deciding between a client and a plugin:

  • Since plugins are linked with olad, they must be licensed under the GPL or a GPL compatible license.
  • Plugins included in the main tree will be maintained if the plugin API changes. If your plugin isn’t included in the main tree it may break between releases.
  • Plugins will generally perform better than clients, since they run in the same process as olad.
  • Plugins must be written in C++. Clients can be written in any language with an OLA Client API.