Hallo Welt, mein Anliegen ist folgendes: Im Rahmen eines Wärmebildkamera-Eigenbaus mit dem FLIR-Lepton 3.5 bin ich momentan am überlegen, welche Darstellungsweise der Datensätze die "einfachste" wäre; hierbei bin ich u.A. auf die Analog-Displays von Adafruit gestoßen (https://www.adafruit.com/product/911). Einige dieser Art habe ich auch bereits erfolgreich im Einsatz, hier zeigen sie den direkt angeschlossenen Stream einer FPV-Analogkamera (sowohl NTSC als auch PAL wird verarbeitet) über eine eindrähtige (mit Masse zweidrähtige) Kabelverbindung. Kurzgesagt gibt es am Screen einen Eingang für das analoge Videosignal - hier künstlich erzeugt von der FPV-Kamera. Die verwendete Wärmebildkamera gibt mit knapp 10fps (ITAR sei Dank...) Frames mit jeweils 160x120 Pixeln aus. Die interne Verarbeitung der Farbwerte vor Anzeige sei hier bewusst vernachlässigt bzw. ergibt sich im Folgenden vielleicht. Meine Idee wäre folgende: Die Daten des Sensors in ein Array werfen (leichter gesagt als getan, aber offtopic) (Als Zwischenspeicher und "Gehirn" soll hier ein STM32 F4[46RET6] herhalten, da rumliegend), und dieses Array dann zyklisch auslesen und als Videostream ausgeben; wo es letztlich den Eingang ins Display findet. Dies ausserdem so platzsparend wie möglich. Und so wenig rechenleistungsintensiv wie möglich. Was man eben so für Ansprüche hat :D Dass das möglich ist, zeigt mir allerdings das genannte System aus FPV-Cam und Bildschirm(treiber): Der CMOS-Kamerasensor selbst leistet wesentlich besser aufgelöste Bilder als die (nominal) ca. 1000 Zeilen die letzlich als Video ausgegeben werden, was darauf schließen lässt, dass eine Umwandlung von "Array"/Frame zu künstlichem Analogsignal stattfindet, und das eben auf engstem Raum innerhalb der Kamera! (Beispielsweise: https://shop.rc-hangar15.de/CADDX-ANT-1200TVL-WDR-Ultra-Light-Nano-FPV-Kamera) Diese Anordnung hätte den Vorteil, dass ich mir das Schreiben eines Bildschirmtreibers sowie dadurch Rechenleistung sparen würde, und mir ausserdem verschiedenste Verarbeitungsweisen des Analogsignals zur Verfügung stehen würden (Analogfunk aus dem Modellflugbereich, Bildaufnahme via DVR, selber Treiber größeres/kleineres Display, ...) Leider Gottes habe ich zur synthetischen Herstellung eines solchen Streams bisher nichts konkretes finden können - und wenn, dann nur für tatsächliche Analoggeräte, was leider doch nicht wirklich vergleichbar ist, da es sich ja nicht wirklich um einen Röhrenbildschirm und zugehörige Elektromechanik handelt. En plus bin ich leider nicht mehr aus der Generation Röhre, und habe ausser der theoretischen Funktionseise noch keinerlei praktische Erfahrungen mit derlei Signalformaten (meint NTSC/PAL/...). Daher die Frage: Auf welche Art und Weise ließe sich so ein Signal ausgehend (fürs Beispiel mal) von einem Standbild in einem Array generieren? Wonach müsste ich suchen, um das NTSC-"Protokoll" (wenn es denn eins gibt) aufschlüsseln zu können? Und wie kann es anscheinend einfach genug sein, um in eine 2 GRAMM (!) Ultraleichtkamera ohne nennenswerte Rechenleistung zu passen? Ich bedanke mich im Voraus für Denkanstöße und erörtere gerne ausführlicher. VG!
:
Verschoben durch Moderator
Moin, Guck' mal im www nach "Repetitorium Fernsehtechnik" von Rudolf Maeusl. Da sind Grundlagen der Fernsehtechnik recht konzentriert beschrieben. Ansonsten ist's gut, wenn der Prozessor irgendwas DMA-artiges hat, um dein "Array" (das Dingens heisst dann Framebuffer) ohne viel Programmierarbeit mit genau dem richtigen Timing ausgeben kann. Oder gar direkt eine entsprechende Videoausgabe-Hardware. Gruss WK
Jan G. schrieb: > Daher die Frage: Auf welche Art und Weise ließe sich so ein Signal > ausgehend (fürs Beispiel mal) von einem Standbild in einem Array > generieren? Wonach müsste ich suchen, um das NTSC-"Protokoll" (wenn es > denn eins gibt) aufschlüsseln zu können? Und wie kann es anscheinend > einfach genug sein, um in eine 2 GRAMM (!) Ultraleichtkamera ohne > nennenswerte Rechenleistung zu passen? Schau mal nach "World´s worst video card" auf YouTube. Was der baut, hat große Ähnlichkeiten mit dem, was dir vorschwebt - allerdings gibt er VGA aus. Du kannst sein Design sicher nicht 1:1 übernehmen, aber als Denkanstoß nehmen. Ansonsten wäre es eine schöne Fingerübung für einen kleinen FPGA, wenn man das schon immer mal machen wollte. Oder auch direkt aus einem µC heraus, ST gibt selbst für einen STM32F042 an, dass der 10 MHz an den GPIOs schafft. Allerdings wird das nur mit DMA klappen, der Rechner dürfte gut mit Datenschaufeln beschäftigt sein. NTSC (wie auch PAL) ist blöd, weil es kein reines Basisbandsignal ist, sondern die Farbinformation auf einen Träger moduliert wird. Und NTSC wird nicht umsonst auch als "Never the same color" gelesen. Bleibe bei VGA oder einem seiner Verwandten wie EGA.
Unter "Worlds worst video card" konnte ich tatsächlich halbwegs fündig werden was einen Suchbegriff angeht (NTSC sync rate oder so ähnlich), welcher mich dann weiter zu Artikeln brachte, die sich tatsächlich wie gesucht mit der Zusammensetzung dieses Signals befassen. Das heißt nicht, dass es einfach ist, aber vielleicht möglich. Insbesondere, wenn man mit Graustufen arbeitet (bei Wärmebild ja nicht soo schlimm). Werde ggf. mal einige dieser Artikel hier verlinken und das Projekt etwas dokumentieren, die ein oder andere Frage tut sich wahrscheinlich sowieso noch auf. Danke bisher! Sollte jemandem noch etwas einfallen oder hinzufügen wollen, bitte nicht zögern!
Jan G. schrieb: > Insbesondere, wenn > man mit Graustufen arbeitet (bei Wärmebild ja nicht soo schlimm). Die diversen Fernsehsignale (NTSC, PAL, SECAM) unterscheiden sich alle nicht bezüglich der S/W-Signale. Der Unterschied liegt lediglich im Transport der Farbinformation. VGA (was im angesprochenen Beitrag verwendet wird) ist mit HSYNC und VSYNC und Schwarzschulter und so weiter recht nahe an das analoge Fernsehsignal angelehnt. Wenn dir ein S/W-Signal reicht, vereinfacht das die Angelegenheit erheblich. War meine Wahl des Faches "Fernsehtechnik" im Hauptstudium vor vielen, vielen Jahren doch nicht ganz sinnlos :) Gruß, Max
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.