DALI Communication: Is DALI protocol a byte transfer mechanism or packet layer mechanism?

Question

As per the DALI light-control standard protocol, DALI bus communication uses Asynchronous half-duplex(two-wire) serial communication. It uses Manchester coding at 1200 bits per second(baud). A DALI bus can have up to 64 slave devices in the network.

I am trying to implement DALI protocol on STM32E407 (as Master) and STM32F3Discovery board (as Slave). I am looking for some practical advice on implementing DALI communication.

I have a few basic questions about DALI communication:

Is DALI protocol itself is a byte transfer mechanism or is it a software level packet layer (like CAN)?

If DALI is a packet layer mechanism, which byte-level transfer mechanism will better suits for it?

If it is the popular asynchronous communication protocol UART(or USART), how good is UART(or USART) for multi-processor communication (for around 64 slave devices)?? and at micro-controller level, how much faster the serial interface (UART or USART) should be to "DALI 1200 baud rate" for efficient execution Manchester coding?

Thanks in advance!

Answer 1

DALI describes the physical layer, the protocol and the command set.

It is not really a UART type protocol (unless you had external manchester coding), and the usual way to implement is couple of opto isolators and a transistor plus some passives for the the physical layer (Which must be isolated) a timer or two generating interrupts plus a couple of pins with interrupt on change for the IO.

For transmit you set up a 2400Hz interrupt and generate the biphase in software in the ISR.

For receive you use the interrupt on change and a timer to write a simple state machine to extract the 24 bit (IIRC) messages).

The gotcha with DALI is the need for a random number generator for the auto discovery stuff, finding sufficient entropy in a device with no user IO can be a bit of a pain.

Note also that to be DALI compliant you need to hit the dimming curve for your luminare type fairly closely, and DALI uses a log curve (Unlike DMX).

Answer 2

DALI messages are commands (eg Off, Go To Scene 3), configuration commands (eg Set Min Level), queries (eg Query Min Level) or responses (eg Yes). Some commands, mainly the configuration commands, require bytes to be transferred because the message is too small to contain the command, addressing and data. So to set a min level, you have to transfer the required value to the DTR0 of the gear before you issue the Set Min Level command, and you have to send the Set Min Level command twice within 100ms. You can also read back the DTR0 value, and other DTR values (DTR1, DTR2).

It is not practical to use standard UARTs to transmit or receive DALI because of the Manchester coding and the bit and frame timing requirements.

Efficiency of bandwidth with 64 control gears is achieved by using group addressing. If you are interested in multiple masters, then you would need to implement the multimaster timing including collision detection, avoidance and recovery as specified in IEC 62386-103.

Answer 3

DALI is an extremely simple two byte (16-bit) per message protocol , that is also quite complex and clever in its implementation. The master sends out messages over the network that all nodes receive and process (or ignore). Slaves can, but do not always, send [8-bit] replies back to the master.

You will quite happily be able to implement master and slave with your two devices, but you will need to make little hardware adapter boards as "transceivers" and a bus supply. There are lots of examples around. Atmel, Microchip and NXP all have very useful apps notes on this. An example of a transceiver that you need on each node is below.

You could definitely implement much faster comms with a UART and could do 64 nodes per network with no problem using RS485 and some protocol run upon it. However, speed is not the point here. Noise immunity and ease of wiring (including very flexible topology) are paramount - you can connect the wiring either way round with DALI. Something that is definitely not the case with RS485.

You cannot do Manchester encoding and decoding with UARTs, but it is fairly straightforward to bit bash it with a couple of GPIO pins.