1
\$\begingroup\$

I currently have a DALI set-up with three LEDs.

All LEDs turn off when sent a broadcast command to turn off, so the set-up is wired correctly.

I have removed all of their short addresses according to the procedure outlined here and a search from 0-63 with QUERY STATUS reveals that there is no assigned short address to any of the ballasts.

I have sent out INITIALISE with second byte 00, twice within 100ms, to target all operating devices. I have sent out RANDOMISE twice within 100ms. I set the high, medium and low addresses to FF (i.e. the 24-bit address I'm searching for is 11111111 11111111 11111111) and have sent out COMPARE.

Previously I was able to get a response from this procedure but today I am not getting a response from any of my lights.

I am currently using a Raspberry Pi with this AL-DALI-HAT to control my DALI lights. I interpret an "N" and an "X" as no response.

Can anyone suggest debugging steps or if need be how I can hard-reset my DALI lights?

\$\endgroup\$

2 Answers 2

1
\$\begingroup\$

Your interpretation of X as no response is incorrect, the AL-DALI-HAT manual you linked to shows that X means collision on recieve. A collision occurs in DALI when multiple controlgear respond simultaneously to the same query - COMPARE is effectively a query because it requires a response. DALI is not designed for collision avoidance in the response packets, rather it is designed so that collisions can and will usually occur under these circumstances. The application has to be designed to interpret these collisions in the appropriate way. In this case, collisions mean that there are more than one controlgear with a random address below 0xFFFFFF.

The random address search routine has to change the search addresss until it gets no response, then step back up one which should produce just one clean response - at that point the gear is selected and will respond to the Program Short Address command. See the Related Questions on the right for more details.

\$\endgroup\$
1
  • \$\begingroup\$ I have exactly the same problem, but with two ballasts. One ballast reacts properly to address deletion commands, I am also able to pair it in again with standard pairing procedure. The other one however reacts to all broadcast commands, properly, so I disconnect the good one from the line and work only with that single weird ballast which also responds to broadcast status query, identifying that it does not have short address. However it does not respond to compare queries... :( \$\endgroup\$
    – Simanas
    Commented May 16 at 10:55
0
\$\begingroup\$

For me - turned out, that the ballast was giving out a response with super out out of spec signal, so the signal it was broadcasting out was not in respect with official DALI bit lengths. It was way shorter for low's and high's.

Though it respects double high/low times by exceeding minimum time by ~10%.

\$\endgroup\$
1
  • \$\begingroup\$ Out of spec signals used to be a problem quite a few years ago, but the situation was supposed to be improved with the DALI Alliance certification process, which requires extensive testing to ensure all aspects of the relevant IEC standards are met. If your ballast is listed on the official database then you should report the problem through the DALI Alliance, and if it is not listed but has the logo then you should also report it. If it doesn't have the logo, you shouldn't be using it. \$\endgroup\$
    – Martin
    Commented May 20 at 11:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.