Hallo, ich habe ein Touchscreen, welches einige Daten zwischen dem Raspberry 3b+ austauscht. Ich muss die Daten über eine Strecke von ca. 1,5m...2m übertragen. Ich kenne mich da nicht sehr gut aus, weswegen ich hier im Forum erfahren möchte, wie ich folgende Signale am besten übermitteln kann: 1x SDA (100kHz i2c) 1x SCL (100kHz i2c) 1x Touch-Rückmeldung an Raspberry (100Hz?) 1x LCD-Chip-Rückmeldung an Raspberry (200Hz? azyklisch beim Display-Startup) 1x LCD-Programmdaten (250Hz? azyklisch beim Display-Startup) Wie soll ich die Daten übertragen? Evt. ein LVDS-Paar? Und welches Kabel soll ich dazu verwenden? Danke im Vorraus
SDA und SCL ist bidirektional. Sollte man berücksichtigen.
Manuel N. schrieb: > Wie soll ich die Daten übertragen? Evt. ein LVDS-Paar? Problematisch sind die I2C. Erstens war das nie gedacht für solche Entfernungen (I²C = Inter-Integrated Circuit), sondern für die IC-Kommunikation innerhalb einer Platine. Und zweitens, LVDS geht nicht, denn I2C ist, wie genannt, bidirektional. Was du tun kannst: den niedrigst möglichen PU-Widerstand zu verwenden, der für die ICs noch zulässig ist. Und austesten und messen, bevor eine Platine erstellt wird. Bei den anderen Leitungen sehe ich kein ernsthaftes Problem, wenn man die quellseitige Serienterminierung verwendet und ausreichend Masseleitungen mitführt. Auch hier gilt: aufbauen, messen und die Werte der Serienwiderstände zur Terminierung der verwendeten Leitung und den ICs anpassen.
PittyJ schrieb: > SDA und SCL ist bidirektional. Sollte man berücksichtigen. Okey, angenommen ich nehme eine HDMI-Kabel. Welche Leitungen sollte ich für i2c verenden und welche für LVDS respektive die einzelnen Datenleitungen
Manuel N. schrieb: > Hallo, ich habe ein Touchscreen, welches einige Daten zwischen dem > Raspberry 3b+ austauscht. Sag mal, geht's eigentlich noch? Warum zum Geier machst du zum GLEICHTN Thema jeden Tag einen neue Diskussion auf?
Manuel N. schrieb: > Okey, angenommen ich nehme eine HDMI-Kabel. Welche Leitungen sollte ich > für i2c verenden und welche für LVDS respektive die einzelnen > Datenleitungen Ja vielleicht die, welche bei HDMI schon für I2C bzw. die High Speed Leitungen verwendet werden? Leute gibt's . . . . https://de.wikipedia.org/wiki/High_Definition_Multimedia_Interface#Stecker
Falk B. schrieb: > Warum zum Geier machst du zum GLEICHTN Thema jeden Tag einen neue > Diskussion auf? Ja, ich würde auch sehr empfehlen, für ein und das selbe Problem bei ein und demselben Thread zu bleiben. Das ist jetzt dieser hier. Was bisher geschah: Beitrag "Gegenspieler zum DS90C385A-serializer?" Beitrag "Mehre LVDS-Leitungen nebeneinander, geht das?"
HildeK schrieb: > Problematisch sind die I2C. > Erstens war das nie gedacht für solche Entfernungen (I²C = > Inter-Integrated Circuit), sondern für die IC-Kommunikation innerhalb > einer Platine. das stimmt schon, dennoch ist ein, für I2C reserviertes, Adernpaar fester Bestandteil jeden HDMI (Pin 15 SCL Gelb/Grün, Pin 16 SDA, orange) oder DVI-D (Pin 6 SCL, Pin 7 SDA) Kabels. In der Praxis funktioniert das normalerweise auch über mehr als 2m recht zuverlässig. Bei mir ist die Verbindung zwischen Blueray Player und Beamer 5m + Matrix Switch +1m und das funktioniert problemlos.
Moin. Wie wäre es einfach damit: https://www.ti.com/product/TFP401 Das ist ein DVI auf Parallel Konverter. Damit kannst du ein HDMI Kabel oder HDMI/DVI für das Display nehmen (Von digitaler Audioübertragung habe ich nichts gelesen). (DVI auf deiner Platine da einfacher zu löten) Vorteil: Kabel kannst du kaufen. Auf RPi Seite gibt es schon den Stecker und der kommt damit klar. Auch die Software. Musst nur noch die Displayseite machen. I2C wäre schon mit drinnen zur Datenübertragung. Nachteil: entweder extra EDID EEPROM mit raufbringen und Programmieren (hier liegen die Informationen zu dem Display drinnen [Auflösung, Refresh Rate, usw]) oder fix im RPi per Datei vorgeben. Wie liegen diese Daten denn vor? ================================ 1x Touch-Rückmeldung an Raspberry (100Hz?) --> Kenne ich Hauptsächlich mit I2C mit zusätzlicher Interruptleitung (digital) oder resistive (analog). Resistive könnte man mit extra Chip wahrscheinlich auch didgital hinbekommen und dann wäre es wieder I2C was du schon hast. 1x LCD-Chip-Rückmeldung an Raspberry (200Hz? azyklisch beim Display-Startup) 1x LCD-Programmdaten (250Hz? azyklisch beim Display-Startup)
Moin, Nochmal das Ausgangsproblem: Manuel N. schrieb: > Hallo, ich habe ein Touchscreen, welches einige Daten zwischen dem > Raspberry 3b+ austauscht. Ich muss die Daten über eine Strecke von ca. > 1,5m...2m übertragen. Wie waer's denn, wenn du einfach den ollen Raspberry direkt an's Display flanschst und alles andere, was jetzt direkt am Raspberry haengt, 1.5m..2m verlaengerst? Gruss WK
Eventuell wäre das so hier etwas für dich, da die Leiterplatte schon fertig ist und damit nur ein Kabeladapter hergestellt werden müsste. https://learn.adafruit.com/adafruit-tfp401-hdmi-slash-dvi-decoder-to-40-pin-ttl-display Nur schnell mal geschaut. Eventuell wo anders günstiger. https://www.ebay.de/itm/114263452098 https://www.ebay.de/itm/174393625138 Dergute W. schrieb: > Wie waer's denn, wenn du einfach den ollen Raspberry direkt an's Display > flanschst und alles andere, was jetzt direkt am Raspberry haengt, > 1.5m..2m verlaengerst? Ich frage mich sowieso schon woher er die parallelen Videodaten beim RPi herbekommt. Der hat so erstmal doch keine. Da muss doch immer der Umweg über den HDMI Ausgang, oder liege ich falsch?
:
Bearbeitet durch User
Manuel N. schrieb: > Hallo, ich habe ein Touchscreen, welches einige Daten zwischen dem > Raspberry 3b+ austauscht. Ich muss die Daten über eine Strecke von ca. > 1,5m...2m übertragen. Ich kenne mich da nicht sehr gut aus, weswegen ich > hier im Forum erfahren möchte, wie ich folgende Signale am besten > übermitteln kann: Bei etlichen Versendern gibt es fertige Displays mit HDMI-Eingang plus USB für Touch. Beispiel: https://www.amazon.de/dp/B07FDYXPT7 Nimm sowas. Alles andere wird mit Sicherheit teurer, und es ist fast idiotensicher. fchk
Beitrag #7076102 wurde vom Autor gelöscht.
Hallo, ich möchte von meinem Raspberry Pi ein RGB666 Signal mittels LVDS über eine Strecke von ca. 1 bis 2 Meter an ein Touchscreen übertragen. Das Clock-Signal beträgt ca. 25MHz und als Kabel verwende ich das offizielle Raspberry Pi HDMI auf micro HDMI Kabel. Das RGB666 Signal wird an den GPIO's ausgegeben. Von Dort möchte ich die Signale auf ein PCB führen und dann mittels einem LVDS-Transmitter die Daten von RGB666 nach LVDS "serialisieren". Auf der Displayseite "deserialisiere" ich die LVDS daten wieder nach RGB666 und gehe so auf das Touchscreen. Mein geplanter LVDS-Transmitter: MS90C385B Mein geplanter LVDS-Receiver: MS90C386B Gemäss Receiver-Datenblatt soll die Impedanz zwischen 30 und 100Ohm sein. Genügt es, ganz platt einen 100Ohm Widerstand zu nehmen? Was müsste ich ausrechnen, damit ich die Impedanz genauer bestimmen kann? Wieso wird etwas zwischen 30 und 100Ohm angegeben und von was ist dieser Wert abhängig? Auf dem Datenblatt des Transmitters sind Beispielfrequenzen das Clocksignals aufgeführt. Ist nur eine zulässig, welche auch aufgeführt ist? Oder passt sich der Transmitter und demnach auch der Receiver dem angelegten Clocksignal an? Die Minimale Frequenz des Clocksignals beträgt gemäss Datenblatt 20MHz. Was passiert wenn ich darunter wäre? Der Receiver kann bis zu 1.4W Leistung aufnehmen. Sind meiner Meinung nach extrem viel! Wie kommen solche Werte zustande? Ich habe einige Eingangssignale am LVDS-Transmitter & Receiver übrig. Kann ich theoretisch auch "normale" digitale Signale übertragen? Also solche Signale, welche sich nicht dynamisch mit den RGB666 werten mitändern? Ich hätte da konkret an ein PWM-Signal für die Dimmung einer einzelnen LED gedacht. Müsste ich auf der Receiverseite das Spannungssignal für die LED verstärken? Oder kann ich direkt die Spannung welche am Ausgang des Receivers anliegt auf die LED führen? Auf welche Dinge sollte ich bei der Verwendung dieser LVDS-Technologie achten? Habe gehört, dass die Leitungen möglichst gleich lange und parallel verlaufen sollen. Zudem sollte die Impedanz möglichst nahe am Receiver sein, richtig? Was wäre die Wirkung bei Nichteinhaltung solcher Regeln? Wieviel Beachtung sollte ich diesen Regeln schenken? Wie verhält sich das ganze bei höheren Übertragungsraten? Ich bin ja ziemlich am unteren Ende. Danke für zahlreiche Antworten
Manuel N. schrieb im Beitrag #7076102: > Hi, sorry. Hab nen neuen Thread gemacht für das selbe Problem. Wäre nett > wenn mit trotzdem jemand helfen könnte. Danke Dir wurden schon viele, wertvolle Vorschläge gemacht. Warum willst du das krampfhaft vom IC auf selber bauen? Das wird nicht nur teurer, es wird auch VIEL Arbeit. Und bei deinen Vorkenntnissen bezweifle ich, daß du es überhaupt schaffst. Nimm diese Lösung und gut. Beitrag "Re: Wie übertrage ich meine Signal am besten?"
> Dir wurden schon viele, wertvolle Vorschläge gemacht. Warum willst du > das krampfhaft vom IC auf selber bauen? Das wird nicht nur teurer, es > wird auch VIEL Arbeit. Und bei deinen Vorkenntnissen bezweifle ich, daß > du es überhaupt schaffst. Nimm diese Lösung und gut. > folgendes Problem: Ich möchte eine Platine designen und bei JLCPCB bestellen. Deshalb bin ich von der Wahl der Bauteile ein wenig beschränkt. (TFP401 geht nicht) Das ganze soll ein Heimautomationssystem werden und ich habe nicht unbegrenzt platz. Aus diesem Grund möchte ich auf das Hyperpixel 4.0 vom Pimoroni zurückgreifen. Es ist sehr schmal und hat eine hochwertige Bildqualität.
Manuel N. schrieb: >> Dir wurden schon viele, wertvolle Vorschläge gemacht. Warum willst du >> das krampfhaft vom IC auf selber bauen? Das wird nicht nur teurer, es >> wird auch VIEL Arbeit. Und bei deinen Vorkenntnissen bezweifle ich, daß >> du es überhaupt schaffst. Nimm diese Lösung und gut. >> > > folgendes Problem: > Ich möchte eine Platine designen und bei JLCPCB bestellen. Deshalb bin > ich von der Wahl der Bauteile ein wenig beschränkt. (TFP401 geht nicht) > Das ganze soll ein Heimautomationssystem werden und ich habe nicht > unbegrenzt platz. Aus diesem Grund möchte ich auf das Hyperpixel 4.0 vom > Pimoroni zurückgreifen. Es ist sehr schmal und hat eine hochwertige > Bildqualität. Kannst Du noch 0.3" Diagonale hinzugeben? Dann kannst Du das hier z.B. nehmen: https://www.buydisplay.com/ips-tft-4-3-inch-display-raspberry-pi-w-usb-touch-panel-800x480-hdmi Oder das hier: https://www.buydisplay.com/4-3-inch-800x480-raspberry-pi-touch-screen-tft-lcd-display-hdmi-board Vergiss den Selbstbau. Sorry, das wird so nichts. Nicht so, wie Du fragst. fchk
> > https://www.buydisplay.com/ips-tft-4-3-inch-display-raspberry-pi-w-usb-touch-panel-800x480-hdmi > > Oder das hier: > > https://www.buydisplay.com/4-3-inch-800x480-raspberry-pi-touch-screen-tft-lcd-display-hdmi-board > > Vergiss den Selbstbau. Sorry, das wird so nichts. Nicht so, wie Du > fragst. > Gehen beide nicht. Mein Display ist wirklich komplett ausgereizt von der Grösse. Ich möchte immer noch meinen Weg mit dem LVDS-Signal gehen. Ich würde mich trotz allem sehr über einige Antworten zu meinen Fragen freuen.
Moin, Auweia, das wird nix. Aber nur zu... Manuel N. schrieb: > Gemäss Receiver-Datenblatt soll die Impedanz zwischen 30 und 100Ohm > sein. Genügt es, ganz platt einen 100Ohm Widerstand zu nehmen? Wenn der nicht im Receiver integriert ist, dann brauchst du jeweils einen externen Widerstand. > Was > müsste ich ausrechnen, damit ich die Impedanz genauer bestimmen kann? Die Geometrie und EpsilonR deiner Leitungen bestimmen den tatsaechlichen Wellenwiderstand. > Wieso wird etwas zwischen 30 und 100Ohm angegeben und von was ist dieser > Wert abhängig? Von deinen Leitungen. Dieser Widerstand muss auch nicht 100% exakt stimmen. > Auf dem Datenblatt des Transmitters sind Beispielfrequenzen das > Clocksignals aufgeführt. Ist nur eine zulässig, welche auch aufgeführt > ist? Oder passt sich der Transmitter und demnach auch der Receiver dem > angelegten Clocksignal an? Vermutlich werden die PLLs auf alle Frequenzen innerhalb min und max. locken koennen. > > Die Minimale Frequenz des Clocksignals beträgt gemäss Datenblatt 20MHz. > Was passiert wenn ich darunter wäre? Die PLL wird nicht zuverlaessig locken. > Der Receiver kann bis zu 1.4W Leistung aufnehmen. Sind meiner Meinung > nach extrem viel! Wie kommen solche Werte zustande? Max. Temperatur, die der Halbleiter abkann in Tateinheit mit der Waermeabfuhr ueber Gehaeuse in PCB und Umgebung. > Ich habe einige Eingangssignale am LVDS-Transmitter & Receiver übrig. > Kann ich theoretisch auch "normale" digitale Signale übertragen? Also > solche Signale, welche sich nicht dynamisch mit den RGB666 werten > mitändern? Mutig, aber vielleicht nicht komplett ausgeschlossen. > Ich hätte da konkret an ein PWM-Signal für die Dimmung einer > einzelnen LED gedacht. Müsste ich auf der Receiverseite das > Spannungssignal für die LED verstärken? Oder kann ich direkt die > Spannung welche am Ausgang des Receivers anliegt auf die LED führen? Guck, was die Ausgangstreiber des Chips treiben koennen. Aber das Signal wird nicht unterbrechungsfrei uebertragen werden. In den Blankingphasen wuerd' ich mich z.b. nicht drauf verlassen. > > Auf welche Dinge sollte ich bei der Verwendung dieser LVDS-Technologie > achten? Habe gehört, dass die Leitungen möglichst gleich lange und > parallel verlaufen sollen. Zudem sollte die Impedanz möglichst nahe am > Receiver sein, richtig? Die Abschlussimpedanz, richtig. Die Leitungen sollten auch ungefaehr diese Impedanz aufweisen. Und nicht zuviel Nebensprechen untereinander haben. > Was wäre die Wirkung bei Nichteinhaltung solcher > Regeln? 's dud net, oder sieht kagge aus. > Wieviel Beachtung sollte ich diesen Regeln schenken? Naja, die werden solche Regeln nicht aus Spass an der Freud aufstellen. > > Wie verhält sich das ganze bei höheren Übertragungsraten? Ich bin ja > ziemlich am unteren Ende. Wird immer unangenehmer, das dann ans funktionieren zu bringen. Versauf das Geld lieber, da haste echt mehr davon. Ohne Scheiss. Gruss WK
> >> Ich habe einige Eingangssignale am LVDS-Transmitter & Receiver übrig. >> Kann ich theoretisch auch "normale" digitale Signale übertragen? Also >> solche Signale, welche sich nicht dynamisch mit den RGB666 werten >> mitändern? > Mutig, aber vielleicht nicht komplett ausgeschlossen. Habe ich dich richtig verstanden, dass das Signal übertragen werden kann, jedoch wahrscheinlich nicht unterbrechungsfrei? Kann das auch zu Problemen an den anderen Datenleitungen führen? Also nach dem Motto, dass ein fremdes Signal vorhanden ist, welches nicht zum Rest passt.
Moin, Ich hab' keine Ahnung; die Datenblaetter sind ja nicht besonders umfassend. Ich wuerde mich aber z.b. nicht blind drauf verlassen, dass die Pixeldaten alle richtig uebertragen werden, wenn z.b. DE inaktiv ist. Probier's aus. Gruss WK
Manuel N. schrieb: > ich habe ein Touchscreen, welches einige Daten zwischen dem > Raspberry 3b+ austauscht. Ich muss die Daten über eine Strecke von ca. > 1,5m...2m übertragen. Nimm einen zweiten Raspi direkt am Display und lass die beiden über LAN oder WLAN kommunizieren.
Moin, Bernd schrieb: > Nimm einen zweiten Raspi direkt am Display und lass die beiden über LAN > oder WLAN kommunizieren. Vieeel zu einfach und erfolgversprechend. Und geht nicht. Aus Gruenden. scnr, WK
> Vieeel zu einfach und erfolgversprechend. Und geht nicht. Aus Gruenden.
exakt... Das Display darf eine gewisse Dicke nicht überschreiten. Wäre
zusammmengesteckt(Display auf Raspberry zu dick). rundherum habe ich
auch keinen Platz für den Raspberry.
Habe nochmals einige Fragen bezüglich LVDS-Signal:
Die ganze Strecke von Raspberry GPIO's welche RGB666 ausgeben, bis zum
HDMI-Anschluss wo ich mein LVDS abgreifen möchte, beträgt ca.
8centimeter.
Ich nehme an, es wäre besser, wenn das RGB666 Signal möglichst schnell
nach LVDS gewandelt wird oder?...und die Mehrheit dieser 8cm als LVDS
Signal bis zum HDMI-Anschluss gehen, oder?
Ist es richtig, dass das Display-Enable Signal taktet? Ist dieses auch
für das Blanking zuständig?
Im Datenblatt der LVDS-Chips steht, dass 4 "control lines" übertragen
werden könnnen. HSYNC,VSYNC,DisplayEnable & CNTL. Für was steht CNTL??
Und brauch ich das CNTL?
Ist es richtig, dass bei längeren Leitungen der LVDS-Widerstand kleiner
sein muss? Gibt es da so eine Faustregel für die Errechnung? Habe im
Internet etwas von 133Ohm Kabelimpedanz gelesen und dieses Resultat
ebenfalls mathematisch bekommen. Bringt mir das etwas?
Danke
Moin, Manuel N. schrieb: > Die ganze Strecke von Raspberry GPIO's welche RGB666 ausgeben, bis zum > HDMI-Anschluss wo ich mein LVDS abgreifen möchte, beträgt ca. > 8centimeter. > Ich nehme an, es wäre besser, wenn das RGB666 Signal möglichst schnell > nach LVDS gewandelt wird oder?...und die Mehrheit dieser 8cm als LVDS > Signal bis zum HDMI-Anschluss gehen, oder? Es geht nicht um moeglichst schnell oder kurz oder sowas. Es geht um Signalintegritaet. Die kann man (also du eher nicht) wahrscheinlich in solchen Anwendungen auch Single ended hinkriegen. Aber was hat da jetzt HDMI wieder ploetzlich damit zu tun? > Ist es richtig, dass das Display-Enable Signal taktet? Ist dieses auch > für das Blanking zuständig? Das ist ein Signal, was dem Austastsignal im Analogen enspricht - hier ist es eine Unterscheidung ob gerade sichtbare Pixel uebertragen werden oder nicht. > Im Datenblatt der LVDS-Chips steht, dass 4 "control lines" übertragen > werden könnnen. HSYNC,VSYNC,DisplayEnable & CNTL. Für was steht CNTL?? > Und brauch ich das CNTL? In dem von den Chips unterstuetzten 4 Lane LVDS werden 28 bit zu einer Sequenz zusammengefasst (7 clkcyles x 4 lanes). Fuer 3x8 bit RGB brauchts nur 24 bit. Also hat man 4 bit Platz. In denen wird H,V und DE uebertragen. Dann bleibt noch eines uebrig: CTRL. Ich hab' noch nicht erlebt, dass da was sinnvolles drinnensteht, aber mein Horizont ist da nicht sehr weit. > Ist es richtig, dass bei längeren Leitungen der LVDS-Widerstand kleiner > sein muss? Gibt es da so eine Faustregel für die Errechnung? Habe im > Internet etwas von 133Ohm Kabelimpedanz gelesen und dieses Resultat > ebenfalls mathematisch bekommen. Bringt mir das etwas? Eine Leitung hat einen Wellenwiderstand. Mit Glueck ist der in dem interessanten Frequenzbereich einigermassen konstant. Der Wellenwiderstand der Leitung ist von allem Moeglichen, aber nicht von deren Laenge abhaengig. Und wiegesagt: Der muss auch nicht 100% stimmen. Im Datenblatt des LVDS-Tx seh' ich so auf Anhieb auch nix davon, welche Impedanz die Treiber aufweisen. Das ganze hat echt was davon, jemanden mit Vollgas auf eine Betonwand rasen zu sehen. Du kannst zwar bruellen, dass jetzt Bremsen eine gute Idee waere, aber der Fahrer ist sich ganz sicher, dass "Vollgas auf Betonwand" der einzig moegliche Kurs ist und sich die Betonwand kurz vor dem Aufprall magisch in Luft verwandelt... Gruss WK
Angehängte Dateien:
-
Receiver.PNG
55 KB -
Transmitter.PNG
52 KB
Hallo, ich melde mich mal wieder. Habe es nun die RGB666 nach LVDS transmitter&receiver zuhause. Leider habe ich es bis jetzt nicht hingekriegt, die Daten erfolgreich über LVDS zu übertragen. Komischerweise messe ich auf der Receiverseite auf jedem Channel 0V... Im Anhang die Schemaausschnitte aus dem Transmitter MS90C385 und receiver MS90C386, ich wäre sehr froh, wenn mir jemand behilflich sein könnte. Gemäss aktuellem Stand hätte ich das Geld wirklich lieber versaufen sollen... P.S. Habe beim PCB-Design sehr auf kurze Leitungen geachtet, welche Parallel und möglichst mit viel Abstand verlaufen. Danke
Manuel N. schrieb: > Hallo, ich habe ein Touchscreen, welches einige Daten zwischen dem > Raspberry 3b+ austauscht. Ich muss die Daten über eine Strecke von ca. > 1,5m...2m übertragen. Ich kenne mich da nicht sehr gut aus, weswegen ich Merkt man an der Sprach"begabung". Zwischen dem RasPi3b+ und was? Ein "Touchscreen" 2 Nümmerchen grösser ist locker auch aus 1.5 ..2m Entfernung ablesbar. Optisch. Drahtlos. Lizenzfrei. Watt wollnse meer? SCNR
Moin, Manuel N. schrieb: > Leider > habe ich es bis jetzt nicht hingekriegt, die Daten erfolgreich über LVDS > zu übertragen. Huch, welch' eine Ueberraschung... Kannste denn auf den Eingaengen des Transmitters z.b. gutmuetige Signale, wie die Syncs oder DE messen? Wenn ja, kannst du die auf der LVDS Seite noch messen, der Pegel ist da halt kleiner, das LV in LVDS steht ja nicht zum Spass da - aber messen kann man's mit nem Scope schon noch, Sind da Terminierungs-Rs am Receiver? Zeig' mal die tatsaechlichen Layouts und kompletten Schaltplaene. Wahrscheinlich ist's auch keine so gute Idee, die verschiedenen Geschmacksrichtungen von VCC der ICs (z.v. IOVCC, PLLVCC, ...VCC) stumpf und ohne z.b. Ferritbeads zusammenzuklemmen. Gruss WK
Angehängte Dateien:
-
127_127_127.jpg
230 KB -
128_128_128.jpg
200 KB
Habe es nun doch noch mehr oder weniger zum laufen gebracht Hehe;) Der Fehler lag daran, dass aus meiner Schaltung ein Widerstand nicht ins PCB-Design mitgenommen wurde. Folglich hat der "Power-Down"-Pin gefloatet und wurde nicht auf VCC gezogen. Das Bild wird dargestellt und die Pixel sind aus meiner Sicht am richtigen Ort. Problem ist nun, dass ich in der unteren Bildschirmhälfte einen ca. 1.5cm hohen Balken habe, welcher über die ganze Bildschirmbreite teilweise ein wenig flackert. Die Pixel darin scheinen jedoch i.O. zu sein. An was könnte das liegen? Ein weiteres Problem ist, dass die Farben ein wenig krumm dargestellt werden. Habe einen RGB-Farbkreis genommen und festgestellt, dass wenn ich den R-G- oder B-Anteil von der Wertigkeit 127 auf 128 erhöhe, die Farbintensität sich nicht um ein Wert erhöht, sondern auf Null fällt. Scheint mir irgendwie so, dass ich die einzelnen Bits von der Wertigkeit ein wenig vertauscht habe, liege ich richtig in dieser Annahme? Habe folgenden Farbkreis verwendet: http://www.spectrumcolors.de/cor_rgb_demo.php Habe im Anhang ein Bild mit RGB auf 127:127:127 und 128:128:128 zum vergleichen. 127:127:127 sieht i.O. aus, 128:128:128 sollte da schon etwas anderes Darstellen...
Moin, Dadurch, dass du dir halt alle Klabusterbeeren einzlen aus der Nase ziehen laesst, und z.b. nur Auschnitte von Schaltbildern, die nix mit der Realitaet zu tun haben muessen, zeigst, machst du's nicht grad einfacher... Wenn du von 8bit pro Farbe auf 6bit reduzierst, wirds sinnvoll sein, auch die richtigen 2 bit wegzulassen: von 127 (bunt) auf 128 (schwarz) koennt man ja fast auf die Idee kommen, dass du das MSB weglaesst. Gruss WK
Ich würde erstmal anhand einfarbiger Muster testen, ob die Bits überhaupt ankommen.
Manuel N. schrieb: > Das Bild wird dargestellt und die Pixel sind aus meiner Sicht am > richtigen Ort. Naja. Deine Bilder sehen sehr griesig und verwaschen aus. Entweder hast du das sehr schlecht photographiert oder das Bild ist wirklich so. Das Sieht nach einer leicht gestörten Übertragung aus. Vermutlich durch ei ungünstiges Layout und Leitungsführung oder fehlende bzw. falsch platzierte Entkoppelkondensatoren. Zeig mal deine Layouts. > Problem ist nun, dass ich in der unteren Bildschirmhälfte > einen ca. 1.5cm hohen Balken habe, welcher über die ganze > Bildschirmbreite teilweise ein wenig flackert. Die Pixel darin scheinen > jedoch i.O. zu sein. An was könnte das liegen? Siehe oben. > Scheint mir irgendwie so, dass ich die einzelnen Bits von der Wertigkeit > ein wenig vertauscht habe, liege ich richtig in dieser Annahme? Scheint so. Nutze verschiedene Testbilder, z.B. Farbtreppen in RGB, die von 0x00 bis 0xFF laufen. Ebenso Linien und Schachbrettmuster.
Manuel N. schrieb: > Das Bild wird dargestellt Für mich sieht das auch nach analogen Problemen aus. Ändert sich die Darstellung, wenn du das (hoffentlich paarweise verseilte) Kabel anders verlegst oder die Hand auf die Platine/Leitung auflegst oder das Kabel mit der Hand umschließt? Hast du auf der Senderseite auch Terminierungswiderstände? Wo sind die jeweils platziert? Schon direkt an den IC-Pins? Hast du die vielen Blockkondensatoren hübsch angeschlossen? Manuel N. schrieb: > Habe beim PCB-Design sehr auf kurze Leitungen geachtet Zeig doch mal...
Lothar M. schrieb: > Hast du auf der Senderseite auch Terminierungswiderstände? Wo sind die > jeweils platziert? Schon direkt an den IC-Pins? Hast du die vielen > Blockkondensatoren hübsch angeschlossen? Mit Schleifchen? ;-) Die Kombination aus 100, 10 und 1nF ist Schmarrn, aber die Diskussion hatten wir schon dutzendfach.
Manuel N. schrieb: > Ein weiteres Problem ist, dass die Farben ein wenig krumm dargestellt > werden. Habe einen RGB-Farbkreis genommen und festgestellt, dass wenn > ich den R-G- oder B-Anteil von der Wertigkeit 127 auf 128 erhöhe, die > Farbintensität sich nicht um ein Wert erhöht, sondern auf Null fällt. Hattest du nicht was von 6 Bit geschrieben? Die gehen nur bis 63. Wenn alle Bits darüber wegfallen, wird aus 127 eben 63, also maximale Helligkeit, aus 128 wird 0.
:
Bearbeitet durch User
Rolf M. schrieb: > Hattest du nicht was von 6 Bit geschrieben? Die gehen nur bis 63. > Wenn alle Bits darüber wegfallen, wird aus 127 eben 63, also maximale > Helligkeit, aus 128 wird 0. Nö. Wenn man ein RGB666 Display an einen RGB888 Ausgang anschließt, klemmt man die Bits 2-7 vom Ausgang an die Eingänge 0-5. Man verliert die untersten 2 LSB und damit die Auflösung, aber der Maximalwert von 255 (Sender) wird zum Maximalwert 63 am LCD. Es gibt KEINE Überläufe, wenn man es richtig macht. Eine einfache Farbbalkentreppe aus 8 Stufen mit den Werten 0,1,2,4,8,16,32,64,128 jeweils einzeln für RGB zeigt sofort, was los ist.
Falk B. schrieb: > Man verliert die untersten 2 LSB und damit die Auflösung Das passt, wenn man auf der Senderseite ein RGB666 Signal an einen RGB888 Sender anschließt und ein 24-Bit LVDS Display hat. Wenn man aber einen RGB888 Sender hat und ein 18-Bit LVDS Display anschleißen will, dann klemmt man die Finger ein, weil auf den LVDS-Lanes 0..2 die 666 Signale sind und auf der LDVS Lane 3 die zusätzlichen MSB(!!) des 888 Signals kommt. Man kann also kein 18-Bit LVDS-Display an einen 24-Bit LVDS Sender anschließen, ohne die oben beobachteten Farbeffekte zu bekommen.
Moin, Lothar M. schrieb: > und auf der LDVS Lane 3 die > zusätzlichen MSB(!!) des 888 Signals kommt. Ja, wenn man kacke baut, ist das so. > Man kann also kein 18-Bit > LVDS-Display an einen 24-Bit LVDS Sender anschließen, ohne die oben > beobachteten Farbeffekte zu bekommen. Wenn man's richtig macht, geht das genau so. Die auf den ersten Blick wirre Zuordnung der bits auf die Lanes wird dann sinnvoll (also jeweils die 2 /L/SBs von R,G,B auf Lane 3). Gruss WK
Angehängte Dateien:
-
RGB-Balken.png
1017 Bytes
Lothar M. schrieb: > Falk B. schrieb: >> Man verliert die untersten 2 LSB und damit die Auflösung > Das passt, wenn man auf der Senderseite ein RGB666 Signal an einen > RGB888 Sender anschließt und ein 24-Bit LVDS Display hat. > > Wenn man aber einen RGB888 Sender hat und ein 18-Bit LVDS Display > anschleißen will, dann klemmt man die Finger ein, weil auf den > LVDS-Lanes 0..2 die 666 Signale sind und auf der LDVS Lane 3 die > zusätzlichen MSB(!!) des 888 Signals kommt. Man kann also kein 18-Bit > LVDS-Display an einen 24-Bit LVDS Sender anschließen, ohne die oben > beobachteten Farbeffekte zu bekommen. Versteh ich nicht. Wo soll da das Problem sein? Die beiden ICs sind transparent, 24+4 Bit rein, 24+4 Bit raus. Ob man dann nur RGB888 oder RGB666 am Sender anklemmt ist egal, man muss nur die richtigen Daten am Empfänger anklemmen. Der OP hat ja keinen SERDES im Display sondern als extra IC VOR dem LCD! Also sollte das passen, WENN man die richtigen Signale anschließt.
Die Fehlersuche wird auch durch das unsinnige Symbol der beiden ICs erschwert. Man zeichnet Schaltplansymbole NICHT gemäß der mechanischen Pinbelegung am Gehäuse sondern der LOGISCHEN! https://www.mikrocontroller.net/articles/Schaltplan_richtig_zeichnen Beitrag "Re: eagle Schaltplan Bauteile drehen" Und wie das Layout aussieht, wissen wir auch nicht.
Angehängte Dateien:
Dergute W. schrieb: > Lothar M. schrieb: >> und auf der LDVS Lane 3 die zusätzlichen MSB(!!) des 888 Signals kommt. > Ja, wenn man kacke baut, ist das so. Nein, das ist leider unter den LVDS-Displays weit verbreiter VESA-Standard. > (also jeweils die 2 /L/SBs von R,G,B auf Lane 3). Das entspricht der Definition nach JEIDA, die aber nur von wenigen Displays umgesetzt wird. Wenn du einen 24-Bit LVDS-Sender hast und ein 18-Bit LVDS-Display, dann passiert es dir dir in den allermeisten Fällen, dass die MSB auf der Lane 3 abgeschnitten werden. Falk B. schrieb: > Versteh ich nicht. Wo soll da das Problem sein? Die beiden ICs sind > transparent, 24+4 Bit rein, 24+4 Bit raus. Ob man dann nur RGB888 oder > RGB666 am Sender anklemmt ist egal, man muss nur die richtigen Daten am > Empfänger anklemmen. Das ist der Witz dabei: wenn man es richtig macht, dann geht es. Man sollte eben nur die Fallstricke und die "üblichen" Standards kennen, falls das in irgendeine Richtung kompatibel sein soll. Falk B. schrieb: > man muss nur die richtigen Daten am Empfänger anklemmen. Oder im Fall hier eher am Sender? Denn wenn der Sender RGB888 sendet, davon aber nur die unteren RGB666 angeschlossen sind, weil das Display ja auch nur RGB666 kann, dann gibts natürlich 4 Wrap-Arounds pro Farbe. > Die Fehlersuche So wie ich das sehe, sollten am Sender auch keine Eingänge unbeschaltet mit X, sondern immer mit einem definierten Pegel belegt werden.
Moin, Lothar M. schrieb: > Wenn du einen 24-Bit LVDS-Sender hast und ein 18-Bit LVDS-Display, dann > passiert es dir dir in den allermeisten Fällen, dass die MSB auf der > Lane 3 abgeschnitten werden. Wenn du dir aber LVDS-Sender und -Empfaenger selber baust (was offensichtlich hier der Fall ist) und es dann nicht tut, bist in den allermeisten Faellen nur du selbst verantwortlich... Gruss WK
Moin, Nochwas ganz anderes: Der MS90C385B scheint mir bis max. Pixeltakt 100Mhz zu gehen. Kennt jemand einen aehnlich "dummen" LVDS-Multiplexer/Pegelwandler, der bis >212MHz geht? Damit plus ein billig-FPGA (ohne echte Transceiver) und 4 Leitungstreiber koennt' man evtl. guenstig 4x HD-SDI Ausgaenge bauen... Gruss WK
Angehängte Dateien:
-
PCB_Receiverseite.PNG
120 KB -
PCB_Transmitterseite.PNG
120 KB -
Schematic_Receiver1.PNG
180 KB -
Schematic_Transmitter1.PNG
54 KB -
Schematic_Transmitter2.PNG
130 KB
Hi, habe ausschnitte vom Schema und PCB angefügt. Möchte nur ungern das vollständige Schema preisgeben, welches aus meiner Sicht eh nix mit meinem aktuellem Problem zu tun hat. Habe ein 2-Layer PCB und auf beiden Layern ne groundplane. Aus Ansichtsgründen hab ich die ausgeblendet. Raspberry Pi bringt RGB666 raus und Touchpanel könnte theorethisch RGB888 darstellen. -->die zwei LSB's werden folglich am Touchpanel nicht verwendet. Ich habe jeweils bei einem vielfachen von 4 immer einen sprunghaften ansteig der Farbintensität. Also bei 4,8,12,16,..... Zudem sieht es aus optischer Sicht für mich so aus, als würde von 0...63 die gleiche Farbintensität wie von 64 bis 127 wie von 128 bis 191 und 192 bis 255 herrschen. Also glaube wirklich, dass alle bits um 2 stellen verschoben sind. Was mir ein Rätsel ist, warum im vierschritt der Farbton sprunghaft ändert und nicht regelmässig... Das flackern an einem Teil des Displays geht mit dem Scrollen des Bildes mit. Also wenn es am Displayboden flackert und ich auf einer Webseite runterscrolle verschiebt sich das flackern nach oben. Sprich, das flackern geht mit der Anzeige mit. Das auflegen meiner Hand auf Kabel, Platine, Anschlusspins hat nix mit der Bilddarstellung o.ä. bewirkt. Bin mir nicht ganz sicher ob ich die Antworten von oben richtig interpretiert habe. Aber wenn LVDS-Transmitter und Receiver ein Clocksignal für RGB888 erwarten, der Raspberry Pi aber ein Clocksignal für RGB666 ausgibt könnte es einen "Interpratationsfehler" an LVDS Transmitter und Receiver geben oder? Müsste ich also das Clocksignal für ein RGB888 Signal auf die LVDS-Chips geben damit es keinen Versatz von RGB666 auf RGB888 gibt? Versteht jemand meine Denkweise?? Bin schlecht im erklären von Dingen... Und wenn wir grad schon dabei sind. Warum sind 1,10,100uF-Filter unnütz? Wie wäre denn die bessere Art zu "Filtern"? Danke im Vorraus
Bei den MHz an Pixeltakt, der üblicherweise bei Displays verwendet wird, kannst du die Leiterbahnführung nicht dem Autorouter überlassen. Das sieht ja so schlimm aus wie beim Arduino. Differentielle Signale heißen nicht nur so, weil da + und - dransteht, sondern sie sollten auch gemeinsam geroutet werden. Wenn du die Stützkondensatoren noch etwas weiter weg schiebst und die Leiterbahnen dahin noch etwas dünner machst, haben sie gar keine Funktion mehr... Hier noch zwei Links: https://www.mikrocontroller.net/articles/Richtiges_Designen_von_Platinenlayouts https://docs.toradex.com/101123-apalis-arm-carrier-board-design-guide.pdf
Manuel N. schrieb: > Hi, habe ausschnitte vom Schema und PCB angefügt. Naja, aber als PDF wäre es besser, siehe Bildformate. Hast du mal die Dateien angeschaut? Wer soll da was gescheites erkennen? Und man könnte und SOLLTE den Schaltplan DEUTLICH besser zeichnen! Schaltplan richtig zeichnen Und lass diesen Müll mit dein 1000 Labels! Nimm Busse! Die RGB-Signale nennt man R0-R7, G0-G7, B0-B7, das spart Tipperei und macht die Sache besser lesbar. Und Die Symbole LOGISCH zeichnen, nicht physikalisch wie das Gehäuse! > Möchte nur ungern das > vollständige Schema preisgeben, welches aus meiner Sicht eh nix mit > meinem aktuellem Problem zu tun hat. Habe ein 2-Layer PCB und auf beiden > Layern ne groundplane. Aus Ansichtsgründen hab ich die ausgeblendet. Hää? Wie kann man bei 2 Lagen beidseitig Ein Masselage haben? Die hast du nicht! Du hast nur Masseflecken! Das ist was anderes, die wirken nicht als gescheite Massefläche. > Raspberry Pi bringt RGB666 raus und Touchpanel könnte theorethisch > RGB888 darstellen. -->die zwei LSB's werden folglich am Touchpanel nicht > verwendet. Dann muss man die untersten LSBs am LCD aber auf GND legen. > Ich habe jeweils bei einem vielfachen von 4 immer einen sprunghaften > ansteig der Farbintensität. Also bei 4,8,12,16,..... Zudem sieht es aus > optischer Sicht für mich so aus, als würde von 0...63 die gleiche > Farbintensität wie von 64 bis 127 wie von 128 bis 191 und 192 bis 255 > herrschen. Jaja, schöne Lyrik. Mensch Meier, zeig mal ein gescheites TESTBILD! Ich hab dir ne Vorlage gezeigt! > Also glaube wirklich, dass alle bits um 2 stellen verschoben > sind. Was mir ein Rätsel ist, warum im vierschritt der Farbton > sprunghaft ändert und nicht regelmässig... Mir ist es ein Rätsel, wie das überhaupt halbwegs läuft. > Das flackern an einem Teil des Displays geht mit dem Scrollen des Bildes > mit. Also wenn es am Displayboden flackert und ich auf einer Webseite > runterscrolle verschiebt sich das flackern nach oben. Sprich, das > flackern geht mit der Anzeige mit. Deine Schaltung stört sich selber, was aber kein Wunder ist. > Bin mir nicht ganz sicher ob ich die Antworten von oben richtig > interpretiert habe. Aber wenn LVDS-Transmitter und Receiver ein > Clocksignal für RGB888 erwarten, der Raspberry Pi aber ein Clocksignal > für RGB666 ausgibt könnte es einen "Interpratationsfehler" an LVDS > Transmitter und Receiver geben oder? Nein. > Müsste ich also das Clocksignal für > ein RGB888 Signal auf die LVDS-Chips geben damit es keinen Versatz von > RGB666 auf RGB888 gibt? Versteht jemand meine Denkweise?? Bin schlecht > im erklären von Dingen... Scheint so. Du liegst trotzdem falsch. Der Sender bekommt ein Taktsignal und bis zu 28 Bit parallel. Die verpackt er seriell auf 3 differentielle Datenleitungen + 1 Taktsignal. Der Empfänger macht daraus wieder das Taktsignal und die 28 parallelen Signale. Wie ich schon sagte, das ist transparent. > Und wenn wir grad schon dabei sind. Warum sind 1,10,100uF-Filter unnütz? > Wie wäre denn die bessere Art zu "Filtern"? Erstens sind das nF und NICHT uF und 2. reicht es, wenn man 100nF oder einen ähnlichen Wert in einem halbwegs HF-tauglichen Gehäuse NAH an die ICs packt. 0603 ist dafür OK, aber deine Platzierung und Leitungsführung NICHT! Schau dir C10, C11, C12; C16, C17, C18 beim Reveiver an! Das ist Unfug^3. Aber der IC ist gutmütig genug, daß er irgendwie noch läuft, wenn auch mit Störungen. Diese Kondensatoren müssen NAH an den IC, so 5mm oder weniger! Es ist auch genug Platz, vor allem wenn man die 10 und 1nF wegläßt und dort einfach 100 oder 220nF platziert. Und zwar an JEDEN VCC Pin ein Kondensator! https://www.mikrocontroller.net/articles/Kondensator#Entkoppelkondensator Das 2. große Problem sind deine "Masseflächen" https://www.mikrocontroller.net/articles/Richtiges_Designen_von_Platinenlayouts#Vorgehen_bei_der_Layouterstellung Man braucht für so eine Schaltung ein DURCHGEHENDE Massefläche und keine Schnipsel! Das kann man mit VIEL Erfahrung mit 2 Lagen und WENIGEN Leitungen auf der Unterseite hinkriegen, oder man ist "faul" und nimmt gleich eine 4 Lagen Platine, das kann fast jeder. Die Spannung für PLL_VCC könnte auf jeden Fall auch eine Reihendrossel, mindestens eine Ferritperle vertragen, denn sie sollte möglichst störarm sein, dmit die PLL sich bei ihrer Arbeit nicht verschluckt und einen möglichst sauberen Takt generiert. Beim Sender UND Empfänger! Aber bist du komplett irre? Glaubst du ernsthaft, nach ALL den Hinweisen, daß es eine gute Idee ist, den seriellen Tak über sie Signale RESERVED und HOT PLUG Detect zu schicken? Das sind keine HF-tauglichen Leitungen im Kabel! Jaja, ich sehe schon, HDMI hat nur 3 differentielle Datenleitungen und einen differentiellen Takt, deine SerDes halt 4+1. Also falsches Kabel oder falscher Serdes!
Ich frage mich eher warum er die parallel <=> LVDS Chips, USB/HDMI Buchsen usw. löten kann aber nicht den TFP401. Dann könnte er das HDMI Kabel ganz normal verwenden. Und ich gehe davon aus, dass alle RPis das herausgeführt haben. Effektiv ist DVI auch nur LVDS mit einem anderen Seriel-Wandler mit einfacher Kodierung (TMDS). Das macht dir der TFP401 aber alles transparent.
Moin, Falk B. schrieb: > Jaja, ich sehe schon, HDMI hat nur 3 differentielle > Datenleitungen und einen differentiellen Takt, deine SerDes halt 4+1. Wenn man eh' jeweils nur 6 bit RGB ueber LVDS uebertragen will, dann braucht man auch nur 3 Datenlanes, wenn man weiss was man tut. Das ginge sogar zur Not (wenn man wirklich sicher ist, dass da niemand mal versuchen wird "echtes" HDMI ein/auszuspeisen) HF/Impedanzmaessig ueber ein HDMI-Kabel. Ansonsten wuerd' ich mal sagen: Mehr Dusel als Verstand (und anscheindend echt gutmuetige Chipse), dass da ueberhaupt was bildartiges rauskommt. Immerhin. Wieso eigentlich die 10k / 2.2uF Kombi an dem einen Powerdownpin? Ist das so irgendwo in einer echten Applikationsschaltung? Ich haette bei dicken Cs direkt an "normalen" IO-Pins immer etwas Muffesausen, dass wenn beim Ausschalten die IC-Spannungsversorgung recht schnell zusammenbricht, sich dann die 2.2u via chipinterner Diode entladen muessen. Und da hat den Entladestrom keiner mehr im Griff... John-eric K. schrieb: > Ich frage mich eher warum er die parallel <=> LVDS Chips, USB/HDMI > Buchsen usw. löten kann aber nicht den TFP401. Er laesst loeten. Und da wo er loeten laesst, gibts den TFP401 halt nicht. Und ob der Chip jetzt von RuiMeng oder TI ist, macht's beim Rest wirklich nicht mehr fett. Gruss WK
:
Bearbeitet durch User
John-eric K. schrieb: > Ich frage mich eher warum er die parallel <=> LVDS Chips, USB/HDMI > Buchsen usw. löten kann aber nicht den TFP401. Dann könnte er das HDMI > Kabel ganz normal verwenden. Und ich gehe davon aus, dass alle RPis das > herausgeführt haben. Warum einfach, wenn's auch umständlich geht? ;-) https://github.com/adafruit/Adafruit-TFP401-HDMI-To-40Pin-TFT-PCB Das Ding ist fix und fertig. Auch wenn man bei der Pinbelegung am 40pol FFC Kabel die Massen ungünstig gelegt hat.
Manuel N. schrieb: > Warum sind 1,10,100uF-Filter unnütz? So beliebig wie die platziert sind, taugt nicht mal 1 davon irgendwas. > Wie wäre denn die bessere Art zu "Filtern"? Es geht da nicht ums Filtern,sondern darum,dem IC den Sttom für schnelle Umschaltstromspitzen zur Verfügung zu stellen. Mach 1x 10nF kleinstmöglicher Bauart so dicht wie möglich (es geht dsbei um mm) zwischen die Vcc und GND Pins (besonders dann, wenn die gleich paarweise nebeneinander am IC herauskommen). Als Denkanstoß lies die Layouthinweise im Datenblatt und das hier: http://www.lothar-miller.de/s9y/categories/14-Entkopplung Ganz interessant sind auch die dort verlinkten Diskussionen.
Lothar M. schrieb: > Mach 1x 10nF kleinstmöglicher Bauart so dicht wie möglich (es geht dsbei > um mm) zwischen die Vcc und GND Pins (besonders dann, wenn die gleich > paarweise nebeneinander am IC herauskommen). Warum 10nF? Das ist auch nicht so sonderlich prall. Jaja, Resonanzfrequnz und so. Aber am Ende des Tages bzw. des Schaltvorgang braucht es Strom bzw. Ladung. Und da hat ein 100nF Typ deutlich mehr als 10nF. Und im gleichen Gehäuse auch ausreichend niederimpedant. Aber wir wiederholen uns, nicht zum 1. Mal.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.