Support added for Nicolaudie SIUDI #1887
Conversation
Support Nicolaudie Sunlite intelligent USB DMX interface. These interfaces require a constant stream of the whole DMX field. Otherwise, the interface will go into a standby mode.
There was a problem hiding this comment.
Amazing thanks @CreaValix !
Please add yourself to Authors:
https://github.com/OpenLightingProject/ola/blob/master/AUTHORS
And the device to udev (assuming that's required):
https://github.com/OpenLightingProject/ola/blob/master/debian/ola.udev
Does the device have a serial number at all? e.g. via lsusb (or maybe via that mysterious return value, but might be hard to tell if you've only got one). Does anything unique show up in their proper software?
I think we want about 22ms for 44Hz. Do you know if the device is just sending the data directly (although there's no start code), or does it retransmit on its own if you don't send a USB packet? Approximately what sort of frequency is too low, and is the behaviour identical with different types of lights? |
|
Hello Peter, thanks for having a look so quickly. I'll address your comments. I hope I can do it by tomorrow or beginning of the next week. |
The device has a built-in LED. I suppose it resembles TX. The device starts sending as soon as I power it on, the LED starts flickering, similar to a Ethernet link with active traffic. If I start the original software, it continues to flicker, but a little bit slower. If I stop it, the LED stops flickering for maybe half a second, until it flickers again, just like before the software start. DMX channel stay at the last set value. I made some experiments with Python. When I send a single package, the LED will turn off and effects stay off (or will go off). Roughly 400 ms later, it will start flickering and effects get the values of this package. When I send the same package twice, the LED will stay off or on (random, but not flicker), but effects get the values immediately. Again ~400 ms later, the LED will flicker and lights will stay on. I am pretty sure now that one USB write will result in a single DMX TX. The firmware enters a USB streaming mode after two endpoint writes. After missing USB traffic for ~400 ms it will revert to a failure state and repeat the last package. I also played with the It looks like the firmware delays USB responses until an ongoing DMX TX is finished. Probably it just disables USB interrupts. To be sure, I set one effect to channel 512 to assure that no DMX packet is „cut“ by a following USB transmission. So it seems that this device needs 32 ms for a full DMX package, resulting in 32 Hz frequency at best. CPU load is not an issue, ola is somewhere at 1 % at this configuration. I found a Windows API here with a linked developer kit to download. Here is the Developper Kit.pdf from inside this package. By changing some parameters in the Windows API, we could find out some of the USB values... |
Co-authored-by: Peter Newman <peternewman@users.noreply.github.com>
It seems that all SIUDI-6 behave the same, according to the docs. Although not tested, allow USB IDs for all SIUDI-6 variants. Print a warning if a SIUDI-6 device is found in a cold state. At least for the SIUDI-6C, there is no firmware download necessary.
Done abcddc1 |
Long story short: I set the inter-bulk-transfer delay to 30 ms and the USB timeout to 10 ms. This should be fine, assuming that the USB response comes in after ~2 ms. See 8e48a0a |
Hello to the ola project,
this patch adds support for Nicolaudie Sunlite intelligent USB DMX interfaces.
I have an old American DJ MyDMX (1.0) interface, which is a rebranded SIUDI-6. These patches work fine for me.
I chose not to extend the existing Sunlite USBDMX2, as the USB protocol is different (and much simpler). Also, there are many SIUDI devices where these patches could work for (due to lack of hardware I could not test this).
SIUDI interfaces require a constant stream of the complete DMX data, 512 bytes every ~20 ms (the original software uses 40, but 20 seems to work well).
If the frequency is too low, the interface will go into some of standby mode, which will result in flickering DMX devices if the next package arrives.
I used
ThreadedUsbSenderto provide this constant data stream, even for the async interface.