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