View Single Post
Old June 30th, 2016   #3
Task Group Member
Join Date: Aug 2008
Posts: 369

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?
ericthegeek is offline   Reply With Quote