LPD8806 Latching Before latch signal

[Safarir]

Hi everyone,

I was doing some experimentation with my led strip and I discover something:

The latch is not working in my case.

If I just send the data, all my led update immediatly, exept the last one, that is waiting for the "writeLatch" function.

Did someone else notice that ?


EDIT: My project progress, here is the result:
http://www.youtube.com/watch?v=WWtAasxjNNQ
http://www.youtube.com/watch?v=cSgwTrLwfa0
http://www.youtube.com/watch?v=hzX7KbN5nFE

BTW you can see my project here:
http://www.youtube.com/watch?v=DoNAjBToB9U

Sorry for my bad english

[mtbf0]

are you sure you're not slipping some zeroes into your data. the video's nice, but your code and a picture of your wiring would be more useful.

[Safarir]

Hi MTBF0,

I am 99% sure is not a wiring issue, I test with a new wheel (5 meters), with original connector, and I get the exact same behavior

At first, I tought it was my code the problem, because I wrote it from scratch, but I also try with a arduino nano, and I get the same behavior.

It realy simple to test, you just have to add a delay before the latch signal in the library, and the last led will be the only one not updating instantly.

Code: Select all

// This is how data is pushed to the strip.  Unfortunately, the company
// that makes the chip didnt release the  protocol document or you need
// to sign an NDA or something stupid like that, but we reverse engineered
// this from a strip controller and it seems to work very nicely!
void LPD8806::show(void) {
  uint16_t i, nl3 = numLEDs * 3; // 3 bytes per LED
 
  // write 24 bits per pixel
  if (hardwareSPI) {
    for (i=0; i<nl3; i++ ) {
      SPDR = pixels[i];
      while(!(SPSR & (1<<SPIF)));
    }
  } else if(slowmo) {
    for (i=0; i<nl3; i++ ) {
      for (uint8_t bit=0x80; bit; bit >>= 1) {
        if(pixels[i] & bit) digitalWrite(datapin, HIGH);
        else                digitalWrite(datapin, LOW);
        digitalWrite(clkpin, HIGH);
        digitalWrite(clkpin, LOW);
      }
    }
  } else {
    for (i=0; i<nl3; i++ ) {
      for (uint8_t bit=0x80; bit; bit >>= 1) {
        if(pixels[i] & bit) *dataport |=  datapinmask;
        else                *dataport &= ~datapinmask;
        *clkport |=  clkpinmask;
        *clkport &= ~clkpinmask;
      }
    }
  }

        // DELAY IS HERE
   delay(2000);
   
  writeLatch(numLEDs); // Write latch at end of data

  // We need to have a delay here, a few ms seems to do the job
  // shorter may be OK as well - need to experiment :(
  delay(pause);
}


[adafruit_support_rick]

At first, I tought it was my code the problem, because I wrote it from scratch, but I also try with a arduino nano, and I get the same behavior.

Could you please post your code? When you say you tried your code with a nano, how does that mean that the problem is not in your code?

What is numLEDs defined to be? Are you using hardware SPI or softwareSPI?

[Safarir]

Can I post my code : no, I delete it

What I was trying to say, is that I try the library on github, the only modification being the delay I post in my last post. My code was something like this:

Code: Select all


#include "LPD8806.h"
#include "SPI.h"

// Example to control LPD8806-based RGB LED Modules in a strip

/*****************************************************************************/

// Choose which 2 pins you will use for output.
// Can be any valid output pins.
int dataPin = 2;   
int clockPin = 3;

// Set the first variable to the NUMBER of pixels. 32 = 32 pixels in a row
// The LED strips are 32 LEDs per meter but you can extend/cut the strip
LPD8806 strip = LPD8806(4, dataPin, clockPin);

// you can also use hardware SPI, for ultra fast writes by leaving out the
// data and clock pin arguments. This will 'fix' the pins to the following:
// on Arduino 168/328 thats data = 11, and clock = pin 13
// on Megas thats data = 51, and clock = 52
//LPD8806 strip = LPD8806(4);

void setup() {
  // Start up the LED strip
  strip.begin();

  // Update the strip, to start they are all 'off'
  strip.show();
}


void loop() {

strip.setPixelColor(0, strip.Color(127,127,0));
strip.setPixelColor(1, strip.Color(127,0,127));
strip.setPixelColor(2, strip.Color(0,127,127));
strip.setPixelColor(3, strip.Color(127,127,127));

delay(2000);

strip.setPixelColor(0, strip.Color(0,0,0));
strip.setPixelColor(1, strip.Color(0,0,0));
strip.setPixelColor(2, strip.Color(0,0,0));
strip.setPixelColor(3, strip.Color(0,0,0));

delay(2000);


 

}

With this code, and the delay in the library before the latch, the only led reacting to the latch is the last one

[adafruit_support_rick]

How did you declare your LPD8806 object? Number of pixels, data and clock pins, etc?
I can't diagnose the issue without any details.

[Safarir]

How did you declare your LPD8806 object? Number of pixels, data and clock pins, etc?
I can't diagnose the issue without any details.

