Control/Dimming who uses RDM?

hey, guys. I'm wondering who uses RDM and what console do you use? I've never used it and I've never seen it used on a gig. can someone explain to me how it actually works and what consoles/fixtures support it?
 
hey, guys. I'm wondering who uses RDM and what console do you use? I've never used it and I've never seen it used on a gig. can someone explain to me how it actually works and what consoles/fixtures support it?
I do believe it works fundamentally the same way, but with UIDs. Data comes to the board from the secondary pair of data pins. And the data to the fixtures are over the primary pair of data pins with a different start code. Data collisions are avoided by having the console start communicating per device. (There console will request data from fixture z, but only fixture z can respond because that was the fixture being requested.) This means that data can't be pushed from fixtures to the console. Googling more about it will yield some results.

www.rdmprotocol.org is a good site with information.
 
Data comes on the same pair of wires that The DMX is sent on, in the interpacket gap. So fixtures that don't conform to the DMX standard can misread the RDM data as another DMX packet and act up.
 
  • Like
Reactions: Ric
Data comes to the board from the secondary pair of data pins.
There was at least one very early protocol that used the second pair in this manner, but I believe it was a proprietary thing and is no longer around. RDM communication is done on the first pair, as @sk8rsdad said. The RDM data is requested using a different set of start codes.
 
There was at least one very early protocol that used the second pair in this manner, but I believe it was a proprietary thing and is no longer around. RDM communication is done on the first pair, as @sk8rsdad said. The RDM data is requested using a different set of start codes.

Good Morning!

Gordon Pearlman promoted the full duplex concept at Entertainment Technology. His method was absolutely the right way to go. The industry saw things differently and so the half-duplex standard got codified and so that is what we have to work with today. That is very regrettable (my personal opinion) because there is so much more that could have been done - and that designers and users are asking for these days - with RDM, and half duplex interpacket can't take us there.

Have a great day!

Van Rommel
Director Business Development
Pathway Connectivity
 
Good Morning!

Gordon Pearlman promoted the full duplex concept at Entertainment Technology. His method was absolutely the right way to go. The industry saw things differently and so the half-duplex standard got codified and so that is what we have to work with today. That is very regrettable (my personal opinion) because there is so much more that could have been done - and that designers and users are asking for these days - with RDM, and half duplex interpacket can't take us there.

Have a great day!

Van Rommel
Director Business Development
Pathway Connectivity

ACN is the answer to that. But don't get me started on the entertainment technology industry's standards development.
 
ACN is the answer to that. But don't get me started on the entertainment technology industry's standards development.

Hi Bill:

Good Evening!

Yes, that is undoubtedly true. What we are seeing is an increasing "demand" for RDM (or something like that) to provide real time streaming feedback on PIDS in multiple attribute luminaires and relays and other end devices, particularly in commercial & architectural lighting installations. Tunable White and Circadian Rhythm color applications in office and healthcare settings are driving this. With ACN, it would require each and every end device to have a NIC and then the switch port count requirements for a system would grow exponentially as would cost.

Whether such a system is truly necessary is up for debate, but a lot of specifiers are asking about this more and more. It's part of the IoT craze taking root, or at least I think so. There are an increasing number of platforms coming on to the market that support RDM over Ethernet (we have one and are coding improvements all the time) and then there is the ANSI standard for that shaping up. It's that "last mile" issue where RS485 half duplex becomes a fairly serious issue because of all the data that wants to go from the many end devices to the single controller and so a lot of water has to go in to a pipe that necessarily gets smaller and smaller.

We could be wrong, but we don't see a world where there won't be an RS485 last mile dependency to connect groups of end devices to Ethernet gateway ports that are acting as proxies for the networked RDM controller/server box.

This much I can tell you. The BMS systems people are getting in to this very quickly - and they aren't going to go away - so all of us need to bone up on things like integration with BACnet IP.

How did we get to this point? It my opinion (let me stress that "my opinion" qualifier again just to be clear) that as the standards writing committees worked on this issue, there was a faction who thought it important to enable RDM to work over previously installed ("legacy") DMX512 signal wiring systems. In those early days a fair number of systems got installed using jacketed two twisted pair cables and Universe A was running on Pair 1 and Universe B was running on Pair 2. There would have been no way to implement full duplex RDM wiring techniques for those sites. Now another topic for debate is whether the vast majority of those facilities would have ever sought to convert to RDM. Anyway, it doesn't matter now because what is done is done.

Come see us at LDI and we'll show you what we have been working on.

Best Regards,


Van Rommel
Director Business Development
Pathway Connectivity
 
  • Like
