ALapos mellényúlás LED-szalag ügyében

bevallom, kapkodtam picit, így aztán sikerült kétszer öt méter RGBW LED-szalagot beszereznem, csak épp 5V-os és 3+2 eres csatlakozóval szereltet (WS2812B LED-ek), ami nagyon nem való a 12V-os vezérlőhöz, úgyhogy most vagy találok valakit, akinek épp ilyenre van szüksége, és ad érte mondjuk darabonként 6E "jó" magyar Ft-ot, vagy kitalálom, hogyan fogom meghajtani és hasznosítani - miután vettem hozzá 5V-os tápot, merthogy 12V-os van egy rakat...

Tanulság: a netes vásárlásnál a kosarat kétszer nézd át - ugyanis volt 12V-os is benne, csak rosszat pipáltam ki, hogy kell :-/

A Banggood kinai oldal, a magyar fogyasztovedelmet a hajara kenheti, a szallitasi koltseg meg csak erre olcso, odafele nagyon nem.

--
When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

( Mcsiv v | 2019. 08. 01., cs – 19:34 )

Címezhetőből szerintem nincs is 12V, milyen vezérlőhöz szeretnéd ezt passzintani?
(egyébként mennyit vettél? engem lehet pont érdekelne ;))

// Happy debugging, suckers
#define true (rand() > 10)

3 sor kód egyébként, van hozzá library (fastled)
A 3-as csatlakozó piros ága a +5, a középső zöld az adat, a fehér pedig a ground
A 2-es csatlakozó ugyan az, leszámítva az adatot (a szálak közösítve vannak a 3-as csatlakozóval).
Gyakorlatilag a 2-esen táplálod, a 3-as csatlakozóról pedig nem a vezérlő adja, hanem ő maga kapja a delejt.
Az adat lábhoz sem kell semmi magic, mehet közvetlen valamelyik kivezetésre

Ezért is kérdeztem, hogy te milyen vezérlőhöz vetted (mert a 12V-ból tippelve te nem ilyen címezhető ledszalaghoz valóval rendelkezel)

// Happy debugging, suckers
#define true (rand() > 10)

Sima mezei MI-Light vezérlőt néztem ki, megfelelő ledszalaggal, meg persze piszkálta a csőrömet a mikrokontrolleres vezérlő "építés" is, de ez utóbbit egyelőre elvetettem - viszont a beszerzésnél pont nem azt a ledsort választottam, amit kellett volna.
Végülis nem annyira hűdedrága ennek a megvalósítása sem - csak ugye a terv egy távvezérlős led-es hangulatvilágítás, amit azért nagyobb falat összerakni normálisan...

Három sor nem lesz elég, mert rgbw szalagom van, a fastled meg nem támogat, csak rgb szalagot - azért némi trükközéssel csak megy, r, g, b, w a négy szín minden ledre kirakandő értéke: 


for ( int x=0; x<50; x++ ) {
  //             r1 g1 b1
  leds[4*x+0] = CRGB(r,g,b);
  //             g2 w1 r2
  leds[4*x+1] = CRGB(g,w,r);
  //             w2 b2 g3
  leds[4*x+2] = CRGB(w,b,g);
  //             b3 r3 w3
  leds[4*x+3] = CRGB(b,r,w);
}

Majdnem implementálja - külön nem tudja vezérelni a w ledet, ha jól olvastam - mindegy, összeraktam egy ilyet, ami egy tömbben várja a 150 darab LED-hez tartozó r, g, b, w értékeket, és a FastLED-del szépen kirakja a szalagra, miután megfelelően összekutyulta a bájtokat :-) 


#include "FastLED.h"
#define R 0
#define G 1
#define B 2
#define W 3
CRGB leds[200];

void rgbw2rgbstrip(byte rgbw[150][4]) {
  for ( byte i=0; i<50; i++) {
    leds[4*i+0] = CRGB(rgbw[3*i+0][R], rgbw[3*i+0][G], rgbw[3*i+0][B]);
    leds[4*i+1] = CRGB(rgbw[3*i+1][G], rgbw[3*i+0][W], rgbw[3*i+1][R]);
    leds[4*i+2] = CRGB(rgbw[3*i+1][W], rgbw[3*i+1][B], rgbw[3*i+2][G]);
    leds[4*i+3] = CRGB(rgbw[3*i+2][B], rgbw[3*i+2][R], rgbw[3*i+2][W]);    
  }
  FastLED.show();
}

