Receiving other DALI traffic

[sde1000]

At the moment daliserver sends network messages when it receives information about 16-bit forward frames observed on the bus from the DALI USB device (packets starting 0x11 0x73), but doesn't send any information about backward frames.

The DALI USB device does also report backward frames it observes, in packets starting 0x11 0x72:

      9 227.191712     1.10.1      host        117300000000ffff00 Received DAPC(0) for A0
     11 273.176066     1.10.1      host        117300000080ffff00 Received DAPC(0x80) for A0
     13 327.736250     1.10.1      host        117300000280ffff00 Received DAPC(0x80) for A1
     15 329.848232     1.10.1      host        117300000280622c00 Received DAPC(0x80) for A1
     17 332.344191     1.10.1      host        117300000200744a00 Received DAPC(0) for A1
     19 439.993644     1.10.1      host        1173000003a0ffff00 Received QUERY ACTUAL LEVEL for A1
     21 440.005665     1.10.1      host        117200000000003e00 Received reply 0
     39 527.888602     host        1.10.2      120100030000ff0600 Send broadcast RECALL MIN LEVEL
     41 527.906402     1.10.1      host        12730000ff06ffff01 ... transmission report
     43 527.917386     1.10.1      host        127100000000008a01 ... no response
     45 561.337931     1.10.1      host        1173000003a0ffff00 Received QUERY ACTUAL LEVEL for A1
     47 561.350888     1.10.1      host        117200000001003d00 Received reply 0x01
     49 613.562179     1.10.1      host        1173000003a0ffff00 Received QUERY ACTUAL LEVEL for A1
     51 613.575177     1.10.1      host        117200000001003e00 Received reply 0x01
     53 640.250805     1.10.1      host        1173000005a0ffff00 Received QUERY ACTUAL LEVEL for A2
     55 640.265802     1.10.1      host        117200000055005c00 Received reply 0x55
     57 657.082566     1.10.1      host        1173000005a0ffff00 Received QUERY ACTUAL LEVEL for A2
     59 657.097562     1.10.1      host        117200000055005b00 Received reply 0x55
     69 1118.068048    host        1.10.2      120200030000ff0000 Send broadcast OFF
     71 1118.085960    1.10.1      host        12730000ff00ffff02 ... transmission report
     73 1118.096959    1.10.1      host        127100000000008a02 ... no response
     75 1118.393445    host        1.10.2      120300030000ff0000 Send broadcast OFF
     77 1118.411935    1.10.1      host        12730000ff000e9703 ... transmission report
     79 1118.422954    1.10.1      host        127100000000008a03 ... no response
    105 3158.917796    1.10.1      host        117700000005ffff00 DSI mode (briefly shorting the bus)
    107 3159.023810    1.10.1      host        117700000006006100 DALI mode
    109 3159.553784    1.10.1      host        11770000000518b900 DSI mode
    111 3159.683781    1.10.1      host        117700000006006100 DALI mode
    113 3182.744513    1.10.1      host        117700000005ffff00 DSI mode
    115 3182.836474    1.10.1      host        117700000006006100 DALI mode
    117 3182.915486    1.10.1      host        11770000000503a900 DSI mode
    119 3183.028523    1.10.1      host        117700000006006100 DALI mode

Notice what's happening in bytes 6–7 of the responses. Most of the forward frames have 0xffff here, but some of them don't (eg. 0x622c in packet 15). Most of the response frames have low numbers here; in particular, "no response" always has 0x008a, and "response" always has a number below 0x008a (eg. 0x003d or 0x003e for A1, 0x005c or 0x005b for A2).

I believe this field represents the length of time since the previous bus activity, in units of 100µs; 0x8a translates to 13.8ms. Table 20 of IEC62386-101 states that the minimum settling time between forward frame and backward frame for a frame not to be interpreted as a backward frame is 13.4ms. I'm not sure exactly when it starts counting; it could be allowing a half-bit time (400µs) with no transition to recognise that the transmitter has stopped.

Let's check by having a look at the transmission reports during a transaction (see issue #22):

      9 3.950105       host        1.10.2      125530030000ff2c55 DTR0=0x55 followed by SET SYSTEM FAILURE LEVEL (DTR0) (twice)
     11 3.967897       1.10.1      host        12730000a355ffff55 ... A355 (DTR0=0x55) transmission report 
     13 3.993899       1.10.1      host        12730000ff2c009155 ... FF2C (SET SYSTEM FAILURE LEVEL) transmission report
     15 4.020910       1.10.1      host        12730000ff2c009155 ... FF2C (SET SYSTEM FAILURE LEVEL) transmission report (again)
     17 4.030894       1.10.1      host        127100000000008a55 ... no response

0x0091 is 14.5ms. Table 17 of IEC62386-101 gives the minimum settling time between send-twice forward frames as 13.5ms and the maximum as 75.0ms, so 0x0091 is comfortably within this range.

What about the times observed for backward responses from the two DALI devices I've been experimenting with? A1 in the above examples is a LTECH LED driver, A2 is a Tridonic EM powerLED PRO DIM C. 0x003d is 6.1ms, 0x5b is 9.1ms. Table 17 gives the minimum settling time between a forward frame and the start of transmission of a backward frame as 5.5ms and the maximum time as 10.5, so both times are within the range.

I don't know what the DALI USB does when it observes an 8-bit frame that does not start within 13.4ms of the end of a forward frame; I don't have any equipment that will generate one to test! It might do nothing, or it might send a type 0x72 packet. To be on the safe side, we should probably check that the time field is less than 0x8a for all packets of type 0x72.

[sde1000]

Huh. I've been writing a new driver for the DALI USB that also does its best to reconstruct commands and responses that it sees on the bus.

In some circumstances, the DALI USB can report traffic it observes on the bus in packets that start with 0x12. It does this when the frame is the same as the last frame the DALI USB transmitted itself; it uses the sequence number from its transmission, and it also sends a type 0x71 or 0x72 packet depending on the observed backward frame.

That's got to be a firmware bug! The firmware in my DALI USB is version 1.10. I'm going to deal with it by ignoring these packets because their sequence number doesn't match an outstanding transmission, and treating them as if they started with 0x11 instead.

(The test rig I'm using for this has a DALI USB and a hasseb DALI interface on the same bus; I'm sending with the hasseb and listening with the DALI USB. I had previously used the DALI USB to send the same test pattern; it must be remembering the last thing it sent and matching against it.)

[onitake]

I think I've seen what you mentioned, but it's been a while, and I didn't investigate further because I was happy with sending commands and receiving responses.

At some point, I also thought the DALIUSB's quirks aren't worth the effort, and it might even be better to just build some open hardware thingamajing instead...

[sde1000]

You are probably right. I did a small project in kicad recently that worked ok, perhaps I should have a go at a USB device or a Raspberry Pi HAT.

[onitake]

This will surely help: http://ww1.microchip.com/downloads/en/appnotes/01465a.pdf