Jag använder PLCC-4 smd Leds med gott resultat. Kör med 10 mm eller 7,62 mm pitch. Betydligt bekvämare med RGB i en Led. Sedan har jag PCB stackningsbara paneler med 16x32 leds.
Vilken datahastighet kommer du behöva mellan modulerna ?
Ledix -en gigantisk LED matris
Mellan varje enhet så blir det 100 Mbit ethernet vilket ger möjlighet till att köra ca 250 enheter med 16x16 pixlar över en enda kabel.
Vad är det för projekt du håller på med ? Blir lite nyfiken när fler verkar hålla på med det här
Vad är det för ytmonterade dioder du använder och vad har de för ljusstyrka ? Antar att du bygger en mer traditionell ledskräm på grund av den låga pitchen. Hur ser dina ledpaneler ut ? Har de både drivers och styrelektronik på samma kort eller har du något externt styrkort i varje modul och vad kör du för typ av överföring för datan mellan panelerna ?
Vad är det för projekt du håller på med ? Blir lite nyfiken när fler verkar hålla på med det här
Vad är det för ytmonterade dioder du använder och vad har de för ljusstyrka ? Antar att du bygger en mer traditionell ledskräm på grund av den låga pitchen. Hur ser dina ledpaneler ut ? Har de både drivers och styrelektronik på samma kort eller har du något externt styrkort i varje modul och vad kör du för typ av överföring för datan mellan panelerna ?Se upp med latenstiden om du kör kaskadkoppling (RX->MAC->TX). Det bör gå att koppla in flera enheter på samma twistpar om man tar hänsyn till kapacitans och impedans. Då det är fråga om enkelriktad kommunikation. Och då vinner man i det att alla noder har samma latenstid från huvudnod till mottagande led-panel.
För automatisk addressering skulle man kunna ha en parallell rs485/oc bus el liknande som är kaskadkopplad och därmed kan inkrementera address angivelse för varje passerad nod.
Du kan skicka valfri data mha UDP och på det sättet ungå att ge noder som kör IP fnatt till kostnaden av mer overhead. IPv4 UDP kräver ingen checksumma tillskillnad från IPv6.
I övrigt så brukar inte IP stackar få alltför mycket fnatt av paket dom inte känner igen alls. Tänk på att normala noder slänger allt som inte stämmer med deras egen MAC eller är Broadcast.
För automatisk addressering skulle man kunna ha en parallell rs485/oc bus el liknande som är kaskadkopplad och därmed kan inkrementera address angivelse för varje passerad nod.
Du kan skicka valfri data mha UDP och på det sättet ungå att ge noder som kör IP fnatt till kostnaden av mer overhead. IPv4 UDP kräver ingen checksumma tillskillnad från IPv6.
I övrigt så brukar inte IP stackar få alltför mycket fnatt av paket dom inte känner igen alls. Tänk på att normala noder slänger allt som inte stämmer med deras egen MAC eller är Broadcast.
Dels konstruerar jag div displayer åt kund, dels så driver jag några egna projekt. Ett av dem rör en kommande krets som kommer förenkla konstruktionen av just video displayer.
Kretsen styr 16x16 lysdioder via standard seriella konstantströmsdrivare, dvs du behöver inte ha dyra PWM drivare. Kretsen har bland annat följande:
* 16Mbit/s seriel matning (med 8-bit adressering inkl broadcast)
* Gamma korrigering (24 bit RGB in till bildbuffer, 48 bit RGB ut till LED:arna)
* Vitbalans
* Dot correction (kompensation för ojämn i intensitet mellan olika LED:ar) som sparas i inbyggt e2)
med mera
Det officiella demokortet kommer innehålla 32x16 RGB leds på ena sidan, samt CC drivare plus två display controllers på andra sidan.
Stackningsbar i både X & Y. Kommunikationen mellan korten sker via LVDS sladd som sedan går till drivkort som matar pixeldata.
Vore inte fel med fler demo projekt för att promota kretsen.
Om du är intresserad och tycker det är ok med en NDA (rörande kretsen) så hör av dig! Kan nog framöver ordna spons på kretsar mm. Om du kör 16x16 leds per modul så passar ju kretsen rätt bra.
Exempel på lysdioder: Farnell 1554799
RGB = 620mcd, 1200mcd, 280mcd
Den hör väl inte till de billigaste, men är väldigt stark för att vara SMD
Blir bra färgblandning också då chippen sitter väldigt tätt i PLCC-4 kapseln.
Kretsen styr 16x16 lysdioder via standard seriella konstantströmsdrivare, dvs du behöver inte ha dyra PWM drivare. Kretsen har bland annat följande:
* 16Mbit/s seriel matning (med 8-bit adressering inkl broadcast)
* Gamma korrigering (24 bit RGB in till bildbuffer, 48 bit RGB ut till LED:arna)
* Vitbalans
* Dot correction (kompensation för ojämn i intensitet mellan olika LED:ar) som sparas i inbyggt e2)
med mera
Det officiella demokortet kommer innehålla 32x16 RGB leds på ena sidan, samt CC drivare plus två display controllers på andra sidan.
Stackningsbar i både X & Y. Kommunikationen mellan korten sker via LVDS sladd som sedan går till drivkort som matar pixeldata.
Vore inte fel med fler demo projekt för att promota kretsen.
Om du är intresserad och tycker det är ok med en NDA (rörande kretsen) så hör av dig! Kan nog framöver ordna spons på kretsar mm. Om du kör 16x16 leds per modul så passar ju kretsen rätt bra.
Exempel på lysdioder: Farnell 1554799
RGB = 620mcd, 1200mcd, 280mcd
Den hör väl inte till de billigaste, men är väldigt stark för att vara SMD
Blir bra färgblandning också då chippen sitter väldigt tätt i PLCC-4 kapseln.
blueint: Har hittat ett ethernetchip som har två ethernetportar och en switch i samma kapsel. Dessa kan köras i repeat mode vilket ger väldigt låg latency vilket gör det möjligt att länka flera moduler efter varandra. Datan kommer sen skickas i råa ethernetframes. Kretsen kan även stänga ner valfri port vilket jag tänkte använda för att addressera enheterna. Masternoden skickar ut ett broadcast för att tala om att det är dax för nya addresser och alla noder slutar att skicka vidare all trafik. Sen skickas de nya addresserna ut och varje nod som blivit tilldelad en address börjar skicka vidare trafik igen. På så sätt kommer alla enheterna att få addresser i samma ordning som de är anslutna.
pegasus: Kan du ändra addressen, gammatabell och korrektionsdata via databussen eller är det hårdkodat från början ? Vad har du för PWM frekvens och frame rate ? De flesta drivare klarar väl som högst att klockas med 30 MHz och kör man 16 bitars PWM så kommer man väl inte upp i mer än 30 Hz om det är 16 bitar som ska in varje gång.
Har kollat på dessa dioder också och de verkar rätt trevliga. Avago har tydligen även en lite större diod i PLCC-6 kapsel med samma data som verkar intressant. Har du nån erfarenhet av dem kanske ? Måste man kompensera mycket för att få samma intensitet mellan dioderna ? Funderar på om det räcker med att bara kompensera för intensiteten eller om man måste ge sig på att korrigera för våglängden också.
pegasus: Kan du ändra addressen, gammatabell och korrektionsdata via databussen eller är det hårdkodat från början ? Vad har du för PWM frekvens och frame rate ? De flesta drivare klarar väl som högst att klockas med 30 MHz och kör man 16 bitars PWM så kommer man väl inte upp i mer än 30 Hz om det är 16 bitar som ska in varje gång.
Har kollat på dessa dioder också och de verkar rätt trevliga. Avago har tydligen även en lite större diod i PLCC-6 kapsel med samma data som verkar intressant. Har du nån erfarenhet av dem kanske ? Måste man kompensera mycket för att få samma intensitet mellan dioderna ? Funderar på om det räcker med att bara kompensera för intensiteten eller om man måste ge sig på att korrigera för våglängden också.
Alla parametrar (gamma tabell, dot correction, vitbalans, pixelpos mm) kan laddas om via databussen. Man kör multidrop så långt 16Mbit räcker, bygger man större displayer så får man köra med flera segment.
Angående adressen så sätts den initialt via en daisy chain signal i kabeln.
Angående dot correction så kommer ju ofta dioderna bin-sorterade (intensitet och våglängds sorterade) så inom en bin märker man initialt inte någon större skillnad. Dock har jag märkt att de de blir mer "individuella" med åldern, dvs efter nått år så ser är det synbar skillnad. Angående våglängd så har jag sett synliga skillnader i lågprisdioder. Var en batch där det var blandat två olika gröna våglängder.
Dot correction kommer finnas i 3 eller 9 koefficient variant, dvs det senare är alltså både våglängd och intensitets kompensation.
Här finns en bra artikel på ämnet:
http://www.signindustry.com/led/article ... plays.php3
Den upplevda refresh-raten ligger över 400 Hz vid 16bit.
Dataraten till leddrivare peakar vid 25Mbit/s.
Andra features:
* Extra databuffer för att overlaya text/grafik/bilder ovanpå video (med alpha kanal)
* Vid sidan om RGB kommer den även kunna ta emot exv YCbCr (4:2:2)
* Intern omvandling mellan fysisk och logisk pixel position ligger i tabell (cadvänlig)
Angående adressen så sätts den initialt via en daisy chain signal i kabeln.
Angående dot correction så kommer ju ofta dioderna bin-sorterade (intensitet och våglängds sorterade) så inom en bin märker man initialt inte någon större skillnad. Dock har jag märkt att de de blir mer "individuella" med åldern, dvs efter nått år så ser är det synbar skillnad. Angående våglängd så har jag sett synliga skillnader i lågprisdioder. Var en batch där det var blandat två olika gröna våglängder.
Dot correction kommer finnas i 3 eller 9 koefficient variant, dvs det senare är alltså både våglängd och intensitets kompensation.
Här finns en bra artikel på ämnet:
http://www.signindustry.com/led/article ... plays.php3
Den upplevda refresh-raten ligger över 400 Hz vid 16bit.
Dataraten till leddrivare peakar vid 25Mbit/s.
Andra features:
* Extra databuffer för att overlaya text/grafik/bilder ovanpå video (med alpha kanal)
* Vid sidan om RGB kommer den även kunna ta emot exv YCbCr (4:2:2)
* Intern omvandling mellan fysisk och logisk pixel position ligger i tabell (cadvänlig)
Låter som en imponerande krets det här. Bygger du dessa i FPGA eller ska det tillverkas ASIC av dessa ?
Kör du nån form av subframes i PWM generingen för att få upp frekvensen för jag antar att du använder 16 kanals drivers ?
Har du nån bra lösning på att mäta upp lysdioder ? Har själv kollat lite på en färgsensor som heter TCS230 från TAOS. Kommer ta lite tid att läsa av alla pixlar med denna eftersom det bara går att läsa en pixel i taget. Nån form av kamera hade varit bra men frågan är hur bra resultat det ger.
Kör du nån form av subframes i PWM generingen för att få upp frekvensen för jag antar att du använder 16 kanals drivers ?
Har du nån bra lösning på att mäta upp lysdioder ? Har själv kollat lite på en färgsensor som heter TCS230 från TAOS. Kommer ta lite tid att läsa av alla pixlar med denna eftersom det bara går att läsa en pixel i taget. Nån form av kamera hade varit bra men frågan är hur bra resultat det ger.
Maze: Här är svar på några av frågorna. (På grund av NDA:er så kan jag för närvarande inte svara på alla frågor 
)
Angående led drivare: Ja, man använder standard 16bit seriella (konstantsröms) drivare av enklaste modellen (Exv från ST, Texas, Macroblock)
Kretsen kommer i TQFP64 kapsel och körs på 3.3V och kommer i flera "smaker" under Q1 nästa år. Bland annat så finns det stöd för multiplexing, så kör man exv två led:ar på samma utgång så halverar man antalet led drivare. Dock så tappar man intensitet, men för innomhusbruk så är det rätt vanligt.
Angående mätning av RGB leds så har jag för 3 koef kompensation använt en TSL235 (ljus till frekv sensor) som jag satt in i en rörstump tillsammans med ett ljusfilter (led:arna med sin kraftiga intensitet överstyr annars sensorn). Sedan mätte jag upp R, G och B intensitet var för sig på en referens led i panelen som har bra vitbalans. Sedan jämförs varje leds R,G och B med referensen. Den svagaste led:en på panelen sätter sedan den nya maxnivån. När man senare stackar paneler så blir det den svagaste panelen som sätter nivån i en komplett display. Så pga dot correction och vitbalans förlorar man i slutänden en del av den teoretiska max intensiteten. Just i denna test så var spridningen inom samma bin och ledtyp ca +-10%.
För att hårdtesta dot correction delen så satte jag på testpanelen fler olika RGB leds (olika fabrikat) med olika intensiteter. Vissa var upp till 100% starkare än andra. Efter korrigeringen så såg displayen helt jämn ut...
Dock så hade vissa RGB leds de tre interna chippen lite tätare än andra, så de pixlarna såg lite mindre ut på nära håll.
Ok. Efter att ha flyttat TLS235 sensorn för hand över 256 led:ar så hade jag fått nog... Planerar i stället att göra ett x/y-bord för att automatiskt kunna kalibrera paneler.
Det finns ju led drivare med inbyggd dot correction också. Dock så kompenserar de genom att ändra strömmen vilket kan ge ett nytt problem; våglängden ändras.
Jag har inte provat 9 koef kalibrering ännu. I det läget så måste ju en RGB sensor användas. Finns färdiga produkter för att göra 9 koef kalibrering med (special) kamera och mjukvara. Se: http://www.radiantimaging.com/prapledc.htm
)Angående led drivare: Ja, man använder standard 16bit seriella (konstantsröms) drivare av enklaste modellen (Exv från ST, Texas, Macroblock)
Kretsen kommer i TQFP64 kapsel och körs på 3.3V och kommer i flera "smaker" under Q1 nästa år. Bland annat så finns det stöd för multiplexing, så kör man exv två led:ar på samma utgång så halverar man antalet led drivare. Dock så tappar man intensitet, men för innomhusbruk så är det rätt vanligt.
Angående mätning av RGB leds så har jag för 3 koef kompensation använt en TSL235 (ljus till frekv sensor) som jag satt in i en rörstump tillsammans med ett ljusfilter (led:arna med sin kraftiga intensitet överstyr annars sensorn). Sedan mätte jag upp R, G och B intensitet var för sig på en referens led i panelen som har bra vitbalans. Sedan jämförs varje leds R,G och B med referensen. Den svagaste led:en på panelen sätter sedan den nya maxnivån. När man senare stackar paneler så blir det den svagaste panelen som sätter nivån i en komplett display. Så pga dot correction och vitbalans förlorar man i slutänden en del av den teoretiska max intensiteten. Just i denna test så var spridningen inom samma bin och ledtyp ca +-10%.
För att hårdtesta dot correction delen så satte jag på testpanelen fler olika RGB leds (olika fabrikat) med olika intensiteter. Vissa var upp till 100% starkare än andra. Efter korrigeringen så såg displayen helt jämn ut...
Dock så hade vissa RGB leds de tre interna chippen lite tätare än andra, så de pixlarna såg lite mindre ut på nära håll.
Ok. Efter att ha flyttat TLS235 sensorn för hand över 256 led:ar så hade jag fått nog... Planerar i stället att göra ett x/y-bord för att automatiskt kunna kalibrera paneler.
Det finns ju led drivare med inbyggd dot correction också. Dock så kompenserar de genom att ändra strömmen vilket kan ge ett nytt problem; våglängden ändras.
Jag har inte provat 9 koef kalibrering ännu. I det läget så måste ju en RGB sensor användas. Finns färdiga produkter för att göra 9 koef kalibrering med (special) kamera och mjukvara. Se: http://www.radiantimaging.com/prapledc.htm
En full frame (48bit färg) ritas upp i 120Hz och och den upplevda refreshraten är ca 4 ggr så hög. Det går att köra 54 bit i 80Hz men då börjar led drivarnas olinjäritet (ojämn stig och falltid på utgångarna) att påverka kvaliteten så då är det inte mycket vits med extra bitar.
Du kan alltså mata in pixeldata i 120 frames per sekund och i 24 bit RGB888 så blir det 256x3x120+lite overhead = ca 90Kbyte/s eller x8 = 720kbit/s per RGB controller (16x16 pixels). Men normalt så kör man ju mycket lägre framerate i inkommande data.
Du kan alltså mata in pixeldata i 120 frames per sekund och i 24 bit RGB888 så blir det 256x3x120+lite overhead = ca 90Kbyte/s eller x8 = 720kbit/s per RGB controller (16x16 pixels). Men normalt så kör man ju mycket lägre framerate i inkommande data.
Så det görs med andra ord 120 stycken PWM cykler med 65536 steg per sekund ? Undrar bara hur du får in allt detta i vanliga seriella leddrivers. Om inga drivers är kasadkopplade och data skickas i 25 Mbit/s och alla 16 kanaler används så latchas väl inte datan snabbare än 1,6 MHz ? Jag skulle vilja latcha datan i ca 8 MHz för att få ihop det. Om jag har fattat det rätt så måste man hinnna med minst en komplett PWM cykel under en frame för att det ska fungera.
All lysdiodsmodulering handlar ju om att lura ögat. Att hitta nya sätt att göra det på har ju varit en spännande utmaning. Generation 1 av kretsen (som har färre lysdioder och färre färger) sitter redan i tusentalet RGB-moduler idag. Gen1 är dock inte så lämpad för video utan används i informations/reklam sammanhang. Men det är först med Generation 2 som vi når broadcastkvalitet i hög framerate.
