DMX lighting code doesn't seem to work

[smcameron]

Not to say it ever worked, so this is not new breakage.

I finally got some dmx hardware, specifically, the hardware mentioned here, because it is cheap:

https://artemis.forumchitchat.com/post/easy-plug-play-dmx-28-10051243

(Although not as cheap as the $28 that thread claims.)

In particular, I got a USB to DMX adapter that shows up like this:

[43687.488263] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[43687.488280] ftdi_sio 1-1:1.0: device disconnected
[43693.014699] usb 1-1: new full-speed USB device number 7 using xhci_hcd
[43693.184089] usb 1-1: New USB device found, idVendor=0403, idProduct=6001
[43693.184091] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[43693.184093] usb 1-1: Product: FT232R USB UART
[43693.184094] usb 1-1: Manufacturer: FTDI
[43693.184095] usb 1-1: SerialNumber: A10864I4
[43693.186601] ftdi_sio 1-1:1.0: FTDI USB Serial Device converter detected
[43693.186642] usb 1-1: Detected FT232RL
[43693.186852] usb 1-1: FTDI USB Serial Device converter now attached to ttyUSB0

I believe it is a RS485 (like RS232 but higher voltage and differential so cables can be longer.)

First thing I notice is that I can't seem to do TCGETS2 or TCSETS2 ioctl to get/set the baud rate on it. I get "inappropriate ioctl for device." Ok, perhaps it is permanently set to the right baud rate, and I'm talking to it via USB, so... whatever, comment that part out.

I tried a few more things (and found and fixed a couple bugs by staring at the code) but this is one of those deals where if it doesn't work, it just sits there and does nothing, giving no hints about what you've done wrong.

The lights I got are "Lightahead LA-18w DMX512 RGB LED PAR Light, Red, Green, Blue".

And of course I got some DMX cables (similar to microphone cables with XLR connectors.)

The lights have a few buttons on the back for switching the modes. The demo modes seem to work, and the slave mode seems to work (one light in demo mode can drive the slave light to make it mimic the demo light.)

When I put them in DMX mode (A001 or D001, say) nothing happens. D001 is "4 channel" dmx mode... the 1st 3 channels are Red Green and Blue. The 4th channel is (and I quote) "Fourth channel: save the setting from the 0-150 or 161-255 to 151-160 when the interval moved to save when". It also mentions a "fifth channel" (presumably only there in the 7 channel dmx mode). Again I quote: "Fifth channel from the 0-150 or 161-255 to 151-160 when the interval moved completely out of the dimming mode."

Ok, well, that certainly could not be clearer. :-/

My code in snis_dmx (in particular snis_dmx_set_rgb() expects 3 channel dmx. Tried hacking it to use 4 bytes per, on the theory that the "4 channel dmx" the lights use means I need 4 bytes per light, not 3.) Tried a few other things I can't remember. All behave the same (nothing happened.)
Oh, I shouldn't say "nothing happened". The USB to DMX converter has a transparent plastic case, and inside is a small blue LED. When transmitting out /dev/ttyUSB0, the LED on the converter board inside the transparent case lights up and flashes. But the DMX controllable par lights do nothing.

I was running my test program:

make bin/test_snis_dmx
./bin/test_snis_dmx /dev/ttyUSB0

Had to chown /dev/ttyUSB0 as it is owned by root when it's created.

So it is all very mysterious. So mysterious, I likely will not figure it out without some outside help.

I also tried looking in EmptyEpsilon's code, but no luck so far.

[smcameron]

Also tried using ENTEC start code (based on this thread https://bridgesim.net/discussion/399/dmx-usb-interface since my USB to DMX dongle is also a lixada ) as here: https://github.com/daid/EmptyEpsilon/blob/master/src/hardware/devices/enttecDMXProDevice.cpp#L69 - but so far no luck.

[smcameron]

Hmmmm. The existence of this repo is interesting: https://github.com/lowlander/dmx_usb_module

It's a USB driver for Linux 2.6 kernel for the Enttec DMX USB dongle.

A "small" problem to solve was to make the kernel clear that it should 
use my driver for the dongle and not the standard usbserial driver. 
Since I don't have any other USBserial devices with the samechip type I 
just removed the ftdi_sio.ko module, and changed the /etc/hotplug/usb.distmap 
to point to my module. To support both the ftdi_sio.o module and the 
dmx_usb.o module the ftdi_sio.o module should be patched and the Product ID 
for the FT232BM should be removed from it, this will mean all other 
serial-usb devices are still supported just not the one with FT232BM chips, 
since it isn't possible to differentiate DMX-USB and normal-serial versions.

Hmm. I am sure I'm using the standard usbserial driver. Perhaps this is a problem.

[smcameron]

Hmm, things are not looking too promising. First, there's this (via the homepage of abovementioned dmx_usb_module, here http://www.erwinrol.com/dmx512/ ):

One of the hardest things to get right is the bit timing; since DMX uses a 250kbit/sec speed,
it is not possible to generate DMX with a standard PC serial port [ ... ] The problem of
software not being available for Linux is normally solved by the Open Source community
writing their own; this is what Michael Stickel did for a lot of DMX hardware. His DMX4Linux
site has Linux drivers for many different DMX cards and USB-Dongles.

The DMX4LInux site is here: https://llg.cubic.org/dmx4linux/index.html
and the latest driver there is for a 2.6 kernel circa 2008, and there is this note:

2009-04-03 Maintaining the dmx4linux drivers gets more frustrating with every new release
of the Linux kernel. The kernel people simply don't stop to change their internal APIs and it is
really difficult for a small project like this to keep track of the ever evolving/changing kernel.
We're currently preparing a new release for a fairly new Linux 2.6 kernel, however we know
that it'll probably be outdated the day it is released.

So perhaps this goes some way to explain why people seem to make all these Arduino + 485 chip gizmos to drive DMX lights. But... maybe the thing I bought is such a gizmo? Or maybe this info is outdated? The thing I bought claims to support linux, so... who knows.

edit: well this page does not claim linux support: https://www.lixada.com/p-l0385.html but mine didn't come with a CD and doesn't look exactly like that. Maybe mine is a knock-off of it though?

[smcameron]

but mine didn't come with a CD

Actually, it did. But there's nothing on it for linux. However it does contain a link to this:
https://www.ftdichip.com/Drivers/VCP.htm

And on that page it says:

All FTDI devices now supported in Ubuntu 11.10, kernel 3.0.0-19
Refer to TN-101 if you need a custom VCP VID/PID in Linux
VCP drivers are integrated into the kernel.

And the word "kernel" links to: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/serial/

which is to say the normal linux usb serial driver. Which it may be the case that the normal linux usb serial driver can't work for DMX according to http://www.erwinrol.com/dmx512/

TN-101 refers to this: https://www.ftdichip.com/Support/Documents/TechnicalNotes/TN_105%20Adding%20Support%20for%20New%20FTDI%20Devices%20to%20Mac%20Driver.pdf

which appears to apply to the serial driver for the Macintosh (which has an interesting feature of aliasing baud rates to non-standard values, so to get the non-standard DMX baud rate of 250000, you can alias 300 baud to 250000 (because who the hell uses 300 baud anyway?). However this seems to be something specific to the Mac serial driver.)