Hi, ich möchte 2 Fbas (wobei eines auch zu Bas umgewandelt werden kann) zusammen Mischen sodass die Bilder beider Quellen (2 Kameras, ohne Sync Eingang) mit (idealerweise) einer einstellbaren Stärke übereinander gelegt werden. Quasi einen Fader... Dazu muss ich beide Signale nachträglich synchronisieren. Nur finde ich dazu recht wenig. Das ganze wird in einer Drone eingesetzt und sollte demnach kompakt, vom Akku versorgt (4S Lipo ~ 12-17V) und leicht sein. Ein Mischen der Signale auf Empfänger Seite möchte dringend vermeiden um nicht unnötig viele VTX (Video transmitter) Kanäle zu belegen. Kennt evtl jemand nen IC der die Signale Mischen oder zumindest Synchronisieren Kann? Oder hat wer evtl sogar schonmal sowas gemacht und hat evtl Unterlagen die er teilen möchte?
Radio A. schrieb: > Hi, ich möchte 2 Fbas (wobei eines auch zu Bas umgewandelt werden kann) > zusammen Mischen sodass die Bilder beider Quellen (2 Kameras, ohne Sync > Eingang) Dort liegt schon der 1. Fehler. > mit (idealerweise) einer einstellbaren Stärke übereinander > gelegt werden. Quasi einen Fader... Dazu muss ich beide Signale > nachträglich synchronisieren. Nur finde ich dazu recht wenig. Dazu braucht man einen Framegrabber mit 2 Eingängen. Ob es sowas ultrakompakt für Drohnen gibt, weiß ich nicht. FBAS für Kameras ist eigentlich schon ziemlich out, erst recht bei Drohnen. Mit digitalen Kameras geht das deutlich einfacher und ist an sich Stand der Technik. Denn die meisten (alle?) Drohnen arbeiten und funken so oder so digital.
Sowas macht(e) man eigentlich in der analogen Videowelt immer dadurch, dass man die Kameras miteinander synct. Wenn es keinen SYNC-/Genlock-Eingang gibt, dann kannst Du evtl den Quarz einer der beiden Kameras durch eine PLL ersetzen. Der phase-comparator der PLL muss dann die Sync-Impulse im Ausgangssignal der beiden Kameras miteinander vergleichen. Syncpulse lassen sich mit einem LM1881 aus dem FBAS extrahieren.
:
Bearbeitet durch User
Wenn das zweite Bild mehr oder weniger nur Text oder Zahlendaten enthält, ist ein OSD Chip denkbar. Um 2 FBAS Signale zu mischen, reicht es nicht, sie zu synchronisieren, sodern auch der Farbträger muss in Phase sein. Mein Panasonic Pult speichert beide Bilder in einem Framebuffer, aber sowas passt nicht in eine Drohne.
Falk: Im fertig Bereich mag das stimmen, aber im Diy, racing und kunstflug Bereich nicht. Dort wird Fbas wegen der höheren Ausfallsicherheit (analoges signal....) und wichtiger den geringeren Latenzen (teilweise unter 9-30ms vs 25-150ms bei den Hdmi versionen). Dronen Kameras in der <10g Klasse findet man halt auch leider nicht mit Sync. (Hab da mir schon nen Wolf gesucht...) Andi:sowas ähnliches hab ich schon versucht. Leider hat die 1 Kamera (Runcam Night Eagle V2.5) nen Clock generator im Prozessor und die andere (ne Thermalkamera) baut mist mit ihrer kalibrierung wenn der takt zustark (30hz) schwankt... Dh das fällt auch aus... Mathias: leider nein es handelt sich um 2 Kameras wobei, wie schon im eingangspost beschrieben kann das eine (das des Thermal) kann ich auch in ein Bas (dh ohne colorburst) umwandeln. Dann muss man nur den colorburst aus dem anderen Signal rausfiltern, beide B/W Bas Signale mischen (Opamp?) und am Ende das Colorburst Signal der 2 Quelle wieder drüber legen... Ein bekannter hat mir gesagt das er mal nen Chip von Renesas hatte der genau das konnte, leider weiß er nichtmehr die Typen Bezeichnung und im Internet findet man auch nix. Aber was ist wenn ich beide Signale digitalisiere (ungern wegen dem Latenz Anstieg), für hdmi und Co muss es doch sowas geben...
Moin, Radio A. schrieb: > Aber was ist wenn ich beide Signale digitalisiere (ungern wegen dem > Latenz Anstieg), für hdmi und Co muss es doch sowas geben... Ohne das, und ohne Synchronisationsmoeglichkeit bei den Kameras, wird's eh nicht gehen. Und dann bedeutet das zwingend einen Speicher fuer ein Vollbild und damit das entsprechende Delay. Ob jetzt SW oder in Farbe und Bunt macht's auch nicht mehr wesentlich "fetter". Gruss WK
Es gab die Bild-im-Bild Einblendung, da wurde nur das kleine Bild gespeichert und zur Synchronisation verzögert. Dazu könnte es auch einen Chip geben. https://de.wikipedia.org/wiki/Bild_im_Bild https://en.wikipedia.org/wiki/Picture-in-picture
:
Bearbeitet durch User
Radio A. schrieb: > aber im Diy, racing und > kunstflug Bereich nicht. Solche wichtigen Details sollte man immer gleich nennen, daß es nur um die Bewegung geht und dafür die Qualität und Auflösung total egal sind. Früher in den TV-Studios war dafür ein riesen Aufwand nötig und die Ergebnisse oft unbefriedigend. Ein Zeitversatz lies sich auch nicht vermeiden. Daher wurden die Synchronsignale wenn möglich zentral erzeugt und über Kabel zu den Kameras geführt.
Radio A. schrieb: > Aber was ist wenn ich beide Signale digitalisiere (ungern wegen dem > Latenz Anstieg), für hdmi und Co muss es doch sowas geben... Sicher, aber das ist halt auch Volumen, Masse und nicht zuletzt Entwicklungsaufwand. Wieviel Volumen und Masse kannst du dafür spendieren?
Angehängte Dateien:
-
PIP_View1.png
180 KB -
PIP_View2.png
71 KB
Es gab mal ein PIP-Gerät, hier ein Artikel aus dem TV-Amateur 4/1994 von DJ7OO. Der arbeitete beim ZDF in Mainz. Der genannte Controller TMP47C433 ist ein 4-bit-Typ von Toshiba. Ich fürchte, meine Völkner-Kataloge aus der Zeit sind längst entsorgt, ich kann nicht alles aufheben. Den PIP-Tuner hatte ich damals gekauft, der muss noch irgendwo im Keller liegen.
:
Bearbeitet durch User
Ich würde vermutlich beide Kameras getrennt zum Boden übertragen und da mittels Notebook oder sonst einem Rechenwerk mischen. Das ist viel flexibler als eine fest eingestellte Mischung an Bord der Drohne und erlaubt auch im Nachhinein noch Bearbeitung und Auswertung. Zwei WLAN Kameras vertragen sich meist ganz gut, eine WLAN- und eine analoge 2,4Ghz Kamera eher nicht so. Zwei analoge Kameras muss man halt auf weit voneinander entfernte Kanäle einstellen. Dabei gehe ich davon aus, das die Drohne selber auf 5Ghz gesteuert wird.
2.4ghz ist auf den Größen Events nicht nutzbar, da komplett voll. Wir nutzen fast alle 5.8ghz. Leider werden auf großen Events teilweise die Kanäle begrenzt. Zb 60 Kanäle fest zugeordnet für 50 Teilnehmer... Zur Übertragung soll kein WLAN genutzt werden da die Latenzen zu groß (500ms bei 100+kmh in engen Bereichen....) sind und bei Wettkampf ja eh alles zwingend über 2.4ghz oder 5.8ghz vtx übertragen werden muss... Deswegen habe ich ja bereits geschrieben das ich das Signal auf Dronen Seite mischen möchte. Größentechnisch klar so klein wie möglich, aber 2x Checkkarte sollte max drinne sein....
Radio A. schrieb: > Größentechnisch klar so klein wie möglich, aber 2x Checkkarte sollte max > drinne sein.... Die hat die Maße 85x54mm und wiegt geschätzt 1g. Das wird eher eng, vor allem die Masse. Da müßte es einen einzelnen IC mit wenig Außenbeschaltung geben, der das kann.
Radio A. schrieb: > Größentechnisch klar so klein wie möglich, aber 2x Checkkarte sollte max > drinne sein.... Nur, wenn du deine eigenen Mixed Signal Chips herstellen kannst. Es gibt einfach keine Anwendung ausserhalb der von dir, wo sowas gebraucht wird. Es ist auch sehr schön, das wir jetzt erfahren, daß es da um 50 Teilnehmer und einen Wettbewerb oder so geht, das ist wieder ein Salamischeibchen mehr. Wozu man da eine Thermokamera braucht, bleibt mir verborgen, ich will es aber auch gar nicht wissen. Jungs, ich bin hier raus....
Oh, jetzt haben wir mehr Details: Wenn die Thermokamera in S/W kommen darf (verstehe ich nicht so ganz, denn die Temperatur ist doch i.d.R. in der Farbe codiert, oder?) dann waere doch folgendes denkbar: Speicherbedarf fuer einen kompletter Frame der Thermokamera: 8 MHz samplerate 40ms fuer ein Bild (625 Zeilen a 64us) 320000 pixel - bei 8 bit pro Pixel sind das 320kBytes. Man koennte das Signal mit einem 8MHz Video ADC samplen und in ein 320k grosses FIFO schieben. Eine Logik ermittelt aus den Syncs den Zeitversatz zwischen beiden Videosignalen. Ausgelesen wird das FIFO dann mit genau diesem Zeitversatz so, dass die Sync Signale uebereinander passen. Das Signal kommt dann wieder auf einen Video DAC und wird danach zum anderen Videosignal dazu gemischt. Das Ganze geht evtl sogar schon mit einem schnellen Microcontroller mit ausreichend RAM (RP2350? SMT32?) fast komplett in Software. Schwierig ist dann noch die Logik/Software, die die Syncs miteinander vergleicht und den notwendigen Zeitversatz bestimmt. Das ganze sollte sich immer wieder nachregeln, denn ueber Zeit laufen die Kameras sicher wieder auseinander. Videosignale mischt man uebrigens am besten passiv ueber Widerstaende mit einer anschliessenden Transistorstufe um die Pegel wieder zu versaerken. Einfache Opamps sind zu langsam. Du brauchst da (teure) Video-Opamps, die viel Strom ziehen und auch gerne mal ungewollt schwingen.
Andi M. schrieb: > Wenn die Thermokamera in S/W kommen darf (verstehe ich nicht so ganz, > denn die Temperatur ist doch i.d.R. in der Farbe codiert, oder?) Bei s/w ist die Temperaturauflösung oft besser, als in Farbe.
:
Bearbeitet durch User
verstehe, aber was man da wohl noch erkennen kann, wenn beide Bilder uebereinander liegen... Oder glaubt der TO, dass ein Zusammenmischen der Signale beide Bilder womoeglich nebeneinander platziert? @radio_a: einfaches Zusammenmischen der Signale entspricht einem ueberblenden der Bilder. Die liegen also mehr oder weniger transparent aufeinander. Ist das das Gewuenschte Verhalten???
:
Bearbeitet durch User
Radio A. schrieb: > Dort wird Fbas wegen der höheren > Ausfallsicherheit (analoges signal....) und wichtiger den geringeren > Latenzen (teilweise unter 9-30ms vs 25-150ms bei den Hdmi versionen). Wo hast du diese Angaben zu den Latenzen her? Die sind schlicht Unsinn, jedenfalls ohne die Nennung von Randbedingungen. Grundsätzlich bringt eine AD-Wandlung erst mal nur eine zusätzliche Latenz von einer Pixel-Dauer ein. Das ist fünf Größenordnungen unter der allfälligen Latenz von mindestens einer Framedauer, die allein durch die menschliche Wahrnehmung anfällt, kann man also getröst in den Skat drücken. Sprich: nicht "digital" an sich ist das Problem. Wenn es ein signifikantes Problem gibt, dann bei der Kompression. Die brauchst du aber dann nicht, wenn du digitalisierst, dann deine Bearbeitung durchführst und am Ende dann wieder ein analoges Videosignal aus dem Bearbeitungsergebnis produzierst. Das ist bei den von dir genannten Randbedingungen (Quellen nicht synchronisierbar) sowieso das Einzige, was funktionieren kann. Erfordert aber relativ viel Elektronik, die halt auch die entsprechende Menge Energie schluckt.
Die Latenzen hat ein bekannter gemessen... Hierzu hat er via Controller ne LED auf den Sensor (=ohne Linse) gerichtet und den Ausgang (analog oder Digitalen) vom Controller überwachen lassen. Das hat er 1000 mal wiederholt und den Durchschnitt (je sensor) gebildet... Man sollte auch sagen das viele moderne (für racing und kunstflug designte) Fbas Fpv Kameras während dem messen des nächsfen Pixels bereits den vorherigen als Signal ausgeben... Bei den Digitalen schnittstellen muss in der Regel erst das Komplette Bild erfasst und dann komprimiert werden...
Noch ein Suchbegriff zum Thema: Genlock https://de.wikipedia.org/wiki/Genlock Anscheinend gab es das neben dem PC vor allem für den Commodore Amiga. https://cbmmuseum.kuto.de/steck_a2300.html Der Vorteil des PIP-View war, dass nur eine Videoquelle mit der anderen synchronisiert wurde, die zweite lief frei mit ihrem Originaltakt. https://www.slashcam.de/info/Wie-wichtig-ist-Genlock-404051.html der Begriff TBC = time base correction gehört auch zum Thema.
:
Bearbeitet durch User
Peter D. schrieb: > Früher in den TV-Studios war dafür ein riesen Aufwand nötig und die > Ergebnisse oft unbefriedigend. In der moderneren Analog-TV-Zeit gab es dafür Frame Store Synchronizer. Peter D. schrieb: > Ein Zeitversatz lies sich auch nicht vermeiden. Das ist korrekt, ein Frame wurde zwischengespeichert, man hatte also 20ms Delay. Christoph db1uq K. schrieb: > Noch ein Suchbegriff zum Thema: Genlock Dafür wurde der Rechner mit dem Studiotakt synchronisiert, was bei den Signalquellen des TO nicht geht.
> mit dem Studiotakt synchronisiert Eigentlich ist es egal, welche Quelle den Takt angibt, man wird natürlich die stabilste verfügbare Frequenz nehmen, z.B. ein Atomfrequenznormal oder einen dazu geeigneten GPS-Empfänger. Da hier nur zwei Videosignale vorhanden sind wird man eines davon zur Synchronisation nehmen und das andere daran anbinden. Die sind sicher auch wenigstens quarzgenau und damit für jeden TV-Empfänger gut genug. Zum PIP-view habe ich mehrere ebay-Angebote gefunden: PIP View Roctec RN1812: https://www.ebay.com/itm/265141361614 PIP View Roctec RN1813: https://www.ebay.de/itm/256444731492 Extron PiP Multiview mit PiP Funktion PIP444: https://www.ebay.de/itm/236233278590 Natürlich viel zu groß um in einer Drohne mitzufliegen, aber die Technik hat seit den Neunzigern ja Fortschritte gemacht. Das Schaltungsprinzip könnte man wahrscheinlich auf die gewünschte Größe verkleinern. https://fpv-community.de/threads/pip-picture-in-picture-elektronik-f%C3%BCr-fpv.1121/ da hat schon 2010 jemand PIP für FPV-Kameras vorgeschlagen Es gibt so etwas auch in digital für vier HDMI-Eingänge auf einen HDMI-Ausgang, hier aber uninteressant: https://www.ebay.de/itm/297454907724
:
Bearbeitet durch User
ist es denn überhaupt möglich die beiden Kamerabilder überhaupt geometrisch übereinander zu bekommen? Du hast hier vermutlich Festbrennweiten um Gewicht zu sparen?
Angehängte Dateien:
-
PIP_View_Roctec_RN1813.jpg
360 KB
Und wie soll das überhaupt aussehen? Das Wärmebild farbig über einem farbigen Bild im sichtbaren? Deshalb schreibe ich ja Bild-im-Bild. Hier ein Foto aus der ebay-Anzeige, das die Einblendung zeigt. Das verdeckt leider einen Teil des größeren Bilds.
Christoph db1uq K. schrieb: >> mit dem Studiotakt synchronisiert > Eigentlich ist es egal, welche Quelle den Takt angibt Du konzentrierst Dich auf unbedeutende Details. Der Knackpunkt ist, dass keine der beiden Signalquellen des TO extern synchronisiert werden kann, und damit ist das Thema Genlock hinfällig. Sofern an den Kameras nichts geändert werden kann/darf, bleibt also nur das Zwischenspeichern eines Frames, und das bringt 40ms (PAL, die o.g. 20ms waren natürlich falsch) bzw. 33.3ms (NTSC) Delay.
Angehängte Dateien:
Schade eigentlich, aber die unerbittliche Zeit lässt sich nicht austricksen. Ich hätte noch den Vorschlag, die beiden Kameras auf Hochformat zu drehen, dann lassen sich beide Bilder nebeneinander auf einem Bildschirm darstellen, wie es im Bild zum HDMI-PiP gezeigt ist.
Christoph db1uq K. schrieb: > Und wie soll das überhaupt aussehen? Das Wärmebild farbig über einem > farbigen Bild im sichtbaren? Ja. Sowas machen u.a. die Kameras von FLIR
Stimmt https://www.flir.de/products/mix-starter-kit-for-x-series/?vertical=science&segment=solutions Die Tageslichtkamera hat hohe Auflösung, Vollbildrate 1120 Hz, mit 1920 × 1080 Pixeln. "Ein oder zwei 12 Gbps Verbindungen zur Infrarotkamera und zwei Verbindungen zur mitgelieferten Tageslichtkamera" Das passt nicht in eine Drohne wegen Platz, Gewicht und Strombedarf. Im Foto ist zu sehen, dass die Kameras nebeneinander montiert sind, das ergibt einen Versatz der Bilder, wie es oben schon Heinz fragte. Also bleibt nur ein Umbau der beiden Kameras zur Fremdsynchronisation oder eine der beiden als Taktgeber.
Welches Problem eigentlich hofft man mit einer Wärmebildkamera in einer "Racing"-Drohne zu lösen? Oder geht es um den "single-use"-Einsatz südöstlich von Warschau?
Auf die Idee kann man beim Thema Drohne leicht kommen. "Groß-Event" und "Wettkampf" spricht eher dagegen. Aber mit einer Wärmekamera kann man auch Fahrzeuge und Personen aufspüren.
Nein ist weder für den Einsatz im Nahen Osten noch bei ner "special military operation" gedacht. wir haben mehrere Events ( oder Spieltypen) wo einer Thermal Channel von Vorteil ist und auch bereits eingesetzt wird. Z.b. bei "Drone hunt" (Fangen wo man nen 60cm Papier streifen schreddern muss - andere Dronen Strahlen wärme ab...) oder einigen endurance races (zb das 7h endurance race bei Schachtstein CZ)...
Heißt wohl was selber entwickeln. Kann mir evtl sagen was für datenraten ich bei 8bit (aka 1 byte) Auflösung ich erwarten kann? Würde nen teensy (@800mhz) mit nem Qspi sram (ca 34MB/S und 8MB) und nem externen Adc (dachte an nen AB9226 @65MSPS) und evtl nen Dac (noch unbestimmt) reichen? Oder braucht man das mehr datenrate?
:
Bearbeitet durch User
Radio A. schrieb: > Kann mir evtl sagen was für datenraten > ich bei 8bit (aka 1 byte) Auflösung ich erwarten kann? Ein FBAS-Signal hat etwa 5 MHz Analogbandbreite.
720 Bildpunkte in 52 µs gibt ca 14 MHz und bei 8 Bit entsprechend 14 MB/s. Bei 540 sichtbaren Zeilen braucht ein Vollbild knapp 400 kBytes Speicherplatz.
Radio A. schrieb: > Kann mir evtl sagen was für datenraten > ich bei 8bit (aka 1 byte) Auflösung ich erwarten kann? Ein PAL Bild besteht aus horizontal 720 Spalten und vertikal 576 Zeilen (ohne Austastlücke). Eine Zeile wird (ohne Austast und Sync) in 52µs übertragen. Die Rechnerei überlasse ich dir :-)
Moin, Guck dir mal z.B. von Renesas/Intersil Chips an wie den TW9966 an. Leider ist dessen ausfuehrliches Datenblatt mal wieder streng geheim. Lauft aber auf einen Takt von 27MHz pro Videokanal raus, mit dem 8bit breite Daten geschaufelt werden muessen. BT.601 und BT.656 sind die Specs, die das genauer beschreiben sollten. Gruss WK
Matthias S. schrieb: > Ein PAL Bild besteht aus horizontal 720 Spalten und vertikal 576 Zeilen > (ohne Austastlücke). Als Analogsignal hat es natürlich keine in Stein gemeisselten Spalten, aber wenn Du quadratische Pixel willst, sind es 768.
Radio A. schrieb: > Heißt wohl was selber entwickeln. Kann mir evtl sagen was für datenraten > ich bei 8bit (aka 1 byte) Auflösung ich erwarten kann? Würde nen teensy > (@800mhz) mit nem Qspi sram (ca 34MB/S und 8MB) und nem externen Adc > (dachte an nen AB9226 @65MSPS) und evtl nen Dac (noch unbestimmt) > reichen? Oder braucht man das mehr datenrate? Wenn gleich man sowas prinzipiell heute mit einem FETTEN Mikrocontroller erschlagen kann, macht man sowas eher mit einem passenden ASIC oder FPGA. Die Suche nach Kameras mit Sync Eingang bzw. ein Umbau der Kameras ist aber vermutlich DEUTLICH einfacher. Wie schon geschrieben, wird PAL im Normalfall mit 720 Pixeln/Zeile digitalisiert, macht 720Byte/64us bzw. bei 576 Zeilen (interlace) 414kB/20ms oder eben 20,7Msps. Solche Datenraten können integrierte ADCs eher selten, auch mit DMA wird das eher knapp. Und das ist nur EIN Kanal. Ich glaube du unterschätzt den Aufwand DEUTLICH. Und wenn man schon digital arbeiten will, kann man auch gleich Kameras mit digitaler Schnittstelle nehmen, die kriegt man deutlich einfacher an aktuelle ICs angeschlossen. U.a. Raspberry PI.
Matthias S. schrieb: > Ein PAL Bild besteht aus horizontal 720 Spalten und vertikal 576 Zeilen > (ohne Austastlücke). Eine Zeile wird (ohne Austast und Sync) in 52µs > übertragen. Die Rechnerei überlasse ich dir :-) Du hast interlaced vergessen - aber ja, in der "heutigen" Zeit macht man da halt dann eher progressive segmentated frames draus ... Also nur die halbe Bandbreite
Leider finde ich keine kammer mit Sync Eingang im sub 10g (ohne Kabel) bereich. Teilweise haben die Dronen nen Abfluggewicht unter 200g, da kann ich auch keine 100 oder 500g Kamera drann schnallen. Digital heißt leider wieder Lag und bei 100km will man das auch nicht. (deswegen nehmen eigentlich alle analog) Vorallem mit nem Raspberry (die haben teilweise 100ms lag allein). Viele modernen Kameras haben den mems Oszillator oder ähnliches im IC. Ich will auch nur 1 Kanal (the Thermal) digitalisieren um diesen dann synchronisieren. Als ADC hab ich ja schon gesagt das ich evtl nen Externen nehme. Fpga oder Asic kann ich nicht und ich glaube das das Projekt evtl etwas zu steil ist um damit anzufangen... Als Idee hatte ich Thermal via ADC digitalisieren und (zeilenweise) im RAM ablegen und dann mittels externen Trigger via Dac ausgeben. Zum triggern nen LM1881 auf der anderen Quelle (der normalen Kamera) und dann mischen (via Opamp?)...
:
Bearbeitet durch User
Angehängte Dateien:
-
20191221_175918_A.jpg
510 KB
Christoph db1uq K. schrieb: > Und wie soll das überhaupt aussehen? Das Wärmebild farbig über einem > farbigen Bild im sichtbaren? Jepp. So z.B. (siehe Bild) Gruß Jobst
Radio A. schrieb: > Als Idee hatte ich Thermal via ADC digitalisieren und (zeilenweise) im > RAM ablegen und dann mittels externen Trigger via Dac ausgeben. Zum > triggern nen LM1881 auf der anderen Quelle (der normalen Kamera) und > dann mischen (via Opamp?)... Ich könnte dich noch pfundweise mit alten PAL- Encodern und Decodern (NOS) versorgen. Nur halte ich es für ausgeschlossen, dass daraus eine praktikable Lösung wird. Bis du eine funktionierende Timebase-correction entwickelt hast, wird deine Drone zum LKW und fährt nur noch statt zu fliegen. Und du siehst das Kamerabild nicht mehr wegen des langen weißen Bartes. (sorry, nicht böse gemeint!). Ich will nur sagen, es ist erheblicher Aufwand das zu entwickeln. Zufällig war es genau das Thema meiner Diplomarbeit anno 1990, nur im digitalen HDTV-Studiobereich bei Bosch Fernseh in Darmstadt. Halt 270Mbit/s statt den analogen 27. Es war dann ein 19"-1HE-Einschub.
> Radio A. schrieb: >> Kann mir evtl sagen was für datenraten >> ich bei 8bit (aka 1 byte) Auflösung ich erwarten kann? Habe ich schon am 31.07.2025 15:07 für dich ausgerechnet. Ich schlage dort vor das Signal mit 8MHz zu digitalisieren. Das reicht für S/W zumal die Thermokammera ja auch kein super detailliertes Bild liefert. Ich würde mir nicht die Mühe machen, das Signal von seinen sync-impulsen zu trennen. Einfach alles so wie es ist capturen und mit entsprechend eingeregelten Zeitversatz wieder ausgeben. Fertig.
:
Bearbeitet durch User
Hmmm schrieb: > Als Analogsignal hat es natürlich keine in Stein gemeisselten Spalten, > aber wenn Du quadratische Pixel willst, sind es 768. Stimmt schon, ist aber schon mit 720 Pixeln schlimm genug. Natürlich könnte man die Auflösung der Thermalkamera radikal reduzieren, da wirds nicht so drauf ankommen. Allerdings halte ich die getrennte Übertragung der Kameras zum Boden immer noch für die einzige Lösung, bei der der TE eine Chance hätte, sein eigenartiges Problem zu lösen.
:
Bearbeitet durch User
Mario M. schrieb: > 720 Bildpunkte in 52 µs gibt ca 14 MHz Ein PAL-Signal löst aber gar keine 720 Bildpunkte auf, das hat --wie ich schon schrieb-- gerade mal 5 MHz Analogbandbreite. Und da ist schon der Farbträger enthalten. Die hier verwendeten Kameras werden kein RGB-Signal mit "PAL-Timing" liefern, sondern ein Composite-Video- bzw. FBAS-Signal. Das ist das, was früher als Fernsehsignal auf HF-Träger aufmoduliert und in Fernsehern empfangen wurde, um wahlweise die "Aktuelle Kamera*" oder die "Tagesschau" zu sehen. Heinz R. schrieb: > Du hast interlaced vergessen Er hat die Nutzdauer in einer Bildzeile angegeben, als einzige timingrelevante Information. Und die Zeilenfrequenz ändert sich nicht, ob nun interlace oder nicht, die beträgt 15.626 kHz (64 µs Periodendauer incl. Austastlücke, Schwarzschulter etc. pp.). *) die dann natürlich nicht in PAL, sondern SECAM, aber der Unterschied ist für die Bandbreitenbetrachtung nicht weiter relevant
Moin, eieiei, ich seh' schon: Lauter Videokoniferen hier... Bei SD-Video ist's aehnlich wie bei der heiligen Handgranate von Antiochia. Da gibts genau eine Zahl auf die du zaehlen musst. Und diese Zahl ist hier nicht 3, wie bei der hl. Handgranate, sondern 3x3x3 = 27. Und zwar MHz. Das ist der Takt. Damit hat man einen Kanal fuer Y mit 13.5MHz Samplingrate und 2 Kanaele fuer die Chrominanz mit jeweils 6.75MHz. Und dafuer gibt's Chips. Oder gab's zumindest mal. Wer meint, unbedingt das Videosignal mit einem Feld-Wald-Wiesen ADC oder mit einer anderen Samplingfrequenz digitalisieren zu muessen: Viel Spass dabei - vor allem beim PAL-de- und -encodieren... Gruss WK
Dergute W. schrieb: > Wer meint, unbedingt > das Videosignal mit einem Feld-Wald-Wiesen ADC oder mit einer anderen > Samplingfrequenz digitalisieren zu muessen: Viel Spass dabei - vor allem > beim PAL-de- und -encodieren... Eigentlich alle analogen PAL-TV-Geräte mit digitaler Signalverarbeitung haben mit der 4-fachen Frequenz des Farbhilfsträgers gesampled. Damit hatte man dann nämlich direkt die Phasenlage des selbigen. Gruß Jobst
Harald K. schrieb: > Ein PAL-Signal löst aber gar keine 720 Bildpunkte auf Das sicher nicht, so viel ist klar. Es ist vielmehr andersrum. Die 720Pixel der digitalen Standards wurden so gewählt, dass mit Sicherheit nichts von dem verloren geht, was in einem Signal mit "PAL-Timing" drinsteckten kann, auch dann nicht, wenn die analoge Strecke mit RGB/YUV betrieben wird. > das hat --wie ich > schon schrieb-- gerade mal 5 MHz Analogbandbreite. Und da ist schon der > Farbträger enthalten. Nun, ganz so wild ist es allerdings auch wieder nicht. So stark limitiert wird es wiederum nur, wenn es über einen Sender/Modulator geht, also die 8MHz Kanalbandbreite und die Bandbreiten und Abstände des ganzen Hilfsgedöhns einzuhalten sind. Der erledigt dann auch diese Limitierungen, filtert also die Signalkomponenten noch mal ganz ordentlich. > Die hier verwendeten Kameras werden kein RGB-Signal mit "PAL-Timing" > liefern, sondern ein Composite-Video- bzw. FBAS-Signal. Jepp. Also den Fall, der irgendwo zwischen den beiden oben beschriebenen Extremen liegt. Und da sind, insbesondere für das Y-Signal, in etwas geringerem Umfang aber auch für die Farbkomponenten deutlich mehr Bandbreite möglich, als wenn der Kram über den Sender gehen muss. Was natürlich auch daran liegt, dass es auf diesem Level kein Audio gibt, dieser Teil des Spektrums also unbenutzt ist. Und in der konkreten Anwendung geht das Signal zwar wohl über eine Funkstrecke, aber die ist nicht in den üblichen TV-Bändern, also vermutlich nicht an deren Kanalbandbreite gebunden. Und Audio geht da wohl auch nicht drüber. Es könnte also gut sein, dass hier wesentlich mehr des Potentials von Composite auch über den Sender geht. Das kann man nur raten oder, viel besser: messen.
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.