Teensy 3.2 + Octows2811 random trashed data

Status
Not open for further replies.

Phil_A

Member
Hello everyone , (and happy xmas !)

I'm running a 20x32 (ws2812) led panel with Jinx And Glediator ,using the glediator sample code that comes with the octows2811 library.

It works great most of the time ,except for some random trashed data poping here and here , and only in the bottom half of the panel (more or less random rows of 2 to 7 consecutive leds showing a short burst of random color data).

When i swap the 2 Octows2812 output cables the problem goes to the upper part, so it looks like the problem is in the second part of the data stream (bottom rj45 output).

To be safe from a wiring/power problem, i tried some other sketches (the other octows2811 samples code and the fastled Octows2811 sample code too).
This gave me a 100% correct result in every case.

Btw, i have actually 2 teensy 3.2 + Octows2811 , so i tried the other one , but i get the same result on both (trashed data with glediator serial sketch , fine with sample codes).

any idea ?

Thank you ,
phil
 
Does the incorrect data stay if you pause the serial data in? If stand alone examples work, and swapping hardware does not do anything most likely cause is oddities in your data path. One test would be to pick a gray shade (say 10/10/10). If that does not glitch then your problem is loss/gain of a data byte somewhere. If it does glitch then you are getting corrupted bytes and need to find where from. Using the same gray debug would allow you to instrument the serial parser loop with some debug code to do things like count byte numbers in, or report any time it gets a colour other than the expected gray.
 
Hi , thank you for the answer.

It looks like static dark grey stream shows much less glitches ( Jinx) . I've seen a couple of leds glitching in about 5mn.(btw, it looks like colorless values are much less subjects to glitching)
Saddly , i don't know how i can pause the data stream in jinx ,and the glitches are so fast , capturing a glitched frame won't be easy.



Also my problems are the same on 2 PCs , a recent windows 10 laptop and an older windows 7.

I'm no coder , so my abilities to debug this are very low.

Thanks again,
Phil
 
Debug is made trickier by the fact that you are using the serial port for glediator so getting information back out of the Teensy is a bit tricky and sounds like you don't have setup to plug into the serial port and look for messages there.

Re using glediator, can't you just close the program on the PC side? Certainly with this slowing the frame rate in glediator may be helpful in a number of ways, as may be a look at what speeds it is attempting to send data since something is choking.

Edit - having found the jinx manual I see that they really don't allow speed control or pause. Which is a bit of a problem with this since chasing this would be a lot easier with 'send single frame' options.
 
Last edited:
The only way i found to stop the stream is to unplug the teensy, but with no success capturing a glitched frame.
 
Can you try greatly reducing the brightness of all LEDs in the pattern?

Sometimes strange problems are related to power supply or power wiring issues. If you can reduce the brightness by 80% or 90%, so the whole thing is using only a small fraction of the original power, then whether the problem remains, or remains but is substantially different, or completely goes away can help in confirming or ruling out power issues.
 
Hi paul ,

Power suply or bad wiring was the first thing that came to my mind, of course .

I've got a 40A 5v Meanwell powersupply , with 2 outputs powering 3 strips each (80 leds/strip) , the last output is only powering the last 2 strips .

Really, i have no problem with 100% white.

Like i said , displaying no color at all (on the whole grey scale) is mostly glitch-free ("mostly" , but it's really very rare) .

I can have big glitches with colorfull saturated animation and the master level down to even less than 1/4 to its full range.

And again ,no problem at all with the other sample codes i tried.
 
Small Update :

I uploaded this script to my teensy ,and all my glitches problems disapeared:
Code:
#include <FastLED.h>
#define NUM_LEDS 640 
#define NUM_LEDS_PER_STRIP 80 
#define NUM_STRIPS 8
#define CMD_NEW_DATA 1
#define BAUD_RATE 500000

CRGB leds[NUM_STRIPS * NUM_LEDS_PER_STRIP];

void setup() {
  LEDS.addLeds<WS2811_PORTDC,NUM_STRIPS>(leds, NUM_LEDS_PER_STRIP);               // OctoWS2811 teensy support
  // FastLED.addLeds<WS2811, DATA_PIN, GRB>(leds, NUM_LEDS);                                 // original script code
  Serial.begin(BAUD_RATE);
}
int serialGlediator () {
  while (!Serial.available()) {}
  return Serial.read();
}
void loop() {
  while (serialGlediator () != CMD_NEW_DATA) {}
  Serial.readBytes((char*)leds, NUM_LEDS*3);
  FastLED.show();
}


It's a simple fastled code for glediator that i modified slightly to use fastled support of multiple parallel output ( WS2811_PORTDC is in fact the teensy/octows2811 layout).

I think i was lucky it worked , since i'm no coder (or very beginner level) and i was just basically patching together two pieces of code...

This code apparently doens't make use of DMA and might be slower than using the Octows2811 lib , but i can't really tell.
Also ,i'm not sure i need the serial speed stuff.

Sadly , a mystery remains :why the octows281 glediator sketch didn't work for me ?

Any way, thank you all for your time.
Cheers

Phil.
 
Status
Not open for further replies.
Back
Top