15.06.2009, 03:35 PM
Nenene... Alfschs Überlegung mit der Verkämmung war schon richtig. Auch zielführend!
Damals hab ich ja meinen Video-Grabber ganz genau so laufen lassen.
Delay (= Spalte) einstellen und dann Zeile für Zeile scannen. Pro Scan hatte ich 64us. Dann Spalte etwas weiter stellen und wieder Zeile für Zeile scannen. Pro Bildwechsel erhielt ich also 312 Scans. Das ist schon ok.
Ich konnte alle 64us samplen und mein Delay musste die 64us in 400 Teile teilen können, damit ich 400 Spalten auflösen kann.
-----
Wenn ich jetzt aber - im Gegensatz zu damals - keinen Speicher hab, so muss ich mich eben mit einem Sample pro Bildwechsel begnügen. Damals wäre das nicht gegangen, weil das ausgerissene Zeilen gegeben hätte. Heute geht das aber, weil wir den Kurvenzug ja nur in einer Richtung darstellen.
Kurzum: ich kann
nicht verstehen.
Damals hab ich ja meinen Video-Grabber ganz genau so laufen lassen.
Delay (= Spalte) einstellen und dann Zeile für Zeile scannen. Pro Scan hatte ich 64us. Dann Spalte etwas weiter stellen und wieder Zeile für Zeile scannen. Pro Bildwechsel erhielt ich also 312 Scans. Das ist schon ok.
Ich konnte alle 64us samplen und mein Delay musste die 64us in 400 Teile teilen können, damit ich 400 Spalten auflösen kann.
-----
Wenn ich jetzt aber - im Gegensatz zu damals - keinen Speicher hab, so muss ich mich eben mit einem Sample pro Bildwechsel begnügen. Damals wäre das nicht gegangen, weil das ausgerissene Zeilen gegeben hätte. Heute geht das aber, weil wir den Kurvenzug ja nur in einer Richtung darstellen.
Kurzum: ich kann
Zitat:oder explizit: wie bekommst die weiteren sampels nach dem 1. sample sync zum trigger-ereignis? die sind sync zum cpu clock....was je nach clock einen fehler von 100...500ns ergibt
nur bei erfassen von 1 sample und dann verstellen des delay stimmt alles.
dazu müsste aber das delay die gesamte sampling-zeit überstreichen können:
zb bei 100 dots sample:
bei 10us takt 10us bis 1ms
bei 100ns takt 100ns bis 10us
nicht verstehen.