Artnet to OctoWS2811?

Status
Not open for further replies.
Hey, I've been working on a big project that uses the teensy and ethernet shield based off info found on this site:
http://www.epyon.be/2013/07/18/teensy-arduino-adapter-shield/

The project is called the Mariposa Chandelier, it's 40' tall and is surrounded by a staircase which has buttons along the handrail that send waves up light and sound through the installation.
chandelier1.jpg

More photos here: https://www.flickr.com/photos/122636297@N06/sets/

Anyway the point of why I'm on here is I noticed that occasionally the ethernet boards lose their connection and won't connect back. It's like the ethernet shield just stops working if it gets a hard power reset. The project was pretty rushed and it was pretty much just me on the technical side of things (plus fabricators and random friends and last minute help from a game designer for additional Unity3d support).

The whole project is being controlled by Unity3d for the simulation side of things. The code/project is super messy, but on my github. Lots of cleanup needs to be done. I apologize.

The core of it sends a slightly modified Artnet from Unity3d to the Teensy via the ethernet shield, 99% of the time it works, but as this is a permanent installation, I want it to be rock solid. Currently I DO have flickering if I only light up a few pixels here and there, but if I leave the top set of lamps lit, all flickering goes away.

I'm also using power supplies from illumination Supply(via pixelpusher).

I'm using Neopixels from Adafruit. There are 13 LED per lamp, 10 lamps per cable, each cable is only powered at the TOP where it connects to the board. Yes the colors to fade from white/red as it goes down the line, but the animations have been optimized to reduce this and obviously nobody looking at the installation really sees it as a problem, they think it's an "effect".

I'm looking to either replace or modify the LED controllers so that they are 100% reliable. I'm not sure if it's a Teensy thing, a hardware wiring thing or just that the ethernet shield isn't good? If I reupload the program to the teensy, all is good again. Any thoughts?

Here is the Arduino Code based of some random open source artnet lib.
 
Last edited:
The Arduino Ethernet shield is known to be very slow. Paul made an adapter for the wiz820io board that is much faster. I've been using it with Artnet and did not notice any dropouts... Flickering can be caused by a number of things but the first thing to check is proper voltage along the strip.

Edit: wiz820io adapter: http://pjrc.com/store/wiz820_sd_adaptor.html
 
Oh one more thing I forgot to mention. I noticed that if I send too much data too fast to the setup that I have, it basically freezes and requires a restart, which also means reloading the software onto each board.

I'll try switching to the new wiz820 adapter, I think an all in one Ethernet+Teensy+Octows2811 board would be sweet btw. A cobbled together version works too.
 
@interhacktive
Looking at the photos in the link you posted I must say that the project is a beautifully executed installation. It does not happen too often when the mechanical, electrical and electronic components of a system are integrated as well that it all blends together in such a wondful fashion. The only thing missing from this thread is a video of it!
 
nlecaude said:
The Arduino Ethernet shield is known to be very slow. Paul made an adapter for the wiz820io board that is much faster. I've been using it with Artnet and did not notice any dropouts... Flickering can be caused by a number of things but the first thing to check is proper voltage along the strip.

Edit: wiz820io adapter: http://pjrc.com/store/wiz820_sd_adaptor.html
Click to expand...

Also in order to get the full speed benefit of the higher SPI bus frequency the WIZ820io can take you need to un-comment a line in the Ethernet library:

In file /utility/w5100.cpp the red marked line is by default commented out and needs to be un-commented:

Code: 
uint8_t W5100Class::init(void)
{
  uint16_t TXBUF_BASE, RXBUF_BASE;
  uint8_t i;

  delay(200);
  //Serial.println("w5100 init");

#ifdef USE_SPIFIFO
  SPIFIFO.begin(W5200_SS_PIN, SPI_CLOCK_12MHz);  // W5100 is 14 MHz max
#else
  SPI.begin();
  SPI.setClockDivider(SPI_CLOCK_DIV2);
  initSS();
#endif
  
  if (isW5100()) {
    CH_BASE = 0x0400;
    SSIZE = 2048;
    SMASK = 0x07FF;
    TXBUF_BASE = 0x4000;
    RXBUF_BASE = 0x6000;
    writeTMSR(0x55);
    writeRMSR(0x55);

  } else if (isW5200()) {
#ifdef USE_SPIFIFO
[COLOR="#FF0000"] //   SPIFIFO.begin(W5200_SS_PIN, SPI_CLOCK_24MHz);  // W5200 is 33 MHz max[/COLOR]
#endif
    CH_BASE = 0x4000;
    SSIZE = 4096;
    SMASK = 0x0FFF;
    TXBUF_BASE = 0x8000;
    RXBUF_BASE = 0xC000;
    for (i=0; i<MAX_SOCK_NUM; i++) {
      writeSnRX_SIZE(i, SSIZE >> 10);
      writeSnTX_SIZE(i, SSIZE >> 10);
    }
    for (; i<8; i++) {
      writeSnRX_SIZE(i, 0);
      writeSnTX_SIZE(i, 0);
    }

  } else {
    //Serial.println("no chip :-(");
    chip = 0;
    return 0; // no known chip is responding :-(
  }
  for (int i=0; i<MAX_SOCK_NUM; i++) {
    SBASE[i] = TXBUF_BASE + SSIZE * i;
    RBASE[i] = RXBUF_BASE + SSIZE * i;
  }
  return 1; // successful init
}
 