Ez olyan újrakezdés, hiszen anno 8080 meg Z80 volt az igazi kezdet, aztán némi Xilinx, meg x86 vonal is volt, utána n+1 programozási nyelv jött szembe, és sok-sok év után most Arduino-val szórakozok :-)

A tűzkeresztség ott volt, amikor ki kellett törpölni, hogy a FastLED-del kitolt bájtsorozatból RGBW esetben melyik bájt, melyik LED-et vezérli.

Ez már intelligens, nem kell hozzá pwm-et csinálni, benne van mindegyikben a mikrokontroller. Ahogy nézem, az első LED az első 24 bitet magáévá teszi, a maradékot tovább küldi. A második LED ugyanezt teszi, így az eredeti stream második 24 bitje lesz az övé, és így tovább. A bit formátuma nagyon egyszerű. Egyetlen periódusú négyszög jel, s az alacsony és magas szintek ideje hordozza az információt. A középső élváltás helye van máshol logikai 1 és 0 esetében, a bithatárok mindig ugyanott vannak.

Ezt nem túl bonyás megcsinálni egy MCU-val. Nagyobb probléma kitalálni, hogy milyen mintázat futkorásszon azokon a LED-eken.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ket kiegeszites:
A fenti LEDekben van feher is. Szoval 32 bit kell neki, nem 24. (nekem sima RGB van, de ezen latszik a sargas fenypor).
A tapasztalat azt mutatja, hogy az idozitesre elegge erzekeny. Amikor ezzel jatszottam (mondjuk az enyem nyakon van, nem szalagban), az elso LED kicsit eltero szint produkalt, a jelalakot viszont rendbehozza, es amit tovabbkuld, mar rendben van (repeaterkent mukodik). Letezik hozza valami hivatalos driver, en Arduinos libet hasznaltam fel hozza, amit valaki ASM-kiegeszitesekkel irt, hogy kb. jok legyenek az idozitesei (ATMEGA328P utasitasok hossza alapjan megoldhato). Szoval annyira nem hibaturo, mint ami a protokoll leirasa alapjan latszik.

--
When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

A katalóguslap szerint +/- 150 ns hiba megengedett csak, ami valóban nem sok, ha jól számolom, 12 %. Viszont egy MCU egyetlen gépi ciklusa ennél gyakorta hosszabb - nyilván attól függően, milyen gyorsan van hajtva.

Itt vagy teljesen hardware-es időzítés kell - nagyjából a PIC-ek CLC moduljával realizálható feladat -, vagy úgy kell megírni a stream küldését, hogy az adat felszedése memóriából, netán kiszámítása a bit időzítésének része legyen. Mindezt úgy, hogy ha elágazás van a kódban - s jó eséllyel van -, akkor a különböző ágakon pontosan ugyanannyi legyen a futásidő. Nem lehetetlen, de elég kellemetlen, és tipikusan ez az a feladat, amelyet kizárólag assembly-ben lehet megírni.

A hardware-es támogatás nagyon sokat tud itt segíteni.

Szerk.: Jobban végiggondolva ezzel a roppant merev időzítéssel ez egy igen kellemetlen, nem túl végiggondolt protokoll. Ha lenne címe az eszközöknek, szebb lenne az élet.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Vissza kellene néznem, de úgy emlékszem, nem 400 ns és 800 ns az idők, hanem 450 ns és 800 ns, illetve 850 ns és 400 ns, szóval sajnos rosszabb a helyzet annál, amit írsz. Az persze más kérdés, hogy adott esetben tudatosan kihasználjuk-e a toleranciaként megadott 150 ns-ot az életünket megkönnyítendő. Viszont igaz, a pwm modullal ez egész tűrhetően managelhető. Ha másképp nem, 50 ns felbontású pwm, a bittől függő konstansok írásával.

