Strange behavior of the DALI controlled luminaires

Question

I faced a strange behavior of a DALI controlled LED luminaires circuit. I have 48 LED luimianires with a MeanWell ELG150-C700-DA drivers connaected according to the scheme below: I commissioned the system and it works OK but sometimes I can't switch some luminaires OFF via the DALI commands. When I send DAPC 0 or OFF command this luminaire go OFF, but in a second the go back to 100% of their output. Besides that this problem is floating, because in a different days different luminaires start to work in a such way. Moreover sometimes ALL luminaires go ON spontaneously.

I doubt that the problem is in LED drivers because when I tested some other drivers from the same bunch, everything was OK. I think that something is wrong with the DALI bus installation quality, but I don't know from where to start the thoubleshooting.

I am a novice in a DALI theme, could you advice me what parameters I should check to find the root of the problem?

Here is a DALI signal at the beginning of the DALI bus near the 905 router

By the way why the signal amplitude for 2 DALI packets is different?

Answer 1

DALI requires less than 2V maximum difference between the highest and lowest points on the line. To achieve that you must use sufficient cable gauge and a power supply with sufficient current limit. The luminaires will go on "spontaneously" if they see a system failure condition, which is less than minimum DALI voltage for more than 500ms. For up to 150m you need to use 0.75mm squared CSA.

You may be overloading the PSU in the 905 router. Although it has a current limit at 250mA, which is the maximum allowed by DALI, you have 48 luminaires plus 3 control panels. The luminaires (assuming one DALI driver per luminaire) are restricted to 2mA each by the standard, but the control panels do not have the same restriction; they are allowed to be up to 250mA each (although not a good idea to go that high). So measure with a current meter in series at the router end what you are drawing during non transmit times, and look at the DALI signal with a scope to see if the high levels are dipping below 9.5V.

Answer 2

How are you at debugging any communication serial port? for BER (bit error rate) integrity testing?

Data "0" = -4.5 to +4.5V ( 0V nom) new +/- 6.5V Data "1" = 10.5V to 22.5V (16V nom) new 9.5 to 22.5V

This is to allow "lots" of ringing when sending 0 to 16V. But high power RF bursts on long cables can also induce errors.

This enables reliable communications in the presence of significant electrical noise. But noise spikes can create false triggers and possible command data.

Detection of the problem may be hard if you have no tools or EMI skills.

Radiated?

If transient power or radiated transients are suspected, try an AM radio between channels in a quiet band. Then wait for the event.

Conducted?

Put AM radio near AC line with a lamp to indicate power level.

The ingress of noise ( input)depends on location near-interference and length of the cable. So isolation of an offending zone depends on isolation methods.

Debug tools

If you have access to DALI test tools, , then it is easier to test the 9600 Baud Bit error rate (BER) in a continuous mode in half duplex feedback.

not a testimonial, just an example

My hunch

RF interference from transmitter bursts.

Potential fix, choosing RF cap of right size that does not reduce slew rate of data. Maybe 100 pF to 1 nF across node connection.

Yet shielded pair is about 100pF/m so a 150m cable is 15nF with a low impedance driver (50 ohm?) My guestimate is that > 100nF may cause slew rate limiting or 6x 150m, but noise can affect this range.

Each Rx can load of 2mA which at 22V is equivalent to 11 kOhm . The signal is biphase-M (Manchester)