LED dot-matrix scherm aansturen

[_ferry_]

Een kennis van mij kwam met wat leuks aanzetten, een groot LED dot-matrix scherm.
Vol met leuke hardware, 8x 7,5v 20A voedingen, 2 controllerbordjes en een heel stel LED modules:


(het bord is dubbelzijdig)

Dit is het controllerbord voor de ene helft:

Er zit op:
- I2C met GND, +5v en 2 com. pinnen, waarop een trage klok en een korte puls staan
- RS232 via max232, verstuurde geen data.
- RS422, werd gebruikt ter aansturing, geen zichtbaar signaal.
- RS485/TTL/Optical, waarbij de optical gebruikt wordt voor de aansturing van de panelen, en de RS485/TTL daarbij hetzelfde zichtbare signaal krijgt volgens de scoop.
- Ook nog een andere aansluiting, maar daarop kreeg ik geen signalen te zien.


Achterzijde van een LED module. Deze hebben elk een optical in en out, wat pinnen zonder connectie en aanduiding.

Wat ik al ontdekt heb is dat de modules geen ID hebben, ze werken als 1 groot schuifregister, want als ik module 1 en 2 omwissel, verplaatst ook de tekst. Het scherm start namelijk op met een bewegend streepjespatroon, en daarna de melding "NO RC" (no remote controller)

Op zich is het nog wat vroeg om jullie hulp al in te roepen alsof ik er niet uit kom, ik heb pas een klein avondje besteed om wat onderdelen te bestuderen, te demonteren en even te meten op de poortjes. Maar wellicht hebben jullie wat tips over het aansturen ervan, er zijn tenslotte eerder zulke projecten geweest

Ik zou bijv. nog niet echt weten wat voor data ze over de bus zouden gooien om elke led apart aan te sturen. En hoe ik dit min of meer kan achterhalen of herleiden. De output op een compoort van de PC aansluiten en kijken wat er voor data uit komt OID? Zit je nog wel met de baudrate die correct moet zijn.

Daarna kan ik bepalen hoe ik het wil aansturen, dit bordje aansturen via I2C met arduino of rs232 met de PC, of op de Arduino een ledje aansluiten waarmee ik direct het optische signaal kan sturen. Al heb ik nog geen doel ermee voor ogen, zie het meer als leerproject

[timberleek]

die trage klok en korte puls zal waarschijnlijk zijn om aangesloten controllers te detecteren. mogelijk verzend hij constant een startconditie of general call tot hij een ack krijgt.

schuifregisters zie je overigens heel vaak in dit soort borden.

dan zou het zomaar kunnen zijn dat er een communicatiesysteem naar het eerste led paneel loopt en dan zitten ze achter elkaar aangesloten.

bij elk paneeltje zit dan waarschijnlijk een klein printje met drivers en de dataregisters

[_ferry_]

Ja, het werkt als 1 groot schuifregister, zag ook dat de bordjes qua plek op het frame genummerd waren, en dus op volgorde aangesloten zitten.
Zend nu even wat data, maar op 115200 baud met de arduino is het signaal alsnog een stuk trager dan wat het bordje verstuurd. Dus direct met arduino serieel aansturen gaat denk ik niet werken.
Er zit een 18.432 mhz kristal op, en als ik meet met mijn scoopje zijn de pulsjes 1 a 2uS breed (kan max. 1uS selecteren, dus nauwkeurigheid is dan niet zo best meer, maar zal wel in die buurt zitten van 0,5 of 1mhz bandbreedte)

Dus moet denk kijken naar de seriele poort op het printje zelf, wat ik daarmee kan uithalen.

[Sprite_tm]

Zou je niet eerst eens kijken naar de grote vierkante chip op de led-PCBs? Mijn gok is namelijk dat dat een 8051-achtige is, en als je de in/uitgang van de optische dingen naar de pinnetjes van dat beest weet te traceren, kan je waarschijnlijk ook wel achterhalen wat voor type protocol je verwacht. Ik vermoed namelijk dat 't gewoon asynchroon serieel is, maar op hoge snelheid: iets van 1MBps oid. Dat kan je Arduino trouwens ook wel aan, dus als je dat weet zou je die kunnen gebruiken om te zien welke bytes er precies verstuurd worden.

[_ferry_]

Die grote is een MACH211, programmable logic controller. En bevind zich ook nog op de hoofdprint. Daar zit ie samen met een z180.
Wat ik tot nu toe gedaan heb: data pin op ingang van arduino, 0 of 1 uitlezen, en uitgang met een LED+fiber optic lijntje diezelfde waarde geven. Dacht, als hij dan snel genoeg is werkt t.
In grote lijnen was het signaal hetzelfde, maar met de scoop er aan was de resolutie veel lager. Geen beeld dus.

Ook nog een loopje gemaakt die de uitgang telkens hoog en laag maakt, 2 regels dus. Maar daarmee kreeg ik een 100khz signaal uit de arduino.
Ik zag zo 1,2,3 niet hoe ik een byte of meerdere bytes serieel er uit kon gooien zonder gebruik te maken van de seriele poort die tot 115200baud gaat. Of met de code welke voor shiftregisters is gemaakt, want die is denk ook trager, athans, als ik daarmee continu een 10101010-byte verstuurde zag ik er veel tijd tussen zitten.

