Introducing Open RX, a way to read DMX signals via simple RSR232 FTDI chips

[manuco]

Hi everybody,

I'm in the process of creating a pull request that will enable QLC + to receive DMX signal with a simple FTDI RS232R chip that is commonly used in USB/DMX cheap adapters.

Currently, the state of this feature is "Works for me". Here is my test configurations :

Config 1

- a Stairville DDC-6 LCD DMX Controller (with a DMX XLR 3 female socket)
- a male / male XLR3 adapter
- a USB/DMX device aka a RS232R FTDI chip with a female socket, blinking in green (receiving)
- a computer running QLC + with my brand new Open RX plugin

I have a Stairville DDC-6 LCD DMX Controller. It's a very cheap device that is not very DMX friendly (wrong frame rate, wrong channel number, unable to change the begin address, some frames are incomplete...). I've managed to read its output with a "DMX USB adapter" which is just a RS232R FTDI chip, with a female DMX port. To be able to plug the adapter in the controller, I've put a male / male XLR3 adapter. Not very sure that this last device is designed for DMX signal, but it works well. Some frames are read bogus, but they are filtered. Since the Stairville is producing DMX frame at a very high frequency (~250 Hz), I had to reduce the internal FTDI adapter latency.

Config 2

- a computer running QLC + with an DMX USB plugin set in "Open TX" the usual way (on universe 1)
- a first USB/DMX device aka a RS232R FTDI chip with a female socket, blinking in red (transmitting) as usual for me
- a male / male XLR3 adapter
- a USB/DMX device aka a RS232R FTDI chip with a female socket, blinking in green (receiving)
- the same computer running QLC + with my brand new Open RX plugin and a USB DMX plugin set in "Open RX" (on universe 2)

Here all is working very well : frames are complete and at the right configured frequency (30 Hz for the default setting), no bogus frame at all.

In both cases, I receive the channel values, and the Simple Desk reacts are requested (I can see the sliders moving when I use the Stairville sliders).

Now, I'm working toward addition of this plugin in the main source tree. I would appreciate some feedbacks from people who own DMX source devices and RS232 based DMX devices to know if it works for you too, and if it didn't break anything.

And I would appreciate feedback on the code.

You can see the pull request here :

https://github.com/mcallegari/qlcplus/pull/1182

Thanks !

[manuco]

Hi everybody !

My patch has been accepted. It is working fine on Linux, but not very well on Windows.

I've tried some code to fix it, but the main problem is that the FT2XX driver doesn't accept to set the latency to values beyond 2 ms, which is not very practical to read badly timed DMX frames (sent by cheap controllers for example). The libftdi driver allows a 1ms latency which seems to help a lot with timed idle detection.

Since DMX protocol is based on idle time between frames to distinguish between them, I haven't many ideas to detect such frames automatically. I've found this page : https://www.ftdichip.com/Support/Knowle ... atency.htm and played with FT_SetLatencyTimer and FT_SetTimeouts, but the result is not as stable as with the linux version.

One of my idea is to introduce another mode of reading frames, not based on timing, but on the average length of frames. Such mode would need the help of the user to calibrate the input, by setting some channels to some values. The drawback of this method is that if a byte is lost, the DMX stream won't be synchronized anymore. It can be managed by looking at previously received frames, trying to distinguish the shift, and hoping the controller only change the channel values on a smooth way, but it's a lot of work...

Do you think it's worth the effort ?

[GGGss]

I suggest you keep it simple...
The number of channels used as input will be minimal since this interface (may) will only be used in very small setups.
Not having a galvanical isolated DMX line does make me shiver.

Once I was running a very small show in a municipal venue and while tweaking DMX addressing at the fixtures I clearly could feel some parasitic current / tension being present between truss, fixtures and my hand. Yes really !
The evening started with a loud TACK in the PA and we were only guessing what caused it to find out, 2.5h later, that my laptop was running on battery only and it died past showtime. 8-/ Horror is it was mid show.
We found out that the circuit where my laptop was plugged in died due to the connection between ground and this 'electrical unstable' rig via DMX cabling. (The 'tack'-reason)
Hadn't my DMX interface being fully galvanic isolated ... I surely fried my laptop and/or power supply.
A month later I had to replace the power supply of it - it got banged by this.

So...