Using the artnet sketch with the 820i, when the data rate was overwhelmed I did not get any freezing, but a random colour output in the "top end" led locations. That it, the high frame update rate or volume of data to post caused the leds at the furthest address to receive partial or no update values.
 
Hi guys.. Fantastic that there's discussion already on the exact thing that got me interested in the Teensy :) A quick question for you:

I'm about to buy the hardware to implement this: octoWS2811, wiz820io adapter, wiz820 ethernet, Teensy3.1.. but first I checked all the pins to see if there's any I/O conflict. I notice that both the octo and the wiz820io list pin 8 as being used.. but the wiz820io just says "Jumper Pads" "Left Side" for this pin.. no function. So maybe it's ok???

Can anyone please confirm for me that these two boards don't conflict on that I/O? Thanks!

Also, I have a project that needs more than 8 WS2811 outputs.. not to drive more pixels, my pixel count is actually pretty low. But the physical layout calls for more strings with less pixels on each string. I was wondering about the possibility of stacking two octoWS2811 boards and outputting alternately to one, then the other, wiring the CS (chip select) to different outputs on the Teensy. And then this would obviously require some change to the library. Anyone have any thoughts on this?? As I said my application has a relatively low pixel count so multiple Teensy boards is overkill.

Thanks!
 
Looks like pin 8 is not connected by default so it should be fine.
Regarding layout, why not daisy chain your individual strips ?
 
Thanks!

The reason I'm not chaining them is because each of my pixel chains hangs down with the ends free, so the bottom ends can't be connected to anything. All the power and signal comes from the top. The cables connecting everything together are pre-made so even if the length restrictions allowed me to run the signal back from the bottom pixel up to the top again, I couldn't do it in this situation.

I looked at the WS2811 spec and it seems there is no restriction on keeping the line low for any amount of time, so multiplexing them shouldn't be a problem.. but I don't understand the octoWS2811 code very well yet (have been programming in C many years and done some assembler on PIC & 6502, but this is my first teensy/ARM/WS2811 coding)...
 
Last edited:
Ok so I looked at ways to increase the number of output lines.. I think I understand the OctoWS2811 library now.. the three DMA channels are set up initially to drive 8 pins on one GPIO and then just run in the background on a hardware interrupt from the PWM. There's no user code that's executed at the time the data is being written out.

So first I thought, since the CPU has 16 DMA channels, why not just run two instances of the library, each with their own 8 bit GPIO and own 3 DMA channels (just make it configurable in the library). But they can share PWM's... That would give 16 outputs, but since the GPIO's are all different it would require either a custom output board or significant modification of the traces on the PJRC OctoWS2811 board. Also, maybe the timing is too critical to have them running in parallel like that.

So then my second thought was, stack the octo boards.. so they are looking at the same GPIO's, but on one Octo board, you cut the trace going to -OE on the 74HCT245, and jump that to Teensy pin 5, which normally would be the output for pixel string #8. On the other Octo board, you do the same, but through an inverter.

So with that mod in place, the DMA bit for pixel string #8 now multiplexes the two boards.. giving you 14 outputs without touching any of the timing critical code.. you would only have to change the non-DMA related code (set/get pixel) to shift the bits around differently. So let's say your strings were 200 pixels and you had 14 strings.. in the buffer, the first 200 x 3 x 8 = 4800 bytes of buffer would contain strings 1-7 data in the lower 7 bits, and the high bit would be always 1, to enable the first octo board. Then the next 4800 bytes of buffer would be for strings 8-14, with the high bit set to 0 to enable the second octo board.

Voila, 14 outputs with the same DMA's.
Does this make any sense?

But maybe if I learn a bit more about how it all works, I'll come up with some way that uses separate GPIO's to do the OE without having to waste space like that....
 
nlecaude said:
Checkout this thread:
http://forum.pjrc.com/threads/26203...orrect-and-dithering?highlight=octows2811+dma

Also note that you do not need the octows2811 board, you can run it directly from the Teensy with some 74HCT245 and resistors...
Click to expand...

Thanks again, that's using exactly what I didn't know about the DMA but I was hoping to figure out :)
I see in other peoples projects that they are driving the WS2811 directly from the Teensy output but I want to run more distance from the controller to the first pixel than I see them running.. I figure the driver on the octo board must be able to drive the line better than the GPIO pin directly, else it wouldn't be there. Also it is just convenient to have the connectors all worked out for me so I don't have to deal with that part...

I think I will use the code in the thread you linked as the starting point and I'll buy an additional octo board, but won't stack it, but just mount it alongside and run wires where I need them.. it'll still be easier, neater, more consistent than protoboarding the whole thing myself...

Thanks again.
 