[Sprite_tm]

Lekker antieke PLD. Uit de datasheet: 'Platform support extends across PCs ... under advanced operating systems such as Windows 3.1, ...'

Probleem is wel dat het protocol wat de logica in de PLD snapt van alles en nog wat kan wezen, dat zul je dus eerst daadwerkelijk moeten decoderen. Als je geen (digitale) scoop hebt die snel genoeg is is dat misschien lastig. Misschien kan je echter de frequentie van het geheel wat omlaag brengen: programmeer je Arduino om een signaal van 100KHz oid te genereren en zet die via een condo'tje van een nF of wat het juiste pinnetje van het kristal op de hoofdprint en je signaal zou ineens een stuk trager moeten wezen. Doe dat ook bij de ledprinten en je hebt ineens je communicatie weer lopen, maar nu een factor 200 trager, wat een stuk makkelijker te meten zou moeten wezen Misschien kan je het zelfs wel onder de 22KHz krijgen, dan kan je netjes je stroom data via je geluidskaart opnemen en posten, kunnen we allemaal aan het analyseren gaan

Ow, en de serieele poort van de AVR die op je Arduino zit haalt makkelijk de MBit/seconde. Hoe je de Arduino-omgeving vertelt dat ie dat moet doen kan ik je niet vertellen tho'.

[ Voor 17% gewijzigd door Sprite_tm op 02-09-2011 19:42 ]

[_ferry_]

Sprite_tm schreef op vrijdag 02 september 2011 @ 19:35:

Ow, en de serieele poort van de AVR die op je Arduino zit haalt makkelijk de MBit/seconde. Hoe je de Arduino-omgeving vertelt dat ie dat moet doen kan ik je niet vertellen tho'.

dat is makkelijker dan ik dacht gewoon Serial.begin(1000000); Al zei de Reference dat het tot maximaal 115200 gaat.

serial print 10101010 via arduino:


En stukje van de data vanaf het bordje:

Zo te zien is dat dus geen 1Mb/s, want de pieken staan wat verschoven ten opzichte van de hokjes. Maar om dat echt goed te kunnen bepalen moet ik inderdaad een betere scoop hebben... Dit is nogal gokken en vol met afronding.
Hmmm, misschien toch maar eens kijken naar een upgrade, want die analoge op t werk gaat ook niet veel voordeel opleveren.

Zal ergens van het weekend IIG eens het printje doormeten of ik schematisch het EEA an herleiden.

[ Voor 4% gewijzigd door _ferry_ op 02-09-2011 21:15 ]

[Stoney3K]

Die displays zien er trouwens uit alsof ze wel eens van het busstation van Spijkenisse Centrum zijn 'veiliggesteld'?

[_ferry_]

Oh dat zou kunnen Vooral als ik even een plaatje opgoogle:

Er kwamen nieuwe OID, maar dat scheen nogal wat voeten in de aarde te hebben. Zag dat deze uit 2000 kwamen.

Overigens een Logic Analyzer besteld. In de hoop dat ik dan het signaal duidelijk krijg en het kan nabootsen en versturen met de arduino.

[LauPro]

Volgens mij kan je het beste het schermen met RS422 aansturen. Gooi eens wat data erop met wat control karakters. Ik denk dat het dan gewoon op het schermpje komt. Zoals je zegt is het 1 groot schuifregister. Dus het enige dat die elektronica doet is data relayen in misschien het systeem monitoren om zo fouten te kunnen melden.

Trek die modules eens los bijvoorbeeld (optisch) en kijk wat er op de die RS422 komt te staan. En vooral ook als het scherm 'boot'.

[_ferry_]

Vandaag de Logic analyzer binnen, dacht eerst dat ik gek werd, en geen match kon vinden, tot ik na 3 uur spelen met bitrates, het apparaatje/software proberen, zoomen en opnieuw inlezen dit zag:

2 Pulsjes die breder zijn, met precies daartussen 7 leds.
En da's geen toeval, want deze opname is gemaakt met de scanning lines zoals je op 1 van de foto's ziet. Daarbij zitten dus 16 leds boven elkaar, waarbij er telkens 2 aan zijn, met daartussen 7 leds die niet aan staan.
Ingestelde bitrate is 369235 wat ik heb berekend door de periode van 2,7083uS. De seriele readout snapt de werking niet geheel, maar als de pulsbreedte 50% bedraagd, dan is het een 1(rood kruisje), anders een 0.

Hier nog wat uitgezoomd:

Met een stukje van de I2C erbij.
Ook zie je dat tussen de volgende 2 bitjes zo'n 40 pulsjes zitten, hoe dat precies zit weet ik niet, but we'll find out Misschien gaan ze uit van schermen die 32 pixels hoog zijn IPV 16 ofzo.

Wat verder uitgezoomd zie je deze blokken:

Waarbij er in 1 blok 16x 2 van deze bitjes langskomen.

