Hallo zusammen!
Ich habe folgendes Problem:
Für ein Projekt sollen die Rohdaten einer Maus ausgelesen werden. Ich
habe mich für eine nette Lösung entschieden, wo man über Linux auf die
Input Datei zugreift und die Daten dann einfach mit einem kleinen Python
skript ausliest.
Die Daten werden dann in eine Xlsx Datei geschrieben und ein Graph
erstellt.
Das funktioniert auch sehr gut, aber nun wollte ich eine Maus mit dem
Avago ADNS 9800 Sensor auslesen und bekam das was ihr im anhang als
adns9800.png findet
Also ein sehr merkwürdiges ZigZag statt eines halbwegs linearen
Verlaufs. Meine eigene Fireglider von Sharkoon liefert das
erwartete(Anhang fireglider.png)
beides sind Laser Mäuse, nur mit unterschiedlichen Sensoren.
Wenn ich die Datasheets beider vergleiche, so sehe ich, das beim Avago
9800 Delta_X_L/H und Delta_Y_L/H ausgegeben werden anstatt nur Delta_X/Y
wie bei der Fireglider. Wäre die Annahme korrekt, das sich der Verlauf
dadurch ergibt, das der 9800 Sensor High/Low daten ausgibt? Gibt es eine
Möglichkeit das irgendwie zu Filtern? So das ich nur einsvon beiden oder
ein gemittelten Wert erhalte?
der Python Code sieht so aus:
[http://stackoverflow.com/questions/4855823/get-mouse-deltas-using-python-in-linux]
Ich wäre für alle Hinweise dankbar :)
Gruß
P.S.: Die Graphen zeigen eine horizontale Verschiebung. Aufgetragen ist
nur die X-Koordinate über n
Timo Teller schrieb:> Gibt es eine> Möglichkeit das irgendwie zu Filtern?
Die Daten umzuordnen oder einen Mittelwert zu bilden, sollte mit irgend
einer Skript-/Programmiersprache kein Problem sein. Das sollte man
eigentlich können, wenn man sich an solche Experimente wagt, sonst macht
es wenig Sinn. Fertig findet man da aber eher nichts.
P. M. schrieb:> Timo Teller schrieb:>> Gibt es eine>> Möglichkeit das irgendwie zu Filtern?>> Die Daten umzuordnen oder einen Mittelwert zu bilden, sollte mit irgend> einer Skript-/Programmiersprache kein Problem sein. Das sollte man> eigentlich können, wenn man sich an solche Experimente wagt, sonst macht> es wenig Sinn. Fertig findet man da aber eher nichts.
Ich habe hier nicht danach gefragt, mir einen Code vorzuschreiben. Ich
wollte wissen, ob meine Annahme richtig ist. Falls sie richtig ist,
könnte ich ja ruhigen gewissens eine Sortierung vornehmen. Und keine
Sorge, Daten sortieren kriege ich hin ;)
Das Experiment ist auch nicht gefährlich. Da kann ich auch mit weniger
Hintergrundwissen ran gehen :)
Gruß
Also nach High/Low-Daten im Sinne eines H/L-Bytes sieht das jedenfalls
nicht aus. Die Unregelmässigkeiten bei rund jedem zehnten Wert sehen für
mich ebenfalls verdächtig aus.
Ich würde zunächst nach einem Datenblatt suchen und falls das nicht
hilft, mit verschiedenen Messreihen (schneller, langsamer,
beschleunigen, usw.) versuchen herauszufinden, was die Daten ungefähr
bedeuten.
Meiner Meinung nach liest du die Daten so low level, vor dem
Maustreiber, dass du das indivuduelle Protokoll der jeweiligen Maus
liest.
Und das ist eben bei adns nicht button,x,y als Bytes.
Ich überlege, ob button,xhi,xlo,yhi,ylo den Effekt ergeben könnte, wenn
man sie mit dem oberen Protokoll einliest, meine aber nein.
MaWin schrieb:> Ich überlege, ob button,xhi,xlo,yhi,ylo den Effekt ergeben könnte, wenn> man sie mit dem oberen Protokoll einliest, meine aber nein.
In diesem Fall müsste sich der LOW-Wert über den gesamten Wertebereich
ändern, bevor sich der HI-Wert auch nur um eins ändert.
Im moment bin ich mir halt nicht sicher. Ich werde morgen einfach noch
mehr Messungen machen. Im Datenblatt werden natürlich nur die Funktionen
des Sensors dargestellt. Ich weiss nciht, was der MC da genau
abfragt,aber die motion Abfrage scheint mir sinn zu machen:
"Register 0x02 allows the user to determine if motion has occurred since
the last time it was read. If the MOT
bit is set, Delta_X_L, Delta_X_H, Delta_Y_L and Delta_Y_H register
should be read in sequence to get the
accumulated motion."
Im schlechtesten Fall, muss ich einen anderen Sensor (bzw. eine andere
Maus verwenden), aber ich würde das Rätsel gerne gelöst wissen^^
Gute Nacht!
Timo
sieht für mich so aus als würden immer 2 werte abwechselnd gesendet,
z.B. x /y. aller paar werte dann noch ein zusätzlicher wert, vielleicht
ein mittelwert oder so.
Also mit Linien dazwischen kann man dazu nichts aussagen, weil man nicht
sieht was da eigentlich passiert. Auch fehlt die Größenordnung. Das
Zick-Zack ist für das Integral, sprich die Zeigerposition, in aller
Regel irrelevant.
Timo T. schrieb:> Ich weiss nciht, was der MC da genau> abfragt,aber die motion Abfrage scheint mir sinn zu machen:
Nein, scheint sie nicht. Wenn jeder zweite ein H-Werte wäre und sich
dabei so stetig ändert, müsste sich der zugehörige L-Wert sich ziemlich
zufällig benehmen, tut der zweite Wert aber nicht. Der ändert sich
ebenfalls sehr stetig.
Also ich kenn mich nicht mit Linux und nicht mit Pyton aus.
Aber für mich ist völlig offensichtlich was da bei der "zickzack" Kurve
passiert. Da werden bei den "zick" werten einfach 2 Delta-Werte
zusammengefasst. Denn die "zick"Werte sind meist ca. doppelt so hoch wie
die "zack" werte. Irgendwie schreibt die Maus die Delta-Werte schneller
in die
/dev/input/mice. als dein Pyton sie abholt. Und um keine Delta zu
verlierenwerden sie einfach akkumuliert.
Max Mustermann schrieb:> Aber für mich ist völlig offensichtlich was da bei der "zickzack" Kurve> passiert.
Die Erklärung klingt plausibel. Es würde auch erklären, warum bei dem
größeren Ausreißer auf der rechten Seite sowohl nach oben, als auch nach
unten "ausgerissen" wird. Da war der Rechner kurz mit was beschäftigt,
oder der Python-Garbage-Collector hat zugeschlagen oder so, und deshalb
kam die eine Abfrage etwas später, und es wurde vorher mehr Weg
zurückgelegt.
Was hier rauskommt, sind ja nicht die Werte vom Sensor, sondern vom
Treiber, und der muß irgendwie sicherstellen, daß keine Bewegung
verloren geht, auch wenn die Daten mal nicht so oft abgefragt werden
können, wie der Sensor sie liefert.
Rolf Magnus schrieb:> ...daß keine Bewegung verloren geht...
Der Mauszeiger läuft dann nur ein wenig "ruckelig"
Und man sieht auch das in ziemlich regelmässigen Abständen
ein"Doppelzack" auftritt.
Freut mich, dass hier so viele Ideen kommen. Max Mustermanns Erklärung
klingt in der Tat sehr plausibel und vor allem ziehe ich daraus den
Schluss, das ich die Daten nicht sortieren brauche, da die grundlegende
Information ja noch vorhanden ist.
Ich werde trotzdem im Laufe des Tages mal beide Sensoren mit gleichen
Parametern (Dpi, Polling Rate, Oberfläche) testen.
Danke fürs Feedback bisher!
So! Ich habe mal je drei mal die Drakonia (die hat den Avago ADNS 9800)
und die Fireglider betestet. Dpi war 1200, die Pollingrate 125 HZ.
Oberfläche war mein Arbeitstisch(Matt).
Leider war meine Geschwindigkeit nicht immer die gleiche. Ich vergleiche
aber die Messungen, bei denen in der Summe in etwa die gleichen X-Werte
auftreten.
Anhang 1 und 2 zeigen je die drei Messungen (Automatischer Stop bei 150
Messungen)
Anhang 3 Stellt die Summen als Balkendiagramm dar. Nach optischen
Maßstäben habe ich dann Messungen mit gleichen Summen ausgewählt und im
Anhang 4 und 5 Dargstellt.
Grad in den Letzten beiden Bilder kann man gut sehen wie die Kurve der
FG zumindest stellenweise die DR Kurve "mittelt". Nur weiss ich noch
nicht, wie ich das zu interpretieren habe :)
Ideen?
Wenn dein Grafikprogramm das kann.
Mach mal eine Grafiken in der die Werte aufaddiert werden
So dass der Y-Wert dem gesamt zurückgelegten Weg entspricht.
Dann sollten die Kurven ungefär die gleiche Steigung haben.
Nur das die einen ebend "glatter" sind als die anderen.
Was mir jetzt nicht so ganz klar ist: Werden da die Mausdaten auf der
HID-Treiberebene gelesen, oder direkt auf den Sensor der Maus
zugegriffen?
Wenn letzteres nicht der Fall ist, dann hilft das Datenblatt des Sensors
nicht wirklich weiter.
Werden die Daten auf der HID-Ebene angeholt, dann wäre ein Blick auf den
Descriptor der Maus mal hilfreich. Da teilt die Maus nämlich mit wie sie
ihre Daten zur Anlieferung verpackt. Eine ordentliche Gaming-Maus sollte
16 Bit pro Achse abliefern, da es sonst etwas eng wird die Daten bei
schnellen Bewegungen durch den USB zu kriegen.
Wenn die Zahl der Mickeys (Mausimpulse) bei konstanter Bewegung zwischen
aufeinander folgenden Datenpaketen deutlich schwankt, dann liegt das
wahrscheinlich mehr an der Pufferstrategie im Mauscontroller als am
verwendeten Sensor. Treffen da ungeschickte Kombinationen von Abholen
vom Sensor und Weiterschicken per USB aufeinander, dann kann so eine
Sägezahnkurve entstehen.
Guido Körber schrieb:> Was mir jetzt nicht so ganz klar ist: Werden da die Mausdaten auf der> HID-Treiberebene gelesen, oder direkt auf den Sensor der Maus> zugegriffen?>> Wenn letzteres nicht der Fall ist, dann hilft das Datenblatt des Sensors> nicht wirklich weiter.>> Werden die Daten auf der HID-Ebene angeholt, dann wäre ein Blick auf den> Descriptor der Maus mal hilfreich. Da teilt die Maus nämlich mit wie sie> ihre Daten zur Anlieferung verpackt. Eine ordentliche Gaming-Maus sollte> 16 Bit pro Achse abliefern, da es sonst etwas eng wird die Daten bei> schnellen Bewegungen durch den USB zu kriegen.>> Wenn die Zahl der Mickeys (Mausimpulse) bei konstanter Bewegung zwischen> aufeinander folgenden Datenpaketen deutlich schwankt, dann liegt das> wahrscheinlich mehr an der Pufferstrategie im Mauscontroller als am> verwendeten Sensor. Treffen da ungeschickte Kombinationen von Abholen> vom Sensor und Weiterschicken per USB aufeinander, dann kann so eine> Sägezahnkurve entstehen.
Also ich denke das alles läuft auf HID Ebene ab, da ich über Python auf
die "Mausdatei" in linux zugreife und nicht auf den Sensor. Meine
Annahme war bisher allerdings, das die Datenpackete mehr oder weniger
die gleichen sein sollten, egal wer die Anfrage grade sendet.
Aber interessanter Hinweis. Ich werde das mal im Netz mit dem Maus
Descriptor suchen, das wird ja doch recht spannend hier :)
Anbei die Summierten Daten in den Anhängen. Wenn mans nicht allzu genau
nimmt, könnte man eine ähnliche Steigung feststellen.
adns9800.png
(120 KB)
fireglider.png
(36 KB)
