ch341 usb dongle

[Florian Bantner]

Hi,

I'm quiet new to lighting with dmx and linux. (But I have some experience in lighting, electronics and linux on their own s. e.g.: http://www.blinkenlightballs.de/ )

So I looked into it, found qlightcontroller, ola and this very cheap (about $3) usb dongle: http://de.aliexpress.com/item/USB-to-RS485-USB-485-Converter-CH340-chip-Adapter-Support-Win7-ME-2000-XP-Vista/1154787985.html

The device registers as "Bus 003 Device 003: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter" and creates /dev/ttyUSB0 if plugged in.

It aparently uses ch341 kernel driver.

I've installed ola on ubuntu 14.04 via deb repositories (by the way: the website doesn't mention the 14.04 repos).

But now I'm pretty stuck. Which OLA driver/plugin do I need and how can I check it is really working? I tried creating

/var/lib/ola/conf/ola-usbserial.conf

and the Gui is telling me

Config Location /var/lib/ola/conf/ola-usbserial.conf

Enabled in Config File Yes

Active Yes

but if I try to create a universe there is no UsbSerial something which I could check.

So what do I do next?

Thanks in advance

Florian

[Sean Sill]

When you start olad please use "olad -l 3" Then check to see if olad finds the device. 

[Florian Bantner]

Hi Sean,

seems like it finds it but doesn't like it ...?!

Olad.cpp:84: OLA Daemon version 0.9.1

OlaDaemon.cpp:114: Using configs in /home/flo/.ola

OlaServer.cpp:494: Updated PID definitions.

OlaServer.cpp:212: Server UID is 7a70:1400400a

HTTPServer.cpp:463: HTTP Server started on port 9090

PluginManager.cpp:77: Skipping FTDI USB DMX because it was disabled

PluginManager.cpp:77: Skipping UART native DMX because it was disabled

PluginManager.cpp:108: Trying to start ArtNet

DeviceManager.cpp:116: Installed device: ArtNet [10.64.0.20]:2-1

PluginManager.cpp:112: Started ArtNet

PluginManager.cpp:108: Trying to start Dummy

DeviceManager.cpp:116: Installed device: Dummy Device:1-1

PluginManager.cpp:112: Started Dummy

PluginManager.cpp:108: Trying to start E1.31 (sACN)

DeviceManager.cpp:116: Installed device: E1.31 (DMX over ACN) [10.64.0.20]:11-1

PluginManager.cpp:112: Started E1.31 (sACN)

PluginManager.cpp:108: Trying to start ESP Net

DeviceManager.cpp:116: Installed device: ESP Net [10.64.0.20]:4-1

PluginManager.cpp:112: Started ESP Net

PluginManager.cpp:108: Trying to start KarateLight

IOUtils.cpp:38: Failed to open /dev/kldmx0: No such file or directory

KaratePlugin.cpp:79: Could not open /dev/kldmx0 No such file or directory

PluginManager.cpp:112: Started KarateLight

PluginManager.cpp:108: Trying to start KiNET

DeviceManager.cpp:116: Installed device: KiNet Device:16-1

PluginManager.cpp:112: Started KiNET

PluginManager.cpp:108: Trying to start Milford Instruments

PluginManager.cpp:112: Started Milford Instruments

PluginManager.cpp:108: Trying to start Enttec Open DMX

IOUtils.cpp:38: Failed to open /dev/dmx0: No such file or directory

OpenDmxPlugin.cpp:80: Could not open /dev/dmx0 No such file or directory

PluginManager.cpp:112: Started Enttec Open DMX

PluginManager.cpp:108: Trying to start OSC

OSCDevice.cpp:88: No targets specified for OSC Output port 0

OSCDevice.cpp:88: No targets specified for OSC Output port 1

OSCDevice.cpp:88: No targets specified for OSC Output port 2

OSCDevice.cpp:88: No targets specified for OSC Output port 3

OSCDevice.cpp:88: No targets specified for OSC Output port 4

DeviceManager.cpp:116: Installed device: OSC Device:14-1

PluginManager.cpp:112: Started OSC

PluginManager.cpp:108: Trying to start Renard

PluginManager.cpp:112: Started Renard

PluginManager.cpp:108: Trying to start SandNet

DeviceManager.cpp:116: Installed device: SandNet [10.64.0.20]:7-1

PluginManager.cpp:112: Started SandNet

PluginManager.cpp:108: Trying to start ShowNet

DeviceManager.cpp:116: Installed device: ShowNet [10.64.0.20]:3-1

PluginManager.cpp:112: Started ShowNet

PluginManager.cpp:108: Trying to start SPI

