Artnet to OctoWS2811?

Not open for further replies.
the reason why my arnet won't work; very stupid. I had to modify this code

void Artnet::begin(byte mac[], byte ip[])
  byte subnet[] = { 255, 0, 0, 0 };                  
  byte gateway[] = { 2, 0, 0, 1};                   
  byte dnServer[] = { 2, 0, 0, 1};                   

i always use subnet but didn't change it in the code. So now i receive artnet :) very happy. But still thank you to everyone who responded
Last edited:
Here's my version of ArtNet OctoWS2811.

Based on this ArtNet library for Arduino:

The advantage being that it's a little more fleshed out, and does respond with ArtPollReply packet when starting up and when asked with ArtPoll packet. Not sure if that's such a great advantage, but it seemed that lots of Android Art-Net control apps wanted or needed that. (I still have not found one that works well enough, any suggestions?)

Lifted the ArtNet config code here:

Needs a bit more work, but the general idea is there...

I changed the display too, no copying of the data into a channelBuffer and calling right at receiving each universe instead of waiting to get all before turning any leds on. There must have been a good reason for you to do that, but I don't know it... Do tell please.

This works better, from what I've seen so far. The example included with hanged on my setup after a few hours of "Color Scroll" effect from Jinx! I've ran this for 12 hours or so and no similar issue. I also find it's faster... I noticed that on the "Strobe" effect, the third universe was lagging behind and out of sync, not with this.

I'm sure you guys will point out any errors, or issues with this... Thanks! :)

#include <SPI.h>
#include <ArtNet.h>
#include <Ethernet.h>
#include <OctoWS2811.h>

// OctoWS2811 settings
const int ledsPerStrip = 240; // change for your setup
DMAMEM int displayMemory[ledsPerStrip*6];
int drawingMemory[ledsPerStrip*6];
const int config = WS2811_GRB | WS2811_800kHz;
OctoWS2811 leds(ledsPerStrip, displayMemory, drawingMemory, config);

const int ledsPerUniverse = 170;