A baj még így is az, hogy 800 kHz-cel kell adagolni a biteket, ami IT-ből nem fog menni. 32 MHz-es PIC esetén is csak 10 gépi ciklusunk van egy bit átadására, de gondolom, jó volna a bitet kiszámolni előbb. Vagy az egészet kiszámoljuk előre, letesszük memóriába - ez jó sok adat sok LED esetén -, majd onnan bután kitoljuk ennek a csodának. Ez pwm vagy CLC használatával menni fog, de még így is elég feszes lesz. Szubrutin nem fér bele, legfeljebb macro.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ilyen problémára ott a shift regiszter. Van uart meg spi és rögtön 8x több időd van.
Aztán nem biztos, hogy mogóképet kell közvetíteni, hanem elég csak egyszer beállítani. ;)
Az adatlap specifikál 0, 1 és reset állapotot. Itt a reset az a SET. ;) Tehát amit egy reset után shifteltél, abból az első 24 bitet megjegyzi, a többit továbbadja. A reset hatására megjeleníti a kapott adatot.
Az időzítés meg laza, mert 1250 +/-600ns (ciklusidő), vagy 400,450,800,850 +/-150ns, és a reset 50us.
Kísérletek, program itt: https://cpldcpu.wordpress.com/2014/01/14/light_ws2812-library-v2-0-part…

Ha programmal adod ki a biteket, akkor a nx24 bitnyi ideig azzal kell foglalkozni, aztán pihi.
A két 24 bites csomag között szerintem lehet egy << reset szünetet tartani. A cikk szerint a hatásos reset legalább 9us.

Amit elképzeltem, az annyi, hogy két analóg bemenet, az egyik a fehér LED-eket vezérli, ha ennek az értéke nagyobb, mint nulla, akkor R=G=B=0, W meg az analóg bemenet értékét kapja, és ez megy az összes LED-re, ha nulla, akkor W=0, és a másik analóg bemenet értékétől függően, célszerűen táblázatból jönnek az R/G/B értékek, szintén az összes LED-re. Hogy ezt egy "olcsó" Arduino-val hogy csinálom meg, az jó kis tanulás lesz - kérdés, hogy egy ilyen A2378 jó-e erre a célra?

30$ rohadt sok ezért :) Válasz egy tetszőleges kínai klónt, pl egy arduino nano (kínában 1$, idehaza 1500huf környékén van).
Arduino IDE feltelepít, majd az IDE library manager-ben a FastLED nevezetű csomagot keresd. Azt feltelepítve 3 sorból megvan a vezérlés. Telepítéssel, forrasztgatással, kutyafülével együtt kb 1 órás mutatvány :)

// Happy debugging, suckers
#define true (rand() > 10)

Az 1$-osban is, cserébe ugyanaz mint a 30$-os, csak kínai, mint ahogy a 30$-os is, de ők bevallják :D

Egyébként meg vehetsz egy ilyet is és akkor wifi-n keresztül is buzerálható lesz.
Ez is Arduino IDE-vel programozható, csak pár kattintással több az install, kódban meg ha kell, tudok segíteni

// Happy debugging, suckers
#define true (rand() > 10)

Az, hogy mit és hogyan fogok számolni, az megvan fejben, szerintem a mechanikai része a dolognak (potméterek és boboz beszerzése, összerakása) komolyabb munka lesz, mint a kódot összerakni, hogy működjön :-) Ja, és ,ár nézegetem, hogy kijelző, meg mindenféle szenzor is jó lenne hozzá - hiába, elkapott a gépszíj - meg a nosztalgia, hiszen automatika laboron is hasonló egyszerű feladatokkal indultunk :)

Hát igen, Arduino alatt letöltöd a programot és lám megy.

Bár igazából az Arduino épphogy elég a 800 kHz szalag vezérléséhez. Semmi mást nem tudsz csinálni vele, csak szalagot vezérelni.

Ha veszed az 500 Ft-os kínai blue pillt (stm32f103c8t6), abban DMA vezérlő van, igazából 1%-os CPU terheltség mellett 72 MHz-es processzoron 20k-s RAM-mal, 64k flash mellett átvered rajta az egészet. És nem kell interruptot tiltani, nem kell órajelet számolni, a DMA vezérlő megcsinálja.

A probléma, hogy egy DMA vezérlő felprogramozásához azért már ész is kell, nem elég a szoftvert letölteni.

Nem sértésnek írtam. Ha gyorsan LED szalagot kell vezérelni, én is Arduinozok.

Csak annyit akartam kiemelni, hogy az Arduino sem árban, sem képességekben nem versenyképes egy rendes ARM-mal.

Az a probléma, hogy rohadt kényelmetlen bármit is leprogramozni ARM alatt, pedig hardver szempontjából ideális.