PluginManager.cpp:112: Started SPI

PluginManager.cpp:108: Trying to start StageProfi

StageProfiDevice.cpp:84: StageProfiPlugin: no device found at /dev/ttyUSB0

PluginManager.cpp:112: Started StageProfi

PluginManager.cpp:108: Trying to start Serial USB

WidgetDetectorThread.cpp:204: Found potential USB Serial device at /dev/ttyUSB0

WidgetDetectorThread.cpp:210: new descriptor @ 0x7f6168000d10 for /dev/ttyUSB0

WidgetDetectorThread.cpp:373: trying stage 0 for 0x7f6168000d10

PluginManager.cpp:112: Started Serial USB

PluginManager.cpp:108: Trying to start USB

PluginManager.cpp:112: Started USB

PluginManager.cpp:108: Trying to start Pathport

DeviceManager.cpp:116: Installed device: Pathport [10.64.0.20]:9-1

PluginManager.cpp:112: Started Pathport

UsbProWidgetDetector.cpp:312: Usb Widget didn't respond to messages, esta id 0, device id 0

WidgetDetectorThread.cpp:373: trying stage 1 for 0x7f6168000d10

WidgetDetectorThread.cpp:370: no more detectors to try for  0x7f6168000d10

[Peter Stuge]

Florian Bantner wrote:
> The device registers as "Bus 003 Device 003: ID 1a86:7523 QinHeng
> Electronics HL-340 USB-Serial adapter" and creates /dev/ttyUSB0 if
> plugged in.
> It aparently uses ch341 kernel driver.

I have a problem with a USB device like this; my hardware doesn't
correctly transfer data.

Apparently the driver published by the vendor does work, I haven't
yet investigated that.


//Peter

[Simon Newton]

This appears to be a generic USB to 485 convertor. I doubt it will
work with any of the OLA plugins.

The logs show that the USB Pro plugin is trying to communicate with
it, but because it doesn't have an onboard microprocessor it won't
work as a USB Pro device.

Simon

> --
> The Open Lighting Project: open-l...@googlegroups.com, #openlighting
> (irc.freenode.org)
> To unsubscribe from this group, send email to
> open-lightin...@googlegroups.com
> For more options, visit https://groups.google.com/groups/opt_out?hl=en

[Florian Bantner]

Hi Peter, Simon,

shouldn't this work simply (tm) with the plain serial driver?

Until now I thought dmx was just: send a break, then 513 bytes data, repeat. But there seems to be more to it?

regards,

Florian

[Peter Stuge]

Florian Bantner wrote:
> shouldn't this work simply (tm) with the plain serial driver?
> Until now I thought dmx was just: send a break, then 513 bytes data,
> repeat. But there seems to be more to it?

The timing isn't based on 1843200 Hz like common UARTs. See
https://en.wikipedia.org/wiki/DMX512


//Peter

[Peter Newman]

I think you want the FTDI USB DMX plugin enabled instead Florian. That uses basic FTDI interfaces to generate DMX.

[Simon Newton]

The issue is this isn't an FTDI chip, so it's not going to show up
under libftdi.


Simon

[Florian Bantner]

Hello Everyone,

a little wonder has happened: Trying some time I figured out, that I had a general problem with the dongle: echoing something with 'echo foo > /dev/ttyUSB0' blocked every time. I tried writing a little c programm which only opens the port with fd = open( ... ) and it did block, too.

So I went to a friend who gave me the dongle and asked him if he got it to work. He saied yes, put it in his computer and it worked. I put it in mine again and now it was working here, too?!?

So now I'm one step further: 

olad/PluginManager.cpp:104: Trying to start USB

olad/PluginManager.cpp:108: Started USB

olad/PluginManager.cpp:104: Trying to start UART native DMX

common/io/ExtendedSerial.cpp:69: Port speeds for 37 are 250000 in and 250000 out

common/thread/Thread.cpp:190: Thread , policy SCHED_OTHER, priority 0

olad/DeviceManager.cpp:105: Installed device: UART native DMX:20-/dev/ttyUSB0

olad/PortManager.cpp:119: Patched 20-/dev/ttyUSB0-O-0 to universe 0

olad/PluginManager.cpp:108: Started UART native DMX

plugins/uartdmx/UartDmxThread.cpp:136: Granularity for UART thread is GOOD

But now I have another problem:

I've got a cameo rgb spot connected which is configured for rgb on channels 1-3. (3Ch2)

