Hat jemand schon mal so was gemacht ? Mit welchem A/D ? Wie sieht die Eingangs- und Audgangsbeschaltung eines bestimmten A/D aus ? Es muss doch irgent eine gute Möglichkeit geben. Bisher hat mich noch niemand dem Ziel näher bringer können.
Definiere digitalieren: - Ein Standbild ? - Ein Bild aus einem Film ? - Einen ganzen Film ? Welche Auflösung brauchst du, was hast du bereits usw.
Und wo soll das Problem sein? SAA 7113 von NXP oder TVP 5150 von TI oder, oder, oder...
Ich möchte aus einem Fbas Signal die Bildinformation als S/W Info digitalisiert eine Controller bereit stellen. Jedes Pixel soll als Digitaler Wert dem MC bereit gestellt werden Als Video Datenstrom so zu sagen incl. Sync Signale, alles was kommt. Mit - nimm nen SAA7113 kann ich nix anfangen, wie anschliessen, Eingangsbeschaltung ect. Muss ich das RAD ganz neu erfinden und entwickeln ? Gibt es keine Schaltung mit gängigen Schaltkreise die schon jemand mit Erfolg eingesetzt hat?
> Muss ich das RAD ganz neu erfinden und entwickeln ?
Wenn du das Datenblatt nicht lesen willst oder kannst - ja.
Ich habe die dortige Schaltung eingesetzt und sie funktioniert. Der SAA
7113 ist ein gängiger Schaltkreis.
Es gibt meist application notes zu den ICs, oder zuminstest eine Beispielbeschaltung.
Dieser SAA7113 ist ein ganz schöner brocken. Gibt es einen einfacheren Baustein auch 5V statt 3,3 ohne I2C Setup usw. Bischen happig für die ersten Erfahrung im PAL Bereich. Habe mehr an eine möglichst einfache Samplung gedacht und mich erst nach und nach mehr in die FBAS Geschichte rein zu arbeiten.
Wenn dir der schon ein Zwerg wie der 44-pinner SAA7113 als Monster erscheint, dann vergiss den Versuch, das mit einem Controller zu erledigen. Nimm einen PC, und wenn's ein Minimalboard ist, und steck eine TV-Karte rein. Schau doch einfach mal in die Dokumentationen zum FBAS Format, und überleg dir, wie du rein durch A/D-Sampling daraus die Farbinformation gewinnen kannst. D.h. wie schnell du abtasten musst, damit das rein digital möglich ist. Tip: Der Farbträger hat 4,xMHz und die Information steckt u.A. in der Phase, d.h. unterhalb einer Abtastrate von weit 2stelligen MHz wird das nix. M.a.W: Du landest ungefähr bei der Aufgabe, ein Digiscope mit zig Megasamples pro Sekunde und reichtlich Speicher zu bauen. Dagegen ist der SAA ein Zwerg.
Ralf schrieb :
>Ich möchte aus einem Fbas Signal die Bildinformation als S/W
Wobei das F in FBAS für Farbe steht.
Martin wrote:
> Wobei das F in FBAS für Farbe steht.
Und das PAL im Subject erst recht.
Weshalb die Empfehlung fällig ist, sich erst einmal mit dem Thema tiefer
vertraut zu machen (www.gidf.de). Denn ohne jede Kenntnis der Sache ist
das ziemlich hoffnungslos.
Also : Ich habe ein FBAS Signal nich BAS oder sonst was und beides ist ja wohl für ein s/w Bild gleichermaßen verwendbar. Irgentwie bin ich noch nicht schlauer als vorher Offensichtlich kennt sich hier niemand so aus das er mir viel weiter helfen kann wie man mit möglichst geringen Aufwand Bildinformationen digital bereit stellen kann - das geht ohne Frage. Vor langer Zeit habe ich solche an irgenteiner Schule ein Projekt gesehen mit nur wenig Bauteilen haben die die Bild und Sync Signale einem MC bereitgestellt, ich meine die haben das mit Hilfe von Komperatoren gemacht, da war sicher kein A/D mit im Spiel.
> Irgentwie bin ich noch nicht schlauer als vorher
Wir auch nicht. Beantworte mal die erste gegenfrage.
>ich meine die haben das mit Hilfe von Komperatoren >gemacht, da war sicher kein A/D mit im Spiel. Mit Komparatoren ist auch ein A/D. Das nennt sich Flash Wandler.
Hallo, mit 2 Komparatoren hab ich das am C64 Userport gemacht, immerhin Schwarz, weiß und 2 Graustufen. Naja, mehr Graustufen hatte der C64 auch nicht. ;) Standbild war natürlich Pflicht, Bild einlesen ware 160 Halbbilder bei 200 Zeilen und warten auf Sync, also run 7s für ein Bild. Konnte man sogar was drauf erkennen. ;) Da immernoch unklar ist, was mit den Daten geschehen soll, wo sie bleiben sollen und wer sie wie weiter nutzen soll, ist es eher Glaskugelraten... PS: Falls jemand damit noch rumbasteln will: ich habe noch ein paar TDA 8708/8708A/8709A rumliegen, die ich wohl kaum noch benutzen werde... Sind unbenutzt, waren mal als Ersatz für die VLAB-Grabberkarte vom Amiga. Gruß aus Berlin Michael
>Vor langer Zeit habe ich solche an irgenteiner Schule >ein Projekt gesehen mit nur wenig Bauteilen haben die die Bild und >Sync Signale einem MC bereitgestellt, ich meine die haben das mit >Hilfe von Komperatoren gemacht, da war sicher kein A/D mit im >Spiel. Aus dieser Info könnte ich mir vorstellen worum es Ralf geht: Ein LM1881 zum Synchronisieren auf die Vertikal- und Horizontalimpulse und dann ein Komparator, den man einfach nur genügend Punkte während der 64µs Zeile samplen lässt. Das sind nicht viel mehr als 2-3 Bauteile und schon hat man einen ganz primitiven Video-Digitalisierer. Meinst Du so etwas?
Also ich kapiere nun auch nicht mehr, was das ganze Gerede hier eigentlich soll, die Frage des OP war doch ziemlich simpel, und er selbst hat die Antwort eigentlich auch schon gegeben. Also konkret @Ralf J. Stell Dich einfach dumm und tu so, als wärst DU ein alter s/w Bildröhrenfernseher. Der kennt keine Farbinformationen und stört sich also auch nicht an deren Anwesenheit. Schlichtweg ignorieren. Sync-Impulse abwarten, eine Zeile so oft wie möglich A->D wandeln, einlesen. Solange wiederholen, bis ein Bildsync kommt und dann alles von vorne. WO GENAU IST DAS PROBLEM? Und WAS GENAU gibt es da seitenlang zu palavern? Und was nützen da dubiose Chipempfehlungen, die NICGHTS weiter machen, als das Problem massiv zu verkomplizieren. Das was der OP da will ist KINDERLEICHT, das haben wir schon in den 80er Jahren mir prähistorischen Bauteilen gemacht. Jochen Müller
Jochen Müller wrote:
> Und WAS GENAU gibt es da seitenlang zu palavern?
Vielleicht ist dir nicht aufgefallen, dass die Einschränkung auf
S/W-Information aus der ursprünglichen Frage nicht hervorging und im
Gegenteil die Wortwahl ("FBAS", "PAL") deutlich auf Farbauswertung
rausläuft. Das hat die Diskussion sofort auf's falsche Gleis gesetzt und
dann dauert es halt etwas bis sich das legt.
Insofern hat das auch viel mit einem häufigen Problem zu tun: wie man
Frage so stellt, dass man die gewünschten Antworten kriegt. Immerhin
kamen von Benedikt sofort die Kernfragen, die bislang immer noch nicht
beantwortet wurden.
vielleicht hilft dir ja auch so ein "Wandler-Dingens" weiter, welches FBAS in VGA umsetzt (weiß grad nicht wie die Kisten so heißen). Da kannst du an bestimmter Stelle halt auch das Videosignal digital abgreifen, das kostet so um 50-100 EUR als Fertiggerät
Jochen Müller (taschenbuch) wrote: >Sync-Impulse abwarten, eine Zeile so oft wie möglich A->D wandeln, >einlesen. >Solange wiederholen, bis ein Bildsync kommt und dann alles von vorne. Nicht mal das will er! Ansonsten hast du vollkommen recht: Einfach Videosignal nehmen und auf einen Video-ADC geben (>10MHz Abtastfrequenz, typ. war 13,xxx). Haben wir auch schon in den 80er Jahren gemacht ... ;-) Ralf J. (rujatt) wrote: >Mit welchem A/D ? Video-ADC , an den Typ kann ich mich nicht mehr erinnern - gibt es vermutlich auch nicht mehr. >Wie sieht die Eingangs- und Audgangsbeschaltung eines >bestimmten A/D aus ? Das gibt dann sicherlich das Datenblatt her. Goggle ist dein Freund (Composite-Video DAC). Nach kurzer Suche fand ich z.B. eine Applikation von National mit dem ADC1175: http://www.national.com/appinfo/adc/files/video_ckt_clamps.pdf Das wäre es doch - oder nicht?
Warum wird jetzt immer weiter Spekuliert und schon gesagtes nochmal wiederholt?
>Ich habe die dortige Schaltung eingesetzt und sie funktioniert. @Bernd G. Zur Bildauswertung möchte ich die Bilddaten in einen Speicher schreiben, um sie dort zu analysieren. Gib es ähnlich elegante Bausteine, die die Ansteuerung fürs RAM anbieten und sich einfach an den SAA7113 anschließen lassen (außer FPGA)?
@ Gast Es gibt Steine, die die Wandlung sofort wieder rückgängig machen. :-) Aber im Ernst: Das was du haben willst, kenne ich so nicht. Sei dessen eingedenk, daß die Daten aus dem SAA (oder auch aus anderen vergleichbaren Steinen) mit einer Breite von 8, 10 oder 12 Bit bei einer Taktfrequenz von 27 MHz rauspurzeln - also etwa 270 Mbit/s (das ist die Leib- und Magenbitrate der Videotechniker: SMPTE 259 C). Wenn du da was analysieren willst, ist der FPGA in Verbindung mit einer SDRAM-Ansteuerung aus meiner Sicht die einzig handhabbare Lösung. Direktaufzeichnung auf Festplatte bzw. Festplattenarray geht erst nach Komprimierung (MPEG, MJPEG, Wavelets...). Aber dann kann man nichts mehr analysieren. Vielleicht kannst du konkreter werden? Brauchst du vielleicht nur ein Einzelbild zur Abspeicherung?
Wenn's nur Helligkeitsinfo sein muss, kann man bei manchen VideoADCs auch auf 13,5Mhz Dotclock herunterschalten (Y und C kommt dann auf verschiedenen Ports heraus) Die Datenmenge halbiert sich, ist aber für einen µC meist immer noch zu hoch. Ich verwende einen ADV8171B und daran hängt ein FPGA, damit kann man dann schon was mit den Daten anfangen.
@Gabriel Wegscheider Zu ADV8171B liefert mir eine bekannte Suchmaschine leider garnichts :-( @Bernd Etwas ausführlicher: ein s/w-Kamerabild soll von links nach rechts auf Helligkeitswechsel (Kanten eines Werkstückes) untersucht und vermessen werden. Aktuell arbeite ich auf analoger Basis, indem ich die Sync-Impulse abtrenne und ein neues Bild zusammensetze, in welches ein µP Maßlinien und Ergebnisse einblenden kann, die per Mausklick vom Benutzer visuell festgelegt werden. Es gibt PC-Lösungen, die mit Framegrabber und entsprechendem Programm diese Auswertung erledigen. Dies soll auf günstige Weise ohne PC realisiert werden. Hierbei ist es notwendig, das komplette Bild in den Speicher des µP zu bringen, damit er auf die Pixel zugreifen kann. Als µP kann ein leistungsfähiger 16-Bitter eingesetzt werden (SH2). So, wie ich das Datenblatt des SAA7113 verstanden habe, würde er die A/D-gewandelten Pixel als 8-Bit Werte anliefern. Wenn jetzt ein 'Videogerät' ein Standbild speichern soll, müssen diese Daten ja auch in irgendeiner Form gespeichert und ausgelesen werden. Wenn der µP ebenfalls Zugriff auf diesen Speicher bekommen könnte, könnte dies meines Erachtens eine einfache Lösung sein, die Pixel auszuwerten.
Nö, ein Standbild lässt sich auch einfacher erzeugen: Indem man das Werkstück vor der Kamera in Ruhe liegenlässt, bis das gesamte Bild erfasst ist. Gleichmäßige Beleuchtung etc. sei mal vorausgesetzt.
@Rufus Und wie bekommt der µP mit, daß vor der Kamera etwas liegt oder besser steht?
Mit einem Kontakt, der vom sich abschaltenden Fließband betätigt wird? Dadurch, daß der Arbeiter, der den Automaten betätigt, auf einen Knopf drückt? Sollte ja wohl relaisierbar sein.
>Sollte ja wohl relaisierbar sein.
Sicherlich. Das löst nur mein Problem nicht.
Also eine Frage habe ich noch dazu die ich aus den Timings der datenblätter nicht ersehen kann. Wie erkenne ich genau welches Halbbild über BAS Signal jetzt gerade übertragen wird, jenes das alle ungeraden Zeilen liefert oder jenes das alle geraden Zeilen liefert. Ich muss ja die zwei Halbbilder in der richtigen Reihenfolge zusammen setzen und irgentwie muss ich ja erkennen können in welcher Halbbildübertragung ich mich gerade befinde. Sind die VSync Signale der beiden Halbbilder irgentwie verschieden um damit den Bezug herstellen zu können. Zwischen FBAS und BAs Signal dürfte es dabei ja keine Unterschiede geben. Ich gehe immer davon aus das ich ein Videorecorder(Farbe) jha an einen S/W Fernseher anschliessen kann. Wie ist das genau ?
Hi! Ich habe mich noch nicht näher damit beschäftigt, aber irgendwas muss es doch damit auf sich haben, dass zum Beispiel AT91SAM962x mit einem Kamera-Interface ausgestattet sind. Da gab es auch einen Standard, ich meine BT656 oder so ähnlich. Vielleicht schaust Du da mal nach, wechselst ggf. Deine Prozessorplattform und hast ein Problem weniger bei Einsatz einer Kamera mit passendem Gegenstück. Gruß, Ulrich
@Ulrich Danke für den Tipp, es ist der ...9263. Ein schönes Teil, wenn man das BGA324 handhaben kann. Für mich ist das eine Nummer zu groß, da die Entwicklungskosten für die kleinen Stückzahlen zu hoch sein werden. Einen SAA7113 o.ä. bräuchte der µP allerdings auch noch :-)
@ Gast Ich glaube, ich weiß, was du brauchst. Muß noch nachdenken, wie es am blödesten geht. Es sollte aber möglich sein, ein Einzelbild aufzuzeichnen und dann den Speicher auszuwerten. Um einen (kleinen) FPGA wirst du wohl trotzdem nicht herumkommen. Das Problem besteht darin, daß es kein fertiges Videogerät (als Schaltkreis)gibt, das einen Speicher hat, auf den man von außen zugreifen könnte. @ Ulrich BT 656 beschreibt lediglich die 10-bit-Parallelschnittstelle.
@ Gast Nur mal rein hypothetisch: Wenn du einen in bekannter Weise mit dem Bildinhalt vollgeschriebenen RAM hast (ein komplettes Einzelbild), kannst du dann mit diesen Rohdaten aus eigener Kraft was anfangen?
Mir ist die Aufgabenstellung immer noch nicht klar. Eine Skizze von den auszuwertenden Positionen des Werkstücks würde evtl. helfen. Was genau muss von der Position erkannt werden? Nur das X-Offset oder auch die Drehung und Y-Offset - oder sind die Umrisse komplett unbekannt oder unregelmäßig? Bis jetzt sehe ich keine Notwendigkeit für eine 2D-Bildauswertung. Nach meinem derzeitigen Verständnis reicht 1D. Das wiederum wäre mit einem Random-Sampling auch mit deutlich schwächerer Hardware zu bewältigen.
>Nur mal rein hypothetisch: Wenn du einen in bekannter Weise mit dem >Bildinhalt vollgeschriebenen RAM hast (ein komplettes Einzelbild), >kannst du dann mit diesen Rohdaten aus eigener Kraft was anfangen @Bernd Ich denke ja; die Kantenerkennung ist nicht ganz problemlos kann aber entwickelt werden. Mittlerweile habe ich mir einige Informationen zum ITU-R BT.601/656 Format besorgt und sehe, daß und wie die Sync-Information dort eingebaut sind. Ggf. wäre es sinnvoll, eine Kamera zu verwenden, die dieses Format gleich ausspuckt. Ich denke, ich muß alle Informationen erst einmal verdauen und prüfen, ob die Datenbandbreite verarbeitet werden kann. Prinzipiell könnte man - wie Du erwähnt hast - eine kleinere Logik einsetzen, um dem µP die Nutzdaten per DMA mundgerecht in den Speicher zu packen. An Alle: vielen Dank für die Denkanstöße! Das Fließband und den Schalter habe ich aber wieder abbestellt :-)
> Ggf. wäre es sinnvoll, eine Kamera zu verwenden, die dieses Format
gleich ausspuckt.
Der SAA 7113 und alle seine Verwandten liefern dieses Signal. Wenn du
eine bezahlbare digitale Kamera mit diesem Format bekommst, vereinfacht
das die Sache natürlich noch.
Wenn es geschäftlich ist, könnte ich dir vielleicht unterstützend was
zuliefern.
> Es gibt PC-Lösungen, die mit Framegrabber und entsprechendem Programm > diese Auswertung erledigen. Dies soll auf günstige Weise ohne PC > realisiert werden. Wenn ich höre, daß eine bestimmte aufwendige oder anspruchsvolle Aufgabe ohne PC gemacht werden soll und das ganze dann auch noch billiger als mit einem Standard-Wald-und-Wiesen-Einplatinen-Industrie PC, dann klingeln bei mir alle Alarmglocken. So günstig wie mit einem S-W-u-W-E-I PC, kann man die meisten anspruchsvollen Aufgaben in der Eigenentwicklung nicht erledigen. Für €1000 kriegt man nun mal nicht viel Entwicklungszeit. Da muß man schon sehr viele Einheiten bauen und auch verkaufen, bis sich das wieder reingespielt hat.
Also um ein Videobild in einen Speicher zu bekommen gibt es mehrere Optionen. Es gibt einige Grabberchips (genaue Type weiss ich nicht, zu lange raus aus dem Markt), die mittels DMA in den Speicher schreiben können. Da dürfte einem aber häufig PCI und Ähnliches begegnen. Zu Fuß kann man sowas gut mit einem FIFO machen. Man braucht halt einen Video A/D Wandfler vorzugsweise mit Sync-Separator und baut sich den passenden Zählersatz für Zeilen und Spalten z.B. mit einem FPGA. Dazu dann ein ausreichend großes FIFO aus dem der Microcontroller dann am anderen Ende ausliest. Wenn man ausreichend Prozessorleistung hat kann das FIFO auch ganz kurz ausfallen und man holt sich die Daten in Echtzeit ab. Habe sowas mal vor etlichen Jahren für Mac II gebaut, da war praktisch nur der Sync-Separator und ein A/D Wandler mit 16 Byte FIFO drauf. Dazu ein einstellbarer Clock-Generator, den wir je nach gewünschter Pixelzahl den Wandler haben takten lassen, das reichte aus um in Software bis zu 320 Pixel horizontal abzuholen (16MHz 68020).
Also im Grunde gebe ich meinem Vorredner recht, oft ist es einfacher zunächst für die Entwicklungsbasis etwas tiefer in die Tasche zu greifen und dafür hinterher sehr viel schneller zum Ziel zu kommen. Des weiteren ist heute bei vernünftigen Leiterplatten-Herstellern und Bestückern bei Kleinserien das Handling von BGA kein Problem mehr. Da wird es nur schwierig, wenn man große Stückzahlen zu niedrigen Preisen haben will. Du hast Dir für Dein Projekt auch einen schlechten Zeitpunkt ausgewählt, weil alle bekannten Hersteller von Controller-Boards auf der CBit und der HMI alles mögliche Neue angekündigt haben, aber vom dort vorgestellten Prototypen bis zur Serienreife werden noch ein paar Wochen vergehen. Ich rechne aber mit einem deutlichen Preissturz bei den ARM9 Dev-Kits in naher Zukunft. Es erfordert also lediglich etwas Gedult, bis man für ein ausreichend bestücktes Dev-Kit mit AT91SAM9263 deutlich weniger bezahlt als die 800..1000€ des offiziellen ATMEL Kits. Ich rechne aber auch nicht damit, dass Du eine Lösung aus separatem Sync + Framegrabber+RAM+DMA für einen anderen Controller schneller fertig bekommst. Und das sage ich nicht, weil ich Deine Fähigkeiten einschränke, sondern weil das alles Zeit braucht. Das musst Du jetzt abwägen. Aber mangels klarer Aussage, ob das eine auf privater Finanzbasis aufgestellte Entwicklung oder eine firmenfinanizierte Lösung werden soll, kann man auch schlecht zu etwas raten. Und ein Entwicklerkit kann nach Abschluss des einen Projektes ja auch gleich wieder für das nächste Projekt genutzt werden. Ist also keine Verschleißware. Dazurechnen muss man auch, dass drei oder vier Fehlschüsse einer einfachen Platine genau so teuer sind, wie ein Entwickler-Kit mit dem man vorab sein System hätte testen können. Und man kann die Entwicklung parallelisieren, also auf dem Kit schon mal Programmieren und anschließen und parallel die später zu produzierende Hardware designen. Wärend diese dann beim LP-Hersteller und Bestücker herumschleicht kann man weiter an der Software arbeiten. Damit sind diese Tage dann nicht so leer :) Gruß, Ulrich
Kann ich nochmal den netten Plausch unterbrechen. Also eine Frage habe ich noch dazu die ich aus den Timings der Datenblätter nicht ersehen kann. Wie erkenne ich genau welches Halbbild über BAS Signal jetzt gerade übertragen wird, jenes das alle ungeraden Zeilen liefert oder jenes das alle geraden Zeilen liefert. Ich muss ja die zwei Halbbilder in der richtigen Reihenfolge zusammen setzen und irgentwie muss ich ja erkennen können in welcher Halbbildübertragung ich mich gerade befinde. Sind die VSync Signale der beiden Halbbilder irgentwie verschieden um damit den Bezug herstellen zu können. Zwischen FBAS und BAs Signal dürfte es dabei ja keine Unterschiede geben. Ich gehe immer davon aus das ich ein Videorecorder(Farbe) jha an einen S/W Fernseher anschliessen kann. Wie ist das genau ?
Versuch dir mal vorzustellen, wie ein alter Schwarzweiss-Fernseher mit seinem Dutzend Röhren festgestellt hat, welches Halbbild oben und welchen unten hin gehört. Vielleicht fällt dann der Groschen.
Das hilft mir nun gar nicht weiter - kenne mich mit Röhren nicht sonderlich aus und beantwortet auch nicht meine Frage. Hat jemand noch was konstruktiveres ? Ist halt nicht mein Steckenpferd die TV Technik, deshalb frage ich ja. wäre echt super
Ist egal ob der mit Röhren arbeitete, weil er keine einzige davon für diese Aufgabe investieren musste. http://freespace.virgin.net/ljmayes.mal/var/tvsync.htm
Also in den Diagrammen kann man keine Unterschiede zwischen ersten und zweiten Halbbild erkennen. Bin ich total auf dem falschen Dampfer. Wenn ich die zwei Halbbilder in der verkehrten Reihenfolge zusammen setze ergibt sich doch ein total falches versetztes Bild. Wie ich das sehe steht im Text auch nix handfestes
Ich kann einen Unterschied sehen. Schau dir nochmal die Zeile 623 an und vergleiche sie mit der 310. Wenn dir dann immer noch nichts auffällt... Wobei es neben Bildchen gucken manchmal auch ganz nützlich sein kann, den drumherum und im Bild stehenden Text zu lesen.
Ja das hab ich bereits gesehen. Eine Schwierigkeit dabei ist bei der Abtastung mit einen A/D um die Daten in den MC zu kriegen das die Abtastrate nicht hoch genug ist um die kleine 35ns Lücke aus zu sampeln. Dazu müste ich die ganze Abtastfrequenz auf sagenhafte 30 Mhz steigern , besser mehr, wenn ich mit dem A/D erstes und zweites Halbbild identifizieren will.
Ralf J. wrote:
> um die kleine 35ns Lücke aus zu sampeln.
Die wiederum habe ich jetzt nicht erblicken können. Zeiten in dieser
Grössenordnung tauchen da nirgends auf, schon garnicht im Umfeld der
Synchronisation.
Aber dass es ohne etwas Hilfe zusätzlicher Schaltungen interessant wird,
ein Bild nur durch Sampling zu erfassen, das hatte ich weiter oben schon
mal fallenlassen. Das geht am ehesten bei Standbilderfassung, indem ein
schneller S&H in beliebig vielen aufeinander folgenden Bildern an immer
anderen Stellen abtastet und so mit der Zeit ein Gesamtbild entwickelt
(vgl. equivalent time mode eines DSOs).
Ja schon klar worauf du raus willst. Aber das beantwortet immer noch nicht die Frage. Ich gehe also mal davon aus das du genauso im Dunkeln tapst wie ich wie die Halbbilder identifiziert werden.
Willst du eine fertige Lösung, mit Schaltung, Programm und sauberem Platinenlayout? Dann nimm einen Minimal-PC mit einer TV-Karte. Wenn du hingegen eine eigene Lösung entwickeln willst, dann wirst du nicht darum herum kommen, dich eingehender mit dem Thema zu befassen. Wirst die Grundlagen des TV-Signals verstehen müssen. Und wirst auch ein bischen drüber nachdenken müssen. Auch wenn das nicht dein Stecknpferd ist - es ist dein Thema. Ich habe bis jetzt auch nicht gewusst wie diese Felder auseinander gehalten werden, nur war mir klar, dass es etwas mit Zeit zu tun hat, denn viel Aufwand konnte man anno dunnemal seitens des Empfängers nicht reinstecken. Aber kurze Recherche führte mich auf diesen Text, in dem die Antwort auf deine Frage sowohl im Bild als auch im fettgedruckten Klartext explizit drinsteht. Wenn du damit nichts anfangen kannst, dann mag es auch sein, dass die kulturellen Unterschiede zwischen uns wohl zu gross sind. Ich versuche die Leute dazu zu bringen, Dinge selber zu verstehen. Wenn das nicht klappt, hat die Sache für mich keinen Sinn mehr.
Hallo, da einem (analogen) Fernseher die halbbilder egal sind, hat man da nichts eingebaut. Indirekt erkennt man die an der Lage der Vor- und Nachtrabanten zum Sync, eigentlich nur dazu da, damit der Fernseher seine (rein analogen) Ablenkstufen richtig syncronisiert. Nutzen notgedrungen auch die Videosampler-ICs. um die Halbbildzuordnung zu finden. Du kannst Dir das aber sehr wahrscheinlich sparen, betrachte das Signal als Signal mit 50 Vollbildern zu je 312,5 Zeilen. Der vertikale Auslösungsverlust dürfte für Deine Pläne keine Rolle spielen. Diverse einfache Kameras erzeugen auch heute noch ein solches Signal, also ohne Trabanten im Sync. Merkt ganz praktisch kaum jemand... Ansonsten nimm einen LM1881 für die Sync-Geschichte, der liefert auch einen Halbbild-Impuls ab. Gruß aus Berlin Michael
Michael. Was du schreibst ist hoch interessant. Ich sehe dies genauso die Trabanten können kaum als Identifizierung dienen. Allerdings kann ich nicht nach vollziehen warum ich alle Signale bis H-Sync als Vollbild betrachten soll. Laut Datenblatt kommt über den TV Sender Even/Odd Halbbilder. Aber du hast recht wenn ich ein Computer generiertes Bild auslese krieg ich 50Hz Vollbilder
Hallo, naja, eigentlich machen wir jetzt Fernsehgeschichte. ;) Der ursprüngliche Trick ist ja nur, daß für Flimmerfreiheit z.B. die üblichen 24B/s beim Kinofilm nicht reichen. Beom Projektor nahm man den Trick, das Bild durch eine Blende 3x pro Bild abzudecken, es werden also sozusagen 48 Vollbilder/s gezeiht, von denen immer 3 aufeinanderfolgende identisch sind, weil das Filmbild im Projektor solange stehenbleibt. Beim Fernsehen sendete man dann eben einfach 50B/s, also jedes Bild 2 mal. Beim Halbbildverfahren werden dann tatsächlich 2 etwas verschiedene Halbbilder ineinander geschachtelt. Da Fernsehen analog war, mußte man dem Fernseher beibringen, ein Halbbild links oben anzufangen und das 2. in der Bildmitte. Damit die Ablenkschaltungen (horizontal üblicherweise Phasenvergleich und nachgestimmter Generator) das auch machten, baute man die Trabanten ein. Die sorgen "nur" dafür, daß die Synconschaltung jedes 2. Halbbild eine halbe Zeilenbreite später startet. Logischerweise müssen die dazu auch immer stimmen, man kann deren Lage zum H-Sync also auch digital nutzen, um das Halbbild zu erkennen. Wenn man einem Fernseher ein Sync ohne Trabanten anbietet, schreibt er einfach alle Halbbilder übereinander, immer links oben beginnend. Kann man beim digitalisieren oft genauso machen, entweder alle einlesen und annehmen, daß sich die ehemals gerade und ungeraden Zeilenpaare kaum unterscheiden oder nur jedes 2. Halbbild einlesen, wobei es da egal ist, wo man anfängt... Gruß aus Berlin Michael
REICHT DEM MANN EINE ZIGARRE (ich hoffe du bist Raucher) Ne ganz im ernst. Habe bestimmt schon mit ein dutzend Leuten gesprochen. Nicht jeder kann sich mit den Thema auskennen. Das ist nicht das Thema. Aber du bist der erste der ganz klare Antworten liefert und nicht irgentwie versucht sein Unwissen durch drum rum gerede zu verdecken, sondern ganz nebenbei auch noch die Lösung liefert. Klasse ! So jemand hätte man gerne auch beruflich im Team. Übrigens der Tipp mit dem Sync Seperator - der die Halbbild Identity liefert ist super. Besten Dank
Gast wrote: > @Gabriel Wegscheider > Zu ADV8171B liefert mir eine bekannte Suchmaschine leider garnichts :-( Opps Sorry, Wollte ADV7181B schreiben, dann klappts auch mit der Suchmaschine.
Und wenn wir gerade bei Halbbildern sind, der von mir verwendete VideoADC, liefert zusätzlich zu V und H sync auf ein Field Signal. Das ist 1 bei erstem Halbbild und 0 beim zweiten (oder wars umgekehrt, müsste ich im Datasheet nachsehen)
Jetzt bin ich wieder da: Halbbildsignal kann auch aus dem digitalen SAV (Start of Active Video) oder EAV (End of Active Video) der kompletten digitalisierten Bildinformation herausgeholt werden: F-Bit Beim SAA 7113, um dabei zu bleiben, läßt sich die Klemme RTS0 als Odd/Even- Indikator programmieren. Die Bilder 38 und 39 des Datenblattes hätten da eigentlich bereits Klarheit schaffen sollen.
Also das mit den Halbbildern ist eigentlich relativ einfach zu erkennen. Aber bei Bildverarbeitung ist es keine gute Idee die Halbbilder zusammen zu setzen wenn das Objekt nicht absolut ruht. Zwischen den beiden Halbbildern ist eine Zeitdifferenz von 1/50s. Bewegt sich der Gegenstand horizontal vor der Kamera, dann kommt es zum Kammeffekt, die beiden Halbbilder zeigen den Gegenstand verschoben. Das ist genau eines der Probleme, die bei 100Hz Fernsehern und LCD Fernseher gelöst werden müssen.
Einfach, aber langsam, geht's so: http://www.roboterclub-freiburg.de/AtmelAVR/Hardware/AtmegaKamera/AtmegaKamera.html chris
@Ulrich P. Der Tipp mit einem EK loszulegen ist sicherlich nicht verkehrt. Neben dem AT91SAM9263 scheint wohl auch der AVR32AP7000 ein geeigneter Kandidat für mein Problem zu sein. Leider, leider haben die Entwickler des "Grasshopper" die ISI-Schnittstelle nicht an Pfosten herausgeführt. Das wäre eine günstige Möglichkeit, schnell zu testen und Land zu sehen. Ein nachteiliger Punkt ist aber beiden µPs gemein: das Programm muß in externen Speichern abgelegt werden, wodurch ein Kopierschutz kaum möglich ist. Oder irre ich hier? Da das Gerät ww vertrieben werden soll, kann es Probleme aus dem Fernen Osten geben.
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.