Teensy 3.5 Octo2811 lib - second LED bug

Status
Not open for further replies.

Welocs

Well-known member
Hi there, i tried out you octo lib and have the following problem (btw, thx 4 this lib) with 2812B LEDs:

every LED is addressable, except of the second one (address #1). First i connected the teensy 3.5 without a level converter, just to test the library. Then i thought, the problem is because of a bad data signal or a damaged LED.
I tested 4 stripes, all have the second LED bug. A level converter to 5V didn't solve the problem, so i thought, i should be a software problem.
Also i tried out to change the configuration to WS2813_800kHz - no success.

Is the Octo2811 lib fully compatible to the teensy 3.5?

greetings!

here the code:

Code:
#include<SD.h>
#include <SPI.h>
#include <OctoWS2811.h>

//Frame settings
unsigned char fps = 1;
unsigned long frameTime = 1000 / fps;

//SD_Card:
#define fileName "myanim.dat"
File file;
const int chipSelect = BUILTIN_SDCARD;

// OctoWS2811 settings
const int ledsPerStrip = 529; // change for your setup
const byte numStrips= 1; // change for your setup
const int numLeds = ledsPerStrip * numStrips;
const int numberOfChannels = numLeds * 3; // Total number of channels you want to receive (1 led = 3 channels)
DMAMEM int displayMemory[ledsPerStrip*6];
int drawingMemory[ledsPerStrip*6];
const int config = WS2811_GRB | WS2813_800kHz;
OctoWS2811 leds(ledsPerStrip, displayMemory, drawingMemory, config);


char red = 0;
char green = 0;
char blue = 0;
bool dirRed = 1;
bool dirGreen = 0;
bool dirBlue= 0;



void setup()
{
  Serial.begin(9600);
  while(!Serial){
    ; // wait for serial port to connect.
  }
  
  Serial.print("\n Initializing SD card...");
  if(!SD.begin(chipSelect)){
    Serial.print("initialization failed!");
    return;
  }
  Serial.println("initalization done.");

  //init led-prog and test connected strips
  leds.begin();
  initTest();

  delay(2000);
}

void loop()
{
  for (int i = 0; i<numLeds; i++){
    leds.setPixel(i, red, green, blue);
  }
  [COLOR="#B22222"]leds.setPixel(2, 177, 0, 177);  // <-- second LED lights too[/COLOR]
  [COLOR="#B22222"]leds.setPixel(1, 177, 0, 177);  // <-- no reaction of LED 1, always goes with LED 2[/COLOR]
  leds.show();
  incColor();
  delay(50);
}

void incColor(){
  if (dirRed){
    red++;
    if (red == 80) dirRed = 0;
  } else {
    red--;
    if (red == 0) dirRed = 1;
  }
}

void getNextFrame(){
  unsigned char color[3];
  
  //open file
  file = SD.open(fileName, FILE_READ);
  for(unsigned int i = 0; i < ledsPerStrip; i++){
      file.read(color, 3);
      Serial.print("Pixel: ");
      Serial.println(i, DEC);
      Serial.print("RED...");
      Serial.println(color[0], HEX);
      
      Serial.print("GREEN...");
      Serial.println(color[1], HEX);
      
      Serial.print("BLUE...");
      Serial.println(color[2], HEX);
      Serial.println(" ");
      leds.setPixel(i, color[0], color[1], color[2]);
  }
  Serial.println(file.position(), 10);
  file.close();
 // leds.show();
}

void initTest()
{
  for (int i = 0 ; i < numLeds ; i++)
    leds.setPixel(i, 80, 0, 0);
  leds.show();
  delay(500);
  for (int i = 0 ; i < numLeds  ; i++)
    leds.setPixel(i, 0, 80, 0);
  leds.show();
  delay(500);
  for (int i = 0 ; i < numLeds  ; i++)
    leds.setPixel(i, 0, 0, 80);
  leds.show();
  delay(500);
  for (int i = 0 ; i < numLeds  ; i++)
    leds.setPixel(i, 0, 0, 0);
  leds.show();
}

Edit: of course i searched for similar posts, but didn't really find a solution.
 
Not many people have that hardware - myself included - and I've not used it. Given that my inclination is: Can you simplify the test case any - like removing '#include<SD.h>' and any code references? Can you test on a shorter strip of 3 or 10 LEDs and see the same problem? I see specific notes in the code in red, that may not be explained in the post as far as what was tried to get to that?

In simplifying you might find removing something fixes the issue allowing it to be pointed out. Also fewer LEDs would simplify another setting it up if it still has the problem.

Also indicate what version of TeensyDuino you are using - the latest just released is 1.37 - and confirm the version of OctoWS2811 that is included with that install. And what version of the IDE.
 
I'm running your program here on a Teensy 3.5. I used Arduino 1.8.3 and Teensyduino 1.38-beta1.

Here's the result I see:

DSC_0543_web.jpg

Pixels 1 and 2 are bright pink. Pixel 0 and 3+ are slowly fading light red.
 
dear defragster,

I tested 4 stripes...
of course i tested different lengths...but in this case, the 2812 chip work as a shift-register, so a longer stripe should not have any effect to ONLY the second LED. I think only high currents over the whole stripe could cause damage or bugs, but then, nobody would use this stripes cause they wouldn't work anywhere. Instead of cutting the stripe i also tested to send out different sizes of data (more LEDs just won't get any data):
e.g.:
Code:
const int ledsPerStrip = 10;

