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