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

[manuco]

This pull request adds another plugin designed for Enttec like USB DMX adapter based on FTDI RS232R chips.

Called "Open RX", it is based on the Enttec Open TX plugin code, but reads data and emits them in the software instead of writing them.

FTDI RS232 chips can send and receive signals. As a DMX widget, they are usually built with a female DMX socket, since it's the main usage.

Using a male/male adaptator and plugging in the widget in a DMX source, it can receive the signal (instead of transmitting it) and forward it to the host computer.

It has been tested with another DMX Open TX FTDI device ran by QLC. It works well and is very stable (if the computer hardware is too).

It has also been tested with a Stairville DDC-6 LCD very cheap ligthing controller. This controller vaguely speaks DMX, with 250 Hz frame rate frequency (!) and frames of 29 channels. This plugin handles this case, trying to manage bogus frames.

As a result, a user can drive 6 sliders (or other virtual widgets) with a cheap DMX Controller using only another cheap DMX USB device.

I didn't have enough devices to test more configuration, but given the fact that the plugin is an optionnal feature, I hope this requests will be accepted.

Please feel free to comment and suggest.

[enbyted]

Tested with my custom FTDI based adapter.
Appears to be working fine, I was actually looking for functionality like that few month ago.

[mcallegari]

Hi, thanks for this.
I haven't got the chance to test it unless I buy a DDC-6 myself, so this review is mainly code cleanup and a couple of major ones to be addressed.

[manuco]

Hi Massimo,

You can test this feature with any DMX controller if you want. Even a grandMa 😊 I think any cheap USB DMX interface will do the job.

Can you review my new commits ?

[mcallegari]