Reactions: Rob
Meanwhile the architectural lighting market is playing with POE, IOT, and even LiFi! If any of that stuff leaks into our world things will get really wild.
 
I would love to see a daisy chainable RJ45 connector that supports ACN (or similar network protocol) integrated into the fixtures themselves. I know that would mean essentially putting a switch in each device and sending the cost sky high. But I would love to have a single cable run from the switch through all the devices (just like we do with DMX currently.)
Then you get all the benefits of IP based, with the convenience of the single cable run.

Probably won't happen till the network hardware becomes cheap enough but it would save me a lot of issues now.
 
Yopu guys may be too young to remember, but there was a time when college radio stations (back in the AM days) 'broadcast' to their own campuses via carrier current. The RF from the transmitter was coupled to the power lines in the dorms. How about a lighting control system that's multiplexed on the power system? Every lighting instrument needs power; why not a system that controls the instrument via the conductors already going to it? Sure, there would be problems of filtering out dimmer "hash" but these could possibly be solved by parity and an FM carrier.
 
I would love to see a daisy chainable RJ45 connector that supports ACN (or similar network protocol) integrated into the fixtures themselves. I know that would mean essentially putting a switch in each device and sending the cost sky high. But I would love to have a single cable run from the switch through all the devices (just like we do with DMX currently.)
Then you get all the benefits of IP based, with the convenience of the single cable run.

Probably won't happen till the network hardware becomes cheap enough but it would save me a lot of issues now.
IPs per device, and maybe a UDP based protocol like OSC? It would also allow for MUCH finer control than what DMX can provide.
 
Yopu guys may be too young to remember, but there was a time when college radio stations (back in the AM days) 'broadcast' to their own campuses via carrier current. The RF from the transmitter was coupled to the power lines in the dorms. How about a lighting control system that's multiplexed on the power system? Every lighting instrument needs power; why not a system that controls the instrument via the conductors already going to it? Sure, there would be problems of filtering out dimmer "hash" but these could possibly be solved by parity and an FM carrier.
I believe there is a home security system that uses your home's AC lines to transmit data and get power. Although when you're running lots of fixtures with many parameters it'd become quite noisey.
 
Yopu guys may be too young to remember, but there was a time when college radio stations (back in the AM days) 'broadcast' to their own campuses via carrier current. The RF from the transmitter was coupled to the power lines in the dorms. How about a lighting control system that's multiplexed on the power system? Every lighting instrument needs power; why not a system that controls the instrument via the conductors already going to it? Sure, there would be problems of filtering out dimmer "hash" but these could possibly be solved by parity and an FM carrier.
Dirk Epperson's thesis at Yale in 60s was just that - dimmers on the yoke with power line data. Built a working model iirc. There were and I believe remain some issues that manufactures apparently thought/think unsolvable, though the power line Ethernet links seem to work well. I seem to recall that there is too much noise in large buildings with so many motors and power supplies as a reason.
 
How about a lighting control system that's multiplexed on the power system? Every lighting instrument needs power; why not a system that controls the instrument via the conductors already going to it? Sure, there would be problems of filtering out dimmer "hash" but these could possibly be solved by parity and an FM carrier.
Those systems exist in the install world - Lumenpulse's Lumentalk system uses this.

http://www.lumenpulse.com/en/product/82/lumentalk

There are challenges with multi-phase power (they make a bridge box to solve this), and I suspect there are scalability and management concerns - how do you isolate it? How do you prevent unauthorized users from controlling your lights by plugging in to the electrical system? It is a good system for some scenarios.
 
In answer to the original question:
I'd like to use RDM but can't due to the poor, or lack of, implementation on some devices.
Those devices interpret RDM as levels on the DMX line and cause the fixtures to flicker randomly, which of course is not acceptable.

My understanding of how it works is that it is extra data at the end of each DMX 'string' of data. This is sent out from the console/system, and the system expects a data string back identifying each device and it's capabilities. It is on the same wires as normal DMX, not a different set.
 
I've used RDM a few times on new systems and permanent installs. Great for avoiding ladders. It doesn't allow wiring problems that DMX forgives. Then turn it off for the show!

Sent from my SM-G900V using Tapatalk
 
In fact, designing systems that are primarily distributed power and data and few or no central dimmers, and heavy use of LED for house, work, and utility lighting, they're heavily dependent on RDM. My most hands on experience was trying to fix a problem after tech left with ETC telphone support (thanks Sasha), an Ion, and the then fairly new Concert. Astounding how easily I was led through sorting it out.
 

Users who are viewing this thread

Back