garageCube

[MrBen85]

Ive manged to get the teensy/madmapper setup working properly but only on a low number of leds. Any setting above 75 leds will make the leds closest to black blink and act weird. Everything else works fine, i can connect and control the whole strip with madmapper, animating correclty. The problem is that the led pixels closest to black act wierd/wrong.

I only want to get this single strip of 250 leds working prpoperly, any suggestions are appreciated.
Led Strip type: WS2812b
Teensy 3.2

-My troubleshooting has been to double check power supply, which i can confirm is working as it should becuase the same setup works fine with other led strip controllers. its a 5v 20A supply.

-Test run the fastled simple test on any number of leds. And i can confirm that this problem does not persist with the simple test file. the leds light up only to the specified number of leds and then cut of cleanly.

-Changed "while (Serial.available() > 0 && bytesRead<30000)" to 3000, 300 and 30. -No change in behaviour.

-Changed both these numbers a few values up and down,-gave no change in behaviour.
"char dataFrame[NUM_LEDS*3];
int readingFrameOnLine=-1;"

Please see attached gifs.

Many thanks.

[MrBen85]

heres an additional gif showing how it looks when running the test leds on 77 leds. it fills in about 10 more leads and acts weird on the ones closest to black.

[mad-matt]

Hi,
I've only been testing with chips that have a clock pin (4 wires: power, ground, data, clock). Those chips permit spending time reading data from USB and delay updating the outputs for a few microseconds.
I would suggest: use a teensy 4 (600 MHz CPU) or use a LED strip with a clock pin (for instance APA102).
With APA102 I tested up to 12 meters of 144 LEDs on a single line at 60 FPS.
But anyway this USB - Arduino thing is great for prototyping, but a good hardware LED driver will do things better (ie Advatek Pixelite)

[MrBen85]

Hi Matt.

Thanks for the reply, I finally got it working as it should, using a arduino esp32 and artnet via wifi.
I also tried the teensy 4.0 but that didnt work either. Perhaps its the 3.3v vs 5v data signal output.

Its been a interesting and at times frustrating process, and ive learned a lot, before this i didnt know the existence of jumper wires, breadboards, artnet universes etc.. and only heard about arduino by name, but never understood the whole devboard thing.

Id like to say thanks to the Mad team for lowering the rental price during the lockdown,
It allowed me to pass some time at home playing around with this software for fun as I already had the led strip along the ceiling as a fancy moodlight, controlled by a off the shelf led controller.
Also thanks to amazon for no quibble returns

For anyone looking to make a similar cheap wifi artnet thingy ($10)
I followed this tutorial:
https://resolume.com/support/en/diy-pixel-lab

And then used this code for the arduino:
https://learn.sparkfun.com/tutorials/us ... pixels/all

*this artnet receiver works with both resolume and madmapper which i have successfully tested.
Im driving 240 leds across 2 universes (720 cahnnels). Both unicast and broadcast work fine, unicast better as its less lag.
-Will it work with more strips, and universes? i have no clue.

Happy Mapping!

[mad-matt]

Good news. So what change fixed the issue ?
I tested upto 12 * 144 RGB LEDs with APA102 at 2 Mhz on a single line at 60 FPS, so 5184 channels * 60 FPS. I suppose you could have a limit with the serial port bandwidth at some point. But no idea where this limit would be.

[MrBen85]

To be honest, i have no idea. But the new setup does point out that the output data signal needs to be converted from 3.3v to 5v.
And you achieve that using the SN74HCT245N chip. The same chip which is in the octows2811 thing.
So my guess would be that the teensy needs this in order to run more than 75 leds properly.... And maybe i do have an idea afterall.

[mad-matt]

Indeed that mightbe the reason. If you use LEDs that require 5V on data (& clock) pin(s), the longer your line is, the more you have chances to have issues.