DMXter4 says "not responding"

[dj41354]

Hi..
1st post. (sorry if I'm a little dense..)
I don't quite understand what the DMXter4 is trying to tell me..
I am responding.. but it reports "not responding" to two different requests..

This 1st one is a SET_IDENTIFY_DEVICE (I think): (it does make me flash)

CAPTURED PACKET
SC SS LEN ------DEST------ -------SRC------- TN PR MC SUBDV CC PID- PDL DATA----
REQUEST
CC 01 19 3A FC 00 00 00 00 47 44 00 41 44 83 0A 01 00 00 00 30 10 00 01 01 03 FC
RESPONSE
CC 01 18 47 44 00 41 44 83 3A FC 00 00 00 00 0A 00 00 00 00 31 10 00 00 03 F9
--AT END OF LIST--


This is a GET_DEVICE_INFO:

CAPTURED PACKET
SC SS LEN ------DEST------ -------SRC------- TN PR MC SUBDV CC PID- PDL DATA----
REQUEST
CC 01 18 3A FC 00 00 00 00 47 44 00 41 44 83 07 01 00 00 00 20 00 60 00 04 36
RESPONSE
CC 01 2B 47 44 00 41 44 83 3A FC 00 00 00 00 07 00 00 00 00 21 00 60 13 01 00 04 00 01 01 52 34 2E 30 04 00 01 00 00 01 00 00 00 05 4D
--AT END OF LIST--

The timing looks pretty good on these on a logic analyzer too..
Where is my mistake that's making the DMXter4 unhappy with these responses and report on the LCD (NOT RESPONDING)

Thank you in advance..
Doug.

[dj41354]

Had a quick conversation with Bob Goddard. He suggested I build a custom packet (an easy one like GET_DMX_START_ADDRESS) and then get the timing information..
I had a little trouble getting it.. but think I finally was successful..

RESPONDER TIMING MIN PRV MAX
RESPONSE DELAY IN us 178 178 178
BREAK LENGTH IN us 256 258 258
MAB LENGTH IN us 87 87 89
INTERSLOT TIME IN us 40 45
TOTAL LENGTH IN us 2541 4179 4179
DISC. FIRST ACTIVITY (EMPTY)
DISC. LAST ACTIVITY (EMPTY)
UNICAST 5 / 9
DISCOVER 0 / 0
UNICAST RETRY COUNT 0
NOISE BEFORE BREAK 0
NSC PACKET COUNT 2686

When I did this (build a custom packet) it seemed happy with the response.
On my logic analyzer, I'm like 180usec from the last stop bit (of the controller) to my responder asserting the leading edge of the break.
Is there some kind of weirdness when not using BUILD CUSTOM PACKET that is causing me an issue?
Thanks..
Doug.

[ericthegeek]

Can you post more details about what you're experiencing? After you've experienced the "Not Responding", press the "RED" key, and choose the "Send Info to USB" option from the menu. This will dump the packet history, timing details, and give a lot more info on what's happening.

Typically, if you're experiencing timeouts when using the "Select Current Device" option, it's because the responder is taking too long to handle broadcast responses. Normally, when the responder receives a request, it can take up to 2ms to process the request, and then respond when it's ready. But with broadcast requests, the controller can start sending the next break as soon as 176us following the end of the broadcast. If the responder is still busy processing the broadcast, it will miss the next packet.

You can test if this is the case by inserting extra time between packets. Go to "Transmit DMX" and edit user flavor A (or B or C) to have the following parameters:

200us Break
25us MAB
512 Slots
20us inter-slot time
and a long Mark Before Break (try 5000us)

Then in the "RDM Flavors" menu select "User A" and try again. Does it start working? Remember to switch back to normal flavor when you're done.


Full Disclosure: I have worked for Goddard Design

[dj41354]

1)From the "MAIN MENU" choices, I pushed <DOWN> to get to "MAIN MENU-RDM CONTROLLER" , pushed <YES/Q>
2)From the "RDM CONTROLLER" choices, I pushed <DOWN> to get to "SELECT CURRENT DEV?", pushed <YES/Q>
3)My responder starts flashing it's lights and DMXter shows:
3AFC:00000000 ":."
(NOT RESPONDING)
4) From the "NOT RESPONDING" screen I pushed the <YES/Q> key
(I have to push <YES/Q> from here to get the <RED> key to work.. it doesn't work otherwise)
5) From the "RDM CONTROLLER" choices, I pushed the <RED> key to get "SHORTCUTS"
6) From the "SHORTCUTS" choices I pushed <DOWN> to get "SEND INFO TO USB"
7) Using TeraTerm 4.47 this is what was sent:
PACKET HISTORY
TIME TN CC NAME RESULT CC PID PDL CC PID PDL RTY RQ
22.41 00h SET IDENTIFY DEV BROADCAST 30h 1000h 01h
* 22.48 01h SET IDENTIFY DEV GOOD RESPONSE 30h 1000h 01h 31h 1000h 00h 00h
22.55 02h GET DEV MODEL DESCR RESPONSE TIMED OUT 20h 0080h 00h
34.74 03h SET IDENTIFY DEV BROADCAST 30h 1000h 01h
* 34.82 04h SET IDENTIFY DEV GOOD RESPONSE 30h 1000h 01h 31h 1000h 00h 00h
34.89 05h GET DEV MODEL DESCR RESPONSE TIMED OUT 20h 0080h 00h
36.80 06h SET IDENTIFY DEV BROADCAST 30h 1000h 01h
* 36.88 07h SET IDENTIFY DEV GOOD RESPONSE 30h 1000h 01h 31h 1000h 00h 00h
36.95 08h GET DEV MODEL DESCR RESPONSE TIMED OUT 20h 0080h 00h
37.99 09h SET IDENTIFY DEV BROADCAST 30h 1000h 01h
* 38.06 0Ah SET IDENTIFY DEV GOOD RESPONSE 30h 1000h 01h 31h 1000h 00h 00h
38.13 0Bh GET DEV MODEL DESCR RESPONSE TIMED OUT 20h 0080h 00h
38.64 0Ch SET IDENTIFY DEV BROADCAST 30h 1000h 01h
38.71 0Dh SET IDENTIFY DEV RESPONSE TIMED OUT 30h 1000h 01h
38.78 0Eh GET DEV MODEL DESCR RESPONSE TIMED OUT 20h 0080h 00h
39.52 0Fh SET IDENTIFY DEV BROADCAST 30h 1000h 01h
* 39.60 10h SET IDENTIFY DEV GOOD RESPONSE 30h 1000h 01h 31h 1000h 00h 00h
39.67 11h GET DEV MODEL DESCR RESPONSE TIMED OUT 20h 0080h 00h
40.00 12h SET IDENTIFY DEV BROADCAST 30h 1000h 01h
* 40.08 13h SET IDENTIFY DEV GOOD RESPONSE 30h 1000h 01h 31h 1000h 00h 00h
40.15 14h GET DEV MODEL DESCR RESPONSE TIMED OUT 20h 0080h 00h
41.33 15h SET IDENTIFY DEV BROADCAST 30h 1000h 01h
* 41.40 16h GET DEVICE INFO GOOD RESPONSE 20h 0060h 00h 21h 0060h 13h 00h 01h 00h...
--AT END OF LIST--

