Hallo,
Zitat Zitat von Sternthaler
...Tapeten sind alle an den Wänden und Decken (Deine lotrechten Wünschen haben sehr gut geholfen)...
Eine Sorge weniger.
Zitat Zitat von Sternthaler
...Nein, irgendwie hätte ich da vorher einen besseren Hinweis geben sollen, was dargestellt wird...
Nein, nein, ich hatte nur bisher nicht ALLE Beiträge aufmerksam durchgelesen. Habs erst heute getan (und war nach einem ruhigen Flug recht aufnahmebereit).
Zitat Zitat von Sternthaler
Die X-Achse zeigt die Tik's ...jeder Tik der Auslöser zum messen der Zeit ist, ist auf der Y-Achse eine Zeitangabe...
Ok, ich hoffe ich habs jetzt verstanden. Es ist aber [polemik] ein Zeitbedarf, keine Zeitangabe[/polemik].

Ich sitze über Deinem Excelsheet, insbes. "Nettodaten-31" (Diagramm) und überlege mir sinnvolle Fehlerquellen (ich hoffe, dass bei mir unterm Weihnachtsbaum ein Asuro liegt, bis dahin müsste ich viel fitter in (AVR-)Assembler und -Syntax werden - und Ähnliches wie Dein Problem wird bei mir haufenweise kommen ). ICH schlage mich momentan mit einem Timerinterrupt für einen Servotester mit einem tiny13 herum .

Ok, Du zeigst also im Diagramm Zeitdifferenzen (Z-Achse) pro Weg (genauer pro 45°-Umfang des Rades). Dargestellt wird somit eine inverse Geschwindigkeit (die umso grösser ist, je niedriger der Z-Wert).

Beobachtungen:
Im Diagramm "Daten-26" vom 12Okt2007,1:15 bin ich, ebenso wie ihr, über die nach unten um ähnliche Beträge verschobenen Punkte im Diagramm gestolpert. Wir sehen also, dass da die Geschwindigkeit über nahezu eine Umdrehung sprungweise ZUGENOMMEN (der Zeitbedarf hat um etwa gleiche offsets abgenommen) und danach über etwa den gleichen Sprung wieder abgenommen hat. Hmmmmmmm - grübel. Die Verschiebung erstreckt sich jeweils über etwa eine ganze Umdrehung (7 bis 8 ticks, einmal nur einer). Im Diagramm "nettodaten-31" haben wir ebenfalls eine annähernd gleiche, blockweise, Verschiebung mit entsprechender Rückkehr zum (der Anschauung nach) glaubhaften Wert. Hmmmmmmm - noch mehr grübel.

FMEA
-Reibung? Kann´s ja wohl nicht sein, weil die Geschwindigkeit zu Beginn des Fehlers zunimmt. Sprunghaft!
-Negative Reibung (Durchdrehen, Durchrutschen)? Aber doch wohl nicht mit der Konstanz!
-Exzentrizität (eiern)? Die einzige Exzentrizität die ich feststelle, ist dieses exzentrische (im Sinne von ausgefallen) Problem. Eiern hatten wir ja schon alle ausgeschlossen.

(Zwischenbemerkung: Die Zeitdifferenzen nehmen sprungweise ab - und danach ebenso sprungweise wieder zu.)

-Falsche Zeitmessung? Kann es sein, dass Du Deinem Timer einen Startwert einschreibst der manchmal >konstant anders< ist? Diese Erklärung ist mir sympathisch, weil sie einen repetierbaren Vorgang im Rechnerablauf beinhaltet (der als Fehlerursache bei meinen Experimenten schon mal auftritt).
-Falsche Zeitmessungdiezweite? Ich gehe davon aus, dass der Prozessortakt nicht geteilt wird. Auch nicht zeitweise.
-Falsche Zeitmessungdiedritte? Möglich wäre es, dass Dein OptoSensor mal einige Farbwechsel nicht erkennt. ABER dann gleich mehrere hintereinander? Und es ist ja nicht der DOPPELTE Zeitbedarf festgestellt worden, siehe oben.
-Falsche Zeitmessungdievierte? Möglich wären auch radiale, strahlenförmige Streifen auf der Codierscheibe. Wäre möglich, WENN Du die Scheibe selbst ausdruckst - beispielsweise mit einem Karusselldrucker - der druckt immer im Kreis und macht nicht horizontale sondern eben radiale Streifen.

Also mehr fällt mit im Moment nicht ein. Ich bin sicher, dass sich das Problem bald selbst löst und wenn dann ein Grund gefunden wird, ist der total simpel und keiner von denen, die ich mir überlegt hatte.