In the past weeks I've been trying to make qlc+ work with a 2006 dmx usb stageprofi on lubuntu 14.04.1 i386.
The interface has been working fine with other software ( Herr Florian Schmitt's "lindmx" on linux, Freestyler and others on windows ).
I did my reading on the source, I was fortunate enough to be able to read the USITT DMX512-A specification ( it is not free ), and opened documentation on serial programming that has been sitting in my library since the 90's ( pstn modems and bbs'es on landlines went out of fashion at a certain point ).
I did my fair share of modifications to the source and recompilations.
After all the above - and keeping in mind I might not be what you'd call an expert - I came to the conclusion that something *might* be off in the implementation of the dmxusb plugin.
Namely:
* It is indeed true that the USB512 spec states - in its timing diagram table - that the Bit Rate is in the range of 245 - 255 kbit/s,
BUT:
bit rate and baudrate are two different concepts ( two documents to support the thesis : http://www.tldp.org/HOWTO/Modem-HOWTO-23.html and http://www.linuxjournal.com/files/linux ... 097s2.html ).
.
Quoting the linuxjournal page: "Multiple bits can be encoded per baud, to get bit rates that exceed the baud rate". In DMX's case to achieve a bitrate of 250000 on a serial line set with 8 transmission bits we would need to set the baudrate to a mere 31250. ( My stageprofi works at 38400 baud or optionally at 19200. )
.
.
* The DMX512 standard might well say it has 2 stop bits,
BUT:
It is irrelevant to us what the properties of the serial line on the DMX side of the ftdi chip are, since it is the dongle's manufacturer's job to guarantee that. What IS relevant to QLC+ is to establish sound communication on the pc->ftdi side.
From a freely downloadable pdf on dmx4all.de called "DMX4ALL_Commands.pdf" :
Baudrate: 38400 Baud (Some old interface can be switched to 19200 Baud)
Bytes: 8
Stop-Bits: 1
Parity: None
Handshake: None
This being the case I see no need to hardcode the baudrate to 250000 in qlcftdi-libftdi.cpp, qlcftdi-ftd2xx.cpp and qlcftdi-qtserial.cpp and I propose that the definition of the line properties be set on a "per device" base or in external configuration files or even through a combo box with user-selectable default settings.
Now I am aware that this may sound suspiciously like a lecture to some, but I guarantee that is not my intention to lecture anyone on matters which I once again state am no expert about. I wrote this hoping it might help the development of the soundest and most flexible open-source lighting software.
Gianpaolo Carapucci
dmusb plugin, serial line properties, devices, stageprofi
-
Jano Svitok
Gianpaolo,
according to RS485/RS232 voltage levels we can assume that baud=bps in this case. There are no tricks like compression or multiple voltage levels.
It seems that StageProfi is a processor-controlled device, so that we are in fact talking about two serial lines: one over USB between computer and the device and the other between device and lights (RS485).
That means the speed between computer and device is totally unrelated to DMX bus speed (in this case). So it may be useful to change the rate here. Lower baud rate may mean slower refresh rates, i.e. transitions will not be as smooth. On the other hand, if the device doesn't work at all now, it may still be improvement!
For dumber devices (like Enttec open dmx usb) there is no processor in the middle. They consist of USB->RS232 converter and RS232->RS485 converter. In that case, the timing must be precisely specified by the computer (i.e. by QLC+) and should be just like it is now.
according to RS485/RS232 voltage levels we can assume that baud=bps in this case. There are no tricks like compression or multiple voltage levels.
It seems that StageProfi is a processor-controlled device, so that we are in fact talking about two serial lines: one over USB between computer and the device and the other between device and lights (RS485).
That means the speed between computer and device is totally unrelated to DMX bus speed (in this case). So it may be useful to change the rate here. Lower baud rate may mean slower refresh rates, i.e. transitions will not be as smooth. On the other hand, if the device doesn't work at all now, it may still be improvement!
For dumber devices (like Enttec open dmx usb) there is no processor in the middle. They consist of USB->RS232 converter and RS232->RS485 converter. In that case, the timing must be precisely specified by the computer (i.e. by QLC+) and should be just like it is now.
-
Massimo Callegari
Hi, I changed the code for the Stageprofi like 3 times so far.
It seems the device behaves differently from the specifications. For example it is supposed to return an aknowledge byte, but instead it doesn't. Totally unreliable in my opinion.
I am well aware the specs say 38400, but believe me, I tried that and it makes absolutely no difference.
What Jano says is correct, one thing is the USB interface and another thing is the DMX interface.
Anyway this weekend I'll try (again) to fix the Stageprofi support and this time I hope it is the last time.
It seems the device behaves differently from the specifications. For example it is supposed to return an aknowledge byte, but instead it doesn't. Totally unreliable in my opinion.
I am well aware the specs say 38400, but believe me, I tried that and it makes absolutely no difference.
What Jano says is correct, one thing is the USB interface and another thing is the DMX interface.
Anyway this weekend I'll try (again) to fix the Stageprofi support and this time I hope it is the last time.
-
gcarapucci
@Jano
And there I go making a fool of myself all over again.. thought I had it all figured out. Duh!
Of course serial lines do only bit signalng... *facepalm*
@Massimo
Err, my deepest and humblest apologies.
In fact even in test programs I had to try a ton of different things. The only time I got something back from the dongle was with ftdi_set_line_property2 to 8, STOP_BIT_15, NONE, BREAK_OFF and 38400 baud and never freeing the handle ( ftdi_free - after this the device becomes totally mute even if you try to reopen ).
While most of the time I got "G" as response, almost as many times the device responded with a garbled char, which I assume it still thinks is a "G"..
And yes, "Totally unreliable" seems to be a fair definition for this dongle..
Sorry, thought I could be of some help..
And there I go making a fool of myself all over again.. thought I had it all figured out. Duh!
Of course serial lines do only bit signalng... *facepalm*
@Massimo
Err, my deepest and humblest apologies.
In fact even in test programs I had to try a ton of different things. The only time I got something back from the dongle was with ftdi_set_line_property2 to 8, STOP_BIT_15, NONE, BREAK_OFF and 38400 baud and never freeing the handle ( ftdi_free - after this the device becomes totally mute even if you try to reopen ).
While most of the time I got "G" as response, almost as many times the device responded with a garbled char, which I assume it still thinks is a "G"..
And yes, "Totally unreliable" seems to be a fair definition for this dongle..
Sorry, thought I could be of some help..
-
Massimo Callegari
No problem Gianpaolo.
I'll add one more bit. It seems the device behaves differently on Linux and on Windows.
That's why I declared it as "working" different times and then I had to go back on my steps.
I'll add one more bit. It seems the device behaves differently on Linux and on Windows.
That's why I declared it as "working" different times and then I had to go back on my steps.
-
gcarapucci
I see.
Then again that might be due to differences between libftdi and ftd2xx.. or the os's tend to initialize serial lines differently on their own - like how windows sets dtr low from the get-go while linux doesn't (if i remember correctly).. which is, i now see, irrelevant since hardware flow control is disabled.
Ok, i'll go back to testing on my own, see if i can squeeze something useful from this dongle.
Thank you for the time and attention.
Then again that might be due to differences between libftdi and ftd2xx.. or the os's tend to initialize serial lines differently on their own - like how windows sets dtr low from the get-go while linux doesn't (if i remember correctly).. which is, i now see, irrelevant since hardware flow control is disabled.
Ok, i'll go back to testing on my own, see if i can squeeze something useful from this dongle.
Thank you for the time and attention.