Teensy 4.1 - OctoWS2811 - FPP - Garbage out

[Loufe]

Hi everybody,

I'm a little out of my technical depth here as I am not sure how to continue my debugging.

I've got xLights creating sequences and 3D mapping my WS2811 lights. The sequence is uploaded to my Pi 4 B running FPP. FPP communicates over USB serial to my teensy 4.1 soldered to an OctoWS2811 board (a MASSIVE thanks to ShadowLight8 for the code and relevant forum points - https://github.com/ShadowLight8/fpp-to-teensy-serial-ws2813 )

It seems as though only the correct channels are being ouput, as I've only programmed the left arm (shown below) and the ethernet plugged in the other port turns off the lights. But they're outputting random, twitching, and wrong colours.

As for debugging, the voltage is stable and not browning out (I've plugged in my old project brains - an arduino uno with raw fastled code) which works like a charm for the arm, displaying perfect. I'm running the data line and ground line directly to the input, bypassing my power bus so I don't feel like the signal is contaminated. I unfortunately don't have an oscilloscope or I'd try to learn that, and I'm not really sure where I'd begin with serial debugging.

I'd really help if anybody could nudge me in the right direction to help me debug this, I'm not asking for charity - I don't mind doing the legwork myself. I'm worried it's somewhere in the hardware so I'm going to buy acetone to wash better where I soldered, but after that I'm out of idea steam.

 

[ShadowLight8]

Glad you found the code helpful! You've posted a good amount of info. Below is a stream of thoughts about what to take a look at:

The first thing that jumped out to me was your table of channel addresses. I put your config into my spreadsheet and got some different channel numbers:


For the left arm, I have channels 4231 to 4530. See if adjusting that in xLights helps. You can shift just the first few leds worth of channels to see if you can get a steady expected output.

Is the LED on the Teensy steady or blinking?

I've not really used xLights, have used Vixen instead. In Vixen, I setup the controller as a generic serial output, so the only thing going out is just the header followed by color data. Here's what that config looks like in hopes that it can match up to xLights:


Your FPP config looks right to me.

I'm assuming in the code you have MAX_PIXELS_PER_STRIP set to 282.

Edit: On the FPP test page - Set the channel range from 1 to 6768. Your screenshot shows 6776 which would send too much data to the Teensy - which should cause the led on the Teensy to blink.

 

[Loufe]

@Shadow,

First off, thank you so much for the thoughts.

You were absolutely right about the channel numbers, I've got them corrected now!

The LED in your original version stays steady - no blips. It looks like data is being streamed constantly without exception. I had noticed the 6776 value before, it now correctly defaults to 6768 with the channel change, oddly.

The staggered channels and wrong cap in the test suite unfortunately don't change the problem. There are still, frustratingly, pixels being entirely skipped or the wrong colour. I tried some more tests and can't seem to glean any ideas.

Here are solid green as set (successfully) by my old arduino directly with FastLEd and (unsuccessfully) through the octo setup.

Would you think this could be caused by a mistake in the soldering on my part? Or perhaps the code needs modifying because, example, the buffer loading differs between Teensy 3.X (your code) and 4.X (my setup)?





Edit: Note the differing colours (perhaps hard to see) and pixels completely off in the Octo photo

Edit2: I noticed this comment in the source code for Octo by the homie Paul, here: https://github.com/PaulStoffregen/OctoWS2811/commit/35c6ff24cf0b598cfb5339aa83bf0a2d4c607f13

// For Teensy 4.x, the pixel data is stored in ordinary RGB format.  Translation
// from 24 bit color to GPIO bitmasks is done on-the-fly by fillbits().  This is
// different from Teensy 3.x, where the data was stored as bytes to write directly
// to the GPIO output register.

I'm going to see if I can't figure it out in the interim.

 

[ShadowLight8]

Oh! If the Teensy 4.x buffers have a different data format, that might be the issue. Try this variation of the loop() code. It uses the setPixel function so that the OctoWS2811 library can populate the buffer correctly.

void loop() {
  // Quickly check if next bytes are the header
  if (Serial.read() == '<' && Serial.read() == '>') {
    Serial.readBytes(megaBuffer, MAX_PIXELS_PER_STRIP * 8 * 3);

    // Original, but slower, method for populating drawingMemory
    curItem = 0;
     while (curItem < (MAX_PIXELS_PER_STRIP * 8)) {
       leds.setPixel(curItem, megaBuffer[curItem * 3], megaBuffer[curItem * 3 + 1], megaBuffer[curItem * 3 + 2]);
       curItem++;
     }

    leds.show();
  } else {
    // Is there USB Serial data that isn't a header? If so, flash LED every 750ms
    // Flashing can indicate the following:
    //    Serial header of <> is missing (Lights most likely aren't working) - Check FPP settings that the header is set
    //    Serial header of <> isn't where it is expected (Lights might be working) - Verify MAX_PIXELS_PER_STRIP * 8 * 3 matches the number of channels
    //    Serial data not being processed fast enough - Sequence refresh rate should be slowed down until flashing stops (Tested with MAX_PIXELS_PER_STRIP = 517 with 17ms sequence timing)
    if (Serial.peek() != -1 && Serial.peek() != '<' && millis() - millisSinceBlink > 750) {
      qBlink();
      millisSinceBlink = millis();
    } else if (millis() - millisSinceBlink > 3000) // Turn LED back on in case it was left off, but no more data has come in
      digitalWriteFast(LED_BUILTIN, 1);
  }
}

 

[Loufe]

Oh! If the Teensy 4.x buffers have a different data format, that might be the issue. Try this variation of the loop() code. It uses the setPixel function so that the OctoWS2811 library can populate the buffer correctly.

void loop() {
  // Quickly check if next bytes are the header
  if (Serial.read() == '<' && Serial.read() == '>') {
    Serial.readBytes(megaBuffer, MAX_PIXELS_PER_STRIP * 8 * 3);

    // Original, but slower, method for populating drawingMemory
    curItem = 0;
     while (curItem < (MAX_PIXELS_PER_STRIP * 8)) {
       leds.setPixel(curItem, megaBuffer[curItem * 3], megaBuffer[curItem * 3 + 1], megaBuffer[curItem * 3 + 2]);
       curItem++;
     }

    leds.show();
  } else {
    // Is there USB Serial data that isn't a header? If so, flash LED every 750ms
    // Flashing can indicate the following:
    //    Serial header of <> is missing (Lights most likely aren't working) - Check FPP settings that the header is set
    //    Serial header of <> isn't where it is expected (Lights might be working) - Verify MAX_PIXELS_PER_STRIP * 8 * 3 matches the number of channels
    //    Serial data not being processed fast enough - Sequence refresh rate should be slowed down until flashing stops (Tested with MAX_PIXELS_PER_STRIP = 517 with 17ms sequence timing)
    if (Serial.peek() != -1 && Serial.peek() != '<' && millis() - millisSinceBlink > 750) {
      qBlink();
      millisSinceBlink = millis();
    } else if (millis() - millisSinceBlink > 3000) // Turn LED back on in case it was left off, but no more data has come in
      digitalWriteFast(LED_BUILTIN, 1);
  }
}

I started my own modifications and you swept in with the fix!! IT WORKS!!! I'm so happy I could kiss you. Thanks a lot, Nick You're the best man

 

[ShadowLight8]

So glad I was able to help out! Have fun