Personal tools
The Open Lighting Project has moved!

We've launched our new site at www.openlighting.org. This wiki will remain and be updated with more technical information.

ArtNet, RDM and Packet Interleaving

From wiki.openlighting.org

Revision as of 13:44, 6 September 2010 by 66.92.11.32 (talk) (Send a single RDM command at once)
Jump to: navigation, search

RDM over Artnet

ArtNet nodes behave as pass-through devices for non-discovery RDM data. The normal sequence of RDM commands looks like this:


ArtNetRDMSequence.png


The Potential Problem

The problem occurs when the RDM device responds with an ACK_OVERFLOW message. From the standard:

To receive the remaining data, the controller should continue to send GET_COMMANDS for the same PID. The responder shall send subsequent blocks of data with a response type of RESPONSE_TYPE_ACK_OVERFLOW until the remaining data can fit in a single message. The responder shall set the response type to RESPONSE_TYPE_ACK on the final response message in the sequence, to indicate completion of the data transfer.

Assuming that PID A causes an ACK_OVERFLOW, the sequence now looks like this:

ArtNetRDMOverflowSequence.png

But the standard also states:

The responder shall abort a partial transfer of overflow data for a PID when receiving a command for a different PID before the overflow data transfer is complete. A subsequent command for the overflow PID will result in a new data transfer starting at the beginning of the data set.

So any RDM packet interleaved between the two GET PID A' commands in the above example will cause the transfer to abort.

ArtNetRDMOverflowResetSequence.png

Note: The Labpack has a bug where it will not abort the transfer so this continues to work. This is present in version 0x20009


Possible Solutions

There are two cases i) the single controller case ii) the multi-controller case. Nothing in the existing protocol can solve the latter, so it's out of scope for the rest of the discussion.

Send a single RDM command at once

This is obviously the most reliable but has the drawback of requiring a full round trip between the controller and responder for each message. Testing with a Net-Lynx showed an average response time of 7ms as seen on the controller when the RTT was 1.3ms. This solution also has the desirable property of not over-running the ArtNet node's buffers. Obviously the controller needs a timeout to detect dropped packets and either re-transmit or move on to the next packet.

Send multiple packets at once without waiting for a response

This appears to be what DMX Workshop does and has the potential to break ack_overflow sequences.

Send multiple packets at once and back off when an ACK_OVERFLOW is received

Similar to the above, this sends multiple packets at once but stops sending other packets when an ACK_OVERFLOW is received until the sequence completes (or a timeout occurs). This reduces the chance of an aborted transfer, but doesn't eliminate it.

Send multiple packets at once, serialize commands expected to generate ACK_OVERFLOWS and back off when an ACK_OVERFLOW is received

Of the PIDs described in E1.20, the following have the potential to generate an ACK_OVERFLOW:

  • PROXIED_DEVICES
  • STATUS_MESSAGES
  • SUPPORTED_PARAMETERS
  • LANGUAGE_CAPABILITIES
  • SLOT_INFO
  • DEFAULT_SLOT_VALUE

When the Controller sends any of these PIDs it can wait to see if an ACK_OVERFLOW occurs before sending any other RDM commands. Of course this doesn't solve the problem for manufacturer specific PIDs, instead it relies on the back off mechanism above.

References