garageCube

[Simonluca]

Hi guys!

I am putting together a project with 300 LEDs arranged in 5 strip of one meter each. I am using a Teensy 4.0 and WS2812b powered through a 5v PSU.

At the moment though I am only testing a single strip of 60 LED, with the same set up.

I get the 60 pixels strip to run the "JUST_TEST_LEDS" almost fine as all LEDs blink as expected apart from the first one which stays on.

When I then go into MadMapper the strip just behave randomly. The whole strip turn on when just the first pixel is on white and then it goes off proportionally when it goes on black but with some heavy blinking, almost like if there is some kind of interference. If I then push the reset button on the teensy the LEDs stop at the last dmx inputs and stop blinking.

I probably have done something dumb somewhere (I should mention that I'm a total noob here!) so if anyone could share some wisdom I would greatly appreciate it!

Thanks.

[Simonluca]

I thought I'd add a video to show the behaviour and also the code I'm running on Tennsyduino:

https://vimeo.com/406195519/d4d20ef04a

[mad-matt]

Hi,
If you have the option, prefer using a LED strip with a clock wire, it avoid all timing issues, which is what you have here. WS2812 requires a constant bitrate and we might spend too much time reading USB data before calling FastLED again.

1- I propose you test this change:

while (Serial.available() > 0 && bytesRead<30000) {
processByte(Serial.read()); bytesRead++;
}

In this line, replace 30000 with 3000 for instance.
I haven't tried with teensy 4.0 at the moment, but as it performs very fast there should be no problem.

Let me know if it solves

[mad-matt]

Also: Which FastLED library did you install ?

I never tried with teensy 4.0, I saw last year they released a fix for teensy 4: https://www.reddit.com/r/FastLED/commen ... 0_support/

[Simonluca]

Thanks for the reply mad-matt. Changing bytesRead<30000 to 3000 did not work.

And yes I was following the new FastLED parallel protocol for the Teensy 4 Dalready. I have also added a level shifter since last time I wrote.

Essentially now everything works but with some random pixels blinking each side of the ones receiving inputs from MadMapper.

Is not having a Clock pin the only reason or is there anything else I should try? I've already changed strip once (I was using RGBW before and they did not work at all) so I would love not to have to buy a new strip, I'm running out of money

[mad-matt]

I was using RGBW before and they did not work at all

MadMapper just send the ArtNet universe data, so you could drive any kind of things with MAD Led protocol, it's just a way to stream DMX channels (8 bits values) to the arduino. But indeed the arduino sketch provided does handle only RGB, so it requires adapting FastLED initialization, ie "RGB here"
FastLED.addLeds<APA102, DATA_PIN_LINE0, CLOCK_PIN_LINE0, RGB, DATA_RATE_MHZ(2)>(leds_line0, NUM_LEDS_LINE0);
and update,
for (int i=0; i<readChannelsCount; i++) {leds_line0=CRGB(dataPtr[0],dataPtr[1],dataPtr[2]); dataPtr+=3;}

Is not having a Clock pin the only reason or is there anything else I should try?

I should try again with teensy 4. I never tested with latest FastLED. I had feedback from a bunch of users having success. But with this kind of things, there can be lots of issues with can't have control on (cabling, soldering...) I'm mostly using APA102 to have a clock.

Changing bytesRead<30000 to 3000 did not work.

To be extreme try with 100. Teensy 4 is so fast anyway that reading 100 bytes per loop shouldn't be an issue, even 10 hehe.

[Simonluca]

Still not working properly.

I also tried the example sketches from FastLED library and they don't work properly either, while the ones from Neopixel, like the strandtest, work perfectly.

I think that should mean that the problem is not in the wiring or soldering, right?

[mad-matt]

If you have a sketch working properly it means that cabling is ok for sure.
Which version of FastLED is installed in your environment ?

[Simonluca]

I am using FastLED 3.3.0 and at the moment I have two parallel output of 120 pixel each.

I tried the FastLED-simple-test.ino and it works properly, same goes for other Examples sketches from FastLED library, except some problem with FastLED.delay().

But when I uncomment #define JUST_TEST_LEDS on the the sketch FastLED-serial-only-single-line.ino the blinking it's very jumpy.

And when I lower the bytesRead<30000 to 3000 or 300 or 100 it gets worse to the point where there's no blinking anymore, the leds just stay on. I have also tried to rise it and that doesn't work either.

[mad-matt]

I don't have WS strips here. Next time I go to the office I'll take some. Sorry I'm not able to help you at the moment. Maybe there's a USB communication issue ? No idea what can be happening.
Maybe you could try to just send data for 30 LEDs on a single line (change routing in MadMapper and reduce LED count in arduino sketch), then if it works, increase LED count, then if works, add the second line... You might understand where the issue starts happening and we'll understand where the problem is.
Does the problem happens if you send a moving line from MM with a lot of black (so you reduce power consumption) - ie "Line Patterns" material ?

[Simonluca]

I tried reducing the LED count from the Arduino sketch but when I go lower than the actual number of LEDs on the strip the behaviour gets worse. The whole strips starts going crazy.

I'm kind of stuck with this project, going through the Arduino sketch for animation is going to be too time consuming and also I don't have the knowledge to do it.

I'm basically building a scaled down "film-studio" to shoot miniatures and create animated lights effects and I need to be able to change and adapt the LEDs animation quickly and precisesly. Mad-mapper would be the best solution!

[franz]

As a sidenote, I'd suggest buying a pixlite LED controller instead of a teensy.
Of course it is not the same price (200e vs 35e), but if you take into account the time you took to try make the teensy work,
I think the pixlite wins ...

[Simonluca]

I know mate!

When I was planning the project I thought I would save some money going through the Teensy route. I was aware it was going to be time consuming and full of head scratches but it also was the beginning of lock-down in my country so I didn't mind some problem solving to keep me busy.

I did not envisage it was gonna be this hard though!