Én arra használtam, hogy sztereo jelet mintavételeztem és a hallottak alapján vezéreltem a szalagot. DMA-val mintavételez, DMA-val küldi ki a jelet a szalagra, emellett még maradt időm FFT-re is. Ennyit tud egy STM32F103 500 Ft-ért.

Én sem sértésként írom. ;)
Ez van, amikor valaki zoftverhez ért.
Már itt is említettem a legegyszerűbb megoldást. Aztán utána is néztem.
Ebben a leírásban láthatod, hogy nem én találtam fel először.
A CPU terhelés 0%. ;) Igény esetén meg marhanagy buffer is köthető hozzá. Ha picike buffer is elég, akkor a külső memória elhagyható, vagy választhatsz száz forinttal drágább processzort. Persze ilyenkor 10-20 sor programot is kell írni. Én kezdésként PIC16F15323 mcu-t választanám. (Pár évvel fiatalabb, mint az an.)
Ezt az áramkört el lehet látni soros bemenettel, nyomógombokkal, van benne adc is. Rádásul megy 5V tápról is, így közvetlenül meg tudja hajtani a led szalagot. Ugyan nincs benne dma, de én anélkül is meg tudom írni. ;)

Az fft roppant elegáns, bár régen ugyanezt néhány rc taggal oldottuk meg. ;) Helyette - még ilyen 8 bites vacakon is - lehet néhány fir filtert futtatni.

16f84a-el kezdtem valamikor 15 évvel ezelőtt, kerülgettem a jófajta pic bugokat, a tonnányi cserét és a viszonylag heavy mplab-ot. Persze, mindig lehet jobb megoldást találni, sőt, DMA SPI-vel talán egyszerűbb megoldás mint amit eddig írtatok, de minek? Egy önbevallás alapon is kezdő pedig ezek közül egyiknek sem fog neki menni, mert nem szopatja magát. Egy kezdőnek tökéletes egy teljes arduino board, vagy egy wemos d1 mini. Ez utóbbiban bőven van craft, van benne wifi, egy click->next->next out of the box ide -vel, nem sokkal drágább mint az arduino vagy az stm32 és lehet koncentrálni arra amire kell.

// Happy debugging, suckers
#define true (rand() > 10)

Inkább "újrakezdő", ha lehet kérni - Anno Z80-at elég sokat gyötörtem, még bőven papír-ceruza-kódtáblázat - hexa kódok epromba írása köröket futva. Tudom, ez egészen más - mármint nem annyira alacsony szinten művelt bit- és bájtbűvölés - de épp ezért érdekelt már korábban is, csak épp nem jött szembe olyan feladat, amihez passzolt volna. Na ez a ledszalag meg pont ilyen :-)
A d1 minit néztem - egy analóg portja van, ami nekem kevés, mert minimum kettőre, de inkább háromra van szükség - multiplexert nem akarok építeni-vezérelni pluszban, bár szerintem nem lenne rettenet nagy kunszt az sem :)

Ezért is ajánlottam tavalyelőtti modellt. Bár a pic bugokat előbb-utóbb megszokja az ember. ;)
Az mplab fostalicska, de azért vannak átmenetek. Pl. a gputils - gpasm, amibe néhány módosítás az én kérésemre került bele az abszolút kód támogatására.
A fenti az egyik legegyszerűbb megoldás, mert program sincs. Pont ezt akartam kiemelni, hogy egy hardver problémát - mivel nincs erre a protokollra céláramkör - a legegyszerűbb hardverrel megoldani. És azt is össze lehet klikkelgetni.
A kezdő meg néha befürdik a nagy szoftverrel. Külön kedvencem, amikor egy dspic-re filtert programoznak, nem assemblerben, de mindössze a 120MHz órajelet kihasználva. Pedig van dsp, lib, csak érteni kellene.

Az ARM-ok DMA vezérlője eszméletlen. Tudsz vele ADC, SPI, I2C, Timer, I2S, USART DMA-t csinálni, párhuzamosan, akár 8 csatornán.

Képes körkörös DMA pufferelésre, kiadhatja a DMA puffer megtelt és a DMA puffer félig megtelt jelet.