I see specific notes in the code in red, that may not be explained in the post as far as what was tried to get to that?
---->>
leds.setPixel(2, 177, 0, 177); // <-- second LED lights too
leds.setPixel(1, 177, 0, 177); // <-- no reaction of LED 1, always goes with LED 2
i think this explains in combination with
every LED is addressable, except of the second one
everything.
Plain text: the second LED (address 1) always has the color of the third one (address 2).
Blame me, i forgot to give the second LED another color, see "fixed" code below.

My teensyduino version is: 1.6.7
My IDE version is: 1.8.2

Also fewer LEDs would simplify another setting it up if it still has the problem.
In my optinon, it doesn't simplify to take fewer LEDs, it's just making it faster.
The code i've posted is the complete code. Of course i simplified my code for fixing the problem and so on.

dear PaulStoffregen,
thanks for testing it with your hardware. Sorry for the mistake in my code. I doesn't work with the fixed code either.

Any ideas, that maybe there are conflicts to newer versions of teensyduino? Seems too me, that, however the memory for the second LED is overridden by the third one, or it just is not accessable?
I try out to connect a scope and find out, if the send out data is right, or if the second three bytes have the same content as the thrid three bytes.

Thanks so far! :)



Code:
#include <OctoWS2811.h>


// OctoWS2811 settings
const int ledsPerStrip = 10;
DMAMEM int displayMemory[ledsPerStrip*6];
int drawingMemory[ledsPerStrip*6];
const int config = WS2811_GRB | WS2811_800kHz;
OctoWS2811 leds(ledsPerStrip, displayMemory, drawingMemory, config);


void setup() {
  leds.begin();

  [COLOR="#B22222"]leds.setPixel(1, 177, 0, 0);  //<- LED no. 1 has the same color as no. 2!
  leds.setPixel(2, 0, 0, 177);[/COLOR]

  leds.show();
  delay(1000);

  leds.setPixel(1, 0xb1, 0, 0);  //<- same result with hex-format
  leds.setPixel(2, 0, 0, 0xb1);
  
  leds.show();
  delay(1000);

  //changing order
  leds.setPixel(2, 0, 0, 0xb1);
  leds.setPixel(1, 0xb1, 0, 0);  //<- same result with another order

  leds.show();
  
}

void loop() {
  //nop;
}
 
Any ideas ..... for the second LED is overridden by the third one

Have you tested with different LEDs?

Maybe this problem is simply one bad LED strip, perhaps with a shorted trace or wire or metal object touching the surface, causing two LEDs to receive the same physical signal?
 
hey there,

thank you again 4 testing my code.

I found the problem, and it has to do with one of the first things i have learned really quickly in the first year of my apprenticeship... -> never trust, what someone says... too bad that you have to proove nearly the simplest things. but thats life.
enough useless words, now switch to the problem, which is good to know for all who may use these LEDs as well:
I am NOT using WS28xx-Chipsets... yes... someone gave me the stripes and said they are WS2812B, but they are not. But they are compatible too the WS28xx chips.
I will explain, why there is a first/second led bug and the difference of the data transmission compared too WS28xx.

The chips i use are the SK6822
PDF -> http://www.led-color.com/upload/201601/SK6822%20LED%20Chip.pdf

