E1.20 RDM (Remote Device Management) Protocol Forums  

Go Back   E1.20 RDM (Remote Device Management) Protocol Forums > RDM Developer Forums > RDM General Implementation Discussion

RDM General Implementation Discussion General Discussion and questions relating to implementing RDM in a product.

Reply
 
Thread Tools Search this Thread Display Modes
Old June 29th, 2016   #1
berntd
Senior Member
 
Join Date: Jan 2008
Posts: 102
Default 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
berntd is offline   Reply With Quote
Old June 30th, 2016   #2
sblair
Administrator
 
Join Date: Feb 2006
Posts: 438
Send a message via AIM to sblair Send a message via MSN to sblair
Default

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.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old June 30th, 2016   #3
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 379
Default

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
Old June 30th, 2016   #4
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 379
Default

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.
ericthegeek is offline   Reply With Quote
Old June 30th, 2016   #5
berntd
Senior Member
 
Join Date: Jan 2008
Posts: 102
Default

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
berntd is offline   Reply With Quote
Old June 30th, 2016   #6
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 379
Default

Quote:
Originally Posted by berntd View Post
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 View Post
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...
ericthegeek is offline   Reply With Quote
Reply

Bookmarks

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

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


All times are GMT -6. The time now is 11:35 AM.


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