DALI lights don't turn on or off at the same time

Response DALI Gateway

It should be noted that the Response DALI Gateway converts DMX to DALI.  As we stated above, DMX is a streaming protocol and DALI is not.  The Response DALI Gateway is unique in that is makes DALI a streaming protocol by re-transmitting the current DMX value over DALI at a frequency of about 2-3 times per minute.  This creates a lot of traffic on the DALI bus but the idea is that if a DALI fixture missed its message to change lighting level, then another message would be transmitted within about a minutes timeframe.  In reality, the DMX lighting level is not re-transmitted but rather the gateway sends a query to each DALI fixtures asking what it's current lighting level is.  If the response from the DALI fixture does not match the DMX value assigned to it, it sends a new DALI lighting level packet to that DALI fixture.

A note that will be relevant below.  Response DALI Gateway will support Individual and Broadcast commands.

DALI - Architectural vs Entertainment use

DALI is an excellent protocol for architectural lighting installations because lighting levels typically don't need to change state often.  In entertainment market, lighting levels are expected to be dynamic and change at a high frequency for effects, chases, or different scenes.  For this reason, DMX is a preferred protocol in the entertainment market as the protocol is more robust and designed specifically for that market.

DALI in an entertainment market is difficult because lights will not be synchronized while changing state which is usually not desirable.

Individual Control vs Broadcast Control

One of the ways to improve this issue (lights not being synchronized) is to use Broadcast DALI commands instead of Individual DALI commands.  As mentioned above, individual control means that a DALI controller will need to send out individual DALI messages for each DALI short address.  A broadcast DALI message sends a single message out to all fixtures.  The screenshot below comes from a DALI Montioring software.  It shows a single message directed to Address Bcast (Broadcast) telling the lighting fixtures to all go to 100% intensity (DIRECT ARC POWER 254).

As an example, if we have a DALI loop filled to maximum capacity of 64 fixtures, and we are controlling them via individual addresses, a command telling lights 1-64 to turn on could take approximately 1-3 seconds to transmit.  That does not include fade times.  This is just the initial message telling the lights to change state.  The reason is takes so long is because the controller can only transmit a single message at a time (and it does not transmit as fast as DMX).  The result is that the lights are not synchronized when they come on.  In the screenshot below, the DALI controller is seen transmitting lighting levels to DALI addresses 0,1,2,3, and 6.  Notice the difference in time on the right side.  This may not be as big for a few fixtures but for a full loop, the delay will be visible. Also note that the commands get transmitted in random address order.

In addition to individual messages being transmitted at different times, they will also be received at the fixtures at different times, thus creating an unsychronized state change (the popcorn effect).

It should be noted that DALI Group commands can be just as effective as Broadcast commands.  A DALI Group command is a single command just like Broadcast.  Before deciding if this is a good solution, verify if the DALI controller will support the transmission of Group commands.

Fade Time

Another important consideration with this behavior is fade time when using individual control.  DALI lighting fixtures can host their own fade times.  If using a DMX to DALI convertor like the Response DALI Gateway, the DMX values may also use a fade time when transitioning between scenes.  A two second DMX fade time will not translate to a 2 second fade even if the DALI fixtures are set to have their individual fade times at 0 seconds.  

As mentioned above, a DALI controller can only send out a single message at a time.  When a DMX fade occurs, the controller will struggle to keep up, meaning that the DALI controller will not send out a DALI level packet for each step in a fade between two levels.  Instead the DALI controller will send a level change packet as fast as it can. 

To isolate an example, lets say we are going to fade address 1 from 100% to 0%, DALI address 1 will likely get two to three DALI set level commands over the course of a 5 second DMX fade.  The result (with DALI fade time at 0 seconds) is a steppy fade from 100% jumping to 70%, jumping to 20%, jumping to 0%.

The best way to ensure a good fade is to let the fixture do the fade.  The biggest downside with this is that the fade time has to be assigned in the DALI ballast itself and therefore is not easy to change in a moments notice.

An alternative is to use compound fade times where the DMX fade may be 1-2 seconds and the DALI fade time may also be 1-2 seconds.  The result is closer to a 5 second fade but the result is also a smooth fade.  Note that this will not help with all lights fading in-sync with each other.

The screenshot below is an example of a 5 second DMX fade going from 100% intensity to 0% intensity (DALI fade time of 0 seconds).  There are 8 fixtures in this DALI loop.  Notice the difference in the times transmitted, the destination level, and the DALI address the message is being sent to.