Müssen Sie beim Lesen von einer Kamera immer die alten Pixel austakten?

Ich schreibe ein Programm, um mit einem TSL1401R-LF Linescan-Modul zu arbeiten. Es funktioniert, indem es ein 1 x 128-Pixel-Array einliest. Ich habe die Kamera zum Laufen gebracht und meine readPixels()Methode kann die Pixel genau einlesen.

timming()Ich bin jedoch gezwungen, eine Methode vor meiner Methode auszuführen, readPixels()sonst schlägt das Programm fehl. Das timming()macht ziemlich genau dasselbe wie die readPixels()Methode, außer dass es die ausgegebenen Werte nicht speichert. Wenn ich es auskommentiere und nur benutze, readPixels()wird mein Bild gesättigt und ich bekomme nur Werte von 1023, selbst wenn ein dunkles Objekt den Kameras im Weg ist.

Dies könnte sinnvoller sein, wenn Sie sich den tatsächlichen Code ansehen:

void timming()
{

  digitalWriteFast(SI, HIGH);
  delayMicroseconds(10);
  digitalWriteFast(CLK, HIGH);
  delayMicroseconds(10);
  digitalWriteFast(SI, LOW);
  delayMicroseconds(10);
  digitalWriteFast(CLK, LOW);
  delayMicroseconds(10);

  for(int i = 0; i < 129; i++)
  {
    digitalWriteFast(CLK, HIGH);
    delayMicroseconds(delayTime);
    digitalWriteFast(CLK, LOW);
    delayMicroseconds(delayTime);
  }

}

void readPixels()  
{
  digitalWriteFast(SI, HIGH);
  delayMicroseconds(10);
  digitalWriteFast(CLK, HIGH);
  delayMicroseconds(10);
  digitalWriteFast(SI, LOW);
  delayMicroseconds(10);
  digitalWriteFast(CLK, LOW);
  delayMicroseconds(10);

  for(int i = 0; i < 128; i++)
  { 
    digitalWriteFast(CLK, HIGH);
    pixelsArray1[i]=analogRead(Cam1Aout);
    pixelsArray2[i]=analogRead(Cam2Aout);
    pixelsArray3[i]=analogRead(Cam3Aout);
    delayMicroseconds(delayTime);
    digitalWriteFast(CLK, LOW);
    delayMicroseconds(delayTime);
  }

  digitalWriteFast(CLK, HIGH);
  delayMicroseconds(delayTime);
  digitalWriteFast(CLK, LOW);
  delayMicroseconds(delayTime);

  delayMicroseconds(20);
}

TL;DR

Grundsätzlich frage ich, ob es eine Möglichkeit gibt, mein Programm zum Laufen zu bringen, ohne die timming()Methode verwenden zu müssen.

Datenblatt: http://datasheet.elcodis.com/pdf/58/61/586128/tsl1401r-lf.pdf

Fügen Sie den Link zum Datenblatt erneut hinzu. Es gibt andere Möglichkeiten: Einige Kameras haben einen Verschlussimpuls; Verlängern oder verkürzen Sie es je nach Lichtverhältnissen, um eine Sättigung Ihrer Pixel zu vermeiden. Aber ich weiß nicht, ob Ihr Sensor tut.
Ich habe es hinzugefügt, die Erklärung zur Integrationszeit befindet sich auf den Seiten 8 und 9. Dort wurde mir gesagt, dass ich beim Start die Taktung von n + 1 Pixeln vornehmen soll.
Soweit ich sehen kann, geht es nicht darum, die alten Pixel auszutakten, sondern die Integrationszeit zu steuern. Die "einfache" Schnittstelle hat ihren Preis: Sie müssen durch Reifen springen, um das Ganze über nur 2 Pins zu steuern. Es gibt bessere Möglichkeiten als Loop/DigitalWrite, aber sie würden normalerweise Spezialhardware oder ein FPGA erfordern. Wenn Sie mit einem Arduino feststecken, können Sie die Integrationszeit immer noch steuern, indem Sie delayTime für die ersten 18 Zyklen (Reset) und den Rest (Integration) separat anpassen. Oder takten Sie sie so schnell wie möglich und warten Sie dann eine angemessene Zeit vor dem nächsten Frame.
@BrianDrummond das dachte ich auch zuerst, aber durch Verkürzen der Integrationszeit sollen die Pixel dunkler werden, da der Sensor weniger Zeit zum Aufladen hat. Ich weiß das, weil ich beim delayTimeVerkleinern immer niedrigere Werte bekam. Wenn die timming()Methode also nur darin besteht, die Integrationszeit zu erhöhen, sollte ich keinen gesättigten Wert erhalten. Rechts? Tut mir leid, wenn ich es nicht verstehe, dies ist mein erster Timer, der mit einer Kamera arbeitet.
Die Methode timing() dient dazu, die Integrationszeit zu VERRINGERN. Ansonsten haben die Pixel integriert und integriert und integriert und integriert und integriert, seit Sie das letzte Mal readPixels() ausgeführt haben.
Ich habe keine Ahnung, wie langsam 384 AnalogReads auf einem Arduino sind, aber ich vermute ... langsam. Daher ist die Timing-Methode ( timming()) vermutlich viel schneller und ergibt eine viel kürzere Integrationszeit (keine Sättigung) als die vorherige readPixels()Funktion.
@RichardCrowley wie kann das der Fall sein, wenn die Integrationszeit erst nach den ersten 18 Taktzyklen beginnt?
@BrianDrummond Mein analogRead ist optimiert und dauert gar nicht so lange.
Das tatsächliche Verhalten des Chips scheint der Theorie "Starts nach den ersten 18 Taktzyklen" zu widersprechen. Oder vielleicht bedeutet "beginnt nach" etwas anderes als wir denken.
@RichardCrowley kannst du näher erläutern, was du meinst? Das Datenblatt gibt an, dass die Integrationszeit vom 19. CLK-Impuls bis zum nächsten SI-Impuls ist.
Woher kommt dieser timing()- und readPixels()-Code? Vielleicht sollten Sie diese Quelle konsultieren (oder zumindest zitieren), um den Rest des Bildes zu enthüllen. Ich sehe keine Erwähnung einer timing() Methode im Datenblatt.
@RichardCrowley Wenn Sie im Datenblatt auf Seite 9 gehen und den ersten Absatz lesen, werden Sie feststellen, dass es sich bewährt hat, die Uhr (n + 1) Mal nach dem ersten SI-Impuls laufen zu lassen.

