(questions and answers from e-mail)
Hi Claude,
I recently found your website while searching for info on building Artnet nodes and USB to DMX interfaces for dmx lighting using the arduino platform. I had a couple questions regarding a couple of your ino files.
Firstly, from what I read the LXUSARTDMX should simulate an ENTTEC DMX USB Pro interface, so am I correct that the interface will then show up in other software as an ENTTEC pro.....ie Q Light Controller, MagicQ, Freestyler, etc? I am asking because I tried another persons code that claimed to emulate an ENTTEC DMX USB Pro, but it would not even show up as an interface at all.......LOL. The other thing I noted is I cannot seem to compile this code for the Arduino Nano.....it compiles for the Leonardo & Mega just fine. I am curious if you know why it fails on the Nano???
Secondly, I am also quite interested in your Artnet/Sacn code......is the mode you want it to run determined by how the software sends traffic.....ie multicast or broadcast? In other words, does it auto select the mode? Or can you explain a little more?
Thanks for a great list of libraries to experiment with on arduino boards.
Github Library Questions
Github Library Questions
Last edited by admin on Sat Dec 24, 2016 11:06 pm, edited 1 time in total.
The answers to your questions are a little involved. I'll do my best to explain how the DMX driver library works.
The LXUSARTDMX driver uses a serial interface built into the microcontroller. The microcontroller's serial interface is sufficient to handle the timing of serial data for DMX. But, to produce the +/- signal for actual DMX, the output needs to be converted with a differential driver chip.
Some microcontrollers have more than one serial interface in their circuitry. This means they can use one serial interface to receive commands and at the same time use another to send DMX. There is an example in the LXUSARTDMX library that accepts serial control using the ENTTEC DMX USB Pro api. This example accepts serial messages that follow the format specified by ENTTEC and also sends DMX using the library's code. To make this work requires that the microcontroller contain at least two serial interfaces in its design. The 32U4 processor of the Leonardo has a built-in USB interface. And it has a UART that can be used for DMX output. The Mega has 4 UARTs. ATmega328P microcontrollers such as the one used by the Nano and Uno, etc. have only a single serial interface. They cannot run this particular example.
The ability of controller software to use a device other than an actual ENTTEC DMX USB Pro depends on how that software connects to the device, including the driver it uses. The api specifies the format and meaning of messages sent between the computer and the widget. But, there's more to it than just that. The actual DMX USB Pro uses a chip that converts from USB to serial made by FTDI. FTDI provides two different types of drivers for this chip. The driver allows software running on the computer to communicate via USB with the FTDI chip (and therefore with the microcontroller in the widget that speaks regular asynchronous serial, not USB). The D2XX type of driver will only work properly with genuine FTDI chips. If your controller software is limited to using a D2XX driver to output to a widget, then it is not possible to use an Arduino alone to substitute for an actual ENTTEC widget (you can still do it with an FTDI serial converter such as an "FTDI Friend"). If your controller is able to use a virtual com port (VCP) driver to talk to a widget, then it is possible that it can communicate with an Arduino and use it in place of an actual ENTTEC device.
There is yet one more issue that might prevent your software from using an Arduino in place of an ENTTEC widget. That is, it must be able to connect to ANY serial device, not just an ENTTEC one. The FTDI chip is programmed by a manufacturer with a code that identifies what type of device it is being used in. Some control software looks at this ID when searching for a widget to connect to. It is "smart" and will not show you serial devices that do not have this ID. You'd need both a genuine FTDI chip and to program that chip with the ENTTEC ID in order for the control software to think that it was talking to an actual ENTTEC device. Other control software (such as LXConsole) allows a more generic serial connection to be used. The drawback of a controller allowing this is that someone could try to output DMX using their serial controlled toaster. This is more flexible, but it requires the user to identify the serial connection used by the widget rather than identifying the connection for the user.
You can look at the comments in the examples for the LXDMXEthernet library for how they work with Art-Net and sACN. Most of the examples require manual configuration of the sketch. ATmega328P processors do not have enough memory to support fully automatic switching of modes or protocols. The topic of DMX over ethernet (and networking in general) involves more than can be covered quickly. In brief, Art-Net is either broadcast or unicast. An Arduino with an ethernet shield will receive either broadcast or unicast packets as long as they are sent to the correct port (and the network/addresses are properly configured and compatible). sACN is either multicast or unicast. A network socket must be specifically configured to join a multicast group for that method to work. You must do this by editing the example sketch before you upload it.
The LXUSARTDMX driver uses a serial interface built into the microcontroller. The microcontroller's serial interface is sufficient to handle the timing of serial data for DMX. But, to produce the +/- signal for actual DMX, the output needs to be converted with a differential driver chip.
Some microcontrollers have more than one serial interface in their circuitry. This means they can use one serial interface to receive commands and at the same time use another to send DMX. There is an example in the LXUSARTDMX library that accepts serial control using the ENTTEC DMX USB Pro api. This example accepts serial messages that follow the format specified by ENTTEC and also sends DMX using the library's code. To make this work requires that the microcontroller contain at least two serial interfaces in its design. The 32U4 processor of the Leonardo has a built-in USB interface. And it has a UART that can be used for DMX output. The Mega has 4 UARTs. ATmega328P microcontrollers such as the one used by the Nano and Uno, etc. have only a single serial interface. They cannot run this particular example.
The ability of controller software to use a device other than an actual ENTTEC DMX USB Pro depends on how that software connects to the device, including the driver it uses. The api specifies the format and meaning of messages sent between the computer and the widget. But, there's more to it than just that. The actual DMX USB Pro uses a chip that converts from USB to serial made by FTDI. FTDI provides two different types of drivers for this chip. The driver allows software running on the computer to communicate via USB with the FTDI chip (and therefore with the microcontroller in the widget that speaks regular asynchronous serial, not USB). The D2XX type of driver will only work properly with genuine FTDI chips. If your controller software is limited to using a D2XX driver to output to a widget, then it is not possible to use an Arduino alone to substitute for an actual ENTTEC widget (you can still do it with an FTDI serial converter such as an "FTDI Friend"). If your controller is able to use a virtual com port (VCP) driver to talk to a widget, then it is possible that it can communicate with an Arduino and use it in place of an actual ENTTEC device.
There is yet one more issue that might prevent your software from using an Arduino in place of an ENTTEC widget. That is, it must be able to connect to ANY serial device, not just an ENTTEC one. The FTDI chip is programmed by a manufacturer with a code that identifies what type of device it is being used in. Some control software looks at this ID when searching for a widget to connect to. It is "smart" and will not show you serial devices that do not have this ID. You'd need both a genuine FTDI chip and to program that chip with the ENTTEC ID in order for the control software to think that it was talking to an actual ENTTEC device. Other control software (such as LXConsole) allows a more generic serial connection to be used. The drawback of a controller allowing this is that someone could try to output DMX using their serial controlled toaster. This is more flexible, but it requires the user to identify the serial connection used by the widget rather than identifying the connection for the user.
You can look at the comments in the examples for the LXDMXEthernet library for how they work with Art-Net and sACN. Most of the examples require manual configuration of the sketch. ATmega328P processors do not have enough memory to support fully automatic switching of modes or protocols. The topic of DMX over ethernet (and networking in general) involves more than can be covered quickly. In brief, Art-Net is either broadcast or unicast. An Arduino with an ethernet shield will receive either broadcast or unicast packets as long as they are sent to the correct port (and the network/addresses are properly configured and compatible). sACN is either multicast or unicast. A network socket must be specifically configured to join a multicast group for that method to work. You must do this by editing the example sketch before you upload it.