usbpro plugin device detection timeout

[Benni Graf]

Hi all!

I'm currently trying to salvage an old Arduino Nano and use it as a USB DMX device. I came accross the DMXUSB library[1] which implements the Enttec USB serial protocol. I setup a very basic "sketch" on the Arduino, but ola didn't see the device, printing the message `USB Widget didn't respond to messages, esta id 0, device id 0`.

[1] https://github.com/DaAwesomeP/dmxusb

After a lot of fiddling and debugging I found that when I would increase the timeout value for the USB Pro device discovery from 200ms to 1200ms, ola manages to discover the Arduino Nano as Enttec compatible USB device. (The corresponding line of code is in `WidgetDetectorThread.h` in the constructor in line 78 – `unsigned int usb_pro_timeout = 1200,`.)

I'm writing here to maybe get some opinions from developers – would it make sense to just raise the value directly in that line (I could create a PR for that I guess) or do you see downsides to this? Or would it make sense to make this value configurable via the config file (I'm quite sure that would be beyond my C++ skills though, so somebody else had to jump in)?

Best,

Benjamin.

[Peter Newman]

Hi Benjamin,

Hopefully Perry will be along soon who might be able to offer more input on his library, however I'd also be curious how our RGB mixer performs (it won't do the exact job you need, but it runs on an Arduino and communicates via the Enttec Protocol so would be a good test:
https://github.com/OpenLightingProject/rgbmixer

Did you need to set it to 1200ms for it to work (i.e. a whole second slower than the default), or did you just jump to that for testing? i.e. does it break if set to 1100ms?

Were you using one of the examples on the Arduino or your own code:

https://github.com/DaAwesomeP/dmxusb/blob/master/examples/DMXUSB_DmxSimple/DMXUSB_DmxSimple.ino

Or the simplest:
https://github.com/DaAwesomeP/dmxusb/blob/master/examples/DMXUSB_Simple/DMXUSB_Simple.ino

Could you share olad -l 4 logs both with and without your change:
https://www.openlighting.org/ola/get-help/ola-faq/#How_do_I_get_olad_-l_4_logs

[Benni Graf]

Hi Peter,

thank you for getting back so quickly!

While writing my reply below, I did some more research and came to another solution: I found out that initiating a serial connection towards the Arduino via USB always resets the device and makes it go through the bootloader again – this takes a considerate amount of time, which I didn't measure myself, but some people on the internet talk about 1-2 seconds. However I was able to program that Arduino Nano with just the DMXUSB "simplest" example without the bootloader (using another Arduino as programmer/ISP). In this mode, olad recognizes the device without any changes/within the original time limit of 200ms.

So the problem is the Arduino bootloader delay; the solution is to remove the bootloader. Increasing the timeout value as suggested (or make it configurable) is probably not worth it with this solution at hand. I'll just have it documented here for now :-).

Here's my original answer for more insights:

 – I did test increasing values for the time and it started to work at 1200ms. 1100 and below didn't work.

 – I did in fact use the "simplest" example you mentioned from DMXUSB for testing

 – Thanks for pointing me to rgbmixer. Unfortunately I can't build it on my machine. The old Arduino 0022 doesn't run on Monterey anymore, and with a current build (not the IDE!), I can initiate a build after adjusting some paths in the Makefile, but it'll fail with "make: *** No rule to make target `/Applications/Arduino.app/Contents/Java/hardware/arduino/avr/cores/arduino/HID.o', needed by `applet/core.a'.  Stop."

Talking about environments: I've tested this on a MacBookPro 2012 with MacOS Monterey 12.6 and on a RaspberryPi 3A+ running DietPi 8.20 (latest).

`olad -l4` with my change (I'll include only the usbpro-related things, I hope you don't mind):

```

olad/PluginManager.cpp:195: Trying to start Serial USB
common/thread/Thread.cpp:200: Thread , policy SCHED_OTHER, priority 31
plugins/usbpro/WidgetDetectorThread.cpp:215: Found potential USB Serial device at /dev/cu.usbserial-A9AHHB7B
common/io/Serial.cpp:158: Checking for /tmp/LCK..cu.usbserial-A9AHHB7B
common/io/Serial.cpp:199: Acquired /tmp/LCK..cu.usbserial-A9AHHB7B
plugins/usbpro/WidgetDetectorThread.cpp:221: New descriptor @ 0x6000022a4b10 for /dev/cu.usbserial-A9AHHB7B
plugins/usbpro/WidgetDetectorThread.cpp:389: trying stage 0 for 0x6000022a4b10
olad/PluginManager.cpp:200: Started Serial USB
plugins/usbpro/UsbProWidgetDetector.cpp:537: Detected USB Device: ESTA Id: 0x0000, device Id: 0x0000, serial: 0x1ffffffa, f/w version: 0.3
plugins/usbpro/WidgetDetectorThread.cpp:314: Defaulting to a Usb Pro device
plugins/usbpro/WidgetDetectorThread.cpp:330: USB Pro Firmware >= 2.4 is required for RDM support, this widget is running 0.3
plugins/usbpro/EnttecUsbProWidget.cpp:859: TX: 3, length 2
olad/plugin_api/DeviceManager.cpp:105: Installed device: Enttec Usb Pro Device, Serial #: 25165165160, firmware 0.3:5-25165165160
olad/plugin_api/PortManager.cpp:119: Patched 5-25165165160-O-0 to universe 0

```

...without my change (or with lower values than 1200ms):

```

olad/PluginManager.cpp:195: Trying to start Serial USB
common/thread/Thread.cpp:200: Thread , policy SCHED_OTHER, priority 31
plugins/usbpro/WidgetDetectorThread.cpp:215: Found potential USB Serial device at /dev/cu.usbserial-A9AHHB7B
common/io/Serial.cpp:158: Checking for /tmp/LCK..cu.usbserial-A9AHHB7B
common/io/Serial.cpp:199: Acquired /tmp/LCK..cu.usbserial-A9AHHB7B
plugins/usbpro/WidgetDetectorThread.cpp:221: New descriptor @ 0x600001c08ea0 for /dev/cu.usbserial-A9AHHB7B
plugins/usbpro/WidgetDetectorThread.cpp:389: trying stage 0 for 0x600001c08ea0
olad/PluginManager.cpp:200: Started Serial USB
plugins/usbpro/UsbProWidgetDetector.cpp:323: USB Widget didn't respond to messages, esta id 0, device id 0
plugins/usbpro/UsbProWidgetDetector.cpp:326: Is device in USB Controller mode if it's a Goddard?
plugins/usbpro/WidgetDetectorThread.cpp:389: trying stage 1 for 0x600001c08ea0
common/io/SelectPoller.cpp:233: ss process time was 0.000003
plugins/usbpro/WidgetDetectorThread.cpp:386: no more detectors to try for  0x600001c08ea0
common/io/Serial.cpp:247: Released /tmp/LCK..cu.usbserial-A9AHHB7B

```

Best and thanks,

Benjamin.

[DaAwesomeP]

Hey all,

Sorry I missed this here! I've responded more on the GitHub issue: https://github.com/DaAwesomeP/dmxusb/issues/19

I agree this is more of an issue on the DMXUSB/Arduino end, so it is probably not worth changing the timeout in OLA to accommodate it. I don't think that any actual Enttec devices would exhibit this behavior.

Thanks,
Perry