E1.20 RDM (Remote Device Management) Protocol Forums

E1.20 RDM (Remote Device Management) Protocol Forums (http://www.rdmprotocol.org/forums/index.php)
-   RDM General Implementation Discussion (http://www.rdmprotocol.org/forums/forumdisplay.php?f=4)
-   -   How should master handle receiving DMX after sending request? (http://www.rdmprotocol.org/forums/showthread.php?t=1249)

berntd June 29th, 2016 07:30 PM

How should master handle receiving DMX after sending request?
 
Hello

We have just come across this and wonder how to handle it.

Master sends a request and waits the prescribed period for a response.

However, somethng else on the line sends a short DMX frame, possibly rubbish.
Just thereafter, the correct RDM response follows, all still in the correct waiting time for a reply.

How should the master interpret / handle this?

Regards
Bernt

sblair June 30th, 2016 12:27 AM

Do you know where the other data is coming from? Solving that would be my first priority. You basically have 2 options in how to handle this. You can either just reject the response and send the request again. Or, if the timing is right and you can get a clean response out that you can parse and passes the checksum then you could accept the response. Of course if you are trying to parse it you definitely want to verify the checksum and bounds check the other fields to make sure they appear valid.

ericthegeek June 30th, 2016 11:32 AM

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 June 30th, 2016 11:48 AM

To answer your specific question:

In my controllers, I allow:

1: Break followed by a proper RDM Response
2: Multiple breaks followed by a proper RDM Response
3: Data Bytes, followed by one or more breaks, followed by a proper RDM Response

I do not support:
4: Break -> Non RDM Data -> Break -> Proper RDM Response
5: Proper RDM Response without a break

Conditions 4 and 5 will ignore the response, retry a few times, and then give up and log an error.

berntd June 30th, 2016 03:50 PM

Thanks everyone.

It is more of a question as to how to handle it and not as much as finding an actual cause. IU was not able to find out in the spec of what shoudl happen in such a case.

However, there are certain fixtures out there that when they loose the DMX input signal (for example if the line goes quiet, like waiting for RDM activity), they start sending DMX like packets. I am not sure what they are but our programmers have encountered them before and now that we are developing a new RDM driver, we want to be sure on how to deal with stuff like that.


Regards
Bernt

ericthegeek June 30th, 2016 08:59 PM

Quote:

Originally Posted by berntd (Post 3030)
IU was not able to find out in the spec of what shoudl happen in such a case.

The standard tells you what you should do when things are working properly. For the most part though, it doesn't tell you what to do when there are errors or faults. That's up to you.

Quote:

Originally Posted by berntd (Post 3030)
However, there are certain fixtures out there that when they loose the DMX input signal (for example if the line goes quiet, like waiting for RDM activity), they start sending DMX like packets.

Yes, some poorly implemented fixtures try to automatically start a master/slave mode when there's no DMX. This lets a string of lights flash and change color in coordination with each other when there's no controller. A proper DMX implementation shouldn't start this this automatically, but there is equipment out there that does it.

Realistically, if there's a device on the '485 wire that is talking when it's not supposed to, it's not going to be polite and only talk between RDM packets. It's going to talk whenever it feels like it. This will almost certainly create contention on the 485 bus that will not make sense to any receiving UARTs. If you detect this, your best bet may be to notify the user that something is talking when it shouldn't, and give up. Then check the line every 10 seconds or so to see if the offending device has been removed.

You might get lucky, for example, if you have a strong 5V line driver, and the jabbering device has a weak 3.3V driver. Then you might be able to overdrive it. But in most cases you'll just end up with oddly flashing lights and upset users...


All times are GMT -6. The time now is 08:56 PM.

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2019, vBulletin Solutions, Inc.