Possible RDM support?

[NeoCortex97]

Hi, I am back. With your help I managed to build a pretty good and pretty reliable master. Ist is working great, but recently I bought some devices that are meant to be installed permanently and that by chance support rdm - just in case somebody messes up the settings and does not test everything before installing them....... 😅😅😅

Is there a chance, that this library has protocol support for rdm? Or if not, is there anything that I could use to hack rdm support into my master?

[6by9]

IMHO RDM through the PIO (which is what this library is doing) is not really viable as it needs to switch between transmit and receive.
However using the UARTs would be totally plausible for RDM transmission and reception. You will need proper RS485 drivers with direction control wired up, and any splitters you have in your system also need to support RDM (I'm not mean to teach you how to suck eggs here).

https://github.com/OpenLightingProject/rp2040-dmxsun/ is an alternative to this project, and possibly the better fit for trying to implement RDM (already considered in OpenLightingProject/rp2040-dmxsun#22)

[jostlowe]

@BollaBerg was looking into this a few months back! Perhaps he can elaborate

[NeoCortex97]

My hardware uses max3485, or a pin compatible ti chip. Both have direction control and one of my options is not really pin compatible, but it would have automatic direction control.

My hardware also has the direction control wired up correctly. And I even have the option to populate a second max3485 and have my master detect which universes are present. For price reasons i also have a layout with max3485 and a quad receiver chips to implement signal detection. So rdm would be okay.

If the pio program is capable of transmit and receive, I think the code side of rdm is not that crazy.

You could either have data in and out tied together, then the pio needs transmit and receive and direction control. Otherwise you could hack something that takes and input and an output and the direction pin and does everything concerning rdm... Would be a bit Jacky tho

[BollaBerg]

The software side of RDM is relatively simple, as the set of required messages/states/options are relatively limited. I do, however, know very little of the hardware side of things, so I'm not entirely sure how well it would work on Jostein's system.

Maybe we should look at this once I get to Trondheim, @jostlowe ?

[NeoCortex97]

I hope, that I can have a look at it too, when I return home from vacation. Maybe my rdm fixture has arrived by the too.

[e120guru]

Honestly. having worked with RDM for many years (also being part of the ESTA task group), RDM is pretty basic... From a hardware perspective - if you have a bi-directional RS485 then you can do RDM...

There are some things in the standard that you sort of have to read between the lines, and some things that you realise by experiences - especially things around performing discovery on the controller side, and handling proxies on the controller side.

[someweisguy]

I'm working on implementing RDM on my own library for ESP32 here and I'm finding that the most difficult part is making RDM easy to use for end-users. I'm just working out the kinks of implementing an RDM controller so I've written functions such as rdm_get_dmx_start_address() and rdm_set_dmx_start_address() which I hope are straight-forward enough for DMX/RDM newbies. The big problem however is that some RDM devices on the market claim that they adhere to the RDM specification but they just don't.

I bought a (now discontinued, lol) device that doesn't properly respond to discovery so I had to make a minor tweak to my discovery algorithm to accommodate. I've also found that when I send a SET DMX_START_ADDRESS command, it takes about 6ms to respond with an ACK which is out of spec so my controller misses it. Trying to find and accommodate for all these bugs in existing devices is incredibly annoying.

[e120guru]

Honestly - you should not…

If it takes 6ms to respond from the end of your request it is not even close to being compliant. Most professional controllers would have turned the bus around again by that time… (our nodes certainly do)

What device is it?

If you’re doing RDM - I’m happy to discuss and share some stuff that you have to read between the lines from the standard also…
(As part of the RDM task group I’m not happy with how certsin things are in the standard - and some things that you otherwise realize by experience…)

[someweisguy]

What device is it?

It's this little, dinky LED Decoder that I bought for $40 USD. On one hand, I was surprised to see it was out of spec. On the other hand I don't know what I was expecting from a cheap, non-name-brand device. It's odd because it seems that it's just that one command that has such a long bus turnaround. All other commands turnaround in about 200μs. In any case, I have some Martin Mac 101's at work; they respond to all of their supported RDM requests just fine.

If you’re doing RDM - I’m happy to discuss and share some stuff that you have to read between the lines from the standard also…
(As part of the RDM task group I’m not happy with how certsin things are in the standard - and some things that you otherwise realize by experience…)

Thanks! I'll let you know if I run into roadblocks. I completely agree about having to read between the lines. The big thing I'm trying to decipher right now is sub-devices. It seems like sub-devices were kind of an afterthought in the spec. I'm interested to see how many real-world devices actually support sub-devices.

[e120guru]

Probably the device writes the new DMX start adress to some NVM before responding - hence not doing it in time and responding outside of spec, instead of responding with an ACK_TIMER and then go away writing.

Sub-devices is pretty straight forward - they were in the spec quite early. More make sense when you think of them as the original typical use case: Dimmers in a dimmer rack. Where the rack is the root device, and the Dimmers are the subdevices.
The quirk is that you need to linear search for them unit you have found the amount that the root device says there are.
After that, sort of everything else is pretty straight forward.

Proxies on the other hand is an after thought… ”We want the document out, lets just throw in a half page describing that there is something called a proxy, and be done…”
For us as manufacturer of wireless stuff, that sort of made us having to figure out how it needs to work by reading between the lines…

There are also discovery related things that one does not necessarily think of - collisions causing ghosted UID responses. (Which if you are unlock is a device that you have - so it responds to mute).
Or even collissions looking like no response at all…
Both these cases can happen when you have many devices with UIDs close to eachother.

That has been a repeated problem for people when they come to the plugfests with the controllers.

[e120guru]

Oh, and about how common it is with sub-devices… It’s not super common, but it’s not uncommon.
RC4 uses sub-devices in LumenDim and similar. Zero88 uses it in their BetaPack dimmers, etc.

since all subdevices needs to support the same things, Dimmers are for sure the absolute majority of devices that utilizes sub-devices.

[jostlowe]

Out of curiosity: What is commonness of RDM out and about in industry?

I have a background in stage lighting, where i experience that RDM is seldom used, and when it is used it is usually a "last resort" when no other options are available. How widespread is RDM in e.g. the movie industry or in architectural lighting?

[e120guru]

It's very varying... Almost all major manufacturers have RDM in their fixtures and consoles (even MA Lighting has it these days).

Many small devices use it to avoid having an alternative way of configuring it. While some devices have it more like "because it is expected".

I know of some larger theatres and opera houses that use it to some extent post-show to gather status to plan maintenance - lamp hours, filter statuses, etc.

Architectural use it quite a lot, as it's convenient to do patching after equipment is installed, as it's often hard to make sure that a particular pre-patched fixture end up in the right location, and especially post-installation to monitor that the system is still running.
Here in Sweden I've heard of cases where equipment could get stolen, so polling the devices to make sure they're still there can trigger alarms instead of some city complaining about the lights being out.

[someweisguy]

I have a background in stage lighting, where i experience that RDM is seldom used, and when it is used it is usually a "last resort" when no other options are available.

This is my experience as well. I was surprised to see that there was a demand for RDM. I like to keep up-to-date with the Home Assistant community. In it, there seems to be interest in DMX and related protocols. It seems like home automation hobbyists start with Art-Net, and then learn that it is based on DMX and start to gravitate towards DMX. DMX for home automation seems like the wrong choice to me, but I am not that involved in home automation so I could be very off-base here.

I know of some larger theatres and opera houses that use it to some extent post-show to gather status to plan maintenance - lamp hours, filter statuses, etc.

Architectural use it quite a lot, as it's convenient to do patching after equipment is installed, as it's often hard to make sure that a particular pre-patched fixture end up in the right location, and especially post-installation to monitor that the system is still running.
Here in Sweden I've heard of cases where equipment could get stolen, so polling the devices to make sure they're still there can trigger alarms instead of some city complaining about the lights being out.

Wow, these are brilliant use-cases. I've done some architainment installs before and I never thought about using RDM. I can see how this would have saved me some headaches.

[jostlowe]

I think RDM support might be possible by using two PIO state machines: One for transmission and one for reception of frames. The configuration of the state machines is so fast that one might actually use a single state machine with two separate PIO programs loaded, and switch between the two programs depending on whether you want to recieve a frame or transmit a frame.

For now, I don't think I will make a conscious effort to add RDM to Pico-DMX, but that might change in the future :)
Pull requests are always welcome, if someone figures out a nifty way to get RDM working with this library!