CAPTURED PACKET
SC SS LEN ------DEST------ -------SRC------- TN PR MC SUBDV CC PID- PDL DATA----
REQUEST
CC 01 18 3A FC 00 00 00 00 47 44 00 41 44 83 16 01 00 00 00 20 00 60 00 04 45
RESPONSE
CC 01 2B 47 44 00 41 44 83 3A FC 00 00 00 00 16 00 00 00 00 21 00 60 13 01 00 04 00 01 01 52 34 2E 30 04 00 01 00 00 01 00 00 00 05 5C
--AT END OF LIST--

PREVIOUS PACKET
SC SS LEN ------DEST------ -------SRC------- TN PR MC SUBDV CC PID- PDL DATA----
REQUEST
CC 01 18 3A FC 00 00 00 00 47 44 00 41 44 83 16 01 00 00 00 20 00 60 00 04 45
RESPONSE
CC 01 2B 47 44 00 41 44 83 3A FC 00 00 00 00 16 00 00 00 00 21 00 60 13 01 00 04 00 01 01 52 34 2E 30 04 00 01 00 00 01 00 00 00 05 5C
--AT END OF LIST--

RESPONDER TIMING MIN PRV MAX
RESPONSE DELAY IN us 178 178 178
BREAK LENGTH IN us 256 258 258
MAB LENGTH IN us 87 87 90
INTERSLOT TIME IN us 40 45
TOTAL LENGTH IN us 2541 4179 4179
DISC. FIRST ACTIVITY (EMPTY)
DISC. LAST ACTIVITY (EMPTY)
UNICAST 7 / 15
DISCOVER 0 / 0
UNICAST RETRY COUNT 0
NOISE BEFORE BREAK 0
NSC PACKET COUNT 1447

