DIY Teensy/Arduino Serial Device

[DaAwesomeP]

Hi,

I am developing a light display that relies on many RGB LED strips connected to a Teensy microcontroller running FastLED. I would like to be able to access the LEDs via Artnet/DMX over USB serial. I think that OLA is the best way to do this. The Teensy 3.2 can operate at 2000000 baud or 2 Mb/s (higher than standard DMX) with 0% error. I will need to control 904 channels spread across two universes on one Teensy and one USB serial port. I couldn't find a simple Arduino library, example code, or specification docs on how to interact with OLA via serial. I found an "Arduino RGB mixer" repo, but there weren't any docs. Becuase the LEDs are connected to the Teensy and it is a one-controller DMX network, I do not need RDM. How can I receive messages from OLA over serial? Is there a doc page or spec for it?

Thanks!

DaAwesomeP

[Peter Newman]

Hi DaAwesomeP,

If you want two universes on one device, you'll need to either go down the Art-Net route as you say, or extend the rgbmixer example to pretend to be a two port Enttec dongle, or finally implement some other probably custom, serial protocol.

There are various docs for the Arduino RGB Mixer:
https://github.com/OpenLightingProject/rgbmixer/blob/master/README
https://github.com/OpenLightingProject/rgbmixer/blob/master/Makefile
Also
https://wiki.openlighting.org/index.php/Arduino_RGB_Mixer

[DaAwesomeP]

Thank you for your response! I see that the DMXking UltraDMX Pro implements 2 universes over USB. I found the spec for how it works in these two documents: http://dmxking.com/downloads/ultraDMX%20Pro%20User%20Manual%20(EN).pdf https://dol2kh495zr52.cloudfront.net/pdf/misc/dmx_usb_pro_api_spec.pdf. I'm going to try to implement this protocol. Can I simply direct OLA to a serial port and tell it what device the serial port is or does OLA rely on identifying the device by USB information? The computer will treat it as a Teensy and won't know that it is a DMX device. To be functional, I think that I only need to implement label 100 and label 101. Does OLA use any other labels or rely on any responses from the UltraDMX device?

[Simon Newton]

Make sure you implement 77 & 78 as well:

https://wiki.openlighting.org/index.php/USB_Protocol_Extensions

> --
> 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

[Peter Newman]

Ah yes, I forgot about the DMXking option for two ports. TBH it's probably easier, we have them in our code here:
https://github.com/OpenLightingProject/ola/blob/master/plugins/usbpro/UltraDMXProWidget.h#L50

The Enttec option involves API keys and all sorts, so wouldn't be compatible with other software anyway, at least the DMXking route should be:
https://github.com/OpenLightingProject/ola/blob/master/plugins/usbpro/EnttecUsbProWidgetImpl.h#L49

In terms of the DMXking route, you'd either need to pretend to be his ESTA ID (which is naughty/bad), or register your own:
http://tsp.esta.org/tsp/working_groups/CP/mfctrIDs.php

Then it's just a case of tweaking here
https://github.com/OpenLightingProject/ola/blob/3cf5575b9b0297854f777ca7378eb84c3389b09d/plugins/usbpro/WidgetDetectorThread.cpp#L254

You'll also need to support at least manufacturer and device name from here:
https://wiki.openlighting.org/index.php/USB_Protocol_Extensions#Device_Manufacturer.2C_Label_.3D_77.2C_no_data
https://wiki.openlighting.org/index.php/USB_Protocol_Extensions#Device_Name.2C_Label_.3D_78.2C_no_data

Aside from all of that, as long as it appears as a serial port in Linux (tweak device prefixes if necessary):
https://github.com/OpenLightingProject/ola/blob/master/plugins/usbpro/README.md#config-file-ola-usbserialconf

Then you're all good (I think!)!

[Peter Newman]

What he said! :)

> open-lighting+unsubscribe@googlegroups.com

[DaAwesomeP]

Wow! Thank you both for the info!

My current plan is to implement labels 100, 101, 77, and 78. I'm not sure that I'm a "manufacturer," so I'll fake the ETSA ID for the time being (personal use only). If I open source this as a reusable Arduino library (I might), then I'll register an ID and make a pull to OLA. I've found various snippets of Arduino code emulating Enttec-like devices, so I should get this to work very quickly.

Thank you all again for helping me! My other route would have been to program light sequences in firmware, to buy more hardware to give the Teensy a DMX port and buy an actual USB-DMX adapter, or to make a laggy, patched-together serial protocol and adapter program.

