Hat sich hier schon mal jemand mit LED-Laufschriften bzw. LED-Panels und den Controlern nach dem "Linsn"-Standard (kein Tippfehler) beschäftigt? Ich suche Hilfe oder Material zum IP-Protokoll welches die Software "LED-Studio" benutzt, um Livestreams auf solchen LED-Matrix-Displays darzustellen. Ich muss/will eine LED-Matrix mit einem solchen Controler aus einer eigenen Software heraus ansteuern ... Auf der Herstellerseite habe ich Nichts dazu gefunden. Danke für Tips. Ich weiss, dass die letzte Möglichkeit das Grabben der Pakete und deren Analyse ist, aber wenn nicht nötig, muss man ja nicht unbedingt das Fahhrad neu erfinden.
Gegoogele nach "linsn protocol" liefert u.a. das hier: http://www.eevblog.com/forum/projects/reverse-engineering-a-chinese-led-screen-control-thing-interesting!/ und das hier: https://wiki.techinc.nl/index.php/LINSN_LED_strips
Rufus Τ. Firefly schrieb: > Gegoogele nach "linsn protocol" liefert u.a. das hier: > > http://www.eevblog.com/forum/projects/reverse-engi... Das habe ich nat. schon gesehen ... ist aber nur ein erster Ansatz. Ich werd' mich mal registrieren, um mit dem Autor Kontakt aufnehmen zu können. > und das hier: > > https://wiki.techinc.nl/index.php/LINSN_LED_strips Das ist nicht so ergiebig, da gehts m.e. mehr un die Hardware-Seite ... trotzdem Danke.
Versuch doch mal ob du den Datentransfer mittels Wireshark oder ähnlichem mitschneiden kannst.
So, ich habe jetzt LED-Laufschrift 192x32 Pixel vom Chinesen hier, sie enthält einen Controller vom Typ "Linsn RV908T". Erste Versuche mit der kostenlosen Software LED-Studio 12.x zeigen, dass das Gerät funktioniert. Aber die Software ist der blanke Horror, extrem instabil und unzuverlässig. Hunderttausend Features und kaum etwas funktioniert wie erwartet - gut dass ich darauf nicht angewiesen sein kann, ich muss das selber steuern. Nun bin ich nicht der Profi um Umgang mit Wireshark, aber es ist mir gelungen, einige Pakete mitzuschneiden (siehe Anhang). Was mir auffällt ist z.B., dass anscheinend kein bekanntes IP-Protokoll genutzt wird, sondern RAW-Daten in Ethernet-Frames. Somit finde ich auch keine IP-Adressen, sondern nur Mac ... Kann mir bitte jemand beim Interpretieren der Daten behilflich sein? Ich muss derweil eine Möglichkeit finden, in ein sog. RAW-Socket zu schreiben ... P.S. Im Paket nicht wundern, wegen der Apple-MAC für den Sender, es ist ein iMac, den ich wahlweise mit OSX oder Windows starte.
Wow, das Protokoll sieht ja richtig krank aus. Schert sich einen Sch.... um alle Standards und macht einfach sein eigenes Ding. Nichtmal das mit den MAC-Adressen machen sie offenbar richtig. Kann das überhaupt so über einen Switch funktionieren? Naja, wahrscheinlich wird dieser alle Pakete broadcasten, da er die Ziel-MAC nicht lernen kann (das Ziel verwendet zum Senden eine andere MAC-Adresse?). Es würde die Sache vereinfachen, wenn Du die Pakete für charakteristische Anzeigemuster mitschneidest, also z.B. Alle LEDs gleich hell auf R/G/B nacheinander, dann nochmal mit halber Helligkeit, dann mal nur die LEDs in der ersten Zeile etc. So kann man systematisch schauen wo die Bits vorkommen. Am Anfang scheint der Rechner ein paar Broadcasts zu schicken und wertet die Antworten der LED-Controller aus, vlt. eine Art "inventory".
Ich habe inzwischen ein anders Problem entdeckt und werde die Sache evtl. ganz anders lösen (müssen): So verkackte Ethernet-Frames kann man m.E. nur mit RAW-Sockets senden, und kaum eine Programmierumgebung bietet das in brauchbarer Form an - meine Lieblings-IDE Realbasic bzw. Xojo schon mal nicht (TCP oder UDP wären kein Problem gewesen). Nun ist das ganze restliche Projekt aber schon zu 85% fertig ... knirsch. Ich habe recherchiert, Delphi mkönnte das mit der Synapse-Bibliothek. Evtl. würde ich mir da eine Art Proxy programmieren: Auf der einen Seite per TCP rein und auf der anderen Seite als RAW raus - kann funktionieren, muss aber nicht. Ich glaube aber, ich werde es ganz anders machen: Ich versuche den Controller gegen einen mit RS232 umzutauschen. Das versetzt mich in die Lage, das Problem auf das Protokoll zu reduzieren, die Daten ansich kommen in jedem Falle an. Dann setze ich einen Arduino mit Ethernetshield als Empfänger vor, per UDP rein und über die Serielle hinten wieder raus. Das geht bis 230.000 bist/s, habe ich schonmal bei einer anderen Sache gemacht. Und für 192x32 Pixel ist das gerade schnell genug, ich brauch' kein schnelles Video, nur etwas animierten Text ...
Nachtrag: Ich habe mir die Daten selber nochmal per Wireshark genauer angesehen. Die Pakete enthalten also: - Zieladresse - Quelladresse - Inhalts- bzw. Protokolltyp - Daten und sonst nix? Wird die Prüfsumme nicht dargestellt oder ist keine drin?
Frank Esselbach schrieb: > So verkackte Ethernet-Frames kann man m.E. nur mit RAW-Sockets senden, > und kaum eine Programmierumgebung bietet das in brauchbarer Form an Du hast Doch einen Mac. Dann hast Du auch die Standard-Umgebung für diese Plattform, und die heißt nun mal Xcode. Im Netz finden sich hunderte Beispiele für Berkeley Sockets und RAW Socket Programmierung. Ein kleiner Daemon, den Du über einen Unix Domain Socket von Deiner Oberfläche ansteuerst, sollte kein Problem sein. C solltest Du können. fchk
Forumler schrieb: > Kann das überhaupt so über einen Switch funktionieren? Was für ein Switch? Hier mal der "Verdratungsplan": http://www.szlamp.net/L_szlamp/attached/image/20120401/20120401094354925492.png Siehe auch Beitrag "Re: RGB LED Controller mit SD-Card - Erfahrungen?" Frank Esselbach schrieb: > Dann setze ich einen Arduino mit Ethernetshield als Empfänger vor, per > UDP rein und über die Serielle hinten wieder raus. Und wie kommt das Signal vom UART zur "RV908 Receiving card"? Oder hast Du 'ne Alternative zur SD802 oder zur RV908? Ich überlege ja, eine Variante der RV908/SD802 mit LVDS und Stern-Topologie zu entwickeln. Aber der Preis der fertigen RV908 ist ja schon fast unschlagbar billig. Frank Esselbach schrieb: > Aber die Software ist der blanke Horror Abhängigkeit von dieser SW ist für mich der einzige Grund, nicht die RV908 einzusetzen, sondern über den LVDS-Stern nachzudenken. Also: Wenn das Protokoll geknackt wird, wäre vieles einfacher.
:
Bearbeitet durch User
Torsten C. schrieb: > Also: Wenn das Protokoll geknackt wird, wäre vieles einfacher. Wenn du das Problem mit dem RAW-Socket löst (Windows genügt fürs Erste), knacke ich das Grafik-Protokoll :-)
Frank K. schrieb: > Du hast Doch einen Mac. Dann hast Du auch die Standard-Umgebung für > diese Plattform, und die heißt nun mal Xcode. Die Zielplattform für das aktuelle Projekt ist Windows.
Torsten C. schrieb: >> Dann setze ich einen Arduino mit Ethernetshield als Empfänger vor, per >> UDP rein und über die Serielle hinten wieder raus. > > Und wie kommt das Signal vom UART zur "RV908 Receiving card"? Oder hast > Du 'ne Alternative zur SD802 oder zur RV908? Ich frag' meinen Chinesen, ob er nicht einen Controller mit RS232 hat, soll es geben. Evtl. nicht von Linsn, aber mit dem gleichen Protokoll ...
Einfachste Möglichkeit unter Windows ist vermutlich winpcap nutzen (welches Wireshark zum Capturen nutzt): http://www.winpcap.org/docs/docs_40_2/html/group__wpcap__tut8.html Für etliche Programmiersprachen findet man da Wrapper zu.
Hmmm, bei ein paar Kacheln (ca. 8..16 Stück) kann man m.E. einfach mit 'nem STM32-Modul (vielleicht reichen die 4€-Module mit 20KB RAM) arbeiten, statt eine LINSN RV908 für 35€ zu nehmen. Ich mache das gerade mit 2 Kacheln für die WordClock24h. Ich bin gespannt, was die Controller mit RS232 kosten. > Wenn du das Problem mit dem RAW-Socket löst http://msdn.microsoft.com/de-de/library/windows/desktop/ms740548%28v=vs.85%29.aspx Das hattest Du Dir sicher schon angeschaut. Komme ich damit weiter?
:
Bearbeitet durch User
Eine weitere Möglichkeit scheint ein Arduino mit Ethernet-Shield zu sein. Laut diesem Beispiel kann die Ethernet Lib auch RAW-Sockets: http://forum.arduino.cc/index.php?topic=74547.0 Wenn es möglich ist (bin im Moment unsicher), zwei Sockets gleichzeitig zu erstellen, einen "normalen" UDP-Socket und einen RAW-Socket, sollte es evtl. machbar sein, den Arduino quasi als Relais/Repeater einzusetzen. Der kann dann sogar irgendwo im Netz hängen, empfängt per UDP ein Datagramm von 1500 Byte (dafür sollte der Speicher reichen) und schiebt die Daten gleich danach per RAW wieder 'raus - wenn das geht, ist die Kuh quasi vom Eis! :-)
Frank Esselbach schrieb: > Wenn es möglich ist (bin im Moment unsicher), zwei Sockets gleichzeitig > zu erstellen Zur Not nimmt man zwei und verbindet die nochmal. Was mich erstaunt (freut), dass das mit einem Wiznet W5100 geht, und dass man keinen ENC624J600 oder CP2201 braucht. Einen W5100-Schield hätte ich sogar in der Bastelkiste, aber noch kein RV908. Sollte ich mir mal einen bestellen? Falls der Zoll hinschaut, muss ich aber zum Amt fahren. Oder der Absender muss die Rechnung außen anbringen. Hmmm.
Torsten C. schrieb: > Einen W5100-Schield hätte ich sogar in der Bastelkiste, aber noch kein > RV908. Sollte ich mir mal einen bestellen? Falls der Zoll hinschaut, > muss ich aber zum Amt fahren. Oder der Absender muss die Rechnung außen > anbringen. Hmmm. Also ich habe z.Zt. beides und werde morgen bzw. nachher mal probieren. Sobald sich irgend ein Geflimmer auf der Matrix zeigen sollte, ist der Teil quasi gegessen. Danach taste ich mich pixelweise an die Codierung der Grafik. Da wird wohl noch so manche Schwierigkeit dabei auftreten, wenn es darum geht, die Bytes herauszufinden, die im Datenstrom dafür sorgen, in welcher Zeile und Spalte die Pixel erscheinen und auf welchem der 12 HUB75-Ports die Signale rausgehen ...
:
Bearbeitet durch User
So ... erste Versuche mit einem Arduino zeigen, dass es ziemlich einfach ist, diesen als RAW-Packet-Sender zu verwenden. Dazu habe ich erstmal als Ziel-MAC die meines PC eingestzt und ein par Pakete mitgeschnitten. In Wireshark sehe ich im Vergleich zu den gestern gesnifften Paketen, dass deren Aufbau soweit stimmt. Allerdings sind die Nutzdaten zur Zeit noch Nullen ... Nun rufen leider erstmal familiäre Pflichten, danach werde ich die Arduino-Software so umstellen, dass ich den gesamten Paketinhalt (Ziel- u. Quell-MAC, Protokolltyp und Nutzdaten) zunächst per Seriell/USB mit 1152000 Bit/s auf den Arduino übertrage und dieser - nach erreichen der erforderlichen Bytezahl - das Paket versendet. So muss ich nicht ständig neu flashen und damit verlagert sich das Problem allein auf die Softwareebene. Später kommt die Umstellung des Empfanges von seriell auf UDP. Sollte das funktionieren, kann man "Linsn" mit einer eigenen "SenderCard" ziemlich cool ins Handwerk pfuschen :-) P.S. Ich brauche mal noch einen Tip: Wie kann ich aufgezeichnete Pakete aus Wireshark rein_binär speichern, so dass ich sie zum Senden in eigener Software selber öffnen und einlesen kann - habe bisher keine spezielle Option gefunden? ... oder ist das die Datei, wie ich sie hier hochgeladen habe? (beim Aufzeichnen Filter setzen, ich weiss ...) Zusatzfrage: Wie erkenne ich in diesen Daten, wann das nächste Paket beginnt? Einfach nur die Bytes mitzählen?
:
Bearbeitet durch User
SO, das ist mein vorläufiger Arduino-Sketch zum Senden von RAW-Packets. Über die Serielle bzw. USB werden 1500 Bytes erwartet, wenn die erreicht sind, werden sie per Ethernet gesendet und der Empfang wartet auf die nächsten 1500 Bytes. Die ersten 6 Bytes sind die Quell-Mac, die nächsten 6 Bytes die Ziel-Mac und dann zwei Bytes der Protokolltyp (bei der Software LED-Studio ist das 0xaa55), dann folgen die 1486 Datenbytes. Wenn das Programm gerade Nichts auf der Seriellen liest, gibt es den Zählerstand zurück, ist vlt. für Debugging-Zwecke gut. Wenn gesendet wurde, kommt eine laufende Paketnummer mit enem führenden Punkt zurück ... Diese Stellen sollte jeder im Code finden und ggf. auskommentieren.
1 | #include <SPI.h> |
2 | #include <Ethernet.h> |
3 | #include <utility/w5100.h> |
4 | |
5 | SOCKET s; // our socket that will be opened in RAW mode |
6 | byte buf[1500]; // buffer to send through socket |
7 | int cnt=0; |
8 | int pak=0; |
9 | |
10 | void setup() |
11 | {
|
12 | // initialize the w5100 chip and open a RAW socket |
13 | W5100.init(); |
14 | W5100.writeSnMR(s, SnMR::MACRAW); |
15 | W5100.execCmdSn(s, Sock_OPEN); |
16 | Serial.begin(115200); |
17 | delay(100); |
18 | } |
19 | |
20 | void loop() |
21 | {
|
22 | if (cnt<1500) |
23 | {
|
24 | if (Serial.available()>0) |
25 | {
|
26 | buf[cnt]=Serial.read(); |
27 | cnt++; |
28 | } |
29 | else |
30 | {
|
31 | Serial.println(cnt); |
32 | delay(100); |
33 | } |
34 | |
35 | } |
36 | else |
37 | {
|
38 | cnt=0; |
39 | pak++; |
40 | Serial.println("."+pak);
|
41 | W5100.send_data_processing(s, buf, 1500); |
42 | W5100.execCmdSn(s, Sock_SEND_MAC); |
43 | } |
44 | } |
> "Linsn" mit einer eigenen "SenderCard" Welche Datenrate schafft deine SenderCard? In dem Wiki-Artikel steht etwas von 50fps Video auf den Linsn LEDs, kommt der Aduino da noch hinterher? Ich finde deinen Proxy Ansatz gut, mit der Synpase Bibliothek müsste das gut machbar sein.
Besucher schrieb: > Welche Datenrate schafft deine SenderCard? In dem Wiki-Artikel steht > etwas von 50fps Video auf den Linsn LEDs, kommt der Aduino da noch > hinterher? Das ganz sicher nicht. Mir würden 10..12 fps genügen. Aber zunächst geht es darum, die Voraussetzungen zu schaffen, um das Protokoll zu knacken. Die Hardware kann man sicher später auch gegen andere austauschen, z.B. einen RasPi ...
Sehr interessanter Thread. Ich beschäftige mich schon länger mit chinesischen LED Controllern, wir haben früher seber welche entwickelt und Linsn dürfte da einiges kopiert haben. Wenn du nur eine kleine LED Matrix ansteuern wilst, hätte ich auch ein Proof of concept mit einem STM32 (bis zu 4x4 HUB75 RGB Module, jeder Pixel mit 24Bit): http://esdblog.org/update-how-to-drive-8192-rgb-leds-each-24bit-rgb-brightness-with-one-stm32-microcontroller-without-much-cpu-load/ Ich kann Scroll-Text und einige andere Spielerein schon anzeigen, oder den Bildschirm capturen und per USB an den STM32 senden. In der Tat kann man zwischen den Linsn Sender (DVI Eingang) und den Empfänger(n) keinen Switch verwenden (zumindest keinen Store and Forward). Ich gehe mal davon aus, es liegt an den "zermatschten" Ethernet chinesen Protokoll, welches eigt. gar kein Ethernet auf MAC Ebene ist. Es scheint als verwenden die zwar Ethernet als physikalisches Übertragungsmedium (also den PHY auf den Receivern), aber fahren da ihr eignes Datenübertragungsprotokoll.
Frank Esselbach schrieb: > So, ich habe jetzt LED-Laufschrift 192x32 Pixel vom Chinesen hier, sie > enthält einen Controller vom Typ "Linsn RV908T". Erste Versuche mit der > kostenlosen Software LED-Studio 12.x zeigen, dass das Gerät > funktioniert. > > Aber die Software ist der blanke Horror, extrem instabil und > unzuverlässig. Hunderttausend Features und kaum etwas funktioniert wie > erwartet - gut dass ich darauf nicht angewiesen sein kann, ich muss das > selber steuern. Dem kann ich nur zustimmen. Warum verwendest du nicht einfach nur die Funktion zum Senden des Bildschirminhalts und zeigst deinen Text/Grafik an der entsprechenden Bildschirmposition an? Natürlich wäre es ein Vorteil das Protokoll zu "knacken" und selbst implementieren zu können. Interessanterweise gibt es andere Hersteller (für synchrone LED Ansteuerungssysteme-ähnlich Linsn), welche sogar DLLs für Eigenentwicklungen anbieten.
> In der Tat kann man zwischen den Linsn Sender (DVI Eingang) und den > Empfänger(n) keinen Switch verwenden (zumindest keinen Store and > Forward). Ich gehe mal davon aus, es liegt an den "zermatschten" > Ethernet chinesen Protokoll, welches eigt. gar kein Ethernet auf MAC > Ebene ist. Es scheint als verwenden die zwar Ethernet als physikalisches > Übertragungsmedium (also den PHY auf den Receivern), aber fahren da ihr > eignes Datenübertragungsprotokoll. Also in meinem Büro habe ich die Anzeige an einem TP-Link 24-Port Gigabit-Switch, das geht. Allerdings haben meine Versuche mit dem Arduino leider nicht das erhoffte Ergebnis: - Ich habe die Kommunkation zwischen LED-Studio und der Anzeige mit Wireshark mitgeschitten, dabei funktioniert die Anzeige. - Ich habe die mitgeschittenen Daten mittels eigener Software und dem Arduino zur Anzeige gesendet - keine Reaktion Dabei habe ich auch diese Übertragung mitgeschitten und ich sehe keinen Unterschied, trotzdem tote Hose. Nicht mal irgend ein Flimmern oder marodierende Pixel, einfach garnix. :-( Den einzigen Unterschied, den ich zur Zeit sehe, ist die Geschwindigkeit, mit der die Pakete zugespielt werden, weil ich das derzeit per USB tue.
:
Bearbeitet durch User
Frank Esselbach schrieb: > Also in meinem Büro habe ich die Anzeige an einem TP-Link 24-Port > Gigabit-Switch, das geht. Ja es funktioniert auch mit einem Gigabit-Switch (100Mbit gehen bei mir nicht). Aber ich meinte oben zwischen Senderkarte (also die SD801D zb., welche DVI als Eingang hat) und Empfängerkarte funktioniert es nicht mit einem Switch.
nosilent schrieb: > Ja es funktioniert auch mit einem Gigabit-Switch (100Mbit gehen bei mir > nicht). Aber ich meinte oben zwischen Senderkarte (also die SD801D zb., > welche DVI als Eingang hat) und Empfängerkarte funktioniert es nicht mit > einem Switch. Ich habe keine spezielle Senderkarte, sondern versuche herauszufinden und nachzumachen, was die Software "LED-Studio" versendet ...
nosilent schrieb: > Warum verwendest du nicht einfach nur die Funktion zum Senden des > Bildschirminhalts und zeigst deinen Text/Grafik an der entsprechenden > Bildschirmposition an? Es ist ein Infosystem in einer Autowaschanlage, basierend auf einem Hutschienen-PC. Der Monitor ist 40 Zoll groß und bereits damit beschäftigt, im Eingangsbereich Werbung und das gewählte Waschprogramm nebst Optionen anzuzeigen. Die LED-Anzeige soll bei der Ausfahrt nochmal anzeigen, was der Kunde fürs Geld erhalten hat und eine gute Fahrt wünschen. Diese Daten sollen nicht von einem Bildschirm gegrabbt werden, sondern einfach "intern" erzeugt und per Netzwerk zum LED-Kasten fliessen ... Wenn der Kunde am Ausgang ankommt, sind bereits 2 oder 3 neue Fahrzeuge hinter ihm.
@nosilent + Frank: Ich blicke bei Euch Beiden gerade nicht durch. Es gibt m.E. genau zwei Strategien: ❶ billige RV908 nutzen und per Ethernet Linsn-proprietär senden ❷ andere (evt. eigene oder RS232) Receiver nehmen Für ❶ muss das Protokoll geknackt werden und für ❷ brauchen wir ein neues Projekt. Für ❷: Ich bastel gerade an einer Lösung mit einem LVDS-Stern statt RS232. Oder gibt es noch eine ❸?
:
Bearbeitet durch User
Torsten C. schrieb: > Oder gibt es noch eine ❸? Ja, die Linsn Empfängerkarten sind ja so schön billig und die Hardware schaut gut aus. Für den FPGA einen eigenen IP-Core schreiben ist sicherlich möglich, der dann auch "ordentliches" Ethernet beherrscht. Ich muss gestehen, die oben genannte Methode verwenden wir (in dem Unternehmen wo ich arbeite) bei einem unserer LED Ansteuerungssysteme, nur mit einer etwas anderen Hardware (aber das Grundkonzept ist gleich).
nosilent schrieb: > Für den FPGA einen eigenen IP-Core schreiben ist > sicherlich möglich Hast Du denn eine Idee davon, was der "L202-Controller" vielleicht macht?
:
Bearbeitet durch User
nosilent schrieb: > Interessanterweise gibt es andere Hersteller (für synchrone LED > Ansteuerungssysteme-ähnlich Linsn), welche sogar DLLs für > Eigenentwicklungen anbieten. Für RotGrün-Anzeigen gibt es zb. noch den ONBON BX-5M1 (http://www.onbonbx.com/en/cp/html/?58.html). Da gibts auch DLLs damit man den selber ansteuern kann. Torsten C. schrieb: > Hast Du denn eine Idee davon, was der "L202-Controller" vielleicht > macht? Wenn du die Senderkarten (TS80x, SD80x) meinst: Die haben ja einen HDMI/DVI zu parallel RGB Daten IC (TI) drauf und senden diese dann an die Empfänger. Ein großes Problem bei diesen synchronen Ansteuerungssystemen ist die Datenübertragung. Und da hat sich Linsn es leicht gemacht und einfach einen Ethernet PHY verwendet. Natürlich haben Sie noch ein eigenes Protokoll, damit Sie mit den Empfängern und den Zusatzkarten (ala Tür ist offen usw.) kommunizieren können.
nosilent schrieb: > Für den FPGA einen eigenen IP-Core schreiben ist > sicherlich möglich Hmmm, ich dachtem das wäre das gleiche wie ❶. nosilent schrieb: > parallel RGB Daten … an die Empfänger. Wenn man `ne eigene SW macht, dachte ich, dass man am besten eigene Sender baut. Macht es Sinn, auch die TS80x/SD80x zu knacken und zu benutzen? > die Software ist der blanke Horror Darum dachte ich an `ne eigene SW.
:
Bearbeitet durch User
Torsten C. schrieb: > Hmmm, ich dachtem das wäre das gleiche wie ❶. Naja bei 1. würde man ja den IP-Core so lassen. Sprich die RGB Daten so senden, wie es die Linsn Software tut. Konfiguration usw. muss man dann noch immer mit der Linsn Studio Software machen (es sei denn man knackt auch die Konfiguration, außerdem hat die Konfiguration einige komische Beschränkungen). Bei 3 würde man ja nur die reine HW verwenden, alles drumherum (die SW) neu. Torsten C. schrieb: > Wenn man `ne eigene SW macht, dachte ich, dass man am besten eigene > Sender baut. Macht es Sinn, auch die TS80x/SD80x zu knacken und zu > benutzen? Das kommt ganz auf das Ziel drauf an. Wenn ich das richtig verstanden habe geht es in dem Thread ja darum, die Teile mit Ethernet von einem PC mit eigener SW anzusteuern. Wenn man aber ein autarkes System haben will (z.B. um von einem DVD-Player Videos auf der Anzeige abzuspielen) ist sicherlich eine eigene Senderkarte von Vorteil. Der Preis der Senderkarten ist ebenso beeindruckend und die HW sieht ebenso vielversprechend aus. Wurde auch von vielen chinesen kopiert (Novastar, ZDEC, ...).
Torsten C. schrieb: > Darum dachte ich an `ne eigene SW. Wenn man eine reine Software Senderkarte haben will ist das sicherlich zielführend. Wenn man gleich den IP-COre der Empfängerkarten neu schreibt, könnte man halt (fast) jede erdenklichen LED Pixelmodule ansteuern und wäre auch bei der Konfiguration nicht an die Linsn LED Stuidio SW gebunden (es sei denn man knackt auch das Protokoll, wobei ich denke das es da einige Limitierungen im Linsn IP-Core gibt).
Bezüglich der eigenen SW Ansteuerung der Linsn Empfänger mit dem propritären Protokoll: Ich habe auch mal die Daten, welche die Linsn LED Studio SW sendet mitgesnifft und mit einem Tool (Colasoft Packet Player) wiedergegeben. Die angeschlossenen LED Module gaben genau den zuvor gesnifften Inhalt wieder, also mal ein kleiner Erfolg.
nosilent schrieb: > Bezüglich der eigenen SW Ansteuerung der Linsn Empfänger mit dem > propritären Protokoll: > Ich habe auch mal die Daten, welche die Linsn LED Studio SW sendet > mitgesnifft und mit einem Tool (Colasoft Packet Player) wiedergegeben. > Die angeschlossenen LED Module gaben genau den zuvor gesnifften Inhalt > wieder, also mal ein kleiner Erfolg. Dann besteht ja noch Hoffnung. Womit hast du gesnifft? Wireshark?
nosilent schrieb: > Wenn man gleich den IP-COre der Empfängerkarten neu schreibt, könnte man > halt (fast) jede erdenklichen LED Pixelmodule ansteuern und wäre auch > bei der Konfiguration nicht an die Linsn LED Stuidio SW gebunden (es sei > denn man knackt auch das Protokoll, wobei ich denke das es da einige > Limitierungen im Linsn IP-Core gibt). z.B. Könnte man dann auch Support für WS2812 und Konsorten einbauen. Ich bin jedenfalls auch interessiert eine eigene SW Lösung für die Linsn HW zu realisieren. Interessant wäre jetzt nur, ob man auch den Core für den FPGA neu entwickelt oder "nur" das Protokoll knackt. Darum wäre interessant, was andere noch so für Wünsche an den LED Controller hätten. Wie oben erwähnt, könnte man bei der vollen SW Eigenentwicklung auch zb. WS2812 und andere LED Pixelmodule unterstützen und das ganze "echt" Ethernet-IP kompatibel machen. Also ich sehe das ganze so: Entweder (1.) das proprietäre Protokoll selber "hinhacken" und nichts an den Empfängerkarten verändern, oder (2.) zuerst einen IP-Core für die Empfänger schreiben, dann eine Ansteuerungssoftware für PC mit Ethernet evt. UDP. Später auch die Senderkarte mit dem eigenen Protokoll ausstatten. Frank Esselbach schrieb: > Dann besteht ja noch Hoffnung. Womit hast du gesnifft? Wireshark? Ja, Daten im Anhang. Wird dir wahrscheinlich nicht viel bringen, da ich sehr wahrscheinlich eine andere LED Pixelkonfiguration habe, aber vielleicht hilft es.
Was ist "*.pcapng"? Interessanz ist m.E. alles, was die billigen LINSN-Clones verwendet, zunächst egal ob RX oder TX. Allerdings sehe ich beim RX die höhere Priorität, da man davon ggf. mehere benötigt. Sender können schon eher aufwendig sein, die braucht man ja immer nur einmal. Ich habe mir gerade alles an HW besorgt, um DVI per FPGA in "irgendwas" zu wandeln. Ein LVDS-Stern war bisher mein Favorit, aber Ethernet ginge sicher auch.
:
Bearbeitet durch User
Frank Esselbach schrieb: > Den einzigen Unterschied, den ich zur Zeit sehe, ist die > Geschwindigkeit, mit der die Pakete zugespielt werden, weil ich das > derzeit per USB tue. Darum wird wahrscheinlich nichts bei dir angezeigt. Die LED Receiver haben ja so eine schöne Funktion, was passieren soll wenn keine Daten daherkommen. Standardmäßig zeigen Sie dann nichts an. Ein weiterer Grund: Man kann bei den Receivern ein Art Anzeige synchron Refresh mit Sender auswählen, d.h. die LED PWM/Clock Frequenz ist bzw. muss ein vielfaches des 50/60Hz Input-RGB Datenstroms vom Sender sein.
Torsten C. schrieb: > Was ist "*.pcapng"? Das neuere pcap/wireshark Datenformat, siehe: http://wiki.wireshark.org/Development/PcapNg Torsten C. schrieb: > Ich habe mir gerade alles an HW besorgt, um DVI per FPGA in "irgendwas" > zu wandeln. Ein LVDS-Stern war bisher mein Favorit, aber Ethernet ginge > sicher auch. Ein guter Ansatz. Aus Erfahrung kann ich sagen, auch bei LVDS kann man mit EMV/EMI Problemen konfrontiert werden. Je nach Einsatzzweck sollte das ja CE usw. haben. Ich möchte an dieser Stelle darauf hinweisen, dass man bei einer EMV-Prüfung nicht die besten Werte mit den chinesischen HUBxx-Systemen (also was Linsn und alle billigen LED Anzeigen Hersteller verwenden) bekommen wird. Es ist eher fraglich ob die überhaupt unsere Grenzwerte einhalten können (auf Grund der Kabellängen in den LED Anzeigen, uvm.) und eigentlich gar nicht CE sind. Wir haben vor einigen Jahren die Systeme von Linsn usw. mal getestet und die haben schlichtweg versagt, was EMV betrifft.
Achja um es der Vollständigkeit halber zu erwähnen: Die Senderkarten senden wirklich nur die RGB Daten vom DVI (also 24bit bzw. 3x10 oder 3x12 Bit in den neueren Versionen). Die Empfängerkarten empfangen die Daten, leiten Sie weiter und steuern die angeschlossenen LED Pixelmatrizen an. D.h. die Empfänger machen auch das Multiplexing, PWM und Gammakorrektur, also die gesamte Datenaufbereitung für die LED Pixelmodule.
Angehängte Dateien:
-
Zwei_Kacheln.jpg
110 KB
nosilent schrieb: > D.h. die Empfänger machen auch … Gammakorrektur Interessant! Das heißt, es gibt 255 echte photometrische Helligkeitsstufen statt 255 linear verteilte PWM-Prozentwerte? Oder sogar 511 oder 1023? Ich habe viel gerechnet: Auf den Modulen/Kacheln sind ja FD9802 drauf, die bis zu 15 MHz Takt können. Wieviel Kacheln mit 32x16 RGB-Pixeln und 1/8 Scan kann man da an einem HUB75-Port kaskadieren? Bei 255 echten photometrischen Helligkeitsstufen (also mit Gammakorrektur) komme ich so auf 16..20 Kacheln. Mehr geht nicht. Aktuell habe ich zum Testen zwei Kacheln an einem STM32F103C8T6. Natürlich geht auch mehr!
:
Bearbeitet durch User
Ich habe jetzt meinen Arduino-Sketch auf UDP-Empfang umgestrickt, aber leider beisst sich da irgendwas - vermutlich kommen sich RAW- und UDP-Socket bei der Initialiserung in die Quere. Könnte bitte mal jemand rüberschauen, woran das liegen kann? RAW- und UDP-Socket funktionieren alleine auch mit dem (für Arduino) großen Puffer. Da ich den für beide gemeinsam benutze, sollte es doch eigentlich gehen, oder? Anhand der LEDs sehe ich, dass immer genau einmal gesendet wird und dann nicht wieder. :-( Empfangen wird immer ...
1 | #include <SPI.h> |
2 | #include <Ethernet.h> |
3 | #include <EthernetUdp.h> |
4 | #include <utility/w5100.h> |
5 | |
6 | #define UDP_TX_PACKET_MAX_SIZE 1486 |
7 | |
8 | byte mac[] = {0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0x01};
|
9 | IPAddress ip(192, 168,200,177); |
10 | EthernetUDP Udp; |
11 | SOCKET rs; // rawsocket |
12 | byte buffer[UDP_TX_PACKET_MAX_SIZE]; // buffer to send through socket |
13 | |
14 | |
15 | void setup() |
16 | {
|
17 | W5100.init(); |
18 | W5100.writeSnMR(rs, SnMR::MACRAW); |
19 | W5100.execCmdSn(rs, Sock_OPEN); |
20 | Ethernet.begin(mac,ip); |
21 | Udp.begin(8888); |
22 | } |
23 | |
24 | void loop() |
25 | {
|
26 | if(Udp.parsePacket()) |
27 | |
28 | {
|
29 | Udp.read(buffer,UDP_TX_PACKET_MAX_SIZE); |
30 | W5100.send_data_processing(rs, buffer,UDP_TX_PACKET_MAX_SIZE); |
31 | W5100.execCmdSn(rs, Sock_SEND_MAC); |
32 | } |
33 | delay(1); |
34 | } |
:
Bearbeitet durch User
nosilent schrieb: > Frank Esselbach schrieb: >> Den einzigen Unterschied, den ich zur Zeit sehe, ist die >> Geschwindigkeit, mit der die Pakete zugespielt werden, weil ich das >> derzeit per USB tue. > > Darum wird wahrscheinlich nichts bei dir angezeigt. Die LED Receiver > haben ja so eine schöne Funktion, was passieren soll wenn keine Daten > daherkommen. Standardmäßig zeigen Sie dann nichts an. Ein weiterer Mein Chinese hat mir ein Lego-Logo da irgendwie reingespeichert, was ich immer sehe, wenn keine verwertbaren Daten ankommen. Ich nehme an, auch das macht man mit LED-Studio. > Grund: Man kann bei den Receivern ein Art Anzeige synchron Refresh mit > Sender auswählen, d.h. die LED PWM/Clock Frequenz ist bzw. muss ein > vielfaches des 50/60Hz Input-RGB Datenstroms vom Sender sein. Also bei mir klappt das mit dem Packet Player auch, also sind meine gesnifften Daten in Ordnung. Ich habe beobachtet, dass erst mehrere Pakete auf den Controller einprasseln müssen, bevor der ein Bild anzeigt. Die Abspielgeschwindigkeit im Packet Player hat dagegen keinen EInfluss, auch die langsamste Möglcihkeit nicht.
Sieht sich hier jemand in der Lage, ein kleines Tool für Windows zu stricken, dass z.B. basierend auf Winpcap Folgendes leistet: - stellt lokal einen offenen UDP-Socket, z.B. auf Port 8888 bereit - sendet den Inhalt jedes eigegangenen Datagramms als RAW-Packet wieder hinaus Das Einlesen einer Datei ist, ausser zu Testzwecken, nicht wirklich hilfreich, weil am Ende ja Livedaten gesendet werden sollen - so eine Datei muss "vorproduziert" werden und kann nicht geändert werden, solange sie offen ist.
:
Bearbeitet durch User
Torsten C. schrieb: > Interessant! Das heißt, es gibt 255 echte photometrische > Helligkeitsstufen statt 255 linear verteilte PWM-Prozentwerte? Oder > sogar 511 oder 1023? Ja, als Standard verwendet Linsn 4096 Helligkeitsstufen, geht aber bis zu 65535. Sogar die Gammakorrektur bzw. die Kurve lässt sich einstellen. Torsten C. schrieb: > Wieviel Kacheln mit 32x16 RGB-Pixeln und 1/8 Scan kann man da an einem > HUB75-Port kaskadieren? Bei 255 echten photometrischen Helligkeitsstufen > (also mit Gammakorrektur) komme ich so auf 16..20 Kacheln. Theoretisches Limit des Linsn FPGA Cores ist 512x512 Pixel. Wobei bei 1/8 Scan das sich auf 256x256 Pixel limitiert. Praktisch gsehen würde ich nicht mehr als 160 Pixel in der Breite verwenden. Das ist dann bei 16Bit echter Farbtiefe 10MHz und du hast eine PWM Frequenz von 840Hz (mit synchronem Refresh der gesamten Anzeige). In der Höhe wären es noch 128 Pixel. Im Anhang ist ein RCG (Receiver file) für P7.62 mit Hub75 und 1/8 Scan, die kannst du im Reiter Receiver in der LED STudio SW reinladen, dann kann man mit den Parametern herumspielen....Aber Achtung: habe schon von defekten LED Pixelmodulen und Receivern gehört, wenn man zum falschen Zeitpunkt den Falschen Button klickt...(das zum Thema Stabilität der SW...) Torsten C. schrieb: > Aktuell habe ich zum Testen zwei Kacheln an einem STM32F103C8T6. > Natürlich geht auch mehr! Da mir die Linsn Software auch anfangs nicht sehr zugesagt hat, habe ich auch mit einem STM32F429I-DISCO HUB75 und HUB08 Module angesteuert. Mit bis zu 11MHz Clock Frequenz, dann noch BAM für das PWM verwendet und DMA usw., ist aber eher eine Spielerei. Bei Linsn wären max. 30MHz Clock möglich. Wobei ich strikt davon abrate. Nicht weil es nicht funktioniert, sondern weil 30MHz Clock auf einer großen Fläche einfach der Wahnsinn sind bezüglich EMI.
Frank Esselbach schrieb: > Mein Chinese hat mir ein Lego-Logo da irgendwie reingespeichert, was ich > immer sehe, wenn keine verwertbaren Daten ankommen. Ich nehme an, auch > das macht man mit LED-Studio. Richtig, in der LED Studio SW unter "Receiver 1" "Free Show" kannst du "no display", oder "random", oder eben ein eigenes Logo reinladen. Dann noch "Send to receiver" und, wenn es funktioniert, "save on receiver" klicken und fertig. Von daher kann das Linsn System einiges.
nosilent schrieb: > Theoretisches Limit des Linsn FPGA Cores ist 512x512 Pixel. Wobei bei > 1/8 Scan das sich auf 256x256 Pixel limitiert. > Praktisch gsehen würde ich nicht mehr als 160 Pixel in der Breite > verwenden. Das ist dann bei 16Bit echter Farbtiefe 10MHz und du hast > eine PWM Frequenz von 840Hz (mit synchronem Refresh der gesamten > Anzeige). In der Höhe wären es noch 128 Pixel. Im Anhang ist ein RCG > (Receiver file) für P7.62 mit Hub75 und 1/8 Scan, die kannst du im > Reiter Receiver in der LED STudio SW reinladen, dann kann man mit den > Parametern herumspielen....Aber Achtung: habe schon von defekten LED > Pixelmodulen und Receivern gehört, wenn man zum falschen Zeitpunkt den > Falschen Button klickt...(das zum Thema Stabilität der SW...) Die 160x128 Pixel beziehen sich aber auf die gesamte Receiver-Karte. also pro Port sind eigentlich immer eine horizontale Reihe gedacht. Also wäre die Antwort auf deine Frage 5 Module pro Port in Serie.
nosilent schrieb: > Richtig, in der LED Studio SW unter "Receiver 1" "Free Show" kannst du > "no display", oder "random", oder eben ein eigenes Logo reinladen. Dann > noch "Send to receiver" und, wenn es funktioniert, "save on receiver" > klicken und fertig. Das ganze geschieht im "Setup hardware parameters": Bei gestarteter Linsn LED Studio SW->"linsn" eingeben (ohne Anführungszeichen), dann Passwort 168, da kann man dann "alle" HW relevanten Parameter konfigurieren.
Frank Esselbach schrieb: > Sieht sich hier jemand in der Lage, ein kleines Tool für Windows zu > stricken, dass z.B. basierend auf Winpcap Folgendes leistet: > > - stellt lokal einen offenen UDP-Socket, z.B. auf Port 8888 bereit > - sendet den Inhalt jedes eigegangenen Datagramms als RAW-Packet wieder > hinaus Das geht relativ einfach, z.B. mit jnetpcap. Im Anhang eine sehr einfache Java-Klasse mit der Bibliothek (siehe http://midgetontoes.com/blog/2013/10/23/send-raw-udp-packets-in-java/). Da man ja mehr Nutzdaten übertragen will, als in ein herkömmliches UDP Paket reinpassen, hab ich TCP verwendet.
nosilent schrieb: > Das geht relativ einfach, z.B. mit jnetpcap. > Im Anhang eine sehr einfache Java-Klasse mit der Bibliothek (siehe > http://midgetontoes.com/blog/2013/10/23/send-raw-udp-packets-in-java/). > Da man ja mehr Nutzdaten übertragen will, als in ein herkömmliches UDP > Paket reinpassen, hab ich TCP verwendet. Oh ... danke, cool. Aber ich muss zu meiner Schande gestehen, dass ich mich nicht mit Java auskenne ... wie bekomme ich das zum Laufen? Könntest du bitte daraus ein .jar machen, was man nur noch anklicken bzw. per "launch" aufrufen muss (und das dann unsichtbar im Hintergrund verschwindet)? Gibts einen Parameter, um das Netzwerkinterface zum Aussenden zu bestimmen? Oder wie verhindere ich, dass meine RAW-Pakte auf das Bluetooth-Interface, den WLAN-Adapter oder den Firewire-Anschluss losgehen? Muss ich da ausser einer aktuellen JRE nochwas zusätzlich installieren, oder ist da alles drin? Hast du das ausprobiert?
:
Bearbeitet durch User
Frank Esselbach schrieb: > Könntest du bitte daraus ein .jar machen, was man nur noch anklicken > bzw. per "launch" aufrufen muss (und das dann unsichtbar im Hintergrund > verschwindet)? Ja, siehe Anhang. Einfach Dateien extrahieren und dann die Tcp2eth.bat in einer cmd am besten ausführen. (Ohne Argumente wird eine Usage ausgegeben). Frank Esselbach schrieb: > Gibts einen Parameter, um das Netzwerkinterface zum Aussenden zu > bestimmen? Oder wie verhindere ich, dass meine RAW-Pakte auf das > Bluetooth-Interface, den WLAN-Adapter oder den Firewire-Anschluss > losgehen? Wenn du keine Parameter bei der Tcp2eth.bat angibst werden dir alle vorhandenen NICs angezeigt, dann das Programm mit der entsprechenden ID starten. Also zb. Tcp2eth.bat 0
Frank Esselbach schrieb: > Muss ich da ausser einer aktuellen JRE nochwas zusätzlich installieren, > oder ist da alles drin? > > Hast du das ausprobiert? Ja, kann natürlich noch einige Bugs beinhalten. Hab ich mal eben schnell geschrieben. Sollte alles dabei sein. Da ich hier mit 64Bit arbeite, sind die jnetpcap auch win64, unter win32 musst du den library ordner austauschen (win32 library: http://sourceforge.net/projects/jnetpcap/files/jnetpcap/1.3/jnetpcap-1.3.0-1.win32.zip/download).
nosilent schrieb: > Ja, kann natürlich noch einige Bugs beinhalten. Hab ich mal eben schnell > geschrieben. Und gleich noch einen Fehler gefunden, aktualisierte "binary" im Anhang.
nosilent schrieb: > die kannst du im Reiter Receiver in der LED STudio SW reinladen Hmmm, soll ich mir diesem "Mist" tatsächlich installieren? Na gut, um die Linsn-Logik zu verstehen, ist das wohl sinnvoll. nosilent schrieb: > Praktisch gsehen würde ich nicht mehr als 160 Pixel in der Breite > verwenden. Das ist dann bei 16Bit echter Farbtiefe 10MHz und du hast > eine PWM Frequenz von 840Hz (mit synchronem Refresh der gesamten > Anzeige). Das haut mich erstmal um, ich habe viele Fragezeichen über meinem Kopf schweben: > synchronem Refresh der gesamten Anzeige Wie soll das gehen? Der Refresh erfolgt doch Zeile pro Zeile, oder wie ist das gemeint? > 160 Pixel in der Breite, 16Bit echte Farbtiefe und 10MHz Du meinst also 5 Kacheln kaskadiert an einem HUB75, richtig? Bei "16Bit echte Farbtiefe" ist nicht ganz klar, in welchen Stufen, also wie groß ist der Kontrastumfang? Durch den Kontrastumfang ist m.E. nämlich die Physikalische Grenze festgelegt. Und bei einem Kontrastumfang von 1:100 z.B. braucht man m.E. keine 16Bit Farbtiefe. Nehmen wir an, die dunkelste LED leuchtet mit 1%. Bei 5 Kacheln (160 Pixel), 10MHz und 1/8 Scan wären das 128µs. Die hellste LED (mit 100%) muss dann 12800µs leuchten. Dann hätte man 78 Frames pro Sekunde bei 2 unterscheidbaren Helligkeitsstufen und einen Kontrastumfang von 1:100. Genau genommen sind es sogar 4 Stufen: 0µs, 128µs, 12672µs und 12800µs. aber nur zwei unterscheidbare, wenn man 0% nicht mitzählt. Wenn ich auf diese Weise mit 16Bit Farbtiefe rechne, komme ich nie auf 1:100. Und LCD-Bildschirme haben i.d.R. noch viel mehr. Klar kann man die dunkelsten LEDs auch einfach mit "Output Enable" kürzer leuchten lassen, als ein Refresh-Zyklus dauert. Aber das kann man sich nur bei den 2..4 LSBits der Helligkeit erlauben, sonst geht insgesamt zuviel Helligkeit futsch. Irgendwie reden wir aneinander vorbei.
:
Bearbeitet durch User
Torsten C. schrieb: > Hmmm, soll ich mir diesem "Mist" tatsächlich installieren? Na gut, um > die Linsn-Logik zu verstehen, ist das wohl sinnvoll. Ja die SW ist Müll, aber nur so lernt man auch die Limitierungen des Linsn-Systems kennen. Darum wäre es interessant den ganzen Linsn SW Mist neu zu machen, da ja die HW (Receiver und auch die Sender) sehr billig sind. Torsten C. schrieb: > Wie soll das gehen? Der Refresh erfolgt doch Zeile pro Zeile, oder wie > ist das gemeint? Wenn du eine LED Videowall mit sagen wir mal 100m² hast, kann es zu Großflächenflimmern kommen. Das hat mehrere Gründe. Um das in den Griff zu bekommen braucht man 1. eine Hohe PWM jeder einzelnen LEDs (in meinem Beispiel 840 Hz) und 2. die ganze LED Videowall (also alle einzelnen LED Modul PWMs) laufen synchron und sind ein Vielfaches der Input-Daten Frequenz (also zb. 50Hz), damit Videoframes nicht mal halb oder zu 3/4 in einem Frame der LED Videoanzeige angezeigt werden. Torsten C. schrieb: > Du meinst also 5 Kacheln kaskadiert an einem HUB75, richtig? Richtig, pro Hub75-Ausgang 5 Kacheln in Serie. Torsten C. schrieb: > Bei "16Bit echte Farbtiefe" ist nicht ganz klar, in welchen Stufen, also > wie groß ist der Kontrastumfang? Leider habe ich gerade keine Zeit um deine Berechnung(en) genau nachzuvollziehen. die 16 Bit Farbtiefe sind eine Angabe pro jeder LED. Wenn du dir bei der SW die hardware parameters der Receiver ansiehst, gibt es noch weitere Einstellungen, die sehr wichtig sind um ein ordentliches Bild zu erhalten. Ich kann dir aus Erfahrung sagen, der Kontrast reicht für Videos vollkommen. Und ja du hast recht, 16 Bit Farbtiefe sind sehr viel. Meistens werden 4096 Stufen verwendet, das reicht dann auch für eine schöne Gammakorrektur. Der Output Enable wird im wesentlichen für 2 Sachen verwendet: 1. Um Ghosting zu minimieren (bei schnellem Scan) 2. Um die gesamte LED Videowall zu dimmen (was auch vom Linsn-System in 256 Schritten möglich ist)
Torsten C. schrieb: > Klar kann man die dunkelsten LEDs auch einfach mit "Output Enable" > kürzer leuchten lassen, als ein Refresh-Zyklus dauert. Aber das kann man > sich nur bei den 2..4 LSBits der Helligkeit erlauben, sonst geht > insgesamt zuviel Helligkeit futsch. Das ist der Punkt, genau das macht Linsn teilweise. Man "verschenkt" etwas an Helligkeit unter Umständen. Bei 4096 statt 65535 Stufen ist das noch vertretbar (im Innenbereich, bezugnehmend auf mein Beispiel von oben mit den 10 MHz).
nosilent schrieb: > Darum wäre es interessant den ganzen Linsn SW Mist neu zu machen, da ja > die HW (Receiver und auch die Sender) sehr billig sind. Hmmm, ob man auch die Sender benutzt? Kommt mir zwar kompliziert vor, aber dann erübrigt sich m.E. die ursprüngliche Frage nach dem Ethernet-Protokoll. Das wäre dann doch total egal, da die Sender-Karte das Protokoll schon kann. nosilent schrieb: > Leider habe ich gerade keine Zeit um deine Berechnung(en) genau > nachzuvollziehen. ... Ich kann dir aus Erfahrung sagen, der > Kontrast reicht für Videos vollkommen. Die Berechnung ist ganz einfach, bei 1/8 Scan und 5 Kacheln:
Das ist die Mindest-Dauer für einen Refresh. Bei 30 fps darf ein komplettes Frame 33.3ms dauern. Wenn "100% an" = 33.3ms sind, dann würde die dunkeste LED mit ca. 0,4% leuchten:
Wenn Output Enable also gerade eben so lang wie nötig ist, um Ghosting zu vermeiden, ergäbe das ein Kontrastunfang von rund 1:260. Allerdings wären das nur 2 Zeitschlitze: 0.128ms und 33.205ms, also 2 Bit Farbtiefe. Wie man hier auch sieht, ist "x Bit Farbtiefe" nicht immer in "2^x Helligkeitsstufen" umzurechnen, da "00", "01" und "11" die einzig sinnvollen Helligkeitsstufen wären. "10" und "11" wären kaum unterscheidbar (33.21ms und 33.33ms). Um unter den physikalischen Grenzen eine sinnvolle Farbtiefe zu ermitteln, wäre interessant, welcher Kontrast (1:???) aus Erfahrung für Videos vollkommen reicht. Wenn die Receiver das sinnvoll können, macht es wirklich Sinn, den ganzen Linsn SW Mist neu zu machen, da die Receiver sehr billig sind. PS: Ein FPGA mit LVDS (statt Ethernet) ist auch eine günstige Alternative.
:
Bearbeitet durch User
PS zu "Farbtiefe" und "Helligkeitsstufen": "Photometrich gleichmäßig" = "logarithmisch abgestufte PWM-Prozent-Stufen". Oder? Ich habe mal ein paar Beispiele durchgerechnet: Man benötigt etwa Eineinhalb mal mehr "Zeitschlitze" wie "Bits Farbtiefe" und wirklich Gamma-korrigierte Helligkeitsstufen zu erreichen.
:
Bearbeitet durch User
nosilent schrieb: > nosilent schrieb: >> Ja, kann natürlich noch einige Bugs beinhalten. Hab ich mal eben schnell >> geschrieben. > > Und gleich noch einen Fehler gefunden, aktualisierte "binary" im Anhang. Absolut super, danke. Kann ich aber erst morgen testen, weil derzeit familiäre Pflichten des Vorweihnachtsstresses immer quälender werden ... also bis morgen. Noch eine Frage zum Nachdenken: In meiner Lieblings-IDE "RealBasic" kann ich ein TCP-Socket erzeugen und einfach reinschreiben und lesen. Wie verhindere ich bzw. wie erkennt dein Tool, dass/ob meine Sendung fragmentiert wird? Die TCP-Paketgröße kann ich auf dem Level nämlich nicht selber festlegen. Bei UDP dagegen habe ich selber Zugriff auf den Datagrammaufbau, der bis zu 64k groß sein kann ... könntest du evtl. nochmal UDP in Erwägung ziehen? Also ein Datagramm=1 RAW-Paket. Vlt. wahlweise per Parameter? Ich meine, ist ja nicht nur für mich, der Eine oder andere Mitleser hier wird das sicher auch gerne verwenden.
:
Bearbeitet durch User
nosilent schrieb: > nosilent schrieb: >> Ja, kann natürlich noch einige Bugs beinhalten. Hab ich mal eben schnell >> geschrieben. > > Und gleich noch einen Fehler gefunden, aktualisierte "binary" im Anhang. Bin gerade dabei, mich "ranzutasten", connect aus Realbasic auf 8888 klappt schonmal. Als ich übrigens vorher Winpcap installieren wollte, meinte der Installer, es wäre schon da. Da ich das definitiv vorher nicht installiert habe, kann es nur Linsn's LED-Studio gewesen sein ... aha! ...
Frank Esselbach schrieb: > Bei UDP dagegen habe ich selber Zugriff auf den Datagrammaufbau, der bis > zu 64k groß sein kann ... könntest du evtl. nochmal UDP in Erwägung > ziehen? Also ein Datagramm=1 RAW-Paket. Vlt. wahlweise per Parameter? Die Ethernet Größe ist derzeit fix auf 1486 Byte. D.h. du sendest x Bytes per TCP und es wird nach 1486 empfangenen Bytes diese RAW als Ethernet Frame gesendet. Bei meiner Wireshark-Aufzeichnung ist mir kein Frame mit einer anderen Größe aufgefallen. Natürlich ist das nicht optimal. Eventuell könnte man sich ein eigenes mini-Protokoll überlegen. z.b. angefangen mit der größe bis x Bytes, dann die Nutzdaten.
Achja, bei mir flackern schon einzelne LEDs. Es scheint eine Status/Sync Adresse und eine Daten-Adresse für die/den Empfänger zu geben.
nosilent schrieb: > Achja, bei mir flackern schon einzelne LEDs. Ok ... zwei Fragen a) bei mir hat sich dein Tool mit einer nicht näher bezeichneten Exeption beendet, als es ca. 20 Minuten ungenutzt war ... Ideen wieso? b) was ist eigentlich mit der Ethernet-Frame-Checksum am Ende - erzeugt die dein Tool von sich aus oder muss man das selber machen, wenn man die Daten verändert? Ich habe in den aufgezeichneten Paketen von Wireshark Nichts degleichen gesehen. > Es scheint eine Status/Sync Adresse und eine Daten-Adresse für die/den > Empfänger zu geben. Kannst du das bitte näher erläutern? Ich habe nur Pakte mit der gleichen Ziel-MAC-Adresse gesehen. Wie unterscheiden sich die Pakete?
Torsten C. schrieb: > "Photometrich gleichmäßig" = > "logarithmisch abgestufte PWM-Prozent-Stufen". Oder? Was genau das Linsn-System unter Farbtiefe meint kann ich dir nicht sagen. Ich gehe davon aus, dass die einfach ein PWM machen mit x Bit und dann eine Gammakorrektur-Tabelle hernehmen. Die Input-RGB Werte sind jedenfalls 8 Bit pro Farbe. Torsten C. schrieb: > Um unter den physikalischen Grenzen eine sinnvolle Farbtiefe zu > ermitteln, wäre interessant, welcher Kontrast (1:???) aus Erfahrung für > Videos vollkommen reicht. Kann ich dir leider nicht beantworten, unsere Systeme hatten immer mind. 1:1000. Wir haben aber die LEDs dabei immer konstant angesteuert. Torsten C. schrieb: > Wie man hier auch sieht, ist > > "x Bit Farbtiefe" nicht immer in > "2^x Helligkeitsstufen" Genau, daher sind diese Gammakorrektur-Tabellen annähernd logarithmisch. Torsten C. schrieb: > Klar kann man die dunkelsten LEDs auch einfach mit "Output Enable" > kürzer leuchten lassen, als ein Refresh-Zyklus dauert. Aber das kann man > sich nur bei den 2..4 LSBits der Helligkeit erlauben, sonst geht > insgesamt zuviel Helligkeit futsch. Wie ich nun feststellen konnte, dürfte das Linsn so in der Art auch machen. Bei meinem Beispiels mit 10 Mhz und den HUB75 Modulen bei 160 Pixel in der Breite sind es dann "nur" mehr ca. 80% Hellligkeit bei 12 Bit Farbtiefe und ca. 70% bei 16 Bit. Deine Berechnungen von oben beziehen sich ja auf die Frame-Länge. Vielleicht macht Linsn noch innerhalb des "Scans" etwas. Das Ghosting ist aufjedenfall kein "Problem" beim Frame sondern innerhalb der Scan-Line-Umschaltung. Daher kann man in der Linsn SW ein blanking bei jeder Scan-Line angeben (in der Größenordnung von 100ns, ist für die meisten LED Pixelmodule ausreichend). PS: Es gibt verschiedene Arten von Kontrast. Meistens ist die Angabe ja von der realen Helligkeit der LEDs abhängig und dem Pixelmodul-Hintergrund.
Frank Esselbach schrieb: > a) bei mir hat sich dein Tool mit einer nicht näher bezeichneten > Exeption beendet, als es ca. 20 Minuten ungenutzt war ... Ideen wieso? Socket timeout evt. Außerdem wird nach Trennen der Verbindung des Clients zum Server das Programm "beeendet". Frank Esselbach schrieb: > b) was ist eigentlich mit der Ethernet-Frame-Checksum am Ende - erzeugt > die dein Tool von sich aus oder muss man das selber machen, wenn man die > Daten verändert? Ich habe in den aufgezeichneten Paketen von Wireshark > Nichts degleichen gesehen. Prinzipiell müsste man die selber erzeugen. Meine Linsn SW Sender Card sendet aber keine Checksum bzw. ist es meiner "Receiving-Card" egal, daher hab ich das auch nicht eingebaut.
nosilent schrieb: > Socket timeout evt. > Außerdem wird nach Trennen der Verbindung des Clients zum Server das > Programm "beeendet". Ich habe folgendes Problem: Nachdem ich den Java-Treiber mit meiner eignenen App benutzt habe, funktioniert anschliessend die Übertragung per Coalasoft Packetplayer nicht mehr. Obwohl sich die Java-App anscheinend korrekt beendet - steht zumindest so im Fenster der Eingabeaufforderung. Die LED-Anzeige habe ich kurzzeitig stromlos gemacht und damit resettet. Nur wenn ich den PC neu starte, funktioniert auch die Übertragung per Coalasoft wieder. Irgendwas "verstopft" da im Windows - was kann das sein?
Halo NOSILENT, bitte melden! Irgendwie sendet dein Java-Tool nicht das als RAW aus, was ich per TCP hineinschreibe. Oder wir haben uns irgendwie missverstanden. Ich öffne die *.pcap-Datei von Wireshark, dann 1. lese ich den Header mit 48 Bytes ein 2. lese ich 1486 Bytes Nutzdaten, lege diese in einem String-Array ab 3. überspringe 24 Byte Timestamp u.a. 4. gehe zu 2 Zeige ich die Daten in einem HEX-Grid an, entsprechen Sie genau dem, was ich bei den Originaldaten auch im Wireshark zu sehen bekomme. Die Pakete beginnen alle mit der Ziel-Mac 00:00:00:00:00:fe, der Source-Mac meines PC und dem Protokolltyp AA:55 - soweit ok. Die Strings aus dem String-Array sende ich dann nachenander in den geöffneten TCP-Socket, der zuvor auf 127.0.0.1:8888 connectet hat. Wenn ich das mit Wireshark erneut aufzeichne, stelle ich als erstes fest, dass am Anfang 6 Bytes (alle 00) zuviel drin sind, der Rest ist verschoben, was an meiner LED-Anzeige nat. nur ein gelegentliches Flackern verursacht ...
Hallo Frank, Du testest doch mit original Linsn "Sending card" und "Receiving card", oder? Mich würde mal interessiern, ob auch eine DLL dabei ist, die unter Windows 7 oder Windows 8.1 läuft. Eventuell kommt man weiter, indem man gegen diese DLL programmiert. Nachteil: Man ist bei jedem Windows-Update auf die Chinesen angewiesen, dass die immer kompatible Treiber liefern. Besser wäre, die Hardware zu verstehen und ggf. Treiber - bei Bedarf auch für Linux - selbst zu programmieren. Die Nummer wäre mir aber etwas im Moment zu groß. @All: Wie seht Ihr das? Ggf. würde ich mir mal so eine Karten-Pärchen kaufen. Oder hat noch jemand welche übrig? VG Torsten
chris schrieb: > Wenn es TCP ist, verwende das netcat tool. Es ist eben kein TCP oder UDP, sondern "blankes" Ethernet. TCP oder UDP - das wäre ja viel zu einfach, dann wäre das hier ja nicht wirklich eine Diskussion wert. Weiter oben habe ich eine *.pcap-Datei zur Verfügung gestellt - du kannst sie mit Wireshark öffnen und selber ansehen. Nein, man muss mit diesen dusseligen "RAW-Sockets" hermummachen. In Windows sind sie seit XP/SP3 blockiert, weil "zu gefährlich", also muss man sich mit externen Libs wie Winpcap beschäftigen. Und ausserdem muss am ENde ein kontinuierlicher Datenstrom gesendet werden, da nützt das Hermumspielen mit irgendwelchen Diagnostik- oder Test-Tools evtl. beim Erforschen, aber nicht in der dauerhaften Anwendung.
Torsten C. schrieb: > Hallo Frank, > > Du testest doch mit original Linsn "Sending card" und "Receiving card", > oder? Nein, ich teste mit der Software LED-Studio und einem LED-Controller vom Typ RV908T. Letztes kann sowohl von einer Sender-Card als auch von einer normalen Ethernet-Schnittstelle eines PC beschickt werden. Aber die Software LED-Studio ist für die direkte Bediemung vom Desktop eines PC aus vorgesehen. Ich brauche jedoch das dynamische Erzeugen von Inhalten für die LED-Anzeige aus einer eigenen Anwendung heraus, die auf einem kleinen Steuerrechner ohne Bildschirm und Maus/Tastatur läuft. Deshalb die Bemühungen, da selber irgndwie Daten hinzubekommen. > Mich würde mal interessiern, ob auch eine DLL dabei ist, die unter > Windows 7 oder Windows 8.1 läuft. Eventuell kommt man weiter, indem man > gegen diese DLL programmiert. Die Software LED-Studio verwendet auch die pcap.dll zum Erzeugen von RAW-Ethernet-Paketen, die läuft unter allen aktuellen Win-Versionen. Man muss beim Installieren lediglich zwischen 32 und 64 Bit auswählen. > Nachteil: Man ist bei jedem Windows-Update auf die Chinesen angewiesen, > dass die immer kompatible Treiber liefern. Besser wäre, die Hardware zu > verstehen und ggf. Treiber - bei Bedarf auch für Linux - selbst zu > programmieren. Bei Netzwerk-Geräten benötigt man keine Treiber im eigentlichen Sinn, weil geräteunabhängig. Warun die Chinesen kein normales UDP verwenden ist mir ein absolutes Rätsel, ich wüsste nicht, was damit nicht gehen sollte. Entweder sind die extrem dumm oder extrem clever ...
Frank Esselbach schrieb: > Die Software LED-Studio verwendet auch die pcap.dll zum Erzeugen von > RAW-Ethernet-Paketen OK, verstanden: Damit kann man dann per Standard-Netzwerk-Karte die LEDs steuern. Die Sender-Card brauchst Du dann ja nicht, aber wozu braucht man die überhaupt? nosilent schrieb: > Darum wäre es interessant den ganzen Linsn SW Mist neu zu machen, da ja > die HW (… auch die Sender) sehr billig sind. Ich nehme an, weil die Sender-Card das Bild aus einen DVI-Eingang holt und per Ethernet weiter schickt. Und um die Sender-Card dazu du bringen, den richtrigen Bildausschnitt zu senden, muss man sicherlich über irgend eine DLL mit der Sender-Card reden. Diese DLL meinte ich oben.
Angehängte Dateien:
-
Zeitschlitze.PNG
9,8 KB
nosilent schrieb: > mit einem STM32F429I-DISCO … ist aber eher eine Spielerei. Zustimmung. Ein FPGA mit "Grafik-RAM" (Embedded-Block-RAM?) macht mehr Sinn. Trotzdem: Ich habe gerade eine kleine Anwendung mit zwei "Kacheln": 2 x 32x16 = 32 x 32 mit 1/16 Scan (HUB08), siehe Beitrag "verschiedene LED-Controller mit STM32 ansteuern" Warum ich das hier schreibe? Es geht mir um gleichmäßige Helligkeitsstufen. Ich setze erstmal 9 Timeslots um und kann dann 32 also 5 Bit "echte" (logarithmische) Helligleitsstufen. Im Bild: * Spalten = Helligleitsstufen, * Zeilen = Zeitschlitze nosilent schrieb: > Wenn du nur eine kleine LED Matrix ansteuern wilst, hätte ich auch ein > Proof of concept mit einem STM32 (bis zu 4x4 HUB75 RGB Module, jeder > Pixel mit 24Bit): Ich blicke da auf die Schnelle nicht durch. Wie hast Du das mit den Helligleitsstufen gemacht? Wie das bei "Linsn" geht, würde mich auch interessieren. Ich habe maximal 2% Abweichung von der logarithmischen Stufung. Aber ich bin sicher, ich brauche drei getrennte Lookup-Tabellen: Eine pro Farbe. Blau ist bei mir am dunkelsten.
:
Bearbeitet durch User
Frank Esselbach schrieb: > Wenn ich das mit Wireshark erneut aufzeichne, stelle ich als erstes > fest, dass am Anfang 6 Bytes (alle 00) zuviel drin sind, der Rest ist > verschoben, was an meiner LED-Anzeige nat. nur ein gelegentliches > Flackern verursacht ... Muss ich mir ansehen, habe leider gerade wenig Zeit... Frank Esselbach schrieb: > Warun die Chinesen kein normales UDP verwenden > ist mir ein absolutes Rätsel, ich wüsste nicht, was damit nicht gehen > sollte. Entweder sind die extrem dumm oder extrem clever ... Der Vorteil ist der geringere Overhead. Weiters sparen sie sich einen ordentlichen IP/UDP-Stack, das ganze läuft ja in/auf einem FPGA. So wie das aussieht verwenden die einfach den Ethernet PHY, damit die Daten übertragen werden (von Senderkarte, oder Linsn SW, zu den Receiving Cards). Torsten C. schrieb: > Die Sender-Card brauchst Du dann ja nicht, aber wozu braucht man die > überhaupt? Wenn man keinen (Windows)-PC einsetzen will. DVD-Player, ... etc. Außerdem unterstützt das Linsn System "hot"-Backup, also eine Receiver-Karte kann von zwei Sendern (Senderkarten) angesteuert werden, wenn eine ausfällt wird das Signal vom anderen Sender angezeigt. Torsten C. schrieb: > Ich nehme an, weil die Sender-Card das Bild aus einen DVI-Eingang holt > und per Ethernet weiter schickt. Und um die Sender-Card dazu du bringen, > den richtrigen Bildausschnitt zu senden, muss man sicherlich über irgend > eine DLL mit der Sender-Card reden. > > Diese DLL meinte ich oben. Die Konfiguration der Senderkarte geht über eine serielle Schnittstelle. Auf der Senderkarte ist ein SiLabs USB<->UART Wandler drauf. Da kann man Helligkeit, Bildausschnitt, usw. einstellen. Die Senderkarte agiert wie ein Monitor und hat einen DVI-Eingang. Torsten C. schrieb: > Ich blicke da auf die Schnelle nicht durch. Wie hast Du das mit den > Helligleitsstufen gemacht? Mit binary code modulation. Ich verändere den Takt vom Clock vom Timer der den DMA für den GPIO (an dem sind die LED Module angeschlossen, bis zu 4 Ausgänge) steuert (und somit die Datengeschwindigkeit). Die 24 bit sind aber linear. Bei geringerer Modulanzahl sind natürlich mehr lineare Bit möglich.
nosilent schrieb: > auch mit einem STM32F429I-DISCO HUB75 und HUB08 Module angesteuert. Mit > bis zu 11MHz Clock Frequenz, dann noch BAM für das PWM verwendet und DMA > usw., ist aber eher eine Spielerei. Bei Linsn wären max. 30MHz Clock Woher hast Du Informationen zum BAM Mode? Datenblatt und Referenz Manual werden nicht konkret und die versprochene AN4515 gibt es noch nicht...
Uwe Bonnes schrieb: > Woher hast Du Informationen zum BAM Mode? Datenblatt und Referenz Manual > werden nicht konkret und die versprochene AN4515 gibt es noch nicht... BAM ist sowas wie PWM, nur effizienter in manchen Situationen. Das hat nichst mit STM32 oder so zu tun. Siehe: http://www.artisticlicence.com/WebSiteMaster/App%20Notes/appnote011.pdf
nosilent schrieb: > BAM ist sowas wie PWM … hat also nix mit dem Dynamic Efficiency Batch Acquisition Mode zu tun: https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fcortex_mx_stm32%2fWher%20is%20AN4514 @nosilent, cooler Link, danke: http://www.artisticlicence.com/WebSiteMaster/App%20Notes/appnote011.pdf Die Tabelle auf Seite 8 (Bit Angle Modulation) beschreibt gut, was ich meine, nur dass "Stretched by" bei mir keine 2er-Potenzen sind, um kleinere Stufen (24.7, 28.1, 32.0, …) für die dunklen Werte zu haben, ohne unnötig viele "Bit-Positionen" (=Zeitschlitze) zu benötigen, siehe Zeitschlitze.PNG. ^^ Bei Linsn sind die "Stretched by"-Werte bestimmt auf 2er-Potenzen festgelegt, oder?
:
Bearbeitet durch User
@ nosilent: So, ich kann jetzt die Daten mit eigener Software so abspielen, wie mit Coalasoft Packetplayer. Das erforderliche Timing hatte ich wohl gründlich unterschätzt, aber ist ja nun auch klar - da ist keinerlei Speicher, also müssen die Daten live und immer wieder kommen. Hast du ein par Erkenntnisse zum Aufbau der Datenpakete gewonnen und kannst sie hier bekanntgeben? Ich versuche zur Zeit einen Bereich aus einem Wireshark-Mitschnitt einerseits zyklisch zu senden und andererseits soweit wie möglich einzuengen. Es scheint so zu sein, dass zu Beginn immer mindestesn ca. 300 Pakete gesendet werden müssen, bis die Empfängerkarte überhaupt synchronisiert ...
Frank Esselbach schrieb: > ist ja nun auch klar - da ist keinerlei > Speicher, also müssen die Daten live und immer wieder kommen. Wieviele Frames können denn diese Receiver speichern? Haben die nur einen "Double-Buffer", oder können die noch mehr Frames in einem FIFO speichern? Ich frage so viel (auch wegen der "Stretched by"-Werte), weil ich mich frage, ob es sich lohnt, diese Karten zu kaufen oder selbst einen FPGA zu programmieren.
:
Bearbeitet durch User
Torsten C. schrieb: > Wieviele Frames können denn diese Receiver speichern? Haben die nur > einen "Double-Buffer", oder können die noch mehr Frames in einem FIFO > speichern? > > Ich frage so viel (auch wegen der "Stretched by"-Werte), weil ich mich > frage, ob es sich lohnt, diese Karten zu kaufen oder selbst einen FPGA > zu programmieren. Ich habe gerade erst das Problem der physikalischen Übertragung gelöst und bin nun dabei, mich an die Kodierung heranzutasten. Derzeit übertrage ich für eine Anzeige von 32x192 Pixeln, bestehend aus drei Modulen 32x64 zyklisch 143 Pakete zu je 1486 Bytes (davon 1472 Payload). Das sind also (derzeit) für meine Anzeige 210496 Bytes, obwohl eigentlich rein rechnerisch nur 18432 (192x32x3) benötigt würden. Da muss ich mal sehen, wieweit ich das noch eingrenzen kann. Wenn ich z.Zt. die Datenmenge verrringere, geht die Synchronisation verloren und es wird das im Controller gespeicherte "Pausenbild" angezeigt. Was ich bisher sicher weiss, ist, dass jeweils drei aufeinanderfolgende Bytes "ganz normal" für die Intensität von R, G und B zuständig sind. Umgestzt wird das ohne weiteres Zutun vom Controller. Die geometrische Zuordung ist etwas wirr, da bin ich noch am Forschen ...
Torsten C. schrieb: > Die Tabelle auf Seite 8 (Bit Angle Modulation) beschreibt gut, was ich > meine, nur dass "Stretched by" bei mir keine 2er-Potenzen sind, um > kleinere Stufen (24.7, 28.1, 32.0, …) für die dunklen Werte zu haben, > ohne unnötig viele "Bit-Positionen" (=Zeitschlitze) zu benötigen, > siehe Zeitschlitze.PNG. ^^ > Genau > Bei Linsn sind die "Stretched by"-Werte bestimmt auf 2er-Potenzen > festgelegt, oder? Kann ich nicht sagen, hab mir das noch nicht ganz genau angesehen. Sie machen das aber wohl eher über eine Lookup-Tabelle, also ja. Zuerst viele Stufen und dann auf die 8 Bit je Farbe adaptieren. Frank Esselbach schrieb: > Hast du ein par Erkenntnisse zum Aufbau der Datenpakete gewonnen und > kannst sie hier bekanntgeben? Nein leider nicht, da andere Projekte wichtiger sind. Torsten C. schrieb: > Wieviele Frames können denn diese Receiver speichern? Haben die nur > einen "Double-Buffer", oder können die noch mehr Frames in einem FIFO > speichern? Sehr wahrscheinlich einen Double-Buffer. Verwendet wird unter anderem ein EtronTech EM638325 (2M x 32). Frank Esselbach schrieb: > Die geometrische > Zuordung ist etwas wirr, da bin ich noch am Forschen ... In der Linsn SW kann man die Anordnung der LEDs in einem Pixelmodul und die Anordnung der Receiver konfigurieren. Vielleicht erhält man da Erkenntnisse.
Ich kann jetzt verkünden, dass in den Linsn-RAW-Packets Byte 32 bis 1469 jeweils in 3er-Gruppen einen Pixel transportieren - also 479 Pixel, wobei einige davon ausserhalb der Anzeigefläche zu liegen scheinen. Die Farbcodierung ist x+0=Blau x+1=Grün x+2=Rot Allerdings sind die restlichen Werte, vor Allem die räumliche Zuordnung z.Zt. noch nebulös. Ich muss für meine 192x32-Matrix z.B. 143 Pakete aus einem Mitschnitt übertragen, von denen nur 32 wirklich Grafikinformationen enthalten. Verringere ich die Zahl der übertragenen Pakete, verliert die Anzeige die Synchronisation und zeig ihr fest eingespeichertes Pausenbild.
Frank Esselbach schrieb: > Ich muss für meine 192x32-Matrix z.B. 143 Pakete aus > einem Mitschnitt übertragen, von denen nur 32 wirklich > Grafikinformationen enthalten. Hast Du den Mitschnitt von einer Linsn Sender-Card? Kann es sein, dass man die Receiver noch konfigurieren muss bzw. dass sie die Konfiguration aus den Daten bekommen? Also an welchem HUB75-Anschluss wieviele Kacheln mit welchem Scan (1/4, 1/8, 1/16, ...) hängen? Das muss doch auch irgendwie einstellbar sein. Vielleicht erscheinen die Pixel, die Du überflüssiger weise mitsenden musst, auf einer Kachel, die hinter Deiner letzten an einem HUB75 hängen könnte. nosilent schrieb: > Sie machen das aber wohl eher über eine Lookup-Tabelle, also ja. Das klingt brauchbar. :-) Wenn man jetzt diese Loopup-Tabelle noch beeinflussen könnte, hätte man ja alle Parameter voll im Griff!
:
Bearbeitet durch User
Torsten C. schrieb: > Hast Du den Mitschnitt von einer Linsn Sender-Card? Steht in diesem Thread etwas weiter oben. > Kann es sein, dass man die Receiver noch konfigurieren muss bzw. dass > sie die Konfiguration aus den Daten bekommen? Also an welchem > HUB75-Anschluss wieviele Kacheln mit welchem Scan (1/4, 1/8, 1/16, ...) > hängen? Das ist durchaus möglich, "mein Chinese" hat mir den Controller in LED-Studio genau auf die Dimensionen meiner Anzeige konfiguriert, habe ich gesehen. Allerdings läuft LED-Studio bei mir zuhause unter WIn 7 derart grottig (und die üble Oberfläche tut ihr Übriges hinzu), dass ich mich frage, die der das wohl gemacht hat. Ich bin trotz ausführlichen Studiums der Bedienungsanleitung und Kenntnis aller Passwort-Tricks ("linsn", "8888", "168") nie selber bis dahun vorgedrungen. Ist aber im Moment auch nicht wichtig, ich muss Daten Senden, nicht das Teil konfigurieren. > Das muss doch auch irgendwie einstellbar sein. Vielleicht erscheinen die > Pixel, die Du überflüssiger weise mitsenden musst, auf einer Kachel, die > hinter Deiner letzten an einem HUB75 hängen könnte. Ganz sicher, aber später. Im Moment bin ich stark unter Zeitdruck und muss baldigst eine brauchbare Anzeige liefern. Immerhin bilden die Pixelzeilen immer einen zusammenhängenden Block, aber teilweise auch über Paketgrenzen hinweg. Ich nehme an, der Controller hat einfach einen Mindestspeicher, der gefüllt werden muss. Wenn ich nämlich die Startadresse innerhalb meines Datenpaketes verschiebe, erscheinen auch Desktop-Objekte die während des Wireshark-Mittschnittes garantiert nicht innerhalb des Auswahlrechtecks von LED-Studio waren ...
Angehängte Dateien:
-
linsn_receiver1.png
67 KB -
linsn_display_cn.png
61 KB -
linsn_color_correction.png
39 KB
Torsten C. schrieb: > Kann es sein, dass man die Receiver noch konfigurieren muss bzw. dass > sie die Konfiguration aus den Daten bekommen? Also an welchem > HUB75-Anschluss wieviele Kacheln mit welchem Scan (1/4, 1/8, 1/16, ...) > hängen? Ich glaube eher, dass die gesondert gesendet werden. Immerhin gibt es in der Linsn SW auch den Punkt Send to receiver und save on receiver. Torsten C. schrieb: > Das muss doch auch irgendwie einstellbar sein. Vielleicht erscheinen die > Pixel, die Du überflüssiger weise mitsenden musst, auf einer Kachel, die > hinter Deiner letzten an einem HUB75 hängen könnte. Sehr wahrscheinlich Torsten C. schrieb: > Das klingt brauchbar. :-) Wenn man jetzt diese Loopup-Tabelle noch > beeinflussen könnte, hätte man ja alle Parameter voll im Griff! Durchaus, man kann die Gamma-Kurve ja einstellen. Das System hat ja auch noch eine Pixelkorrektur, die wird wahrscheinlich nach der Lookup-Tabelle angewendet auf die >8 Bit ("Stretch -by-werte") Werte.
nosilent schrieb: > Das System hat ja auch noch eine Pixelkorrektur Das setzt nich noch immer in Erstaunen. Die haben für jedes Pixel nochmal Platz für Korrekturwerte im RAM? Hut ab! Lohnt sich wohl echt nicht, Receiver selbst zu bauen. Da es genügend Clone zu geben scheint, ist die Versorgung mit den Receivern wahrscheinlich auch lange sichergestellt.
:
Bearbeitet durch User
So, was mein initiales Problem betrifft, so bin ich jetzt erstmal damit "durch" - rein pragmatisch betrachtet. Die Lösung beinhaltet folgende Schritte: 1. RAW-Socket. Dazu hat mir jemand aus dem C++-Forum eine App geschrieben, die per UDP empfängt und RAW sendet. Funktioniert extrem zuverlässig und ist lediglich 1,8 MB groß, inkl. einiger statisch gelinkter Dlls. Setzt ein installiertes Winpcap voraus. 2. "LED-Beamer". Das LED-Display muss mit einem kontinuierlichen Datenstrom versorgt werden und wenn der stockert, gibts sofort hässliches Flackern. Die Grundalgorithmen habe ich zunächst als Bestandteil einer Desktop-App entwickelt und die prinzipielle Funktion nachgewiesen. Allerdings gibts bereits bei Mausbewegungen Aussetzer oder Bildwackler. Lösung: Der Programmteil, der die Grafikinformationen als Block aus meinem Hauptptogramm erhält, umcodiert und zum UDP2RAW-Treiber sendet, wird abgetrennt und als Windows-Dienst mit hoch eingestellter Priorität betrieben. Das stellt einen kontinuierlichen Datenstrom der Grafikdaten zum Display sicher, kein Flackern bei GUI-Aktionen mehr. 3. Die eigentliche Anwendung, die die Inhalte generiert, ist eine Prozessvisualisierung (Autowaschanlage), ist nun vollkommen entkoppelt. Sie sendet die grafischen Daten per IPC-Socket zum "LED-Beamer" Das eigentliche Protolkoll habe ich nicht wirklich entschlüsselt. Auf Basis eines Wireshark-Mitschnittes habe ich einen Teil des Datenstromes (149 Packets) durch Trial&Error "herausgepickt", lade diesen in den RAM und streame ihn kontinuierkich (inkl. Modifikationen, s. nächster Abschnitt). Dieser Mitschnitt zeigt beim Streamen eine dunkelblaue Fläche, einen Ausschnitt meines Desktop, erzeugt von Linsn LED-Studio. Dann habe ich durch gezieltes Verändern von Bytes in meinem RAM-Puffer die Adressen der eigentlichen Bild-Pixel herausgefunden. Die Zeilendaten für mein Display (192x32) finden sich in Abständen von 512 Bytes im hinteren Bereich der 149 Packets, allerdings auch über Paketgrenzen hinweg ... am Ende habe ich eine Funktion gefunden, die es mir tatsächlich ermöglicht, mit einigen Konstanten, Mods und Divs aus x- und y-Werten den dazugehörigen Speicherplatz zu errechnen und somit gezielt zu "malen". Damit kann ich also nun eigene Inhalte per eigener Software anzeigen. Derzeit erreiche ich eine Frame-Rate von 8..10/s, was aber nur für Animationen oder Video wichtig wäre ... das lässt sich bestimmt noch verbessern, ist aber für mich aus Zeit- und Effizienzgründen derzeit unwichtig.
Hallo Ich hab mit den Fred nun 2 mal durchgelesen. Trotzdem bin ich noch nicht sicher, ob und wie ich die ReceiverCard direkt am EtherNet Port des PCs betreiben kann. Wenn ich Led Studio 12 öffne, erhalt ich die Meldung LED screen system not found. Auch beim Durchspielen verschiedener EInstellungen konnte ich kein Licht in die Angelegenheit bringen...
Electronic R. schrieb: > Wenn ich Led Studio 12 öffne, erhalt ich die Meldung LED screen system > not found. Led Studio 12 redet m.E. nur mit einem Linsn-Sender mit DVI Eingang. In diesem Thread ging es darum, die vom Linsn Sender über IP gesendeten Daten auf einem anderen Wege, also ohne Linsn-Sender zu erzeugen, also z.B. durch Mittschnitt und wiederholte Aussendung der Daten die mal von Led Studio 12 und einem Linsn-Sender gesendet wurden. Aber auch dazu benötigst Du einmal einen Linsn-Sender. Hast Du einen?
Ich habe den Rotz mit Linsn inzwischen aufgegeben und verwende einen Raspberry Pi, entweder mit dem Hat von Adafruit (1 Strang, bis zu 5 Module 32x64 "In Reihe") oder den Passiv-Adapter von Henner Zeller (3 parallele Stränge mit bis zu 5 Modulen). Das reicht für meine Aufgaben von der Größe her vollkommen aus, die Software und was da passiert habe ich ohne Rätselraten vollkommen unter Kontrolle. Man kann von einer selbstgeschriebenen PC- oder Mac-Anwendung aus bis zu 25 Frames/Sekunde per UDP zur Anzeige bringen ...
Torsten C. schrieb: > Hast Du einen? nein, ich habe leider keienen ich habe gestern eine Lieferung mit 30 Modulen samt Controller RV908 erhalten und sollte damit eigentlich nur einen Testaufbau machen und 20 Minuten lang eineige Bilder Animationen abspielen. Das ganze um zu prüfen ob die Module für den geplanten Verwendungszweck in Frage kommen, Pixeldichte, Stromaufnahmen usw. ok ist. Erst beim Aufbau habe ich gemerkt, dass öfters "Senderkarten" erwähnt werden. Beim Controller schreibt der Verkäufer
1 | This is sync receiver card, receiver card need working with comptuer Gigabit 1000MB network card(if no sending card) |
trotzdem hatte ich bislang keinen Erfolgt... da ich hier im Umkreis wohl an keine Senderkarte komme muss ich mich wohl mit dem Gedanken anfreunden wieder ein paar WOchen auf die Lieferung aus Asien zu warten...
Electronic R. schrieb: > receiver card need working with comptuer Gigabit 1000MB network card > (if no sending card) Dann frage bitte mal den Verkäufer, wie man seine 'receiver card' über eine 'comptuer Gigabit 1000MB network card' ansteuert. Das wäre dann die Antwort auf die ursprüngliche Frage von Frank. Die Antwort würde auch mich interessieren. Frank E. schrieb: > oder den Passiv-Adapter von Henner Zeller … Oops, ich dachte immer, der RasPi kann so ein exaktes Timing nicht. Wieviele Helligkeitsstufen sind mit dem Hat von Adafruit oder dem Henner Zeller Adapter möglich? Der Linsn-Sender hat ja sogar Gamma-Korrektur und Einzel-Pixel-Korrektur, wenn ich mich richtig erinnere. Die '8192 RGB LEDs (each 24Bit RGB brightness) with one STM32' von nosilent^^ finde ich spontan erstmal schlanker.
Angehängte Dateien:
-
20160727_213349.jpg
240 KB
hab den Verkäufer mal angeschrieben, mal abwarten... hier mal das aufgebaute Display mit Testbild. 10 Reihen x 3 P10 Module. Die 10 Reihen sind an 10 der 12 Ports des Controllers angeschlossen. Warum 4 davon nur Murks anzeigen ist mir noch ein Rätsel. Wahrscheinlich sind momentan nur 6 Ports des COntrollers konfiguriert. Bei den 6 Reihen (18 Module) bei denen das Testbild angezeigt wird habe ich 4 Pixelfehler..
("Psycho Dad (Gast)" == "Electronic R. (electronic_r)") ? "ja" : "nein"
Psycho Dad schrieb:
> mal abwarten...
Ich bin gespannt!
Pixelfehler können bei Billig-China-Ware immer sein. Ich habe 100
Ersatz-Treiber, ein paar LEDs und einen Lötkolben für einen solchen
Fall.
Electronic R. schrieb:
> Das ganze um zu prüfen ob die Module für den geplanten Verwendungszweck
> in Frage kommen
Ich brauche noch Module.
Falls Du mal wieder bestellst: Können wir eine Sammelbestellung machen?
Ich habe bislang bei JS INDUSTRIAL LTD, also
'Winter (S*l*s Manager) <s*l*s*jsin*ust*ial*td.c*m>
bestellt. Ich war bislang sehr zufrieden.
Damit es hier nicht OT wird: Rest bitte ggfs. per PN
oder im Forum 'Markt'.
LG Torsten
:
Bearbeitet durch User
Torsten C. schrieb: > ("Psycho Dad (Gast)" == "Electronic R. (electronic_r)") ? "ja" : "nein" "ja" :) hab einen zweitcomputer verwendet und war dort nicht eingeloggt.. der verkäufer meinte es sollte funktionieren. er war per teamviewer am gerät aber kam nicht weiter. jetzt soll ich ihm noch daten über den aufbau schicken. sobald in shenzen wieder die sonne aufgeht will er es nochmal versuchen. inzwischen hab ich auf der seite http://www.szbako.com/show-45-17346.html dies gefunden:
1 | 1, first make sure your network card is Gigabit Ethernet and whether they are compatible: |
2 | in LED Studio software, choose set software - Settings - input & lsquo; linsn’ and & lsquo; 168’ backward into the send card set, in sending card set interface to input & lsquo; netlst’ can check the computer card types and transmission speed. As shown in the figure below, the connection speed bit 1000M is a Gigabit Ethernet card and can be used. |
3 | |
4 | 2 and 568B GB cable connection Gigabit Ethernet and receiving card, distance cannot be more than 80 meters, led the studio software with more than 12.* version open the power LED screen, which is receiving card given the green light to flash slowly; |
5 | |
6 | 3, start led studio, tips & ldquo, such as startup, no available serial port! & rdquo; directly click OK to skip; skip if LED display lighting and receiving card of the green indicator light normal flash quickly explain the connection is successful, then you can normal to do the next step work (such as receiving card parameter settings and display connection, etc), operation way to send card connection is similar. As shown in the following figure can be set to connect to the success of the network card, see the hardware and connection mode (NETCARD for the network card connection)]]. |
7 | |
8 | 4, if the third step prompts ‘ no serial port! ’ click OK to skip after the prompt ‘ can not find the big screen ’ then you need to check the cable or receive card installation is correct! After the investigation continues to operate the next step (the connection can not be successful in the sending card set to choose to remember the network card and view the hardware model). |
bin grad dabeiu den sinn zu entschlüsseln
Wir haben das früher mal aus Spass getestet - es geht wirklich, direkt vom Gigabit Ethernet Port zum LED-Modul was zu schicken. Wenn ich mich recht erinnere, wurde da dann sogar in Windows ein weiterer Monitor angelegt Ist aber lange her, das Ergebnis reichte auch nur um was zu testen, Aussage Linsn war damals das man wohl die neuere Generation an Receiving Boards benötigt Wir haben eigentlich immer die Standart Sending Cards verwendet, das Ergebnis war rel. gut Mittlerweile ist aber Linsn wohl kaum mehr uf dem Markt üblich, NovaStar das gebräuchliche Produkt, liegt wohl vor allem an der Arroganz von Linsn vor paar Jahren, auf des Kunden Meinung zu hören Wenn Du Dir was basteln willst, besorg Dir eine Sending Card und spiele per DVI zu, damit wirst auf Dauer glücklicher
die Sturheit hat sich ausgezahlt, es funktioniert :) :) Grund war lediglich der Netzwerkadapter. Heute startete ich einen neuen Verscuh mit dem mittlerweile fünften Computer. Dieser hat ein Asus Board mit einem Realtek Netzwerkadapter verbaut. Bei diesem hat es eigetnlich auf Anhieb geklappt und funktioniert seither relativ zuverlässig und flüssig. Im Video kommen leider die Farben nicht richtig zur Geltung. Bis auf die insgesamt 12 Pixelfehler bin ich eingetlich sehr begeistert. Torsten C. schrieb: > ixelfehler können bei Billig-China-Ware immer sein. Ich habe 100 > Ersatz-Treiber, ein paar LEDs und einen Lötkolben für einen solchen > Fall. ich hatte noch keine Zeit um zu kontrollieren ob die Treiber oder die Leds selbst defekt sind. Welche Erfahrung hast du gemacht, kann man tendenziel auf das eine oder andere tippen?
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.