ArtNetConfig artNetConfig = {
  {0x04, 0xE9, 0xE5, 0x00, 0x69, 0xEC}, // MAC
  {192, 168, 3, 20},                    // IP
  {255, 255, 255, 0},                   // Subnet mask
  0x1936,                               // UDP port
  true,                                 // DHCP
  0, 0,                                 // Net and subnet
  "OctoWS2811 Node",                    // Short name
  "OctoWS2811 Node",                    // Long name
  4,                                    // Number of ports
  {0, 1, 2, 3},                         // Input port addresses
  {0, 1, 2, 3}                          // Output port addresses

ArtNet artnet = ArtNet(artNetConfig, 530); // 530 is buffer size

void setup()

void loop()
  // Receive ArtNet package from Ethernet shield
  if(artnet.parsePacket()) {
    // Read and handle packet
    // Check packet type
    if(artnet.getOpCode() == ARTNET_OPCODE_DMX) {
      //uint16_t dmxLength = artnet.getDmxLength();
      // Get header and dmx data
      byte* dmxData = artnet.getDmxData();
      uint8_t dmxUniverse = artnet.getDmxPort();
      // Do your DMX handling here!!
      int j = 0;
      for (int i = dmxUniverse * ledsPerUniverse; i < (dmxUniverse + 1) * ledsPerUniverse; i++,j++)
        leds.setPixel(i, dmxData[j * 3], dmxData[(j * 3) + 1], dmxData[(j * 3) + 2]);
      }   ;


#define RED    0xFF0000
#define GREEN  0x00FF00
#define BLUE   0x0000FF

void initTest()
  int wait = 500;
  colorChange(RED, wait);
  colorChange(GREEN, wait);
  colorChange(BLUE, wait);

void colorChange(int color, int wait)
  for (int i=0; i < leds.numPixels(); i++) {
    leds.setPixel(i, color);
The reason I call show after the reception of all universes is to actually display a consistent frame each time. Otherwise technically you're not displaying a complete frame. Also I found out that with a lot of leds calling too often than necessary slowed things down. Not sure why it crashes after a while, will have to investigate.
I'm curious as to why it seems faster in your case. Did you change the SPI speed of the Ethernet lib to 24mhz ?
OK, I tried to reproduce the lag I observed on the third universe and could not. I did change the SPI speed to 24Mhz and I did not try both sketches with the slower speed. I'll get to that sometime....

As for the hang, it did happen a couple of times when running the example sketch from your ArtNet library, modified only for the IP address and the number of LEDs connected. SPI was set to 24Mhz when this occurred. (I am new to Arduino and Teensy so I don't know how to debug it yet, the observation was that the "Color Scroll" I had running from Jinx! froze after about 3 to 4 hours, I did not time it exactly. It resumed OK after rebooting the Teensy without having touched anything else.)

I used your example sketch and modified it to use the Media Architecture Arduino Art-Net library. I made two versions one extensively modified with the channelBuffer taken out (code posted above) and a second version where I only swapped the library but kept everything else. I've tried both for over 12 hours and no hang.

FYI, I have 2 strips of ws2812b with 240 pixels each, connected to the first two outputs of the OctoWS2811 adapter.
Thanks for the test. The code in my artnet library is pretty simple so I'm surprised it crashes after a while... will test it with your settings.
I don't understand the need to use bitwise OR and left shift to extract all the values from the header. I know that for some of them that may be needed, but to me creating header structures and typecasting seems like a cleaner approach, one that I can understand easier anyway.
Are you referring to these lines ?
        sequence = artnetPacket[12];
        incomingUniverse = artnetPacket[14] | artnetPacket[15] << 8;  
        dmxDataLength = artnetPacket[17] | artnetPacket[16] << 8;
Yes. The following is how the other lib gets the universe with type casting:
uint8_t uni = ((artnet_dmx_header*)(buffer+sizeof(artnet_header)))->subUni;

And the structs:

typedef struct _artnet_header {
	uint8_t  id[8];
	uint16_t opCode;
} artnet_header;

typedef struct _artnet_dmx_header {
	uint8_t  protVerHi;
	uint8_t  protVerLo;
	uint8_t  sequence;
	uint8_t  physical;
	uint8_t  subUni;
	uint8_t  net;
	uint16_t length;
} artnet_dmx_header;

For me, that's easier to follow.
Are you referring to these lines ?
        sequence = artnetPacket[12];
        incomingUniverse = artnetPacket[14] | artnetPacket[15] << 8;  
        dmxDataLength = artnetPacket[17] | artnetPacket[16] << 8;
yep, not being a programmer either… this was a straight forward way of getting the right parts out of the info header
Well, I was away from it this evening and back close to 24 hours later, I see that the sketch I posted above was also hung. Same as before, resting Teensy got it going again.

So the ArtNet code may be OK in either version.

Now to figure out how to debug this thing.... oh joy!
Thanks for the update, let us know if you find the issue !
I'm also testing on my side. Will see tonight if it has crashed !
Last edited:
Last night I loaded the "Rainbow" example from the OctoWS8211 library, which produces a similar result out to the strips as the "Color Scroll" effect from Jinx!, the plan is to let it run for as long as possible to see if it may hang, to try and isolate the problem.

When I put together the Teensy with the Octo and Wiznet adapters, I soldered the Teensy and Octo together but the Wiznet is with sockets and removable. I pulled it apart for the test above and I noticed that the Wiznet was quite warm to the touch (not burning hot, but warm) and the Teensy much less so. So, it got me thinking if it may be an overheating issue...
I received some more parts yesterday, so I'm trying it now on a brand new teensy, octo, wiznet board stack. It's been 12 hours now and looks OK.
That's a good change in my opinion. No point to make a copy of the data.

I'm also happy to report that my sketch is running OK on the new board stack. One change I made on the new one, I did not mount the WizNet board flush to the adapter as described here, instead I raised it about 5 mm up, so there is an air gap between the WizNet and the adapter boards.

Good work guys! Thanks!
I've been running it continuously for the last few days and the freezing problem is back.

I checked the temperature with a digital laser thermometer (not too accurate but good enough to confirm my previous finding that the Wiznet is running warmer). The Wiznet module is reading at 37 C at the metal jack shield, the chip is showing 28, Teensy chip is 28, octo adapter board bottom side is 30.

I get no ping response when hung, but I am able to reload the sketch after which a reboot occurs and it starts working OK again. Last time this happened just 2 hours or so after reset.

It looks to me like the problem may be with the Wiznet module. So, I unplugged it all to let it cool back down to room temp, I set the SPI back down to 12MHz and started another test run. This setup is not enclosed in a box, just sitting out in the open on my workbench and nothing covering it up to retain the heat.

Any suggestions on how to find this problem?

It may be worth mentioning that my "libraries\Ethernet\utility\w5100.cpp" file did not contain a commented out line like this, I added it:

SPIFIFO.begin(W5200_SS_PIN, SPI_CLOCK_24MHz); // W5200 is 33 MHz max

Perhaps I have an older version of the Ethernet library? I installed Arduino 1.0.6 and Teensyduino 1.20.

Anyway, I am back to this now:

SPIFIFO.begin(W5200_SS_PIN, SPI_CLOCK_12MHz);  // W5100 is 14 MHz max

And there does not appear to be a problem with speed on my 2 x 240 pixel strips, it looks OK. I think the glitching I was having before was coming from bad settings in MADRIX. Now I'm testing with Jinx!
Hello everyone, I have a quick question about the OctoWS2811. I will be receiving a teensy 3.1 and a OctoWS2811 in the mail tomorrow. Is it possible to use Jinx! with the OctoWS2811 and teensy connected through USB or do I have to connect it through ethernet requiring me to get the Wiznet WIZ820io as well? I am upgrading my current setup that is using an Ardunio, so I am new to the teensy. Also is the OctoWS2811 even required? I am only going to have about 512 LEDs in this setup. Can the Teensy 3.1 handle that many LEDs without the OctoWS2811? Sorry if this question is not posted in the right place I didn't know where it was best to put it. Thanks.
A couple of things: there are two parts to OctoWS2811 - a library and an adaptor board.
You don't need the adaptor board to use the library, but it makes things easier as it has inbuilt resistors for the data lines and the appropriate logic level. You can connect led strips to pins without the adaptor, soldering a 100ohm resistor in the data line of each strip, and bridge the 15 and 16 pins. This is noted in the BasicTest sketch in the Arduino IDE.
The Teensy can handle that many Leds, but you will need to think about update rates with using different libraries.
The octoWS2811 library is very powerful as it makes things go a lot faster. You could use a different library also, such as FastLed:
Sorry, haven't used Jinx as I use Mac. You might want to check on the Jinx site for output methods from your source to see if you can send via USB? it says:
"various and flexible output options, supporting Art-Net, sACN (E1.31),, tpm2, Glediator protocol and MiniDMX as well as real DMX ( Enttec OpenDMX USB and Enttec USB DMX Pro compatible interfaces)"
Last edited:
Yes, it helps. If you can send data out from Jinx with tpm2 (serial data that will be sent via USB), you can write a sketch that grabs the incoming data and send it to the leds via the OctoWS2811 or FastLed libraries. Have a look at the pixelController website and the github repo, as Michu has written a sketch that is Teensy compatible that receives tpm2 serial. This will give you a really good starter for putting something together.

in the repo you will find the sketch that receives tpm2serial in a subfolder of the integration folder. You should recognise some of the code functions for setting the led colours and for receiving the data. You will need to change these to either the updated FastLed calls, or replace with the OctoWS2811 lib and calls.
Hi, I have got a stacked up setup with a teensy3.1, an octows2811 breakout and a wiznet ethernet controller. I am trying to get artnet working on my ledstrip. But it doesn't.
The led's work well with the InitTest, so all is wired up okay. I have been trying for a lot of time now to get some artnet signal to reach the led's but in the line something goes wrong.
I have changed the ip address like so: byte ip[] = {2,0,0,101};
I have given the network adapter (IP4) an IP of and subnetmask, no gateway.
Using Freestyler or Jinx or DMXControl etc I do not see the node. So in those programs I have tried Broadcasting ( With "the artnetominator" I see th dmx values changing, but nothing much happens Led-wise. I assume it has something to do with addressing or some kind of reply from the teensy or so. But being new to the matter the concrete wall is getting thicker and thicker and my skull a bit bit bruised

I am looking for some sign of life of the artnet receiver. How can I best test and set the artnet-connection?
Not open for further replies.