When you say you "don't have support for that command", what are you doing when you receive it? Are you responding with a NACK/NR_UNKNOWN_PID, or are you just dropping it and not responding at all?
If you're not responding to the GET DEVICE_MODEL_DESCRIPTION, then you're seeing the expected behavior from the DMXter. The DMXter sends the GET, and then waits 3440* microseconds for a response. If it doesn't get a response within the allowed time, then it's considered a lost response. This timeout shows up in the packet history, and the UI shows that the device is "Not responding".
"Timeout", "Lost Response", and "Not responding" are all different names for the same thing: The DMXter didn't get a response when it expected a response.
RDM Responders should respond to every unicast GET or SET request. If for some reason the request can't be handled, you should respond with NACK and the appropriate NACK Reason Code.
I also noticed that your MAB length is rather long. It's supposed to be between 12 and 88us, and you're showing 87 to 89. This is unlikely to cause a problem, but you may want to shorten it a bit. I typically like to see MABs in the 20 to 40 us range.
*3440 is the default, you can change the lost packet timeout in the RDM Flavors menu.
Last edited by ericthegeek; November 25th, 2015 at 10:20 PM.
Reason: Add the word "Unicast" to the fourth paragraph for clarity
|
November 25th, 2015
Similar Threads
Threaded Mode