Ethernet-Protokoll für LED-Controller "Linsn"?

[Frank E. (Firma: Q3) (qualidat)]

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.

[Rufus Τ. F. (rufus)]

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

[Frank E. (Firma: Q3) (qualidat)]

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.

[Otto (Gast)]

Versuch doch mal ob du den Datentransfer mittels Wireshark oder 
ähnlichem mitschneiden kannst.

[Frank E. (Firma: Q3) (qualidat)]

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.

[Forumler (Gast)]

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".

[Frank E. (Firma: Q3) (qualidat)]

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 ...

[Frank E. (Firma: Q3) (qualidat)]

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 K. (fchk)]

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

[Torsten C. (torsten_c)]

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.

[Frank E. (Firma: Q3) (qualidat)]

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 E. (Firma: Q3) (qualidat)]

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.

[Frank E. (Firma: Q3) (qualidat)]

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 
...

[bluppdidupp (Gast)]

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.

[Torsten C. (torsten_c)]

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?

[Frank E. (Firma: Q3) (qualidat)]

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! :-)

[Torsten C. (torsten_c)]

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.

[Frank E. (Firma: Q3) (qualidat)]

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 ...

[Frank E. (Firma: Q3) (qualidat)]

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?

[Frank E. (Firma: Q3) (qualidat)]

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.

#include <SPI.h>
#include <Ethernet.h>
#include <utility/w5100.h>

SOCKET s; // our socket that will be opened in RAW mode
byte buf[1500]; // buffer to send through socket
int cnt=0;
int pak=0;

void setup()
{
  // initialize the w5100 chip and open a RAW socket  
  W5100.init();
  W5100.writeSnMR(s, SnMR::MACRAW); 
  W5100.execCmdSn(s, Sock_OPEN);
  Serial.begin(115200);
  delay(100);
}

void loop()
{  
  if (cnt<1500)
  {
    if (Serial.available()>0)
    {
      buf[cnt]=Serial.read();
      cnt++;
    }
    else
    {
      Serial.println(cnt);
      delay(100);
    }
   
  }
  else
  {
    cnt=0;
    pak++;
    Serial.println("."+pak);
    W5100.send_data_processing(s, buf, 1500);
    W5100.execCmdSn(s, Sock_SEND_MAC);
  }
}

[Besucher (Gast)]

> "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.

[Frank E. (Firma: Q3) (qualidat)]

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 ...

[nosilent (Gast)]

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.

[nosilent (Gast)]

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.

[Frank E. (Firma: Q3) (qualidat)]

> 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.

[nosilent (Gast)]

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.

[Frank E. (Firma: Q3) (qualidat)]

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 ...

[Frank E. (Firma: Q3) (qualidat)]

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.

[Torsten C. (torsten_c)]

@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 ❸?

[nosilent (Gast)]

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).

[Torsten C. (torsten_c)]

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?

[nosilent (Gast)]

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.

[Torsten C. (torsten_c)]

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.

[nosilent (Gast)]

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, ...).

[nosilent (Gast)]

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).

[nosilent (Gast)]

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.

[Frank E. (Firma: Q3) (qualidat)]

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 (Gast)]

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.

[Torsten C. (torsten_c)]

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.

[nosilent (Gast)]

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.

[nosilent (Gast)]

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.

[nosilent (Gast)]

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.

[Torsten C. (torsten_c)]

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!

[Frank E. (Firma: Q3) (qualidat)]

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 ...

#include <SPI.h>        
#include <Ethernet.h>
#include <EthernetUdp.h>
#include <utility/w5100.h>

#define UDP_TX_PACKET_MAX_SIZE 1486

byte mac[] = {0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0x01};
IPAddress ip(192, 168,200,177);
EthernetUDP Udp;
SOCKET rs; // rawsocket
byte buffer[UDP_TX_PACKET_MAX_SIZE]; // buffer to send through socket


void setup()
{
  W5100.init();
  W5100.writeSnMR(rs, SnMR::MACRAW); 
  W5100.execCmdSn(rs, Sock_OPEN);
  Ethernet.begin(mac,ip);
  Udp.begin(8888);
}

void loop()
{  
  if(Udp.parsePacket())
  
  {
    Udp.read(buffer,UDP_TX_PACKET_MAX_SIZE);
    W5100.send_data_processing(rs, buffer,UDP_TX_PACKET_MAX_SIZE);
    W5100.execCmdSn(rs, Sock_SEND_MAC);
  }
  delay(1);
}

[Frank E. (Firma: Q3) (qualidat)]

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.

[Frank E. (Firma: Q3) (qualidat)]

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.

[nosilent (Gast)]

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.

[nosilent (Gast)]

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 (Gast)]

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 (Gast)]

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.

[nosilent (Gast)]

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.

[Frank E. (Firma: Q3) (qualidat)]

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?

[nosilent (Gast)]

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

[nosilent (Gast)]

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 (Gast)]

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.

[Torsten C. (torsten_c)]

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.

[nosilent (Gast)]

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)

[nosilent (Gast)]

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).

[Torsten C. (torsten_c)]

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:

$$\frac{1}{10MHz} \times 160 \times 8 = 128 \mu s$$

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:

$$\frac{128 \mu s}{33.3ms} = 0,384%$$

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.

[Torsten C. (torsten_c)]

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.

[Frank E. (Firma: Q3) (qualidat)]

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.

[Frank E. (Firma: Q3) (qualidat)]

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! ...

[nosilent (Gast)]

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.

[nosilent (Gast)]

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.

[Frank E. (Firma: Q3) (qualidat)]

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?

[nosilent (Gast)]

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.

[nosilent (Gast)]

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.

[Frank E. (Firma: Q3) (qualidat)]

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?

[Frank E. (Firma: Q3) (qualidat)]

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 ...

[Torsten C. (torsten_c)]

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 (Gast)]

Wenn es TCP ist, verwende das netcat tool.

[Frank E. (Firma: Q3) (qualidat)]

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.

[Frank E. (Firma: Q3) (qualidat)]

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 ...

[Torsten C. (torsten_c)]

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.

[Torsten C. (torsten_c)]

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.

[nosilent (Gast)]

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.

[Uwe Bonnes (Gast)]

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...

[nosilent (Gast)]

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

[Torsten C. (torsten_c)]

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?

[Uwe Bonnes (Gast)]

Argh. Diese TLAs... :-)

[Frank E. (Firma: Q3) (qualidat)]

@ 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 ...

[Torsten C. (torsten_c)]

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.

[Frank E. (Firma: Q3) (qualidat)]

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 ...

[nosilent (Gast)]

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.

[Frank E. (Firma: Q3) (qualidat)]

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.

[Torsten C. (torsten_c)]

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!

[Frank E. (Firma: Q3) (qualidat)]

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 ...

[nosilent (Gast)]

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.

[Torsten C. (torsten_c)]

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.

[Frank E. (Firma: Q3) (qualidat)]

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.

[Electronic R. (electronic_r)]

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...

[Torsten C. (torsten_c)]

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?

[Frank E. (Firma: Q3) (qualidat)]

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 ...

[Electronic R. (electronic_r)]

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

 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...

[Torsten C. (torsten_c)]

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.

[Psycho Dad (Gast)]

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..

[Torsten C. (torsten_c)]

("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

[Electronic R. (electronic_r)]

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, first make sure your network card is Gigabit Ethernet and whether they are compatible:
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.

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;

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)]].

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

[Heinz (Gast)]

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

[Electronic R. (electronic_r)]

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?