View Single Post
Old November 26th, 2015   #11
Task Group Member
Join Date: Aug 2008
Posts: 362

Originally Posted by dj41354 View Post
Yeah, I was ignoring it... The fact that I need to respond to every unicast GET or SET was not understood. Thank you for that nugget... I'm getting there (slowly).
Good, glad you found the problem. It sounds like you're making good progress in the implementation.

When to respond or not respond is a bit more complicated then you might expect. Here's an overview:

Discovery Command Class - Discover Unique Branch:
Respond iff all of the following requirements are met:
  • You are unmuted
  • The packet is properly formed (valid checksum, correct PDL length, etc.)
  • You are within the requested discovery range given in the upper and lower bounds
  • The packet destination address is to you (this means Broadcast, a Vendorcast to your MFGID, or a unicast to your UID)

Otherwise, don't respond.

Discovery Command Class - Mute/Unmute:
Respond with an ACK iff the request is a valid request and unicast to you.

Do not respond if the request is a Broadcast or Vendorcast
Do not respond if the request is corrupt or malformed.

Note 1: Due to a quirk in how the standard is written, you are not allowed to NACK a discovery command class request. This means if you get a corrupt or invalid discovery request the only thing you can do is ignore the request and not respond. However, many responders will NACK an invalid discovery command class request. While this is technically not allowed, it's a common behavior and will not cause problems most real-world systems.

Discovery Command Class - Unknown PID:
Do not respond (see Note 1 above)

Get/Set Command Class:
Respond with ACK, ACK_TIMER, ACK_OVERFLOW, or NACK as appropriate iff the request is unicast to your UID.

Do not respond if the request is a Broadcast or Vendorcast

Unknown Command Class:
The standard is not clear what you should do in this case.

One interpretation is that you should ignore the request and not respond. Another interpretation is that you should NACK with an appropriate Reason Code.

The DMXter's "Specific Tests" menu can help you work through the various corner cases. I believe the automated test suites also cover many of these conditions.

If you run into more questions, feel free to post them here. Supporting RDM developers is the reason this forums exists. Everyone benefits when new implementations are done well...

Last edited by ericthegeek; November 26th, 2015 at 11:19 PM. Reason: Spelling
ericthegeek is offline   Reply With Quote