A Neopixel protokollt timer DMA-val szokták csinálni. Elindítasz egy 800 kHz-es timert és az "0/1 bit" hosszát DMA-val vezérled (nálam az előosztás után 29 volt egy ciklus, 0 bitnél 8-at írtam, 1 bitnél 21-et, de más előosztót is használhatsz).

1 bájt átküldéséhez timernél 8 bájt kell. Létrehozol egy 64 bájtos puffert, feltöltöd, amikor puffer megtelt, vagy puffer félig megtelt megszakítást kapsz, akkor a puffer megfelelő felét felülírod új adatokkal.

Úgy kell elképzelni, hogy miközben egyik félpuffert küldi a rendszer DMA-val, aközben a másik félpufferen dolgozol. Amikor meg elfogynak az adatok, 0-t írsz a timerbe (50 us-ig), ami hatására kimegy a RESET és kikerülnek a bitek a szalagra).

Az a durva, hogy timer DMA-val tetszőleges jelalakot előállíthatsz, csak a 0-1 jelek hosszát kell beállítani. Hihetetlen képességei vannak ennek a chipnek.

Szóval ravasz timer van a kezedben, ami sok dologgal - pl. dma - összeköthető, és ebből egy szinkron sequencer kialakítható.
Minden feladatot meg lehet oldani célhardver (pl. usb), sequencer, program vagy hardver alkalmazásával. A célhardvert nem neked kell összerakni. A további kettő általában szinkron megoldás, ezért csak az órajel növelésével biztosítható a megfelelő felbontás és pontosság. Ha ez nem megy, akkor külső áramköröket kell alkalmazni az aszinkron külső események feldolgozására.
Az általam javasolt mcu pont erre (is) ad lehetőséget. Látszólag egyszerű and, or, stb. áramöröket lehet kialakítani, ami elsőre nem tűnik nagy durranásnak. Ha meg szembejön egy feladat, akkor kiderül, hogy arra az egyszerű and kapura 40 külső és belső jelforrást lehet kötni. Azzal meg szinte bármi könnyedén megoldható. A végén lényegesen kisebb, olcsób mcu alkalmazható, amelynek még a memóriája, órajele és fogyasztása is kisebb lehet.
Ezek a specializált áramkörök kisebbek, egyszerűbbek, és az új fejlesztésekben már tömkelegével szerepelnek. Már a megfelelő típus kiválasztására sem kell sok energiát fordítani, mert - akár az alacsony lábszámú tokban is - mindenben minden is van, és látszólag felesleges számban. Csak ki kell válogatni, összekötni és paraméterezni a megfelelő elemeket. Igaz, ez inkább hardver, de hát fillérekért ott van a tokban!
Érdekessége a dolognak, hogy csokorban hozzák ki a pic16 sorozat új elemeit - úgy látszik fogy. Pedig az csak 8 bites és 14 bites utasítással rendelkezik. Viszont választhatsz a feladatnak megfelelő konfigurációt. Létezik pl. olyan, amibe benne van a 64 bites, több üzemmódú pid vezérlő. Nem kell magas órajel, sem lib, csak fel kell kapcsolni és megy. Az ára meg 300Ft.

A PIC-től nekem zsigeri hátborzongásom van.

Valami memória szegmentált rémborzalomra emlékszem, de lehet, hogy csak a 8 bitesek lettek eszméletlen szétbarmolva, a többi normális.

Ismerkedésképpen a PIC dokumentációját kezdtem olvasni és miután végetért, úgy gondoltam: váltok.

Persze lehet, hogy kellene valahonnan olcsóért programozót szerezni, de oda is +12V kellene, ami baromira nem tetszik, mert a programozó lábakat rendre rosszul szoktam felrakni, aztán azonnal szétég minden.

Meg a C fordító (mplab): ingyér szar kódot generál, ha fizetsz, akkor jót. Ha ingyér használod, dupla annyi memória kell, mintha fizetnél.

Kb. erre emlékszem, nekem túl macerásnak tűnt a PIC.

Nem jársz messze az igazságtól. ;)

Ahhoz, hogy takarékoskodni lehessen a fogyasztással, a flash méretével és az utasítások 1 vagy max 2 szó hosszúak lehessenek, ezt kell tenni. Valójában ezért olyan olcsók ezek a 8 bites processzorok. A 12, 14 vagy 16 bites utasításban annyi címbit fér el, ami egy szegmens (bank) mennyiségű memóriát tud megcímezni. A 16bites és 24bites utasításszélességű modellek (PIC24 és dsPIC) már az űrrepülőgép katergóriába tartoznak. Bár ott is poénos, ha ha flash-t 3 bájtonként vagy párosával címzed. ;)

