Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support added for Nicolaudie SIUDI #1887

Open
wants to merge 12 commits into
base: master
Choose a base branch
from

Conversation

CreaValix
Copy link

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 ThreadedUsbSender to provide this constant data stream, even for the async interface.

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.
@peternewman peternewman added this to the 0.11.0 milestone Jul 27, 2023
Copy link
Member

@peternewman peternewman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

plugins/usbdmx/SiudiFactory.cpp Show resolved Hide resolved
plugins/usbdmx/UsbDmxPlugin.h Outdated Show resolved Hide resolved
plugins/usbdmx/SyncPluginImpl.cpp Show resolved Hide resolved
plugins/usbdmx/Siudi.cpp Outdated Show resolved Hide resolved
plugins/usbdmx/Siudi.cpp Outdated Show resolved Hide resolved
plugins/usbdmx/Siudi.cpp Outdated Show resolved Hide resolved
plugins/usbdmx/Siudi.cpp Outdated Show resolved Hide resolved
plugins/usbdmx/Siudi.cpp Outdated Show resolved Hide resolved
@peternewman
Copy link
Member

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 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?

@CreaValix
Copy link
Author

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.

@CreaValix
Copy link
Author

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?

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 usleep() parameter in TransmitBuffer(). Below 200 µS effects will start flickering. The USB response time is 32 ms then. I could also measure 32 pkt/s.
If I usleep() 30 ms, I get the same frequency, but only 2 ms USB response time. So usleep(30000) seems to be a good choice.

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.
There, they also mention that the device will go to sleep after 5 seconds. However, I found different values.

By changing some parameters in the Windows API, we could find out some of the USB values...

CreaValix and others added 8 commits July 28, 2023 15:37
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.
@CreaValix
Copy link
Author

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

Done abcddc1

@CreaValix
Copy link
Author

So it seems that this device needs 32 ms for a full DMX package, resulting in 32 Hz frequency at best.

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants