And here begins my journey to RDM nirvana. I should preface this with I didn’t get that degree in electronic engineering, and my interest in this sort of stuff is that of frustrated lighting technician. I have recently had two RDM experiences, one; 30 led batterns with no interface whatsoever and a controller provided (French interface only) that would make a cup of tea better than addressing fixtures. The other was a JEM AF2 fan, that had a nasty case of random wind when connected to an EOS with RDM discovery enabled.
So here we go, how can I make a controller, and how does it work anyway.
First steps.
Most things I read about RDM is about being a responder (a fixture) There is an extremely boring spec document that specifies how to behave. With DMX you are just sending frame after frame of data, separated by breaks and stop bits, to be an RDM sender you need to be able to send stuff that isn’t DMX and then immediately stop and listen to see what comes back. All that toss about RDM compliant buffers is all to do with being able to send data both ways down a cable that you only normally send one way.
The spec shows a whole load of standard messages to send, I’m going to try a “Get Device Info” first or “E120_GET_DEVICE_INFO” because engineers love a caps lock underscore combo. The packet of data starts with a Hex 0xCC byte, if it was DMX we would send a 0x00.
Once you can send and receive you need to need to know who to talk to, and of course it can’t be via start addresses that we all know and love as the whole point is RDM is to able to mess about with them.
In the standard all fixtures that work with RDM should now have a unique ID or UID.
The first thing as a controller is to figure out who is connected to your line and what their UIDs are via “Discovery” I’m saving this for another rainy day. Today I am just trying to talk to one ELDO led driver sat on my desk, I know it has a UID of 0x64, 0x6F, 0x00, 0x00, 0x8C, 0x10 (don’t ask me how I know that)
So thanks to Open Lighting Project’s packet builder and some assistance from computer genius Peter I have worked out what I need to send to get the thing to talk back, and start sending out data and trying to listen. On my microcontroller I have a RS485 transceiver hooked up to the dmx line, and I have control of the most important pin – the REDE (receive enable send disable) when this pin is high or low puts the transceiver in a state of listen or send.
Here is me sending out the get info packet , the left blob is the data going out, and on the right is the ELDO talking back… or in this case, the line is still being biased by the controller so it is just causing a load of noise on the line. I checked this by sending data with the ELDO unplugged and I didn’t get the right hand blob.
Now I’m flipping that REDE pin straight after sending out the message, on the right you can see the ELDO taking control and writing some stuff onto the bus
Zooming in we can see the message comes 560us after I send the message.
The yellow trace is the receive pin on the micro receiving the data.
Cue nearly a whole day of messing about trying to actually listen to that data.
Turns out I didn’t understand much about how DMX was working and “framing error” in the context of receiving this data is actually a good thing, as my micro triggers a framing error every time is gets a “break”…
And after a tonne of nobbing about here we go, a string of hex numbers back from the device, copy and paste this into Open Lighting Project’s “RDM packet dissector” and success, it shows me my led driver amongst other things has a start address of 5 and a footprint of 8 channels.
Whoop.
Now I can talk, listen and understand. Next job is to find out how to discover those devices…