Holla zusammen.
@jeffrey
Ja, ich gebe dir Recht, dass die Zeit wohl keine Rolle für die Positionsberechnung spielt.
Ich wollte damit nur andeuten, dass die aufgenommenen X-/Y-Werte eben nicht stetig erfolgen.
Wenn man sich das Datenblatt zum Sensor ansieht, dann ist der Defaultmode so eingestellt, dass man nicht kontinuierlich vom Sensor Daten gepusht bekommt, sondern dass man sie selber abholen muss. (Kommando DIASBLE "Disable stream mode" ist Default.)
Somit stellt sich mir die Frage, wie PRobot die Sensorabfrage macht. (Natürlich auch, ob eine andere Initialisierung vorgenommen wird.)
Weiter wird als Defaulteinstellung eine Auflösung von 8 counts/mm angegeben. Finde ich schon ominös, dass in mm und nicht in inch angegeben wird. Nochmals ominös ist, dass mit der maximal einstellbaren Auflösung von 16 counts/mm gerade mal eine Auflösung von 16*2,54=40,64 cpi erreicht wird. Angegeben wird der Sensor aber mit 400 cpi.
Mit diesem Default von 8 counts/mm müsste ein alpha-Wert im EXECL von mare_crisium von 0,125 eingetragen werden.
Wenn man nun mal ganz blöde diesen Wert durch 2,54 mm/inch teilt, dann kommt man auf 0,049.
Dies kommt dem von mare_crisium oben angegeben Wert von 0,05 für einen halbwegs sinnvollen Output merkwürdig nahe.
Halbwegs deshalb, da dann die gefahrenen X- bzw. Y-Strecken aber nur ca. 32 mm ausmachen.
Es bleibt dabei, dass eigentlich 62,6 mm in X- und Y-Richtung gefahren sein müssten.
Und deshalb bleibe ich dabei, dass mir der Maßstab für X und Y, und auch die in mm angegeben Entfernungen, in der Grafik im Excel-Blatt nicht so recht einleuchten.
kaktus hatte am 30.07..2008 ja schon darauf hingewiesen, dass bei einem 90°-Turn die aufgenommenen X- und Y- Zählerwerte identisch sein müssen. Er hatte vorgeschlagen den großen durch den kleinen Wert zu teilen und hatte den Faktor 1959/ 827 = 2,369 angegeben.
Auch hier kommen wir den 2,54 mm/inch wieder 'gefährlich' nahe.
Eine an den Haaren herbeigezogene Annahme:
Wie würde es aussehen, wenn eine der Koordinaten in mm und die andere in inch vom Sensor gesendet werden?
Wie überhaupt werden die Daten transportiert?
@PRobot
Kannst du hier weiterhelfen, was du vom Sensor bekommst?
Laut Datenblatt kommt auf ein "READ_DATA"-Kommando ein "FA nn nn nn"
Leider nur mit einem Verweis auf die 'IBM PS/2 Mouse Technical Reference'. (Käuflich für 7,90 Dollar zu erwerben.)
Was zum Teufel sind die nn nn nn? 3 Byte? Laut Datenblatt liegen Information zur Richtung und Stärke der Bewegung vor. "... mathematically determining the direction and magnitude of movement."
Wenn "nn nn nn" X, Y, Beschleunigung sind, dann müssten X und Y vorzeichenbehaftet sein. Die delta_x- und delta_y-Werte liegen immer unter diesen dann möglichen +/-128
Liegt eventuell ein Überlauf in den Koordinatenangaben vom Sensor vor? Messrate zu klein?
Das könnte dann zu der von mir angesprochenen 'Kraut und Rüben'-Kurve führen, da beim Abschneiden von höchstwertigen Bits nur der 'flatternde' Anteil der letzten 7 Bit benutzt werden.
Mehr fällt mir im Moment nicht mehr ein.
Gruß Sternthaler
Lesezeichen