PAL Signal digitalisieren - Hilfe!

Definiere digitalieren:
- Ein Standbild ?
- Ein Bild aus einem Film ?
- Einen ganzen Film ?

Welche Auflösung brauchst du, was hast du bereits usw.

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?

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.

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.

Zur Erinnerung: Der Ansatz mit A/Ds war deine Idee.

TDA8703 wäre ein recht einfacher Video A/D 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

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

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.

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.

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.

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

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.

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