How should master handle receiving DMX after sending request? - E1.20 RDM (Remote Device Management) Protocol Forums

ericthegeek · June 30th, 2016

In a properly functioning system, that shouldn't happen. But obviously that doesn't help you since it's happening.

What else is in the system besides the controller? What responders, Splitters, etc?

The first test is to figure out what's generating the unexpected data. When you say "short DMX frame", do you mean there's a full, properly formatted NSC packet that happens on the wire before the RDM response? Or is there just some garbage data without a break followed by a Break+RDM response?

Some things to try:
Get out the oscilloscope, and see when the unexpected data is happening. Is it during the 176 microsecond turnaround time (when the line is supposed to be idle between the request and the response), or is it happening during the normal response period.

Using a scope will also help you verify that it's real data on the wire, and not a buffer management/thread synchronization problem in the controller.

Is the garbage data coming from the same responder that you're sent the request to, or from another responder? You might be able to see the difference with a scope by watching the 485 TX amplitude, or you may have to probe the TX-enable signal on the other responders.

Do you disable the controller's RX while you're TX'ing the request? Is it possible that you're reading your own TX data that's sitting in a FIFO somewhere?

Make sure the line bias resistors are installed and active. You might see garbage data if the 485 line is floating while it's waiting for the response.

In my splitters, I include a Jabber detection feature to detect if a port has a device that's transmitting when it's not supposed to, and cutoff that port until it starts behaving. This usually happens when someone has two controllers connected to different ports on the splitter, or when there's a responder that responds too quickly. Is there another controller somewhere in this system that's briefly getting ahold of the 485 line?

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Request Call for New PIDs!	sblair	RDM General Implementation Discussion	0	January 27th, 2014 01:44 PM
RDM Master UID assignment question	berntd	RDM General Implementation Discussion	4	May 30th, 2012 10:14 PM
Master list of RDM Product IDs	pkirkup	RDM General Implementation Discussion	1	July 29th, 2009 10:33 AM
Master Fader accross Rdm implementation Question	berntd	RDM General Implementation Discussion	1	May 9th, 2008 12:12 AM
Request in the middle of ACK_TIMER	endoftheworld	RDM Interpretation Questions	1	July 13th, 2006 10:53 PM

June 30th, 2016	#3
ericthegeek Task Group Member Join Date: Aug 2008 Posts: 390	In a properly functioning system, that shouldn't happen. But obviously that doesn't help you since it's happening. What else is in the system besides the controller? What responders, Splitters, etc? The first test is to figure out what's generating the unexpected data. When you say "short DMX frame", do you mean there's a full, properly formatted NSC packet that happens on the wire before the RDM response? Or is there just some garbage data without a break followed by a Break+RDM response? Some things to try: Get out the oscilloscope, and see when the unexpected data is happening. Is it during the 176 microsecond turnaround time (when the line is supposed to be idle between the request and the response), or is it happening during the normal response period. Using a scope will also help you verify that it's real data on the wire, and not a buffer management/thread synchronization problem in the controller. Is the garbage data coming from the same responder that you're sent the request to, or from another responder? You might be able to see the difference with a scope by watching the 485 TX amplitude, or you may have to probe the TX-enable signal on the other responders. Do you disable the controller's RX while you're TX'ing the request? Is it possible that you're reading your own TX data that's sitting in a FIFO somewhere? Make sure the line bias resistors are installed and active. You might see garbage data if the 485 line is floating while it's waiting for the response. In my splitters, I include a Jabber detection feature to detect if a port has a device that's transmitting when it's not supposed to, and cutoff that port until it starts behaving. This usually happens when someone has two controllers connected to different ports on the splitter, or when there's a responder that responds too quickly. Is there another controller somewhere in this system that's briefly getting ahold of the 485 line?