Zwei Mäuse mit unterschiedlichen Daten

[Timo T. (Gast)]

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

[P. M. (o-o)]

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.

[Timo T. (Gast)]

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ß

[P. M. (o-o)]

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.

[MaWin (Gast)]

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.

[P. M. (o-o)]

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.

[Timo T. (Gast)]

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

[ollib. (Gast)]

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.

[Christian B. (casandro)]

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.

[Mike (Gast)]

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.

[Max M. (jens2001)]

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.

[Rolf M. (rmagnus)]

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.

[Max M. (jens2001)]

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.

[Timo T. (Gast)]

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!

[Timo T. (Gast)]

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?

[Max M. (jens2001)]

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.

[Guido Körber (Gast)]

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.

[Timo T. (Gast)]

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.