I'm starting to test a WS2801 string with the release candidate,

Archive FastLED Archive
1

I’m starting to test a WS2801 string with the release candidate, and getting a strange result.

I’m fading up each light in turn (one channel only), then zeroing it and fading up the next (and looping). The targeted light is doing what I expect - BUT the following light toggles on/off (one channel only, but a different one!). So in this case, blue fades up while the downstream light’s red toggles on/off.

I was wondering if it could be some electrical defect in my string, but the interesting part is that when I get to the last light in my configured set, it’s the first light that toggles! So when I’m testing the first 10 (of a longer string), when light 8 is fading up in blue, light 9 is toggling in red, then when light 9 is fading up in blue, light 0 is toggling in red. So when fading light N up in blue, light (N+1) % NUM_LEDS is toggling red…

Any ideas? I can simplify and post some code if this doesn’t strike any bells.

2

I have seen some weird noise things with all the chipsets in certain conditions - usually solvable by grounding the data line at the far end - but someone who knows electronics better than I can probably speak to better solutions.

3

Usually when I have those random flickering it’s due to not enough current for the string. You can try to feed power in from both sides and also ground the data lines (at the far end) like Dan suggested.

4

No, it’s not the power or noise. There is zero flicker; the effect happens only when you send new data out, and is absolutely repeatable - and it “knows” how many pixels you have configured because it wraps.

Here’s a trimmed down version of the example code from the library, adjusted for 2801 on pins 6 and 7, and with the loop() code modified to show the problem.

There is code below (and more comments). Do I need to embed something to allow it to display?

//------------ code ------------
#include “FastSPI_LED2.h”
#define NUM_LEDS 3

struct CRGB leds[NUM_LEDS];

void setup() {
delay(2000);

LEDS.setBrightness(64);

LEDS.addLeds<WS2801, 6, 7, BGR, DATA_RATE_MHZ(1)>(leds, NUM_LEDS);

}

#define TARGET 2

void loop() {
leds[TARGET].r = 0;
LEDS.show();
delay(500);
leds[TARGET].r = 20;
LEDS.show();
delay(1000);
return;
}
//------- end code ---------

You can change TARGET to 0 or 1 to see the effect on the following pixel (modulo NUM_LEDS). You can also change NUM_LEDS to 4 and note that setting values for pixel 3 then will affect pixel 0.

It only happens if the channel you modify (.r above) is the last channel in the configuration (BGR above). If you change it to leds[TARGET].b there will be no problem, unless you change the order to RGB in the config, in which case it will come back.

I think that the last channel of pixel K is affecting the first channel of pixel (K+1) % NUM_LEDS. It varies depending on what value you set to pixel K, but the effect on pixel K+1 is consistent for any given value sent to pixel K.

I would imagine something like an extra pin transition at the end of the last pixel or electrical noise - except for the way it wraps when you send values to the last configured pixel which then (also) changes the first pixel. The effect “knows” how many pixels you have configured in your code.

5

That code runs just dandy for me. No flashing or flickering of any kind. I set TARGET=0 and the first LED blinked as it should. Then I set TARGET to 2, and the last one blinked. Set it to 1 and the middle one (or second) blinked.

6

Oh, and I made no changes to your code, I ran it as is, with a full 32 pixel string attached to pins 6 and 7, and NUM_LEDS set to 3, like your code.

7

One thing I did eliminate was power. All of my strings are always externally powered from a PSU providing 5V/35A. So I tried running the string both from my Arduino’s 5V as well as the 3V3. No problems.

8

This is running on an Arduino Mega2560. Would that have any effect?

I’m using an external 3.7A 12V power supply, which is also Vin for the Arduino. As I’ve said, there is no flicker and no variability, this is a deterministic rather than random problem, which “wraps” at the number of configured pixels. I can’t come up with any scenarios where noise or power supply could “save state” from the last configured pixel in the string for 1 sec, to reliably change the first pixel in the next refresh. Seems like it has to be something in the software, somewhere.

9