mortonkopf said:
Paul, as requested, here is the sketch and the config file for the pixel controller software so that it works with Teensy 3.0 and Octows2811 lib. I have tested it with a 32x8 array, but would appreciate it if someone else could test this also. There are a number of config parameters that had to be changed. The pixel controller does not auto detect the port in the tpm2serial mode, so this must be done manually in the config file.

Open the sketch below. Set the led strip length values and the define NUM LEDS value to what you have.
Attached: octotpm2serial.ino
Click to expand...

Morton, I was delighted to find the Teensy-sketch you posted last year. I couldn't find any other ready-made TPM2Serial to OctoWS2811 conversion software so far (the best that can be found still use the slow FastSPI library, even on the Teensy). I like it because I don't have a network module connected to my Teensy yet, therefore I wouldn't want to depend on the Ethernet library, like most posts in this topic presume. Your sketch works fine using PixelController. PixelController sends out Block Start Byte 0x9C on the serial port and includes the Packet Number and Total Packet Count bytes.

It is more usual for serial devices to use the Block Start Byte 0xC9 however. With this Start Byte, the Packet Number and Packet Count bytes are omitted. This way your sketch can work using the Jinx and Glediator controller software as well. That's why I made some small additions to your sketch, which I post for other to try:
http://www.tomsoft.nl/files/octotpm2serial_tomsoft.ino
I couldn't test it for 100% since my led strips still flicker due to the lack of the 74HCT245 buffer IC. But at least I do see the leds get updated from the different controller applications now.

BTW, driving this sketch from ArtNet (using localhost on a PC) is then only a small step away, since Open Lighting Architecture (accepting ArtNet or E1.31/sACN as inputs) now supports TPM2.
 
Last edited:
This is all very exciting. I must confess that I did not really think that there would be so many variants of code required for the different output sources (Unity3D, GLediator, pixelcontroller, etc). Not being a very good coder, I don't know whether it is possible to use a single sketch that would be able to determine the variants by using some form of mask matching to make life easier down the line (defines?).
 
Last edited:
There shouldn't be a need to maintain multiple variants of the same sketch for different output sources. The original sketch only implemented a part of the TPM2 protocol standard and I just added some more of that same standard. I only added things to "octotpm2serial.ino", I didn't remove parts or change parts that would affect compatibility with PixelController (the output source application which I think the sketch originally targeted). So no need for defines or multiple versions of the sketch.

The main changes are (in bold):
Code: 
#define TPM2NET_HEADER_IDENT 0x9c
[b]#define TPM2NET_HEADER_IDENT_SERIAL 0xc9[/b]
if ((startChar != TPM2NET_HEADER_IDENT) [b]&& (startChar != TPM2NET_HEADER_IDENT_SERIAL)[/b]) {
    return -1;
}
[b]if (startChar == TPM2NET_HEADER_IDENT_SERIAL) {
    // TPM2.SERIAL over serial for other output source applications (e.g. Jinx & Glediator, maybe Luminosus & Minotor too).
    currentPacket = 0;
    totalPacket = 1;
}
else[/b] {
    // TPM2.NET over serial for the PixelPusher output source applications.
    currentPacket = Serial.read();  
    totalPacket = Serial.read();
}

I also added a "ledOffset" variable for use in the updatePixels() function since the code seemed to assume a fixed packet size, this way it's more dynamic. All in all these are only tiny changes and I was very glad to find the original code which saved me a ton of work. Before I found this one, I even tried FadyCandy which has invented the so-called "Open Pixel Control" protocol, though none of the the named output source applications bothers to support that protocol, nor seems a protocol-bridge to exist. I feel the way to go is TPM2.SERIAL/TPM2.NET-protocol for small installations/low-level and ArtNet-protocol/E1.31=sACN-protocol for bigger installations/high-level, Open Pixel Control would therefore be superfluous.
 
I just stumbled across this library and its been fantastic for our project (controlling neopixel 16 led rings). The only issue we are facing is that we have 22 of them and this is beyond a single universe of dmx (and beyond our needs honestly). I was wondering if you had any knowledge how to modify the existing sketch for the arduino to group the outputs (ie. only using 3 dmx channels to control the entire ring's RGB functions, or 6 channels and do half/half of the ring). I realize that the pixels themselves will still recognize themselves as individuals, so they will each need their own commands, but there has to be some way to distribute the artnet value across multiple outputs.

Any help would be greatly appreciated. I've done some simple sketches in Arduino, but this is currently beyond my knowledge/skillset. Thanks!
 
Thank you, but that's the one I am currently using. It's not a limitation on the Artnet side but that we are converting to Artnet from another protocol so the less we have to convert the better, plus we really do not need individual control of the pixels, just the rings.
 
But why from midi to art net ? You could simply set the Teensy as a USB midi devices and send midi commands directy to the Teensy...
 
Our system natively deals with midi, and has the ability to output artnet for controlling dmx devices. Since the arduino will be far away from the control pc, artnet also made sense. The main issue though is attempting to find a way to group the 2811 LED's, as we do not need the individual control for our circumstances, regardless of protocol.

Do you happen to have any ideas on how to do this?
 
Status
Not open for further replies.
Back
Top