This question is haunting me for a long time. This could be something very basic and I do not know how it works or could be some misunderstanding! I am now using STM32E407 as DALI master and am working on the implementation of DALI. I have achieved some basic results on single Master- single Slave, now I want to look at the problems involved in multi-master DALI.

My understanding/misunderstanding:

My idea is to design a light control system with at least 3 DALI buses and if possible with a (1-10v) controller!

On single MCU, if I use different timers and GPIO pins to run different DALI buses and use two non-terminating loops in while(1) loop(or main loop), it will not obviously work as parallel processing is not possible on single core MCUs!

So, my immediate idea is to go for a modular approach, where each MCU will be implemented and running with DALI stack, providing just one DALI bus and I can use several of these to implement several buses. To do something as shown below is my idea.

enter image description here

This obviously makes it more expensive and also for UI, Light_Controller MCU has to access the data from and write data to DALIx_MCUs which leaves the Light_Controller MCU extra processing overhead or unnecessary extra effort!

I have checked for WAGO Multi-master module (commercial product). It's documentation, WAGO Multi-master doc, on page number 25, it shows the clamp as below.

WAGO Multi-master

I am guessing the "Logic" here is a small MCU or MPU and WAGO is using modular approach that is why each clamp provides one DALI bus!


I would like to know how multiple DALI buses or Multi-master systems will be developed in general?

and is it something that is part of DALI standard??


  • MCU- Micro-controller Unit, MPU- Micro-processor unit, UI - User Interface
  • I am not sure whether "multi-master system" and "single MCU with several DALI buses"(if at all possible!!) are same or not!
  • 1-10v Controller can be part of the Light_Controller MCU and could be irrelevant here!

1 Answer 1


You are confusing several concepts here. Your block diagram is for three Single Master Control Devices (to use the IEC terminology). That is possible to implement in one single core microcontroller using timers and interrupts, since a Single Master is in control of the bus timing. That is, you decide when to transmit, and can only expect incoming messages as responses to queries you have generated - this is what is meant by a Single Master. It might not be possible if the other items on the bus are not control gear, ie. items which can generate a frame at any time would not be allowed, but control gear can only respond to queries.

Multimaster control devices are part of the standard, you need to purchase a copy of IEC62386-103 to see all the details. This is relatively recent, so microcontroller App Notes from several years ago will not have this information. The Multimaster timing requirements are much stricter than the single master timing so that collision avoidance, detection and recovery are possible and mandatory. Several multimaster devices are allowed to share the same bus because of these features, and then you have to implement more commands than you would have to for a Single Master design for it to work properly.

Multimaster in this standard refers to the bus timings so that valid communications can take place. It does not imply multiple application controllers (the control logic). It is up to the system designer to decide if they want multiple application controllers and how to split up the gear addresses so that there are not conflicts, that is not standardised under IEC or DALI.

Your next decision is if you really need 3 busses or whether you can use one bus and use the addressing system to separately control the gear. With 3 busses, you can have the full power supply on each one and use the simpler broadcast address system. With one bus you could have less interface hardware and cabling, but the commissioning is more complicated.

--- Edited to add how to do multiple single master controller on one MCU Firstly, this next section is not about multimaster control devices as specified by IEC62386-103; it is about multiple single master control devices on different buses using one MCU.

One option is sequential frames. Choose to handle one bus at a time, send a frame, if it was a query you would need to allow time for the response or timeout due to lack of response, before handling the next bus. This would probably be fast enough if you only have three buses to deal with for the lights to appear to turn on or off together. Sequential frames A better option in terms of synchronising the effects on the lights would be to send frames on multiple buses at the same time. You don't need to find a way to drive multiple MCU pins absolutely in sync to do this, just run through a list of output pin drive commands every Te (416us). The frames will only be offset from each other on the different buses by the time it takes to change the pin state. Simultaneous frames Obviously this is easy to do if the frames to be transmitted are identical, but it is not much harder to do if they are not, you just need to pick up the next pin level from two/three different variables, one for each bus. Where this would become difficult is if these forward frames were queries, because you have to try to handle multiple responses on different buses at the same time. Personally I would doubt that is possible in a single core/thread, relatively slow MCU. But you could use the sequential frames technique for queries and the simultaneous technique for commands to get the best of both worlds, if you think the added complexity is worth it for the reduced latency between buses.

  • \$\begingroup\$ This is unsettling for my understanding! Please bear with me if this is a further misunderstanding! What still confuses me is the first paragraph of your answer. If my block diagram represents, three "Single Master Control Devices" and if it is possible to implement these three on single MCU, that suggests these three "Single Master Control Devices" are three pairs of GPIO pins on MCU(of course with appropriate DALI PHY circuits). Is it so?? If yes, there is an obvious constraint that we cannot group devices from two different DALI buses!! Isn't it?? Cont.. \$\endgroup\$
    – charansai
    Dec 20, 2017 at 8:25
  • \$\begingroup\$ and we can only send commands to one DALI bus(generated from one Single Master Control Device i.e two GPIO pins) at a time, we have to wait for it to complete the DALI_transaction_loop[Forward Frame(Query/Command), Settling_Time and Backward Frame(Response)] and then only we can deal with other buses! am I correct? If it is so, the DALI standard suggests more tight time constraints to decrease the latency in accessing different buses!? \$\endgroup\$
    – charansai
    Dec 20, 2017 at 8:36
  • \$\begingroup\$ and it would be great if you could elaborate on how to "use the addressing system to separately control the gear"? I hope you understand my bad terminology. If required I can provide further clarifications on each of these ideas. Thank you for your time! \$\endgroup\$
    – charansai
    Dec 20, 2017 at 8:44
  • \$\begingroup\$ @charansai Re: grouping devices on different buses - you could easily send the same command simultaneously (within a fraction of a bit time) on multiple buses at once by driving the transmit pins together (sequential commands in your code). Probably best not to do that with queries because you'd have to handle simultaneous responses on different buses which would be tricky. But this is not a concern of the standard which is of course, for one bus. Re: addressing system - gear can be allocated short addresses 0-63 and be members of up to 16 groups. \$\endgroup\$
    – Martin
    Dec 20, 2017 at 12:45
  • 1
    \$\begingroup\$ @charansai I have made this clearer in my edited answer because I needed to include diagrams. Your short address question doesn't really make sense, if you need more help with that please ask it as a separate question. \$\endgroup\$
    – Martin
    Dec 21, 2017 at 10:45

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.