I designed my own DALI devices and now trying to build-up a DALI system. Since my DALI gears are based on MSP430G2553, I took advantage of code being already done for TI's DALI demonstration board.
Right now I'm working only with one DALI master and one DALI slave. Question is, how will (or how should) the system behave with more DALI slaves.
My point is… How to handle multiple DALI responses, e.g. after broadcasting the QUERY STATUS command? I suppose that all devices in the system would try to send their response, not knowing that there are more slaves trying to communicate. What is the work-around for this case?
Best Answer
There is no "work around" for the case of multiple responses to query, you just have to handle all possible outcomes. DALI is designed to allow for collisions which can occur when multiple gear respond to the same query, so you have to handle this in your master software. The slaves must not attempt to avoid collisions with each other - just wait the required time after the query and respond (unless your response is a NO, which is No Response).
There are various cases you have to handle in master software when you expect a response:
No response within the timeout period. All gear that were addressed have answered NO or were not powered up.
A collision occurs when multiple responses overlap, usually resulting in bit timing errors. When you only have 2 or 3 gear responding, the usual case is that the low bits overlap and you end with shortened
high bits, significantly less than the minimum pulse time.
It is possible but rare to have a multiple gear respond with the same data at exactly the same time and not have any bit timing errors. In this case you would not know the difference between the response being from one gear or several. Maybe you can design the system so that you don't care.
It is also possible but rare to have multiple responses align so that no bit timing errors occur but the response frame is longer than 8 bits. Some gear actually do this by design if they are one hardware unit with several logical short addresses, but the Edition 2 requirement is for this type of design to respond in this case with an extended length low pulse. You should treat either of these as a collision since it is also an invalid frame in terms of what is allowable as a valid response.
As a gear designer, you are encouraged to use the some randomness inside the response timing window so that the rare cases occur as rarely as possible. It has been clarified in Edition 2 that you must not use collision avoidance for the response.
As a control device designer, you need to choose your queries and addressing modes carefully so that you can cope with what the responses might be. For example, if you require the QUERY STATUS bits from several gear, you would query each using its (previously uniquely allocated) short address in turn, rather than using broadcast or group. Alternatively, if you only want to know lamp failure status, a broadcast QUERY LAMP FAIL has the advantage that only gear whose lamp has failed will reply at all, so you might be able to design your logic to deal with a single YES or a collision since that tells you that at least one lamp has failed.