Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden.
Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
2 x ADNS-9500 + Arduino auf eigener Platine SPI - 4,5 Volt Spannung auf 3,3 V Schiene
- Ersteller Osiris1
- Erstellt am
- Registriert
- Feb. 2008
- Beiträge
- 351
Also der SPI Adapter ist fertig und angeschlossen. Hab mal die Spannung gemessen und das schaut jetzt ganz gut aus. Laser ist on. 5V liegen auf der 5V Schiene und 3,3V auf der 3,3V Schiene.
So weit so gut. Leider spinnt das SPI jetzt. Das einzige was noch korrekt ausgelesen wird ist die Product ID. Die Revision Number ist schon wieder Unsinn und alles andere auch. Um auszuschließen, dass der Chip kaputt ist, habe ich ihn mal testweise ohne Adapter angeschlossen. Die Spannungen sind zwar wieder jenseits von gut und böse, allerdings kann ich zumindest die Register wieder normal auslesen.
Daraus schließe ich:
1. Der IC ist noch nicht hinüber
2. Die Widerstände stören das SPI
3. Ob der Sensor selbst einen Schaden hat, lässt sich nicht beurteilen.
Kann das evtl an den SPI Timings liegen? Bzw wo kann das Problem sonst noch liegen? Inzwischen bin ich irgendwie recht ratlos.
Das ist übrigens mein aktualisierter Schaltplan:
Das der Ätzplan für den Adapter:
Anhang anzeigen SPI-3V5V-Adapter_etch_copper_top.pdf
So weit so gut. Leider spinnt das SPI jetzt. Das einzige was noch korrekt ausgelesen wird ist die Product ID. Die Revision Number ist schon wieder Unsinn und alles andere auch. Um auszuschließen, dass der Chip kaputt ist, habe ich ihn mal testweise ohne Adapter angeschlossen. Die Spannungen sind zwar wieder jenseits von gut und böse, allerdings kann ich zumindest die Register wieder normal auslesen.
Daraus schließe ich:
1. Der IC ist noch nicht hinüber
2. Die Widerstände stören das SPI
3. Ob der Sensor selbst einen Schaden hat, lässt sich nicht beurteilen.
Kann das evtl an den SPI Timings liegen? Bzw wo kann das Problem sonst noch liegen? Inzwischen bin ich irgendwie recht ratlos.
Das ist übrigens mein aktualisierter Schaltplan:
Das der Ätzplan für den Adapter:
Anhang anzeigen SPI-3V5V-Adapter_etch_copper_top.pdf
Okay, hast du ein digitales Oszilloskop zur Hand?
Denn der nächste Schritt wäre jetzt, alle SPI-Leitungen zu messen und die Pulse darauf zu dekodieren und vergleichen, ob sie zu dem passen, was du schickst bzw. erwartest.
Eine Möglichkeit wäre auch noch, dass das MISO Probleme bereitet (hab ich früher schon mal erwähnt)
Dies lässt sich aber alles mit einer einfach Oszi-Messung feststellen.
Denn der nächste Schritt wäre jetzt, alle SPI-Leitungen zu messen und die Pulse darauf zu dekodieren und vergleichen, ob sie zu dem passen, was du schickst bzw. erwartest.
Eine Möglichkeit wäre auch noch, dass das MISO Probleme bereitet (hab ich früher schon mal erwähnt)
Dies lässt sich aber alles mit einer einfach Oszi-Messung feststellen.
- Registriert
- Feb. 2008
- Beiträge
- 351
Phu nein hab ich nicht. Auf der Uni müsste es aber welche geben. Ich hab halt noch nie mit einem Oszilloskop gearbeitet. Auf was müsste ich da schaun? Wenn ich die Pulse einzeln auslese führt das ja zu einer unüberschaubaren Datenmenge.
Die Uni hat sicher welche.
Naja, dann wird Zeit fürs erste Mal
Am besten, du schnappst dir einen Freund/Studienkollegen/nettten Tutor etc. der dir bei den ersten Messungen hilft und dir das Gerät erklärt, denn bis ich das alles hier getippt hab, dauerts ewig.
Du müsstest folgende Signale aufzeichen:
SCLK
MOSI
MISO
NCS (von einem Sensor)
die Messung führst zwischen IC und Spannungsteiler aus.
Dann machst du einem Lesezugriff auf die Product ID und haltest den kompletten schreib-&lese-Zugriff am Oszi fest. (alle gesendeten und gelesen Bytes)
Diese dekodierst du dann händisch und vergleichst Sie mit dem, was du per Software ausgelesen hast. Wenns passt, gut, wenn nicht weißt du ob der Sensor Schwachsinn schickt oder du Schwachsinn liest (SW-Fehler am Uno).
Das Prozedere wiederholst du mit der Revision Number.
Und ja, das gibt Berge an Messdaten, die lassen sich aber gut auswerten und verwerten für Uni-Arbeiten (bsc, msc etc.... )
Naja, dann wird Zeit fürs erste Mal
Am besten, du schnappst dir einen Freund/Studienkollegen/nettten Tutor etc. der dir bei den ersten Messungen hilft und dir das Gerät erklärt, denn bis ich das alles hier getippt hab, dauerts ewig.
Du müsstest folgende Signale aufzeichen:
SCLK
MOSI
MISO
NCS (von einem Sensor)
die Messung führst zwischen IC und Spannungsteiler aus.
Dann machst du einem Lesezugriff auf die Product ID und haltest den kompletten schreib-&lese-Zugriff am Oszi fest. (alle gesendeten und gelesen Bytes)
Diese dekodierst du dann händisch und vergleichst Sie mit dem, was du per Software ausgelesen hast. Wenns passt, gut, wenn nicht weißt du ob der Sensor Schwachsinn schickt oder du Schwachsinn liest (SW-Fehler am Uno).
Das Prozedere wiederholst du mit der Revision Number.
Und ja, das gibt Berge an Messdaten, die lassen sich aber gut auswerten und verwerten für Uni-Arbeiten (bsc, msc etc.... )
- Registriert
- Feb. 2008
- Beiträge
- 351
So hab mir das ganze jetzt auf dem Oszi angeschaut:
Vor dem Spannungsteiler:
Nach dem Spannungsteiler:
Wundert mich nicht, dass da nix sinnvolles rauskommt. Werd das ganze morgen am Breadboard testen um zu schauen ob ich mich verlötet habe oder das Design schlecht ist.
Weitere Erkenntnisse:
- Der Takt über SCLK wird nur gesendet wenn Daten übertragen werden.
- Der Laser funktioniert (in der Handykamera sichtbar).
- Auch mit einer externen Stromversorgung des Arduinos bessert sich nichts.
Ich glaub das wars vorerst. ^^
Vor dem Spannungsteiler:
Nach dem Spannungsteiler:
Wundert mich nicht, dass da nix sinnvolles rauskommt. Werd das ganze morgen am Breadboard testen um zu schauen ob ich mich verlötet habe oder das Design schlecht ist.
Weitere Erkenntnisse:
- Der Takt über SCLK wird nur gesendet wenn Daten übertragen werden.
- Der Laser funktioniert (in der Handykamera sichtbar).
- Auch mit einer externen Stromversorgung des Arduinos bessert sich nichts.
Ich glaub das wars vorerst. ^^
Hi,
omg, das kann ja nie funktionieren
Der erste Gedanke: kapazitive Last nach dem Spannungsteiler!
Der Blick ins Datenblatt des Sensors: 10pF Input Capacity ....
Laut meiner Berechnung sollte der Spannungsteiler genug Strom liefern, und 15pF treiben können.
Allerdings würde ich zum ausprobieren die Widerstände des Spannungsteilers auf 1kohm & 1,5kohm verringern, da dies ohne Überlast an den Ausgänge des Arduino möglich ist.
Ich wage einmal zu behaupten, dass die Spannungsversorgungen okay sind und die Spannungsteiler trotzdem benötigt werden. Auch der Rest der Schaltung scheint zu funktionieren. Es hapert anscheinend nur an der Kommunikation.
Grüße!
omg, das kann ja nie funktionieren
Der erste Gedanke: kapazitive Last nach dem Spannungsteiler!
Der Blick ins Datenblatt des Sensors: 10pF Input Capacity ....
Laut meiner Berechnung sollte der Spannungsteiler genug Strom liefern, und 15pF treiben können.
Allerdings würde ich zum ausprobieren die Widerstände des Spannungsteilers auf 1kohm & 1,5kohm verringern, da dies ohne Überlast an den Ausgänge des Arduino möglich ist.
Ich wage einmal zu behaupten, dass die Spannungsversorgungen okay sind und die Spannungsteiler trotzdem benötigt werden. Auch der Rest der Schaltung scheint zu funktionieren. Es hapert anscheinend nur an der Kommunikation.
Grüße!
- Registriert
- Feb. 2008
- Beiträge
- 351
Hab das jetzt nochmal mit 10 und 15 kohm am breadboard getestet. keine verbesserung.
Ok also liegts evtl daran, dass die widerstände zu hoch sind. ok werds mal ausprobieren.
Soooo... mit 1k ohm und 1,5k ohm widerständen schaut das ganze (also das rechteck signal) schon ganz gut aus. das einzige was mir nicht gefällt ist das miso signal. das hat eine menge noise (1V peaks (sobald kommunikation stattfindet) zwischen den echten 3V peaks).
Wenn ich ganz herauszoome, bekomme ich peaks bei 80hz mit ca 1V. Wenn Daten auftreten habe ich logischerweise peaks mit bis zu 3V. Die 80 hz kommen daher, dass ich bei jedem schleifendurchlauf in der software 10 ms verzögerung habe. 2 ms braucht der code vl ansich. Mit 20ms verzögerung habe ich 45hz. das ergibt sinn. nur frage ich mich woher der noise kommt...
Mit der config liefert chip a immerhin sinnvolle x und y werte (die aber um einen bestimmten faktor falsch sind). ein berechnungsfehler ist eher unwahrscheinlich, da das vorher ja gut funktioniert hat.
Chip b liefert weiterhin 0 als werte und hier treten auch keine 3V peaks auf der miso leitung auf bzw wenn dann nur wenn ich andere register auslese. die x/y register bleiben also leer. Vielleicht sind die sensoren doch kaput?
für chip b:
Die beiden 3V peaks am anfang und am ende sind motion byte und resolution. die liefern immer werte zurück. der teil in der mitte bleibt leer, weil die x/y register abgefragt werden und da 0 drinnen steht.
Chip A liefert auch 3V peaks zwischen den beiden links und rechts wenn eine bewegung aufgetreten ist.
Das Clocksignal ist eher mäßig:
active low? hehe...
Der Rest bis auf MISO ist aber durchaus schön rechteckig.
Ok also liegts evtl daran, dass die widerstände zu hoch sind. ok werds mal ausprobieren.
Ergänzung ()
Soooo... mit 1k ohm und 1,5k ohm widerständen schaut das ganze (also das rechteck signal) schon ganz gut aus. das einzige was mir nicht gefällt ist das miso signal. das hat eine menge noise (1V peaks (sobald kommunikation stattfindet) zwischen den echten 3V peaks).
Wenn ich ganz herauszoome, bekomme ich peaks bei 80hz mit ca 1V. Wenn Daten auftreten habe ich logischerweise peaks mit bis zu 3V. Die 80 hz kommen daher, dass ich bei jedem schleifendurchlauf in der software 10 ms verzögerung habe. 2 ms braucht der code vl ansich. Mit 20ms verzögerung habe ich 45hz. das ergibt sinn. nur frage ich mich woher der noise kommt...
Mit der config liefert chip a immerhin sinnvolle x und y werte (die aber um einen bestimmten faktor falsch sind). ein berechnungsfehler ist eher unwahrscheinlich, da das vorher ja gut funktioniert hat.
Chip b liefert weiterhin 0 als werte und hier treten auch keine 3V peaks auf der miso leitung auf bzw wenn dann nur wenn ich andere register auslese. die x/y register bleiben also leer. Vielleicht sind die sensoren doch kaput?
für chip b:
Die beiden 3V peaks am anfang und am ende sind motion byte und resolution. die liefern immer werte zurück. der teil in der mitte bleibt leer, weil die x/y register abgefragt werden und da 0 drinnen steht.
Chip A liefert auch 3V peaks zwischen den beiden links und rechts wenn eine bewegung aufgetreten ist.
Das Clocksignal ist eher mäßig:
active low? hehe...
Der Rest bis auf MISO ist aber durchaus schön rechteckig.
Zuletzt bearbeitet:
Hm, jetzt wirds dann bald schwierig.
Ideal wäre, wenn du einen neuen Sensor (der vorher nicht der überhöhten Versorgungsspannung ausgesetzt war) hast, und dieselben Analysen durchführen könntest. Damit lassen sich einige Fehlerquellen ausschließen. ( u.a. Chipdefekt)
Ich kann am Oszi nicht zoomen, aber die 1V noise zufällig die gleiche Frequenz bzw Flankenabstände wie das SCLK?
Würde zur "tritt nur auf wenn aktive Kommunikation" passen
Der "Messfehlerfaktor" ist konstant? Auch nach 100 Messungen?
Der Clock ist "so lala", noch immer gut kapazitiv verschliffen, kann natürlich auch noch am Tastkopf vom Oszi liegen. Ich finde, das ist aber Feinschliff und nicht funktionsbeeinträchtigend.
Ideal wäre, wenn du einen neuen Sensor (der vorher nicht der überhöhten Versorgungsspannung ausgesetzt war) hast, und dieselben Analysen durchführen könntest. Damit lassen sich einige Fehlerquellen ausschließen. ( u.a. Chipdefekt)
Ich kann am Oszi nicht zoomen, aber die 1V noise zufällig die gleiche Frequenz bzw Flankenabstände wie das SCLK?
Würde zur "tritt nur auf wenn aktive Kommunikation" passen
Der "Messfehlerfaktor" ist konstant? Auch nach 100 Messungen?
Der Clock ist "so lala", noch immer gut kapazitiv verschliffen, kann natürlich auch noch am Tastkopf vom Oszi liegen. Ich finde, das ist aber Feinschliff und nicht funktionsbeeinträchtigend.
- Registriert
- Feb. 2008
- Beiträge
- 351
1. Ich könnte mir vorstellen, dass die Taktflanken des Noises im MISO mit der Clockfrequenz zusammenhängen.
2. Der Fehlerfaktor ist nur innerhalb einer Messreihe konstant. Wenn ich neu starte/kompiliere ändert sich der leicht. Insgesamt bewegt sich der scheinbar zwischen 0.8 und 0.5.
3. Ich hab jetzt 4 frischen Sensoren, und werd das ganze bis Montag auf einem Breadboard testen. Wenns dann geht liegt es entweder an der Platine oder die alten Chips sind kaputt. Daher wird der folgende Schritt sein, auch die alten Chips am Breadboard zu testen.
Ich meld mich dann wieder und bin immernoch dankbar für deine Hilfe
2. Der Fehlerfaktor ist nur innerhalb einer Messreihe konstant. Wenn ich neu starte/kompiliere ändert sich der leicht. Insgesamt bewegt sich der scheinbar zwischen 0.8 und 0.5.
3. Ich hab jetzt 4 frischen Sensoren, und werd das ganze bis Montag auf einem Breadboard testen. Wenns dann geht liegt es entweder an der Platine oder die alten Chips sind kaputt. Daher wird der folgende Schritt sein, auch die alten Chips am Breadboard zu testen.
Ich meld mich dann wieder und bin immernoch dankbar für deine Hilfe
- Registriert
- Feb. 2008
- Beiträge
- 351
So ich hab jetzt das Design überarbeitet und die Chips in das neue PCB eingelötet. Beide Chips funktionieren jetzt! Mir bereiten jetzt nur 2 Dinge Kopfzerbrechen:
1: Wenn ich das Terminal neu starte, habe ich aus irgendwelchen gründen schon Bewegungswerte von ca 0.1 mm (Das sind absolute Werte im Bezug auf den Startpunkt). Wobei die ja eigentlich null sein sollten nach einem Neustart. Abgesehen davon lese ich einmal im Setup die Delta x/y Werte aus ohne die Werte zu verwenden wodurch die Register ja auch zurückgesetzt werden sollten.
2: Der eine Chip misst auf 20 cm immer noch ca 2,5 cm zu viel. der andere um ca 3 cm. Habs auch schon mit einer extra Stromversorgung von 7.4V für das Arduino versucht. Hat aber auch nichts gebracht. Das könnte jetzt natürlich ein Rechenfehler sein... Aber da die Daten von den Chips unterschiedlich falsch sind, ist das eher unwahrscheinlich.
Vielleicht liegts auch daran, dass die Linsen nicht 100% fix montiert sind und ein bisschen wackeln...
1: Wenn ich das Terminal neu starte, habe ich aus irgendwelchen gründen schon Bewegungswerte von ca 0.1 mm (Das sind absolute Werte im Bezug auf den Startpunkt). Wobei die ja eigentlich null sein sollten nach einem Neustart. Abgesehen davon lese ich einmal im Setup die Delta x/y Werte aus ohne die Werte zu verwenden wodurch die Register ja auch zurückgesetzt werden sollten.
2: Der eine Chip misst auf 20 cm immer noch ca 2,5 cm zu viel. der andere um ca 3 cm. Habs auch schon mit einer extra Stromversorgung von 7.4V für das Arduino versucht. Hat aber auch nichts gebracht. Das könnte jetzt natürlich ein Rechenfehler sein... Aber da die Daten von den Chips unterschiedlich falsch sind, ist das eher unwahrscheinlich.
Vielleicht liegts auch daran, dass die Linsen nicht 100% fix montiert sind und ein bisschen wackeln...
VermutlichVielleicht liegts auch daran, dass die Linsen nicht 100% fix montiert sind und ein bisschen wackeln...
Freut mich zu hören, dass es jetzt funktioniert.
Der Rest ist nun nur mehr Software & Kalibrierung. Viel Glück beim fertigstellen!
Und ein frohes Fest natürlich
- Registriert
- Feb. 2008
- Beiträge
- 351
Also auch wenn ich alle Bauteile gut fixiert habe, gibts eine Abweichung (beim einen Chip ~2%, beim anderen ~4%). Also von Chip zu Chip unterschiedlich, aber insgesamt recht konstant. Ich hab das auch einzeln getestet. Also SPI Leitungen liegen nur an einem Chip an (Strom kann ich leider mit dem Design nicht trennen). Auch hier die gleiche Abweichung wie im Mischbetrieb.
Auch mit einer externen Stromversorgung von 7V fürs Arduino gabs da keine Besserung.
Ich hab leider keinen Plan woher diese Abweichung kommen kann. Integrierte Mausbeschleunigung? Aber warum dann unterschiedlich? Außerdem ist die Abweichung immer gleich egal wie schnell ich das Ding bewege.
Im schlimmsten Fall muss ich das rechnerisch ausgleichen. Aber ich weiß halt nicht wie groß oder konstant dieser Fehler überhaupt ist. :/
PS: Danke ^^ War recht ok
Auch mit einer externen Stromversorgung von 7V fürs Arduino gabs da keine Besserung.
Ich hab leider keinen Plan woher diese Abweichung kommen kann. Integrierte Mausbeschleunigung? Aber warum dann unterschiedlich? Außerdem ist die Abweichung immer gleich egal wie schnell ich das Ding bewege.
Im schlimmsten Fall muss ich das rechnerisch ausgleichen. Aber ich weiß halt nicht wie groß oder konstant dieser Fehler überhaupt ist. :/
PS: Danke ^^ War recht ok