(http://www.cameolight.com/produkte/led-flat-par-scheinwerfer/flat-par-can-tri-3w-ir-7-x-3-w-high-power-tri-colour-flat-led-rgb-par-scheinwerfer-in-schwarzem-gehaeuse-mit-ir-fernbedienungsoption/?force_sid=ct4psaph92f15kds1ujqcuinf0)

This does work with an attached cameo 6 channel light controller (again ch 1-3)

Trying to control it with ola web gui it seems there is still something wrong: Now I can controll the light somewhat flickery with channels 2, 4, 6 and much more flickery with 1, 3, 5.

I guessed it could be that I've a wrong baud rate because of some missbehaviour of the dongle/driver so I tried recompiling oled with 125000 baud, but that didn't work at all.

So what could that be?

Thanks again,

Florian

[Simon Newton]

+Richard who wrote the plugin. I'm not sure it's been tested on
anything other than a Ras Pi.


Flickering lights indicates a timing problem.

Simon

>
> Thanks again,
>
> Florian

[KWMATIK]

Serial USB PORT is not same like DMX512 250kBit/s. Software use part of FTDI libs to generate DMX512 signal.
USB to serial chips like ch341 , pl2303 can't generate DMX512, software open only virtual com (current solutions)
Similar issue -> If you use car  software VAG-COM then you must use RS232c interface or based on FTDI , another not work .  If you use converter USB/rs232c based on ex: pl2303 or another but non-FTDI and connect with original RS232c VAG-com interface -> not work.

[Florian Bantner]

Still fighting with this device.

Now I've got an oscilloscope to look into it.

As far as I can see I have these paramters:

+/-: 0..4V

break: 5ms

mark: ~ 1ms

rate: 250kbaud

protocol: 8N1 <-----

So it seems there lies my problem. Since I now found that Linux doesn't support setting CPORTB (2 stop bits) on this device I think I give up.

Thanks for the help anyway.

Florian

[Peter Stuge]

Florian Bantner wrote:
> protocol: 8N1 <-----
>
> So it seems there lies my problem. Since I now found that Linux doesn't
> support setting CPORTB (2 stop bits) on this device I think I give up.

Did you look at the vendor driver source code?


//Peter

[Richard Ash]

I don't think it has. PC serial ports don't work at all because the
UART clock is too small, so the only suitable port I have is the Ras Pi.

You have passed the first hurdle, to get the correct baud rate set from
Linux, but this doesn't necessarily mean that the device is actually
running at 250kbaud - if the clock isn't fast enough, but the device
doesn't report this back properly, you may get the log message when it
isn't true. I had a lot of problems with this getting the Pi working
because of the need to up-clock it's UART with a boot option. I suspect
this isn't the case because it sort of works, but can't be certain
(double or half rate may work by accident!).

The other problem is that the USB UART doesn't have hardware
interrupts, so will likely have more ragged timing (also sensitive to
other USB bus activity) than an integrated UART does. The FTDI driver
is able to mitigate this by using vendor-specific
commands/functionality, but this obviously won't work for your dongle.

Really you need access to an oscilloscope to check what is coming out of
the dongle. This can check both the baud rate is connect, and that the
timing is at least reasonably right.

> Flickering lights indicates a timing problem.

Or that the fixture is in strobe / sound activated mode ...
From the web I can see that the fixture has a number of modes,
including a 6 channel mode.

The user manual seems to be here:
http://www.adamhall.com/en/Cameo_FLAT_PAR_CAN_TRI_3W_IR_-_7_x_3_W_TRI_Colour_FLAT_LED_PAR_Can_RGB_in_black_housing_with_IR-remote_control_capability.html
Page 14 onwards has the DMX channel maps for the four different modes
available.

Assuming you are in 6 channel mode, then you need to have channel 1 up
(master dimmer) but channel 2 at zero (because that is strobe, which
will definitely flicker!), and channel 6 at zero to get colour control
on channels 3 to 5!

Richard

[Richard Ash]

On Tue, 10 Feb 2015 01:31:26 -0800 (PST)
Florian Bantner <f.ba...@axon-e.eu> wrote:
> So I looked into it, found qlightcontroller, ola and this very cheap
> (about $3) usb
> dongle:
> http://de.aliexpress.com/item/USB-to-RS485-USB-485-Converter-CH340-chip-Adapter-Support-Win7-ME-2000-XP-Vista/1154787985.html
>
> The device registers as "Bus 003 Device 003: ID 1a86:7523 QinHeng
> Electronics HL-340 USB-Serial adapter" and creates /dev/ttyUSB0 if
> plugged in.
> It aparently uses ch341 kernel driver.

This chip appears to because various people trouble:
http://article.gmane.org/gmane.linux.usb.general/121997/

Richard