Ojah, op de rs232/485/422 meet ik helemaal _niets_ richting de chippies die voor de omzetting zorgen. Geen initialisatie daarvandaan. Wel op de pinnetjes van I2c, daarin komt wat langs, maar moet mij nog even in I2c verdiepen wat het inhoud en of ik er wat mee kan

Ook moet ik nog bedenken hoe ik het signaal na kan maken, een 0 is 16,6% breed, een 1 is meer dan 50% duty breed. Dus de bitrate zal bijv. 4x hoger moeten, waarbij 1000 een 0 is, en 1110 een 1. Als dat wil werken

[ Voor 5% gewijzigd door _ferry_ op 08-09-2011 22:20 ]

[LauPro]

Maar heb je al wat data over die RS422 poort gestuurd? Bijvoorbeeld een tekst (met aantal karakters als er 'led-karakters' zijn) en een return. Ik denk dat je dan gewoon die data op het beeld krijgt. Waarschijnlijk is die verbinding monodirectioneel.

[_ferry_]

Ja dat heb ik als eerste gedaan toen ik hem aansloot. Via rs422 en 232. Op m'n toetsenbord zitten hengsten, maar daar reageerde ie niet op. Dus er zullen wel de juiste commando's naartoe moeten, maar ik weet niet wat ze doorgaans daarvoor gebruiken? Misschien wil ie wel iets ontvangen als "1:bla bla bla 2: bla bla bla3:bla bla bla 4: bla bla bla. Waarbij het nummertje voor de regel of segment staat.

[Stoney3K]

LauPro schreef op vrijdag 09 september 2011 @ 01:31:
Maar heb je al wat data over die RS422 poort gestuurd? Bijvoorbeeld een tekst (met aantal karakters als er 'led-karakters' zijn) en een return. Ik denk dat je dan gewoon die data op het beeld krijgt. Waarschijnlijk is die verbinding monodirectioneel.

Ik heb zelf ook de ervaring dat blind karakters naar een seriële poort proberen te sturen over het algemeen niet werkt. Je weet immers ook niet wat het apparaat aan baudrate, databits, stopbits en pariteit verwacht, om nog maar niet te beginnen over een bovenliggend protocol wat nog eens andere dingen kan voorschrijven. (zoals _ferry_ al zei, delimiters voor verschillende data-velden, control karakters enz.)

Soms heb je geluk met plain ASCII over 9600/8/N/1 maar dat is over het algemeen erg schaars. Het levert een hoop meer op om het low-level protocol gewoon uit elkaar te frutselen en het display (bv. via een AVR) op pixel-niveau aan te sturen, want dan kun je ook je eigen protocol erin coden en zelfs gewoon graphics weergeven.

[Sprite_tm]

Lijkt me ook. Als ik het zo inschat is het echter wel te doen om zelf een controller te maken: je hebt als ik het zo goed zie en bereken 1344 bytes aan data als je elke pixel maar 2 waardes wilt geven (aka: je wilt een zwart-rood beeld en geen grijstinten.) Yer ole gemiddelde atmega328 heeft 2K aan RAM, je kan de pixeldata dus vrolijk daarin duwen. Gebruik bijvboorbeeld de SPI-poort om die vage pulsjes te genereren om de data door te sturen en de UART om nieuwe pixeldata te ontvangen, en je zou er dmv een PC random plaatjes op moeten kunnen diusplayen

[_ferry_]

Ja, nu ik min of meer weet hoe hij zijn data er naartoe stuurt moet het mogelijk zijn om die controller te bouwen. Er zit aan het begin en einde nog wat pulsjes waarin wellicht brightness of bepaalde functies worden aangeroepen (er zat een lichtsensor op de print aangesloten) en het latchen van de schuifregisters. Voor mij is er nog wel een lange weg te gaan hoor SPI, RAM geheugen lezen/schrijven, en de boel op een hoge snelheid aansturen heb ik nog niet eerder gedaan.

Waar ik denk even mee moet beginnen is het vervangen van de kristallen door tragere (8mhz ofzo) zodat ik makkelijk met de serial out op relatief lage snelheid het signaal kan nabootsen zonder op de grenzen van zijn compoort te zitten. Kan ik kijken of het voldoende is om gewoon die bytes ernaartoe te sturen. Zoja, dan kan ik daarmee aan de slag met SPI op de gewone snelheid.

[SeatRider]

Ferry, doet ie al wat meer?

[_ferry_]

Nope, ik heb nog niet echt een ingeving gehad over hoe ik de boel aanstuur.
Met name omdat ik dus óf op hoge frequentie een klokpuls met daarachter een databit moet versturen, óf op lagere snelheid de klokpuls moet moduleren qua breedte.
Had even met SPI gespeeld, maar zag al dat er na het versturen ook nog een bit verstuurd wordt, wat mijn doel enigszins in de war schopt.
Sowieso had ik wat ruzie met het versturen van veel bytes achter elkaar, wist niet hoe ik dat makkelijk kon doen, gebrek aan kennis, en misschien ook wel motivatie, want stel dat ik het werkend krijg weet ik nog niet echt wat ik er aan heb

[SeatRider]

Op je hoedenplank schroeven en berichten voor andere weggebruikers tonen