[DaAwesomeP]

OK, I got something programmed, but it doesn't work.

Here's what I intercepted via serial:

< 0x7e (~)
< 0x4d (M)
< 0x00
< 0x00
< 0xe7
>     0x6a (j)
>     0x6b (k)
>     0x54 (T)
>     0x65 (e)
>     0x65 (e)
>     0x6e (n)
>     0x73 (s)
>     0x79 (y)
>     0x20
>     0x44 (D)
>     0x4d (M)
>     0x58 (X)
< 0x7e (~)
< 0x4e (N)
< 0x00
< 0x00
< 0xe7
>     0x02
>     0x00
>     0x46 (F)
>     0x61 (a)
>     0x6b (k)
>     0x65 (e)
>     0x20
>     0x55 (U)
>     0x6c (l)
>     0x74 (t)
>     0x72 (r)
>     0x61 (a)
>     0x44 (D)
>     0x4d (M)
>     0x58 (X)
>     0x20
>     0x50 (P)
>     0x72 (r)
>     0x6f (o)
< 0x7e (~)
< 0x0a
< 0x00
< 0x00
< 0xe7
< 0xa5
< 0x14
< 0x00
< 0x00
< 0xb9
< 0x72 (r)

Here is what is in the log:

plugins/usbpro/UsbProWidgetDetector.cpp:323: Usb Widget didn't respond to messages, esta id 0, device id 0
plugins/usbpro/WidgetDetectorThread.cpp:384: trying stage 1 for 0x7f537c000d90
plugins/usbpro/WidgetDetectorThread.cpp:381: no more detectors to try for  0x7f537c000d90
common/io/Serial.cpp:245: Released /var/lock/LCK..ttyAAM0

Which part of my response is incorrect? Does the device manufacturer and device name need to be exactly the same?

[Peter Newman]

You're missing the packet header and footer in your replies from the looks of things, without double checking our code, the Enttec doc is a bit vague.

[DaAwesomeP]

OK, I didn't think that I needed the 0x7E and 0xE7 for those messages. I'll add them in and try it. If it works, then the message tables in the wiki to show that those are needed: https://wiki.openlighting.org/index.php/USB_Protocol_Extensions#Send_DMX_Multiple_Universes.2C_Label_.3D_100.2C_101

[DaAwesomeP]

I got it to work! I had to format the messages completely. The wiki should be updated to reflect this. I also needed label 10 (serial number):

< 0x7e (~)
< 0x4d (M)
< 0x00
< 0x00
< 0xe7

>     0x7e (~)
>     0x4d (M)
>     0x02
>     0x00
>     0x6b (k)
>     0x6a (j)
>     0xe7

< 0x7e (~)
< 0x4e (N)
< 0x00
< 0x00
< 0xe7

>     0x7e (~)
>     0x4e (N)
>     0x02
>     0x00
>     0x02
>     0x00
>     0xe7

< 0x7e (~)
< 0x0a
< 0x00
< 0x00
< 0xe7

>     0x7e (~)
>     0x0a
>     0x04
>     0x00
>     0xff
>     0xff
>     0xff
>     0xff
>     0xe7
< 0x7e (~)
< 0x03
< 0x02
< 0x00
< 0x00
< 0x00
< 0xe7
< 0x7e (~)
< 0x03
< 0x02
< 0x00
< 0x00
< 0x00
< 0xe7

plugins/usbpro/UsbProWidgetDetector.cpp:536: Detected USB Device: ESTA Id: 0x6a6b, device Id: 0x0002, serial: 0xffffffff, f/w version: N/A
olad/plugin_api/DeviceManager.cpp:105: Installed device: :5-165165165165Enter code here...

Two output and one input connection show up in the OLA web UI. I think that it'll work!

[Peter Newman]

Excellent, glad you got it sorted. Are you willing to share it for others to use, it's something that comes up occasionally?

You should use TeensyMAC's either MAC or serial methods to extract a genuinely unique serial number from each Teensy.
https://github.com/FrankBoesing/TeensyMAC

I'll see if we can clarify things on the wiki, but those tables aren't intended to be complete packet breakdowns, just details of the additional proposed messages with similar levels of detail to the original Enttec USB Pro API docs.

[DaAwesomeP]

That serial number method will work with Teensy devices, but I'll have to come up with something else for Arduino/ATmega devices. I've began to convert my code from a patched-together program into a class here: https://github.com/DaAwesomeP/dmxusb. It's got some odd bugs (right now it only responds to label 77 and I don't know why), but when I sort out the bugs I'll publish it to the Arduino library database and register my own ETSA.

