Whelp, I'm all out of ideas.

Archive FastLED Archive
,
1

Whelp, I’m all out of ideas.

New control board, shielded wiring from the board to the sockets, 100Ω resistors at the start of the data line, 400Ω resistors just before the strips’ Din, 1kΩ terminating resistor between the end of the data line and ground. All of the individual DC-DC converters on each stick have 47µF input caps, some of the sticks have great big honkin’ 1000µF output caps, doesn’t make a lick of difference.

Exhibit 0, full speed (code exactly as you see here at https://bitbucket.org/ratkins/onlyinjapan):

Note the flickering on green.

Exhibit 1, with the count-the-ms-since-last-loop/FastLED.delay() exchanged for a simple Arduino delay(100):

http://youtu.be/j4D8cw3NGcM

Here you can clearly see there’s something going wrong between my code and the WS2812Bs—they’re flashing off/dim blue when they should be full-blue all the time. If I happen to upload a new version of the sketch in the middle of the flickering colour, maybe a 3rd of the LEDs are frozen in in the off state—indicating the last frame was corrupt. Also odd that sometimes it’s the green having a problem, sometimes the blue (red seems always to have been fine.)

I’m trying to get hold of someone with an oscilloscope, but short of that has anyone got any idea what else I might try?

2

Supplemental: from a cold start it works perfectly for a minute or two before the flickering becomes evident. Something gets screwy when everything warms up.

3

Does the problem go away with less LEDs?

You could try a binary chop, to see if there is a magic number your hitting.

Else, the only other thing is, have you got genuine WS2812s?

There is a subtle timing difference between the WS2812(S) and WS2812B

If you cant get hold of a scope, you could try a Saleae logic analyzer in a pinch

4

Looking for WS2812B timings, i just found a good blog post, that mentions “relaxed timing” that might not mess you up on low numbers of LEDs. I guess with more LEDs, the timing will become more critical.

5

Robert, just curious, if you set the FastLED brightness to something very low like 10 out of 255 is the problem still there?

6

That, was a very interesting clue Steve French.

Check this out:


The first video is setBrightness(128), the second is setBrightness(129). Note the odd corruption at the white LEDs (that I’m using to indicate which channel is which.)

@Daniel_Garcia , @Mark_Kriegsman anything else I can specifically test?

7

Have you tried splitting out the led definitions into PORTD/PORTC? Wonder if this is something with the combined 16-way output.

8

Have you tried it fixing the brightness at 255 instead of the analogue input.
Are the data lines from your panel to the strips twisted pairs and grounded at both ends?

9

@Aaron_Liddiment ​ yes, I’ve had weird behaviour when using analogue read, its very sensitive!

10

It’s nothing to do with the pot, those last two videos were shot with setBrightness() set “manually” in code.

@Daniel_Garcia , I didn’t realise I could set the PORTD/PORTC definitions simultaneously. But I did try setting just PORTD and PORTC individually and I still got the shimmering.

11

@Stuart_Taylor the thing with the relaxed timing is to not go too quickly. If you go faster than 1.25µs per bit (30µs/pixel), then what ends up happening is data gets crushed/lost the further down the line you go. As long as you are taking longer than that, you don’t run the risk of losing data. I’ve done strips as long as 240 off the parallel drivers here with no issues.

12

@Daniel_Garcia Have you done 16-way output with that many LEDs on each pin, or just 8-way?

(BTW I’ve finally found someone with a scope and a logic analyser to come around on Wednesday so I’ll have more hard data then. But in the interim, still keen to hear about any more diagnostic steps.)

13

Robert, I can’t remember from before… did you say that if you only ran some of the sticks they were stable? Is that still the case? Is that related to pins on different ports?

14

I was doing 24-way off of a due, and I tested the 16-way on the teensy 3.1 with 60 led strips.

Hey, what happens to the glitching strips if you unplug the rest? (But still run the same code)

15

I am curious to see on video what happens again with sequential output on the 16 pins (non-parallel) after things warm-up as you mentioned.

I understand you will get horrible FPS numbers and that would not be useable for your application but if it is still 100% solid, you will be able to eliminate certain other concerns and focus on the parallel output part only !!

16

There are two separate manifestations here, which may both be rooted in the same problem or may be totally unrelated.

  1. At setBrightness(128) or lower, everything is perfect.

  2. “Dodgy”: these are the ones that at setBrightness(129) go completely haywire—things flash all over the place, we get completely wrong colours (https://youtu.be/AQhawL4YiUE). These are pins 9, 10, 11, 12, 13, 15, 22, 23.

  3. “Shimmering”: with setBrightness(255), the haywire-wrong-colour-ness goes away, but we get the shimmering effect illustrated by https://youtu.be/zZqm2LE1qo4. This happens on pins 9, 13, 21, 22.

So, in answer to your question @Daniel_Garcia , the “dodgy” pins are dodgy no matter how many sticks are connected, and that problem seems to stay with the pins. The “shimmering at full power” problem moves around a bit, but it’s still there when you unplug the non-shimmering ones.

Anyone else really confused?

17

Hi @Robert_Atkins , do not get too entangled with details such as ‘dodgy’ and ‘shimmering’ they are surely manifestations of the exact same problem… bad data !!!

18

Because you get different behaviours with changing brightness (IE: more current to the LEDs) I would look at DC offsets in the GND reference wires.

With DC offset comes greater potential for noise or crosstalk causing data corruptions.

Look for this DC offset specially if your GND reference wire is also used as the DC power carrying GND wire that feed each stick.

19

We’ll definitely look at this when we have the scope on-site tomorrow.

20

you can do that with a simple multimeter !!