Hallo Forum, ich bastel gerade an meiner Masterarbeit in der ich einen Sensor entwickeln soll, der möglichst berührungslos erkennt, wenn eine Carbon-Fasermatte das rutschen beginnt. Da das ganze natürlich (wäre sonst ja zu einfach ;)) höchst integriert sein soll, eignen sich da wohl optische/laser Maussensoren ziemlich gut. Ich hab bereits den ADNS 5020 erfolgreich verwendet, doch da ist die Auflösung ein wenig zu mager. Deshalb hab ich jetzt den ADNS 9800 angestöpselt. Dieser aber bereitet mir Kopfschmerzen. Evtl. hat ja wer von euch ne idee. Das Problem: Kommunikation zu dem Chip läuft 1A (1&2 MHz SPI Frequ. getestet). Doch obwohl ich wie in dem Datenblatt beschrieben die SROM auf den Chip lade, will der die nicht ausführen. Auch die Firmwareversion bleibt immer auf default ( lässt vermuten, dass die garnet richtig aufgespielt ist). Allerdings wenn ich das Motion Register auslese sagt der mir, dass die Laser_Power = valid ist aber der XY- Laser immer wieder ein fehler meldet (shorted to GND). Hier im Anhang ein kleines Bildchen vom Oszi.. Weiss jehmand was das zu bedeuten hat ? und ob man die SROM tatsächlich benötigt? Hab gelesen, dass man die nach dem Power-up neu laden muss. Produkt ID usw. gehen auch ohne. Wenn ich die wirklich brauche, wiso bastelt der mir dann da fehler in das Register? Grüße HtS
Angehängte Dateien:
-
ADNS9800_xy-Laser_nofail.jpg
230 KB -
ADNS9800_xy-Laser_fail.jpg
230 KB
:
Verschoben durch User
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?
Angehängte Dateien:
-
456.png
4,4 KB -
testtest.png
5,3 KB
Harald schrieb: > und ich kann das PGM nur als Textfiles öffnen, Das scheint PNG zu sein. Einfach umbenennen.
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
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.
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.
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.