I wanted to get this information off while it was fresh in my mind.. I'll be trying the other suggestions also. Thanks for your help with this.
Doug.

[dj41354]

I'm having trouble setting up & getting FLAVORS to work for me. I thought I had finally done it, but my logic analyzer is showing that I haven't implemented the settings you indicated I use (and that I thought I implemented)... I'll continue to try and get FLAVORS to work.. Thanks again..
Doug.

[dj41354]

I think I may have uncovered what might be "part" of the problem (all of it maybe?)..
I'm not "implementing" (executing) broadcast commands other than discovery commands. It looks like the DMXter is sending broadcast SET_IDENTIFY_DEVICE commands according to that USB data dump. I'll change to code so that I "execute" these broadcast commands (and will continue to not respond to them)... maybe that will help..

[ericthegeek]

For troubleshooting, you can also turn off the "Identify on Select" option in the RDM Setup menu, this will reduce the number of packets sent when you're browsing the list of discovered devices. You can also disable Null Startcode interleave.

The "Advanced RDM", "Specific Tests", "Fast Broadcast Sequence" test can be helpful for troubleshooting broadcast handling problems.

[dj41354]

I think I made some progress.. the USB data dump is showing fewer time outs..
But it is showing a time out on a GET_DEVICE_MODEL_DESCRIPTION ?
I don't have support for that command.. could this timeout be why the DMXter is still saying (NOT RESPONDING)?

PACKET HISTORY
TIME TN CC NAME RESULT CC PID PDL CC PID PDL RTY RQ
14.93 00h SET IDENTIFY DEV BROADCAST 30h 1000h 01h
* 15.02 01h SET IDENTIFY DEV GOOD RESPONSE 30h 1000h 01h 31h 1000h 00h 00h
15.10 02h GET DEV MODEL DESCR RESPONSE TIMED OUT 20h 0080h 00h
48.07 03h SET IDENTIFY DEV BROADCAST 30h 1000h 01h
* 48.16 04h GET DEVICE INFO GOOD RESPONSE 20h 0060h 00h 21h 0060h 13h 00h 01h 00h...
* 50.50 05h GET DEVICE INFO GOOD RESPONSE 20h 0060h 00h 21h 0060h 13h 00h 01h 00h...
50.59 06h GET DEV MODEL DESCR RESPONSE TIMED OUT 20h 0080h 00h
--AT END OF LIST--

CAPTURED PACKET
SC SS LEN ------DEST------ -------SRC------- TN PR MC SUBDV CC PID- PDL DATA----
REQUEST
CC 01 18 3A FC 00 00 00 01 47 44 00 41 44 83 05 01 00 00 00 20 00 60 00 04 35
RESPONSE
CC 01 2B 47 44 00 41 44 83 3A FC 00 00 00 01 05 00 00 00 00 21 00 60 13 01 00 04 00 01 01 52 34 2E 30 04 00 01 00 00 01 00 00 00 05 4C
--AT END OF LIST--

PREVIOUS PACKET
SC SS LEN ------DEST------ -------SRC------- TN PR MC SUBDV CC PID- PDL DATA----
REQUEST
CC 01 18 3A FC 00 00 00 01 47 44 00 41 44 83 06 01 00 00 00 20 00 80 00 04 56
RESPONSE

--AT END OF LIST--

RESPONDER TIMING MIN PRV MAX
RESPONSE DELAY IN us 178 178 178
BREAK LENGTH IN us 255 258 258
MAB LENGTH IN us 87 87 89
INTERSLOT TIME IN us 40 45
TOTAL LENGTH IN us 2544 4179 4179
DISC. FIRST ACTIVITY (EMPTY)
DISC. LAST ACTIVITY (EMPTY)
UNICAST 3 / 5
DISCOVER 0 / 0
UNICAST RETRY COUNT 0
NOISE BEFORE BREAK 0
NSC PACKET COUNT 1558

[ericthegeek]

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.

[dj41354]

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).

[ericthegeek]

Originally Posted by dj41354

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...

[dj41354]

Thank you for that Eric.. that clarified the responding rules considerably. I was able to fix a couple of other areas thanks to that summary.