RDM discovery controller about esp_dmx

[kudiltz]

Just got a little time to test this a bit... good news. ESP32 discover-er connected to (2) Arduino based devices and (3) ETC fixtures. Discovered all 5 within about 6 seconds. Nice work! I'm just running your basic discovery Example for the time being. Now on to doing something with it!

Any reservations or tips on transmitting DMX and performing discovery simultaneously? I have not tried this yet.

Thanks again and have a good weekend.

[someweisguy]

Thanks for submitting this issue and thanks for the kind words!

I have been able to successfully discover several devices over RDM, but there are a few bugs with transmitting RDM discovery packet that I am aware of. These issues only affect transmitting RDM; they do not affect receiving RDM.

Are the devices you are failing to discover on RDM made by multiple manufacturers?

[kudiltz]

I'm mostly interested in the controller (transmitting) discovery function.

The four responders I have convenient are:
(2) ETC Colorsource PARs
(1) Arduino Nano running DMXSerial2
(1) Arduino Uno running same DMXSerial2

Any one of these alone hooked to the ESP32 transmitter discovers fairly consistently.

Arduino's are using a breadboard setup through MAX485 transceivers. I would suspect my components if the ETC PARs weren't doing the same thing.

I have a DMXCat tool that discovers all four devices without issue.

[someweisguy]

I believe this is an error that typically occurs when trying to discover devices from multiple manufacturers. When the RDM controller sends a discovery packet, multiple responder devices may respond at the same time. I have found that this library is currently able to consistently discover a single device without any issues. When more than one RDM responder is on the RDM network, there are three outcomes of an RDM controller sending a discovery packet.

The first outcome is trivial - zero RDM devices respond to the discovery packet and the controller completes the discovery process.

The second outcome is that the multiple devices send a response packet at nearly the same time. When this happens, the RDM controller detects a response, but the packet checksum is not valid. This is an expected condition of the RDM discovery process and I've found that this library is consistently able to handle this situation. Typically, RDM responders made by the same manufacturer will have similar RDM response times. Because of this, I was able to consistently discover 8 Martin Mac 101s in my tests.

The final outcome is that the multiple devices send a response packet at different times. This results in the controller receiving two separate valid responses to the discovery packet. This is the situation that this library is not currently able to handle. In the best case scenario, the controller is able to process the initial RDM discovery response, and is able to send the next packet in the discovery algorithm. In the worst case, when the RDM controller sends the next packet it is clobbered by the second response packet. In the best case, only the RDM device which sends the initial discovery response is discovered. Either way, RDM discovery does not successfully discover every device on the RDM network..

I apologize for the inconvenience. I understand that this means that RDM discovery is effectively broken. Fixing this is on my to-do list, but unfortunately I have other obligations for features that I must handle before I am able to tackle fixing RDM discovery. If you are so inclined, you are welcome to take a look at the RDM discovery algorithm I wrote here. I had to write a custom algorithm than what is recommended by the RDM specification in order to meet the memory constraints of a microcontroller, but I commented the code pretty well so hopefully it is helpful if you decided to take a look.

Again, I apologize for this. Let me know if there are any questions!

[kudiltz]

No worries. Unfortunately, a coding ninja, I am not.

You mention, "this results in the controller receiving two separate valid responses to the discovery packet." Does your library validate the response checksum? It is my understanding this is how the specification contemplates handling responses from multiple devices and collisions:

From 7.3 Discovery Process:

3. Numerous collisions are expected. Any response indicates devices within that UID range. No response indicates there are no devices within that branch.

4. If the checksum is valid for the response, attempt to Mute the device at the UID included in the response by sending the DISC_MUTE message. If a device is located at that UID then it will provide a response message and will no longer respond to any DISC_UNIQUE_BRANCH messages. Test the same branch again for any further responses. If the checksum is invalid then continue branching down the tree, as multiple devices likely exist.

I suspect the iterative nature of your algorithm mentioned in controller.h at line 103 (memory constrained) is related. I wonder if there is a way to limit it to something likely like 32 anticipated devices(thus branches) in order to stay within available memory. "Full" RDM, I don't suppose would be constrained to 32, but hey... we're trying to run on embedded here.

Forgive me if I'm oversimplifying. I appreciate the responses.

[someweisguy]

You mention, "this results in the controller receiving two separate valid responses to the discovery packet." Does your library validate the response checksum? It is my understanding this is how the specification contemplates handling responses from multiple devices and collisions:

Yep - this library validates checksums. When an RDM collision occurs, the DMX driver can see that a response was received, but the checksum is invalid. This is how the DMX driver knows to branch further in the RDM discovery process. The issue arises when a response is received and the checksum is valid and then afterwards another response is received with a valid checksum. What happens is that two responses are received, but the DMX driver sends a MUTE request immediately after receiving the first valid response and this clobbers the second valid response.