A programozó adapter (PicKit3) maga állítja elő a programozó feszültséget, rövidzárvédett és elég jól bírja a fordított bedugást is. ;) Az eszközök jó része meg programozható 5V-on is.
Ezen kívül van licencelt szoftverem is hozzá (pickitplus, 13GBP)), ami a gyártó által nem támogatott modelleket is tudja programozni. Meg sokkal gyorsabb. Igaz, rengeteget vitáztam a fejlesztőkkel, de még nincs vége. Csak pihenünk. A PicKit3 kínai klónja kb. 3500Ft.

Hát igen, a C fordító. 20+év C programozás után alig bírtam működő kódot előállítani vele. Ráadásul ostobaságokat és felesleges kód darabokat is előállít néha. Valamint a nagygépes libek és a magasszintű nyelveket (nem) támogató emuláció is igen kártékonyan hat a kódra. Hasonló a Mikroelektronika fordítója is. Jókat hallottam az SDCC és PicBasic fordítókról, bár egyiket sem használtam. Az MPLAB X IDE már gcc alapú fordítót tartalmaz.
De sebaj, 35+ év tapasztalatom van assemblerben. Ez is egy kicsit szívás, mert a gyártó fordítója szart se tud. Bár van előnye a bit definícióknak, ami miatt ugyanazt csak hosszadalmasabban lehet leírni. A mai assembler fordítókat minimum C++ vagy java tudással rendelkező programozók készítik. Ezért mindazok a fícsörök, amitől tisszességes lesz egy ilyen fordító, elmaradtak. (Alapul véve az Intel ISIS-II:as, a macro80 és a masm fordítókat.)
A megoldás gputils:gpasm fordító. Az alapvető hiányoságokon kívül tényleg csak néhány apró hibája van. :)

A PIC dikumentációja elég jó, bár néha tényleg lehet fogni nem dokumentált bugokat.
Az egyes termékekben 5V-os szenzorokat használok, ezért a fejletteb 3,3V-os példányok nem jelentenek alternatívát.

Csak úgy megemlítem, hogy a PIC-hez képest az aduino (és rpi) i2c implementáció tökéletlen, az ARM-é meg nem teljesen korrekt. (Ők írják.)

Egy 1500Ft-os cucctól nem is várok többet: képes legyen két analóg bemenetet olvasni, és ha bármelyik változott, akkor az értékeik alapján (vagy az egyiket és három nullát, vagy egy nullát és a másik alapján táblázatból vett három értéket) négy bájtot n-szer kitolni a megfelelő kimenetén, majd ezt ismételni. Mint amit a "buta" rgbw szalagok vezérlői is csinálnak. Persze jönnek a további ötletek (nyomógomb a színes/fehér üzemmód közötti váltásra, a szalag teljes lekapcsolására, etc, etc...), de ezek közül egyik sem az időkritikus részt "terheli". Szerintem...

( bucko | 2019. 08. 01., cs – 16:42 )

Manapság már nem nagy kihívás a 12->5V átalakítás.
A vezérlő jelekre meg köthetsz egy cd4050-et.

( Csab | 2019. 08. 02., p – 07:32 )

30m címezhető LED szalag kezelése, hát hogy is mondjam kihívásokkal teli. Ezek a szalagok arra jók, hogy hóesést szimulálj, de 30m az sok.

Az 5V problémája az, hogy nagy a járulékos veszteség (előtét ellenállások). Kis feszültség, nagy áram kell hozzá, a LED szalag tápkábelei meg képtelenek a szükséges áram biztosítására. Tehát 30m LED szalagnál a szalaggal együtt nyugodtan viheted a +5V, GND kábeleket is, hogy fel ne forrósodjon.

Utána jön a másik, nagyobb probléma: a vivő jel frekvenciája 800 kHz. Egy 30m-es szalag 30x60=1800 LED-et tartalmaz. Egy LED-hez 24 bit kell, a teljes szalag 43200 bitből áll. A végeredmény: 800 kHz / 43200 = 18.5 Hz. Ezt bizony látni lehet, a szalag eleje és vége nem egyszerre fog frissülni.