RDM discovery silent with Enttec DMX USB PRO 2.4

[SimonKagstrom]

I'm using an Enttec DMX USB Pro, with firmware version 2.4 together with Ola. It can send DMX data, but RDM doesn't work.

When starting Ola, I see and initial unmute being sent, and also the device reply to it, but then it's silent. When triggering an RDM discovery after the startup, I don't see any more messages and the discovery splash in the web UI just hangs.

From the logs:

olad/PluginManager.cpp:200: Started Nanoleaf
plugins/usbpro/UsbProWidgetDetector.cpp:537: Detected USB Device: ESTA Id: 0x0000, device Id: 0x0000, serial: 0x02406031, f/w version: 2.4
plugins/usbpro/WidgetDetectorThread.cpp:314: Defaulting to a Usb Pro device
olad/plugin_api/DeviceManager.cpp:105: Installed device: Enttec Usb Pro Device, Serial #: 02406031, firmware 2.4:5-02406031
plugins/usbpro/EnttecUsbProWidget.cpp:276: Incremental discovery triggered
plugins/usbpro/EnttecUsbProWidget.cpp:308: Un-muting all devices, TN: 0
olad/plugin_api/PortManager.cpp:119: Patched 5-02406031-O-0 to universe 1
plugins/usbpro/EnttecUsbProWidget.cpp:308: Un-muting all devices, TN: 1

^^^ I see the unmute here, just after startup. But after triggering it manually with ola_rdm_discover -u 1 -f,

olad/AvahiDiscoveryAgent.cpp:236: State for OLA Server._http._tcp,_ola, group 0x5617826601e0 changed to AVAHI_ENTRY_GROUP_ESTABLISHED
olad/plugin_api/Universe.cpp:523: Full RDM discovery triggered for universe 1

there is nothing. Sounds quite similar to #1694, but if I understand that discussion correctly, it was for another (compatible) device.

[peternewman]

Hi @SimonKagstrom

Please can we have olad -l 4 logs: https://www.openlighting.org/ola/get-help/ola-faq/#How_do_I_get_olad_-l_4_logs

Which version of OLA and how did you install/build it (package or compiled)?

Is your Enttec a Mk 2 (the flat one with the D type connector flails) or an original one with just the USB and two XLRs on the chassis)?

Do you know if your responder is good (e.g. does it work elsewhere)?

[SimonKagstrom]

I'll get the logs tomorrow when I'm back by the computer.

I've tried multiple versions: built from source (latest on github, perhaps minus the last push), the old Raspberry pi image from raspbian-ola-0.9.5.zip and the package from Raspberry pi bullseye (0.10.8 I believe). They all fail in the same way, so it doesn't seem to be a regression. I built from sources on a x86 with ubuntu 20.04.

The enttec is the original type, at least as far as I understand from your description. Looks boxy like a minibus!

The responder works with at least a lumenradio CRMX nova TX2, and I've also tried another responder with the same results. I see the first unmute on the responder, and reply to that, but then no more messages from the enttec / ola.

[SimonKagstrom]

Here is the -l4 log file. The enttec discovery messages are sent when ola starts and stops, but nothing when I run the ola_rdm_discover -u 1 -f command.

l4_log.txt

[peternewman]

So discovery is failing to complete for some reason:

olad/plugin_api/DeviceManager.cpp:105: Installed device: Enttec Usb Pro Device, Serial #: 02406031, firmware 2.4:5-02406031
plugins/usbpro/EnttecUsbProWidget.cpp:276: Incremental discovery triggered
plugins/usbpro/EnttecUsbProWidget.cpp:308: Un-muting all devices, TN: 0
plugins/usbpro/EnttecUsbProWidget.cpp:863: TX: 7, length 26
olad/plugin_api/PortManager.cpp:119: Patched 5-02406031-O-0 to universe 1
common/io/EPoller.cpp:306: ss process time was 0.000000
plugins/usbpro/EnttecUsbProWidget.cpp:874: RX: 3, length 5
plugins/usbpro/EnttecUsbProWidget.cpp:874: RX: 5, length 29

And then nothing until:

common/http/HTTPServer.cpp:559: HTTP server thread exited
common/io/EPoller.cpp:116: EPOLL_CTL_DEL 13
common/io/EPoller.cpp:116: EPOLL_CTL_DEL 40
common/io/EPoller.cpp:116: EPOLL_CTL_DEL 9
common/io/EPoller.cpp:116: EPOLL_CTL_DEL 23
common/io/EPoller.cpp:116: EPOLL_CTL_DEL 24
common/io/EPoller.cpp:116: EPOLL_CTL_DEL 25
plugins/usbpro/EnttecUsbProWidget.cpp:595: Enttec Pro discovery complete: 
plugins/usbpro/EnttecUsbProWidget.cpp:265: Full discovery triggered
plugins/usbpro/EnttecUsbProWidget.cpp:308: Un-muting all devices, TN: 1
plugins/usbpro/EnttecUsbProWidget.cpp:863: TX: 7, length 26
common/io/EPoller.cpp:116: EPOLL_CTL_DEL 26
plugins/usbpro/EnttecUsbProWidget.cpp:595: Enttec Pro discovery complete: 
olad/ClientBroker.cpp:95: Client no longer exists, cleaning up from RDM discovery

I'm particularly suspicious that it looks like it's responding to the broadcast unmute, which it shouldn't do. Did you make/write the software for the device, or did you buy it?

We send the RDM DUB:

plugins/usbpro/EnttecUsbProWidget.cpp:308: Un-muting all devices, TN: 0
plugins/usbpro/EnttecUsbProWidget.cpp:863: TX: 7, length 26

We get a reply to our request for info about the Enttec itself: plugins/usbpro/EnttecUsbProWidget.cpp:874: RX: 3, length 5

We get a "DMX" packet, although this confirms that's what we'd get from a DUB (it's probably dropped one byte of pre-amble) - https://github.com/OpenLightingProject/ola/issues/1694#issuecomment-744826330 : plugins/usbpro/EnttecUsbProWidget.cpp:874: RX: 5, length 29

So I think the issue is that the device is responding to a broadcast unmute, which it shouldn't.

You could test this in two ways, firstly unplug the RDM responder, If you look at the -l 4 logs, you should get a chunk finishing with "Enttec Pro discovery complete" each time discovery is triggered (either automatically on startup), or manually via the webpage or CLI. More conclusively, if your CRMX Nova TX2 is the RDM version, which I guess it must be, if you turn that round, OLA should be able to discover/control that (which would prove OLA and the dongle): http://rdm.openlighting.org/model/display?manufacturer=19541&model=257

[SimonKagstrom]

Thanks!

It's self-written RDM code in development, so the problem might very well lie there. The reason I though it was on the enttec end was because I only saw the initial mute and then nothing. As you guessed, I did respond to the broadcast unmute, so that might be the problem.

I didn't see the TX2 discovered with a quick test, but it might be due to some configuration issue (having been used by the supernova software before).

Closing this issue since it's probably a user error and not a bug as such. I'll reopen if I can prove that the problem is with the enttec after all.

[SimonKagstrom]

I can confirm that the discovery finishes after I corrected the response to the discovery unmute, so your observation is correct.

Thanks!