This is a difficult thing for me to describe over text. If I'm not making sense, let me know. I can also draw some pictures. :)

A naive way to solve this problem would be to modify the RDM discovery algorithm so that it continuously calls dmx_receive() until no data is received. I think this would solve the problem, but it would mean that discovery takes significantly longer to complete. This is probably acceptable as a naive solution, but I'd like to reduce the amount of time RDM discovery takes.

I suspect the iterative nature of your algorithm mentioned in controller.h at line 103 (memory constrained) is related. I wonder if there is a way to limit it to something likely like 32 anticipated devices(thus branches) in order to stay within available memory. "Full" RDM, I don't suppose would be constrained to 32, but hey... we're trying to run on embedded here.

When I initially wrote/copied the RDM discovery algorithm, it malloc()'d about 22kB of data. I can't tell you how great I felt when I wrote my iterative algorithm which got it down to malloc()'ing 588 bytes. I'm working on v4 of the library which, among other things, will statically allocate this memory so that discovery will never fail due to memory constraints.

[kudiltz]

The problem makes sense. I imagine there is a way to count the clobber as reason to branch down further.

For what its worth, I've used many ETC consoles, controllers, Swisson, Fleenor, and most often the DMXCat to discover devices (pretty legit gear). It has been my experience that it can take up to 90 seconds (rarely, but sometimes longer) to discover all devices in. I've never had the hardware to look at the packets and see whether it is the initial discovery that takes this long, or a subsequent read-in of all device parameters. I should have a piece of hardware later this week that will let me watch this traffic.

Much appreciated.

[someweisguy]

It has been my experience that it can take up to 90 seconds (rarely, but sometimes longer) to discover all devices in.

This is great info - thanks for sharing. I have done a bit of testing with an ETC Colorsource console and got some interesting information about which RDM requests the Colorsource uses in its discovery algorithm. Sometime in the coming few months I will have the opportunity to test against some other consoles including an ETC Apex.

In the meantime, I'll keep this issue open. Feel free to share any updates you have! :)

[someweisguy]

I think I have solved this problem in v4.0 while working on #121. The fix for that issue was a rework of how the DMX driver understands the context for DMX and RDM packets. As a result, the DMX driver will be able to wait a full 5800 microseconds between RDM discovery commands. Because this specific wait time is not explicitly stated in the RDM standard, the wait time will be configurable. 5800 microseconds seems to be the safest value so it will be the default.

Part of the fix for the discovery issue is that I've had to disable the quick RDM discovery algorithm. RDM discovery may take up to 90 seconds in the first few patches of v4.

All of this said, I haven't actually been able to test my fix yet. The v4 branch is (almost) feature complete, so I won't be making any more major changes to the code. If you would like to test RDM discovery, you should be able to switch to the release/v4.0 branch and try one of the RDM discovery examples. If not, no worries; I will update this issue when I am able to do some testing myself.

[someweisguy]

v4.0.0 has been released! I feel confident that I've fixed this issue but I still need to run tests to verify.

Let me know if you have any more thoughts to add. Otherwise, I'll close this issue. Thank you! :)

[someweisguy]

Phenomenal! I love to hear it. I still need to do some testing myself but this sounds like success to me.

Any reservations or tips on transmitting DMX and performing discovery simultaneously? I have not tried this yet.

Great question. You should be able to write something that looks like this:

rdm_uid_t uids[32];
const int num_uids = sizeof(uids) / sizeof(rdm_uid_t);

while (true) {

  if (some_flag_is_set) {
    // Handle RDM discovery
    rdm_discover_devices_simple(dmx_num, uids, 32);
  } else {
    // Send normal DMX packet
    dmx_send(dmx_num);
  }

  dmx_wait_sent(dmx_num, DMX_TIMEOUT_TICK);
}

You can also look into setting up FreeRTOS tasks. You can use one task as your loop to send/receive DMX. Then your other tasks can use semaphores or queues to to communicate with your DMX task. This is a feature I am considering adding to this library; something like dmx_loop_start() that would create a FreeRTOS task with which you could communicate when it's time to read or write DMX data.

I also highly recommend playing with the rdm_discover_with_callback() function. There is some documentation about it in the README and it is used in the ESPIDF_RDMDiscovery example. It allows you to perform discovery and fire a callback function when each device is discovered. In this callback function, you can call additional RDM requests. As soon as a device is discovered, you can send requests such as rdm_send_get_dmx_start_address() to collect additional information about the device before attempting to discover more devices. This is the behavior that I've seen in many professional-level DMX consoles. The rdm_discover_with_callback() function also allows behavior such as updating progress bars.

Let me know if you have any other questions!

[someweisguy]

I was able to test RDM discovery against a handful of ARRI fixtures and ETC fixtures. I think my testing process could be a bit more robust but I am calling this resolved for now. I'll reopen if I find any more problems!

Also, be aware that #140 exists because I'm a big dummy. :P