Antworten (1)

Ich vermute, dass die Antwort ganz einfach ist: Führen Sie readPixels() zweimal schnell hintereinander aus. Wie es aussieht, wenn Sie timing() nicht ausführen, wenn Sie readPixels() ausführen, hat der 1401 dort für eine unbekannte (aber sehr lange) Zeit integriert, sodass Ihre Pixelwerte natürlich gesättigt sind. timing() setzt also die Pixelintegratoren auf Null zurück, und readPixels() kann dann ordnungsgemäß Daten erfassen. Das erste Ausführen von readPixels() hat jedoch denselben Effekt.

Wenn Sie dies tun, müssen Sie natürlich den ersten Satz von Werten ignorieren, der von readPixels() erzeugt wird, da sie einheitlich 1023 sind.

Die Antwort auf Ihre Titelfrage lautet also - natürlich.

Aber ist es nicht eine Möglichkeit, die Integrationszeit am Ende von zu stoppen, readPixels()damit die Werte nicht gesättigt werden? Wissen Sie auch, wovon das Datenblatt spricht, wenn es sagt, dass die Integrationszeit am positiven HOLD-Impuls endet.
Nein. Die Integration wird für die 18 Taktzyklen nach dem Empfang eines SI-Impulses angehalten. Das ist es. Den Rest der Zeit integrieren die Integratoren. Es liegt am Benutzer (Sie), die Integrationszeit zu steuern. Wenn die Pixel gesättigt sind, reduzieren Sie die Beleuchtung. Wenn Sie das nicht tun, ignorieren Sie einfach die Ergebnisse des ersten readPixels(). Dies ist keine hochklassige, flexible Kamera. Es hat eine minimale Benutzeroberfläche, sodass Sie nur eine sehr begrenzte Auswahl an Betriebsmodi erhalten (dh einen). Auf dem Datenblatt wird „Hold“ in Abbildung 10 auch als „System Reset“ bezeichnet.
Könnten Sie am Ende der readPixels()Methode nicht einfach einen Impuls an den SI senden?
Vielleicht. Das Datenblatt liegt nicht vor. Aber was haben Sie überhaupt gegen einen Dummy-Lesezyklus?
Es verdoppelt im Grunde die Gesamtlaufzeit meines Programms. Ich versuche, es schnell zu machen, damit ich eine hohe Bildrate bekomme.
Aber Sie müssen den Dummy-Read nur einmal ausführen, wenn Sie das Programm starten. Danach führen Sie einfach readPixel() weiter aus. Ihre Sequenz lautet also readPixel() (Dummy), readPixel() (Daten verwenden), readPixel() (Daten verwenden) usw. Beim Start hat der Sensor dort lange Zeit integriert. Aber sobald Sie anfangen zu laufen, ist die Integrationszeit nur die Verzögerung zwischen Frames. Das allererste Lesen ist also Müll, aber danach sollten Sie keine Probleme haben.
Müssen Sie beim Lesen von einer Kamera immer die alten Pixel austakten?
AntwortenHierDatenschutz-Bestimmungen1y, 0v