Are you sure the string you have is a 12V string? All of my WS2801 are 5V. As for the Mega, shouldn’t make any difference. I ran your code both on my Uno, Mega, and a breadboarded clone. Same result, no wrap around or anything like what you’re experiencing.

Now you said that the code you posted here is a trimmed down version of what I’m assuming is a much larger piece. Have you tried running just the code that you posted, without anything else?

10

This is getting stranger. I substituted an Arduino Uno, and the problem is the same EXCEPT there is no wrap-around. That is, with NUM_LEDS set to 3, setting TARGET to 0 or 1 has the unwanted extra effect on pixel 1 or 2 resp; but setting TARGET to 2 does NOT affect pixel 0. However the problem still shows “awareness” of how many pixels are configured (in the above case it does not affect pixel 3, which is wired and powered but not configured). So this still seems to be a software problem.

11

Let’s try an experiment: how many pixels are on your string? Set the NUM_LEDS to that value. Now set TARGET to NUM_LEDS - 3 (so if your string has 32 LEDs, set TARGET to 29. See which LED blinks. It should be physical LED 30 that’s blinking. Does 31 exhibit neurotic tendencies?

12

Here’s the string: http://www.aliexpress.com/item/DC12-input-WS2801-IP68-led-pixel-module-256scale-gray-IP68-4wire-red-green-blue-black-100pcs/545340313.html

(Except I got 6" spacing)

I tried setting NUM_LEDS to 100 and TARGET to 98, and indeed the last two pixels on the string both blink.

I still have the uno connected, so it’s not wrapping.

Oh, and I copied the code from this thread into a fresh project, and I still get the same effect. (By “trimmed down” in this case, I meant that I removed comments from the example included in the library" in order to create and test this case).

13

Eww. :slight_smile: Ok, hang on, I have one too …

14

By the way, the example that comes with the llibrary does appear to work OK. I’m not sure what’s different.

15

Out of curiosity, what happens if you switch to pins 6 and 10, rather than 6 and 7 - when two pins are on the same port, as 6&7 are, the code is slightly different than when they aren’t. I wonder if there’s a timing or noise things happening that’s causing the clock line to drift or flip when it shouldn’t? Which might explain why Ashley isn’t seeing it.

16

Wait, I take that back. That particular string that I have isn’t a WS2801. They’re LPD1101 … (LPD6803) which are now deprecated. Sorry.

17

I have stuff similar to this http://www.alibaba.com/product-gs/682552374/magic_led_5050_rgb_ws2801_led.html

18

OK, another strange syndrome.

I was wondering if it might have to do with the brightness scaling and found some more strange syndroms.

If you comment out the line “LEDS.setBrightness(64);” in setup(), the anomoly is unaffected.

If you set the brightness to a low value (13 or higher), it appears to dim the target LED K, but not the spurious LED K+1.

If you set the brightness to 12 or lower, neither LED lights. Not surprising, as (12*20)>>8 will be zero.

But these observations suggest that scaling the value set in the TARGET pixel doesn’t affect the anomoly until the target pixel’s value drops out entirely.

//-------------

Also, I used values of 0 and 20 in the demo case, which causes the K+1 pixel to blink in time with the brighter state of the target pixel. If you use, say, 45 and 20, then the K+1 pixel blinks in time with the dimmer value. That is, 0 and 45 both turn off the extra pixel, while 20 turns it on. While the state of the K+1 pixel is deterministic for any given value sent to the target (K) pixel, it’s not as simple as the MSB or LSB.

19

Dan - still testing on the Uno. Using pins 6 and 10 made the problem go away! So maybe it’s about being on the same port.

(Still really odd that the Mega would wrap modulo NUM_LEDS and the Uno doesn’t. Later I’ll test whether the Mega is also fixed by using 6 and 10 rather than 6 an 7.)

That’s it for tonight. Thanks to both of you.

20

When you poke at it again tomorrow, if you could try 5 and 7, I’d be curious how that works out, as they are same port but not adjacent pins.