Optical Mouse Sensor ADNS9800

Hey Leute,

ich hab inzwischen meine Fehler gefunden und jetzt läuft der Sensor 
eigentlich ziemlich super.
Nur eine Sache ist noch ein wenig merkwürdig, wenn ich den Frame_capture 
mache und die Bilddaten in einem .pgm file speicher weiss ich nicht wiso 
das Bild son mist ist ??

Hat von euch jemand eine idee??

Bilder im Anhang sind A: komplett ohne Line und B: mit Linse auf 
schwarzem Grund

Ich hab auch schon mehrere Einstellungen der Shutter werte ( 
Belichtungsdauer) verwendet. Es ändert sich dabei nur die Helligkeit.

Gruß HtS

Kenne den Sensor nicht und ich kann das PGM nur als Textfiles öffnen, 
aber hast Du das Linsensystem auf deinen Zielabstand richtig fokussiert?

Weil Du schreibst auch "komplett ohne Linse" - welchen Sinn ergibt das?

Nein .png ist schon richtig, soll ein portable graymap sein. Mit 
Irvanview kann man das auch anschauen.
Aber gut zu wissen dass es auch mit .png geht.

Bezüglich der Linsenfrage weiss ich nicht ganz genau ob der Fokus passt, 
aber da ich die Originallinse verwende nehm ich das einfach mal an. Ohne 
Linse hab ich einfach mal so gemacht. Sieht aber ja irgendwie nach nem 
Lichtkegel aus.

Komsich ist halt, dass das ein 300x300 Pixel Bild ist und exakt die 
untere hälfte alle Bildpunkte die gleiche Graustufe besitzen. Und die 
obere scheinbar aus zwei identischen Bilder besteht.

Gruß HtS

Sorry meinte natürlich das .pgm richtig sei

Sind die Abstände denn mit der aus der Mausanwendung 1:1 identisch? 
Beide Bilder sehen arg nach einem Fokusproblem aus, bei dem ohne Linse 
natürlich klar. Die identischen Lichtkegel könnte ein Ausleseproblem 
sein, um das ich mich in Schritt 2 kümmern würde.

ja sollte eigentlich schon. Ich hab den vorerst garnicht ausgebaut. 
Außer die Singapurer haben das schon falsch in Ihre Maus eingebaut ;), 
nach dem Datenplatt würde mich das auch net wundern.

Aber rein der Aufbau des Bildes kann ja garnicht sein. Das sollte ein 
konistentes Bild sein.

Ich kann morgen früh auch mal meinen code posten. Evtl. seh ich vor 
lauter Zeichen schon den Wald nicht mehr.

Ist denn ein Fehler beim Konvertieren der Sensordaten ins PGM Format 
gänzlich ausgeschlossen?

Nein gänzlich sicher nicht aber doch recht wahrscheinlich, ich hab da 
den code den ich für meinen ADNS5020 geschrieben habe verwendet und da 
hatte er 1A funktioniert.
Hier mal der code.
Eigentlich findet auch garkeine Konvertierung statt sondern lediglich 
die header macht daraus ein bild.

Da ich den Sensor interessant finde habe ich mir deinen Code mal 
angeschaut. Allerdings finde ich ihn etwas wurschtelig. Vielleicht 
kannst Du mal auflisten, welche Register Du wie konfigurierst hast. Da 
steht ja auch was von 2 Frames warten vor dem Auslesen. Du wartest 
einfach 100us und prüfst dann das Ready-Bit. Falls es nicht passend 
gesetzt ist verlässt Du die Schleife einfach.
Ich habe es mir in der Tiefe nicht angesehen, aber muss man vielleicht 
aus einem Register lesen ob 2 Frames vergangen sind (gibt es das?) und 
dann das Ready-Bit prüfen? Sind die Clockflanken richtig eingestellt 
(Datenübernahme bei rising/falling edge)? Werden die Chipselects zu den 
richtigen Zeitpunkten gesetzt? Hast Du mal einen LogicAnalyzer 
angeschlossen und verglichen?

naja stimmt schon, dass das ein wenig wurschdelig ist aber das is leider 
so wie es das Datenblatt verlangt. Einfach stumpf abgeschrieben.

Die Register ja gut der erste Teil ist einfach Auflösung einstellen und 
die Belichtungsdauer (damit das übernommen wird muss man die frame 
period auslesen und wieder in das selbe register schreiben, dabei 
beachten, dass man erst high dann low byte liest und in umgekehrter 
reigenfoilge wieder beschreibt).

Dann muss man die zwei bytes schreiben (0x93 und 0x5c) um den burst mode 
zu aktivieren.

Das zwei frames warten hab ich mit den 30µsec. realisiert. Hab ich 
inzwischen aber auch geändert, dass ich das solange Abfrage bis das bit 
gesetzt ist und nach max. 10 Runden im Karussell abgebrochen wird falls 
es doch nicht kommt. (hat am Ergebniss allerdings nichts geändert).

Und dann kommen auch schon die Abfragen nach den Pixelwerten.

Die Serielle Kommunikation und SPI Initialisierung ist auf jedenfall 
richtig, da ich ja alle Funktionen des Sensors nutzen kann und die auch 
schlüssige Werte liefern. Desweiteren hab ich das ja wie auch oben schon 
gepostet am Oszi überprüft!

Mir ist auch noch aufgefallen, dass in dem Datenblatt genau die pixel 
die in meinem Bild auch grütze sind Grau hinterlegt sind aber nicht 
kommentiert wiso.

Vielleicht wirkt das Bild auch deswegen unscharf (also das MIT Linse) 
weil die Optik für eine Maus wahrscheinlich nicht abgeglichen wird. Bei 
dieser Applikation wird man ja mit einer gewissen Unschärfe leben 
können. Die Fokussierung im Werk wäre mechanisch aufwändig, teu(r)er in 
der Fertigung und wie gesagt unnütz für Anwendung als Maus. Bei diesen 
kurzen Abständen entscheiden ja 100stel Millimeter über eine scharfe 
Abbildung.
Ich habe das PNG mal auf dem iPad aufgemacht, da ergibt das Bild eine 
Art mikroskopische Aufnahme eines Fadens im oberen Teil des Bildes. 
Fraglich was mit der unteren Hälfte ist...

Vielleicht einfach mal mutig mit den Registern spielen, kaputt gehen 
wird ja nichts.

Und? Gibt es Neuigkeiten?

Ich habe viel gespielt und ich vermute das Problem in der Seriellen 
Übertragung. Muss bei Zeiten nochmal mit dem Oszi schauen ob das Timing 
passt.

Alter Thread, ich weiss. Trotzdem, ich habe eine Loesung:
Ich hatte soeben den selben effekt (bilder von oben) und habe ihn 
geloest. Die Beschreibung im Datenblatt ist irrefuehrend. Ich habe 900 
mal das REG_Pixel_Burst register ausgelesen und den Effekt bekommen. 
Immer mit CS und adresse. Doch das timing diagram zeigt, dass nur einmal 
die adresse zu schreiben ist, danach kann man 900 pixel mit jeweils 15us 
delay lesen.

Effekt ist nun auch einfach zu erklaehren: mit dem schreiben der 
addresse fuer jedes pixel wird jedes zweite pixel ausgelesen, dafuer 
bleiben die letzten 450 pixel auf dem stand des letzten. In wirklichkeit 
wird so versucht 1800 pixel zu lesen.