Q Light Controller+

Hey there, I'm a developer, just not a QLC developer so I'm posting here as the GH issue template asks to keep the issues tidy, let me know if I should make it a GH issue

What's the current stance on adding more FTDI chips for compatibility? Specifically for transmit only.

I see VID for FTDI but also Microchip and Atmel, what were the initial need for adding these?
Are these the vids/pids found in supported hardware?
Link to code I'm refering to: https://github.com/mcallegari/qlcplus/b ... .h#L88-L98

For Arduino projects, there's this excellent library which can virtually make *anything* with serial compatible with the dmxusb plugin: https://github.com/DaAwesomeP/dmxusb
The only issue is the vid/pid checking and support for the 250000bps rate.

I just made it work with 2 ftdi adapters and an esp8266 with a max485 shield to relay the Enttec protocol over DMX cable to the fixtures.
I tried with a third adapter that was based on ft230x, which is not a supported pid. The easiest solution was to rewrite the eeprom using ftx-prog (https://github.com/richardeoin/ftx-prog) to use a supported pid but adding the PID in the section linked above would have the same effect.

Would you support a simple contribution where a triplet of environment variable eg. QLCPLUS_CUSTOM_VID, QLCPLUS_CUSTOM_PID, QLCPLUS_CUSTOM_RATE checked at runtime could be used for one-off setup?

Let me know if you need more infos on this suggestion.

Thank you so much for the excellent software!!

Hi, what would QLCPLUS_CUSTOM_RATE be used for? DMX needs 250kbps to work and the frame rate can already be adjusted via UI.
By the way I wanted to add custom VID/PID in the plugin configuration UI but then I had priority shifted on other topics

Hello and thanks for quickly approving the thread and replying!

It should be custom *baudrate*, maybe. That would be used to set the underlying serial connection with the USB device only, afaik that wouldn't affect the 250kbps of raw DMX as long as the side of the device with the actual connector is kept at 250kbps.
If I read correctly here, 250kbps for ENTTEC protocol is not enforced as per the specs: https://github.com/DaAwesomeP/dmxusb#baudrate-int
Currently it's set here and my proposal would change it here: https://github.com/mcallegari/qlcplus/b ... ce.cpp#L62

To be honest I have yet to actually try this, the baudrate part is secondary to the custom vid/pid though it could enable cheaper serial USB adapters that don't provide 250000 to be used.

Just found this other repo that should allow host-side testing with different baudrates: https://github.com/maxux/enttec-dmx-ftd ... dmx-ftdi.c
baudrate is set to 250000 but nothing should prevent it to be changed. I'll test this with dmxusb at different speed and report back.

FWIW, here's the code I used for the esp8266: https://bpa.st/XTOQ
FTDI adapter is connected to the alternate rx/tx pins and max485 shield to Serial1 TX

EDIT: Just saw your edit, good to know! I'm just getting started with the qlcplus codebase but that seems like something I could potentially achieve/contribute to.

Welcome to the forum and your first contribution.
The DMX protocol is played on top of an RS485 hardware layer, which has to be run at 250kb/s. The pace you use to talk between QLC+ and your interface may deviate from this set RS485 speed.
Quick question: are the DMX frames buffered with your esp8266? I didn't dive deep at all into the code.

[Moved to software development]

QLC+ has also a UART plugin that is built only for Raspberry Pi at the moment.
Maybe with that you can already talk to your adapter without the need of adding a VID/PID.
enable the plugin either via plugins/plugins.pro or plugins/CMakeLists.txt

Thanks for mentioning the UART plugin again, I did try it but overlooked something crucial: it's actually sending DMX frames and not a custom DMX dump as I initially thought. I just tested it with an Arduino Leonardo and DmxSerial (https://github.com/mathertel/DmxSerial) and that worked.

This makes my initial need and question much easier, thanks again!

I think my question/proposal could be rephrased as: making the UART plugin available by default, maybe just disabled? And adding an option for baudrate. Again, I'm willing to contribute.
In my opinion this opens up a very easy and straightforward way to develop DMX-enabled Arduino projects, beyond the specific usecase of UART for RPI/headless setups.

GGGss wrote: ↑Thu Mar 28, 2024 8:11 am Quick question: are the DMX frames buffered with your esp8266? I didn't dive deep at all into the code.

Yes! I think they would always have to be on such platforms; eg. one interface receives it into a buffer that the main loop may process it and, if needed, relay it to another interface running at another speed. Hope that makes sense.