E1.20 RDM (Remote Device Management) Protocol Forums  

Go Back   E1.20 RDM (Remote Device Management) Protocol Forums > RDM Developer Forums > RDMnet (BSR E1.33) Draft Standard General Discussion

RDMnet (BSR E1.33) Draft Standard General Discussion General Discussion and questions concerning the draft E1.33 standard.

Reply
 
Thread Tools Search this Thread Display Modes
Old January 16th, 2012   #1
SeanSill
Task Group Member
 
Join Date: Aug 2011
Location: Lancaster, PA
Posts: 25
Default E1.31 Gateway with multiple inputs

On a gateway with multiple inputs is it allowed to have multiple inputs set to the same universe?

What would be the correct way to deal with this as I see no mention of this in the E1.31 standard. I had planned on dealing with it by giving the inputs a new CID, would this be acceptable?
SeanSill is offline   Reply With Quote
Old January 17th, 2012   #2
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 353
Default

Quote:
Originally Posted by SeanSill View Post
On a gateway with multiple inputs is it allowed to have multiple inputs set to the same universe?
This is probably not a good idea. If you need to support multiple inputs, your safest options is to have the node merge the two inputs into a single universe internally (using HTP or whatever scheme the user configures) and send that out on the universe.

Quote:
Originally Posted by SeanSill View Post
I had planned on dealing with it by giving the inputs a new CID, would this be acceptable?
I suspect this would cause problems for some receivers. There's no guarantee if receivers will track sources as CID:Universe or IP:Universe.

If you need to support this, I would suggest using a new CID and a new IP for the second input. This will make it appear to the receiver as an entirely separate network node.
ericthegeek is offline   Reply With Quote
Old January 17th, 2012   #3
SeanSill
Task Group Member
 
Join Date: Aug 2011
Location: Lancaster, PA
Posts: 25
Default

Its interesting that the standard doesn't specifically say to track by CID it seems its the only reliable way of tracking sources. I understand someone just wanting to throw away the 128 bits, but especially with RDMNet around the corner the probability of having multiple CIDs per IP seems extremely likely.
SeanSill is offline   Reply With Quote
Old September 14th, 2012   #4
Richard
Junior Member
 
Join Date: Sep 2012
Posts: 1
Default

Quote:
Originally Posted by SeanSill View Post
Its interesting that the standard doesn't specifically say to track by CID it seems its the only reliable way of tracking sources. I understand someone just wanting to throw away the 128 bits, but especially with RDMNet around the corner the probability of having multiple CIDs per IP seems extremely likely.
The E1.31 standard does actually say to use the CID in section 6.4 Priority:
Quote:
6.4 Priority
A receiver conforming to this standard may receive data for the same universe from multiple sources that may be distinguished by examining the CID in the packet. (This is a situation that cannot occur in conventional DMX systems.)
Multiple CIDs on the same IP address is already happening, for example the open-source sACNView application uses a different CID for each "Source" MDI window that's opened.

As for the original situation of multiple DMX inputs on the same universe, I can see merit in both approaches.

Merging inside the box to produce a single E1.31 output allows it to be used with receiver devices that don't support multiple sources at the same priority, while transmitting each input port with its own CID allows more 'advanced' receivers to do their own arbitration between the ports on your box - and is likely to be easier to implement, which is always a bonus!

That said, I would recommend doing the merge inside your box if possible, as there are a lot of E1.31 receiving devices out there with limited memory that can only merge one or two sources, and I don't know of any that currently allow selection of source by CID and/or transmitter name.

Merging inside the box also lets you offer multiple merge methods to your end users as a value-add, should you wish to do so. (eg selecting specific channels from input X and input Y regardless of their levels.)
Richard is offline   Reply With Quote
Old September 14th, 2012   #5
SeanSill
Task Group Member
 
Join Date: Aug 2011
Location: Lancaster, PA
Posts: 25
Default

Thanks Richard! Different CIDs per port was appealing but I ended up merging within the unit and sending that as a single packet for mainly the reasons you and Eric were stating.
SeanSill 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
Responders with multiple Responder Ports in a single Device. swisson RDM Interpretation Questions 8 February 17th, 2011 10:41 AM


All times are GMT -6. The time now is 10:43 AM.


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