Thank you again for your help! I'm surprised that I'm the first person to do this and publish working code. All of the other snippets of Enttec-emulating Arduino code only implement label 6.

[Stefan Krüger]

Hi DaAwesomeP,

regarding

I'm surprised that I'm the first person to do this and publish working code

i had this on my wish-to-do-list for as long as i did know of the RGBMixer ;-)

some time ago i tried to get the RGBMixer code working on an Arduino Leonardo type device (ATmega32U4) but failed..

as of this time i never got to the point to try implementing it from ground up  (no concrete need..)

so iam happy to try your code and help if i can :-)

sunny greetings

stefan

[DaAwesomeP]

Hi all,

I have released the first fully functional version of the library! I've applied for it to be added to he Arduino Library Manager, so it should show up there shortly. It works very well with OLA, and I've been testing it by driving APA102 LEDs with FastLED. If you find an issues, please open them on GitHub. I'm going to apply for my own ETSA IDs and add them to the library as modes modes 2 and 3.

https://github.com/DaAwesomeP/dmxusb

https://github.com/DaAwesomeP/dmxusb/releases/tag/v0.0.1

Thanks again for all of your help! I hope that my library is of use to many people down the road. Happy Thanksgiving (if you celebrate it)!

[annist...@gmail.com]

Very nice, thank you so much for releasing this!  I must have missed it, but do you have the hardware components required for this library?  I realize it uses a teensy 3.2, but anything else?  Is there a wiring diagram?

[DaAwesomeP]

This library is only a software implementation. It gives an API to receive DMX messages over USB. No extra hardware is required to use it. It simply gives you the DMX messages. It should work on any Arduino-compatible platform (Arduino, Teensy, ESP8266, etc.). I made this library to add flexibility to projects that want to implement DMX but don't want to buy all of the hardware. For example, I am going to use the library to interface with 300 APA102 LEDs, and because of the library I don't need to buy any extra hardware or USB to DMX adapters—I can send it DMX messages over USB.

If you are looking to actually put a 3 or 5 pin DMX port on the Arduino and use it as a USB to DMX device, then you will need more hardware. However, I'm not sure about the price of the Arduino/Teensy and extra hardware vs. a commercial USB DMX device. You can pair my library with the extra hardware and a library like DmxSimple or DMXSerial to make such a device. I can write an example Arduino sketch that does this if you'd like (though I cannot test it because I don't have the hardware).

DMXSerial or DMXSerial2 appear to be the most up-to-date/current libraries to use:

https://github.com/mathertel/DMXSerial

https://github.com/mathertel/DMXSerial2

There is more information about how to use those libraries and what hardware to get if you follow the links on those projects. I believe that the author sells an Arduino shield.

[Peter Newman]

Hi DaAwesomeP,

I'm not sure how much you ought to add your own ESTA ID to your library, it means you'll rather lose control of which UIDs are out there under your manufacturer ID (although perhaps a bit less of an issue for this device).

I wonder if a more generic approach would help on the OLA end. It strikes me there are currently three device types (Enttec Pro, Enttec Pro with RDM and DMX King with two ports). We already have a certain amount of fallback in OLA to default to particular types. I wonder if we could extend that (for the Enttec Pro RDM and DMX King models), so if you don't match anything else, before we default to a normal Enttec Pro, we could reserve model IDs at the top of the range, so any manufacturer with model ID 0xfffe would be Enttec Pro RDM, 0xfffd would be DMX King two port etc, or something similar. It could use the ESTA ID to show the manufacturer, and the text name to label the widget, but the ID would control behaviour and which code we run. Then any firmware can support those modes.

[DaAwesomeP]

I apologize for the late response! I have looked into applying for an ESTA ID, but I am hesitant to do so because it requires an address. I do not have a business or organization for which to list an address, and I would rather not use my private address. I noticed that at the end of ESTA manufacturer table there are several entries listed as "RESERVED FOR PROTOTYPING/EXPERIMENTAL USE ONLY." This might be the best category considering that I am not selling any devices. Also, if someone uses my library to produce a commercial device, I would rather them be forced to register for their own ESTA. If you adopt the detection scheme that you propose, then you could apply it to the prototyping ESTA IDs and it would work just fine.

I would have it detect all three devices—not just the Enttec with RDM and the DMX King two-port devices. My library doesn't (yet) support RDM, so I don't want OLA to think that any of the devices support RDM. I do need to make the label text configurable.