line #15 of the code i just post ?

I have not touch the library:
https://github.com/adafruit/LPD8806/blo ... PD8806.cpp
exept for the delay as a said earlier...

[adafruit_support_rick]

line #15 of the code i just post ?

Ah - from your video, I thought you were using hundreds of pixels.
OK, so you see the issue with 4 pixels and software SPI. I'll investigate

[Safarir]

line #15 of the code i just post ?

Ah - from your video, I thought you were using hundreds of pixels.
OK, so you see the issue with 4 pixels and software SPI. I'll investigate

I have the exact same behavior with 4leds or 400

[pburgess]

Okay, I've had a moment to mess around with this...

Keep in mind that we don't have a datasheet for the LPD8806; the library was developed through reverse engineering and there are some huge gaps in what we know about this chip.

But yes, near as I can tell now, this is not a bug but a "feature" (ironic quotes) of the LPD8806...if the serial clock is interrupted for too long a period (I don't know the exact length, have gone as low as 100 milliseconds and still observed the phenomenon), then as a failsafe of sorts the LEDs will interpret the last byte received as the latch (which is why the last LED in the strand isn't displaying the right color...the latch byte is eaten, not displayed).

So, moral of the story: don't put a delay before the latch...always issue it immediately following the data, and handle any needed delays elsewhere.

If you're worried about keeping your LED timing consistent (e.g. using a timer interrupt so they always refresh at something like 50 Hz), it's not a problem. The number of cycles spent issuing data is deterministic, and the latch will always occur at the desired interval, just slightly offset from when the interrupt actually fires.

[Safarir]

Okay, I've had a moment to mess around with this...

Keep in mind that we don't have a datasheet for the LPD8806; the library was developed through reverse engineering and there are some huge gaps in what we know about this chip.

But yes, near as I can tell now, this is not a bug but a "feature" (ironic quotes) of the LPD8806...if the serial clock is interrupted for too long a period (I don't know the exact length, have gone as low as 100 milliseconds and still observed the phenomenon), then as a failsafe of sorts the LEDs will interpret the last byte received as the latch (which is why the last LED in the strand isn't displaying the right color...the latch byte is eaten, not displayed).

So, moral of the story: don't put a delay before the latch...always issue it immediately following the data, and handle any needed delays elsewhere.

If you're worried about keeping your LED timing consistent (e.g. using a timer interrupt so they always refresh at something like 50 Hz), it's not a problem. The number of cycles spent issuing data is deterministic, and the latch will always occur at the desired interval, just slightly offset from when the interrupt actually fires.

I PBURGESS

With all my respect, I think you are wrong. I think everybody always things there is a latch feature on those IC but personnaly, I don't think it is case. I did some probing today and what I found does not really match the library. The library work for sure but I think it could be optimized. Tomorrow I gonna test your latch delay theory and I gonna post my finding so far.

[pburgess]

Hi Safarir,

You're right. Upon further examination, it's not really a latch function in the strictest sense, and my impression of there being a timeout/failsafe was simply wrong!

Part of the problem is that the LED driver isn't really a shift register, but we've been relying on shift register terminology because it's the closest thing we have. And that's kind of thrown off my impression on how these things work. But you're right, there isn't really a latch (it's more like a counter reset operation).

Also interesting to note that the LEDs display color data as it arrives, NOT actually at the so-called "latch" signal...but each color byte isn't shown until the NEXT byte of data arrives. I'm not sure why it works that way, but it does, and I think this is the phenomenon you're seeing.

Anyway, if performance is a concern, I stripped out some unneeded debugging code and (finally) incorporated some optimizations that forum user mtbf0 had figured out a while ago. So you might want to take another look at the library on Github.

[johnblagg]

just curious but I bought a controller fron china for the digital led strips and it will run dozens of different chip sets including the 8806 and it came with a free program called lededit2012 to program the controller with ... would it possibly help you to have a copy of it since it is freely available online? could you possibly dissassemble it and figure out the lpd 8806 chip

[Safarir]

Part of the problem is that the LED driver isn't really a shift register, but we've been relying on shift register terminology because it's the closest thing we have. And that's kind of thrown off my impression on how these things work. But you're right, there isn't really a latch (it's more like a counter reset operation).

Also interesting to note that the LEDs display color data as it arrives, NOT actually at the so-called "latch" signal...but each color byte isn't shown until the NEXT byte of data arrives. I'm not sure why it works that way, but it does, and I think this is the phenomenon you're seeing.

That exactly what i figure out.

One thing I still need to test: does the led latch when the next byte arrive or at the next clock signal ? I think it gonna latch at the next clock personally.

Also, it does not really need 3 "latch/reset" signal by 64 leds, the relationship is more direct, something like 1 every 24. I also gonna test that when I gonna have the time.

Btw pburgess, you are working freaking fast, you figure out in 4 hours what took me 30hours straight to debug ...

[pburgess]

Hi John,

Appreciate the offer, but the library seems to be working pretty reliably at this point, so I don't think we need to pick anything apart right now.