These chips on a stripe have a redundant circuit. One LED N has two data inputs: one from the LED N-1 and the other from the LED N-2. So, if LED N-1 blows, the rest of the stripe will still operate, because the LED N will detect the missing data and just operate with the data of the LED N-2.
So your stripe will still work also with a few pixels broken.
The big problem is the first LED... it only receives data on one input. This causes the second led to have a bug, cause it also will only get data on one input, or both - if on both, then not correct (this depends on how you connect / solder the stripe).

see this table:

DIN 1st LEDLED1LED2
d1Val = LED2VA = 0
d2VA = 0VAL = LED3
d1+d2VA = 0VA = 0
Legend:
VA = virtual address
d1 = data input 1 (on stripes may be DI)
d2 = data input 2 (on stripes may be FDI = FIRST DATA IN?)
val = value


The second problem is, that in the SK6822 protocoll you need after each 24 bits (1 pixel) a pause of 12µs. Although you need this WT (wait time), these LEDs work with the OCTO2811 lib. But i think i could cause some bugs, i didn't completely test it yet.

If you have any questions, just ask. =)

Really thank you for answering my questions!
Maybe you can add these LEDs to you library? This would be a nice addition!

Greetings,
Welocs.
 
Last edited:
2nd LED bug: OctoWS2811 v1.4, Teensy 3.2, SK6822 LEDs

I see exactly the same problem with SK6822 LEDs and the v1.4 library using a Teensy 3.2:

- If the Backup IN data line in to the strip is left unconnected, then pixel number 2 replicates exactly what Pixel number 3 is displaying.
- If the Backup IN data line is shorted to DATA IN, then pixel number 2 replicates exactly what Pixel number 1 is displaying.

In both cases, all other pixels are correct.

If anyone has a suggestion on how to get around this, it would be much appreciated.

Thanks.



hey there,

thank you again 4 testing my code.

I found the problem, and it has to do with one of the first things i have learned really quickly in the first year of my apprenticeship... -> never trust, what someone says... too bad that you have to proove nearly the simplest things. but thats life.
enough useless words, now switch to the problem, which is good to know for all who may use these LEDs as well:
I am NOT using WS28xx-Chipsets... yes... someone gave me the stripes and said they are WS2812B, but they are not. But they are compatible too the WS28xx chips.
I will explain, why there is a first/second led bug and the difference of the data transmission compared too WS28xx.

The chips i use are the SK6822
PDF -> http://www.led-color.com/upload/201601/SK6822%20LED%20Chip.pdf

These chips on a stripe have a redundant circuit. One LED N has two data inputs: one from the LED N-1 and the other from the LED N-2. So, if LED N-1 blows, the rest of the stripe will still operate, because the LED N will detect the missing data and just operate with the data of the LED N-2.
So your stripe will still work also with a few pixels broken.
The big problem is the first LED... it only receives data on one input. This causes the second led to have a bug, cause it also will only get data on one input, or both - if on both, then not correct (this depends on how you connect / solder the stripe).

see this table:

DIN 1st LEDLED1LED2
d1Val = LED2VA = 0
d2VA = 0VAL = LED3
d1+d2VA = 0VA = 0
Legend:
VA = virtual address
d1 = data input 1 (on stripes may be DI)
d2 = data input 2 (on stripes may be FDI = FIRST DATA IN?)
val = value


The second problem is, that in the SK6822 protocoll you need after each 24 bits (1 pixel) a pause of 12µs. Although you need this WT (wait time), these LEDs work with the OCTO2811 lib. But i think i could cause some bugs, i didn't completely test it yet.

If you have any questions, just ask. =)

Really thank you for answering my questions!
Maybe you can add these LEDs to you library? This would be a nice addition!

Greetings,
Welocs.
 
hi turbok,

If anyone has a suggestion on how to get around this, it would be much appreciated.

There is no possibility to solve the problem, except of "imitating" the first LED or provide the correct signals!
The chips have no possibility to detect to be the first/second LED.(see example circuit in datasheet page 6)
For this, you would need another hardware configuration, e.g. two data outputs (which means double wiring), or a converter, which makes from one signal two - the normal signal, and one delayed.
Instead of creating a complex hardware converter or using double wires (<-need to change the whole Octo lib!!!) you just could use the first LED of your stripe as a "hardware-converter" in blanking it with some lake or similar stuff.
 
Last edited:
Status
Not open for further replies.
Back
Top