Looks OK now. I would have done the same.
Interestingly, D2XX driver (Windows) has a FT_SetLatencyTimer API as well (https://www.ftdichip.com/Support/Documents/ProgramGuides/D2XX_Programmer's_Guide(FT_000071).pdf)
Perhaps this should be tested on Windows and see if latency is needed there too.
In any case, for consistency, I'd implement setLowLatency in ftd2xx-interface too.
I can deal with it later

[mcallegari]

Are you sure this logic is correct ?
missed_frames is reset to 0 two lines below. To me it looks like missed_frames will never reach 300.
Also

• maybe "missed_frames" is not a proper name since the comment is "a frame has been received"
• "300", "600" and other magic numbers should be placed as defines at the beginning of the cpp file so we can track what they are and easily change them if needed

[manuco]

Yes, I'm pretty sure of the logic. But it needs more explanation:

• when we reach the comment "a frame has been received", it means that all the checks have succedded, so the current_payload contains a valid frame
• but if missed_frames is > 300, it means that there was more than 300 empty reads in the previous cycles
• so we are receiving a correct frame after a long break (probably because the attached controller was plugged or switched on)
• so we display this fact on the debug logger. The whole purpose of this condition is to display on the console the fact that the widget now receives frames, without cluttering the console with a message on each frame received.

You can see that counters have been reset just after that.

I'll add this as a comment at this place to clarify this thing.

[manuco]

For the magic numbers, you are right.

I'll move them, and explain their semantics.

[manuco]

Implementing setLowLatency() in ftd2xx-interface is perhaps a thing to do, but I don't have a compilation stack on my windows setup for now. I see that I can retrieve the Appveyor's dev build. I'll test various configuration to see what can be done on Windows.

[manuco]

I'll plan to make these modifications next Monday evening.

[mcallegari]

Thanks for the explanations. Makes sense now.
I can merge this as it is and implement D2XX latency myself.
Then you can send a further PR with more changes. Sounds ok ?

[manuco]

Ok for the merge now. I'll do a new PR later. Thanks for all :-)

[caitlynrw]

Dumb question, does this mean Open RX was merged into QLC+ and now I can use any FTDI DMX adapter as an input? Or an I misunderstanding the purpose of this?

[manuco]

Open rx is merged. But there are other things to do before using this feature.

Some adapters (i'm not sure that all can do that) have the capability to read signal from the DMX bus. In order for this to work, either you have the right socket on it, or you can use a male/male adapter to plug your adapter into an out port of the DMX line.

Once this hack is made, you can use this plugin. In the driver window, you will see some information about the signal. If you don't see the frequency of the signal, it is probably because your device is not able to read anything. Another issue is that the signal is too poorly sequenced on the line to be read accurately by the software.

Open rx is a hacky pluggin designed to use very cheap devices. It's not a first class solution but yes, it is designed to use some ftdi dmx adaters as input sources.

[caitlynrw]

Currently I'm testing with an Enttec USB Assembled Widget, and plan to grab a M/M XLR5 adapter from Enttec, more long term if this works I plan to either buy another USB/DMX adapter or build one, as my Enttec one is my primary output one.

[omichel]

I am trying to make this work on my Windows 11 machine, to no avail so far. I left the frequency to the default value (30Hz). Here is what I get in the driver window (assuming this is what you mean by driver window):

Moving the sliders on my DMX console doesn't seem to do anything (I am trying to send values on channel 1 using slider 1 on scanner 1). How can I debug this?

Here is my hardware: FTDI FT232RL CHIP USB TO RS485 DMX512

[manuco]

Hi @omichel

Given the datasheet of your device, you should be able to read something from the bus. The adapter I'm using was able to do this and was built with two leds which helped me diagnose its modes. But the vendor who sold me those units told me he no longer does that. Yours doesn't seem to have control leds, so it won't be easy for you to see if it's reading something from the bus, or if it's reading something but not sending it to the host computer. I've tried mine with two setups: a cheap 6-slider console and another USB/DMX device controlled by QLC+. Maybe you could try another device to see if you're more successful?

Idling means that no data has been received from the adapter for the last sampling windows. The computer host sees your adapter, but the adapter doesn't send any data (read from the bus).

In receive mode, the frequency is read from the remote device and you can't change it from the computer side. It's your console that will write data at a specific rate.

[omichel]

Hi @manuco, thank you for the quick reply.

I am on Windows 11. Is it supposed to work there? It does work well in "Open TX" mode and I can control my PAR LEDs without any problem, but the "Open RX" mode with my DMX console doesn't seem to work, although the DMX console works well when connected to the fixtures directly. The "Receiver state:" remains to "Idling" whatever I do... I tried to monitor the virtual COM port corresponding to the device, but I got no information, so I assume the interface doesn't use the VPC, but the FTD2XX.DLL interface instead. Not sure how to debug this...

[omichel]

Could it be due to my XLR male/male adapter as they say:

This adaptor is designed to change an XLR input into an XLR output.

I checked how it is wired and I noticed the left and right pin are inverted:

input        output
1   2        2   1
o   o        o   o
  o            o
  3            3

Which seems to correspond to the XRL standard:

However, in my case (DMX male/male), should I rewire it like that:?

input        output
1   2        1   2
o   o        o   o
  o            o
  3            3

I just ordered a USB 2 DMX adapter with a male DMX connector to try:

I will post the result here once I get it.

[omichel]

I received it today, but sadly, it doesn't work (exact same results as before).

I noticed the last line in the driver window says "NOTE: FTDI VCP interface is not supported by this plugin.". Also this page says for Windows: "DO NOT INSTALL VCP (Virtual COM Port) drivers as they will probably interfere with the D2XX interface.". So I tried to uninstall the COM port driver from the Windows device manager to have only the FTD2xx driver loaded, but that didn't change anything.

Also when I am in Open TX mode and I tick on the output checkbox, the LED on the USB device turns blue, blinking very rapidly. If I untick the output checkbox, it turns off. Then, if I connect my DMX console, turn it on, switch to the Open RX mode and I click the input checkbox, the LED on the USB device turns white, not blinking. DMX commands sent from my console are not received by QLC+ and the LED remains white without blinking. I also checked that my DMX console works properly: it does control my PAR LEDs without any problem.

Any idea?