[hein]

In den letzten Wochen habe ich recht wenig getestet aber dafür viel gerechnet und modelliert. Für die Modellierungen musste ich einen großen Teil meiner Auswertungen in C++ neu schreiben, damit sie schnell genug laufen. Wer sich mit Programmiersprachen auskennt, kann sich vorstellen wie nervig diese Arbeit war - zumal ich C++ in den letzten 10 Jahren nicht mehr angefasst hatte...
So nervig es auch war, es hat sich gelohnt. Durch die Modellierungen konnte ich viele Fragen beantworten und wurde auf Probleme gestoßen, die ich vorher als nicht so gravierend eingeschätzt hätte. Diese Probleme führen auch dazu, dass ich ein paar meiner alten Analysen nicht mehr glaube. Grundsätzlich lassen sich für alle Probleme Korrekturen finden. Allerdings gelingt das nicht immer mit den Daten aus einem Test-Tag.
Aber mal der Reihe nach:
1) Eine exakte Höhenkarte der Teststrecke ist nach Geschwindigkeit und Watt der wichtigste Faktor bei der Berechnung des CdA Wertes. Auch flache Strecken haben immer wieder kleine Steigungen, die ein paar Watt schlucken. Wenn man nur die barometrische Höhe kennt, dann gehen diese Wellen unter. Die verlorene Geschwindigkeit wird dem CdA Wert zugeordnet.
2) Ein Sensor-Lag führt zu systematischen Fehlern, die sich nicht über die Zeit ausmitteln. Wenn z. B. die gemessenen Watt nicht exakt zeitsynchron mit der Höhenkarte laufen, dann wird ein falscher CdA Wert berechnet. Fährt man über eine kleine Welle, dann ist man am Beginn der Welle schneller, verliert dann etwas Geschwindigkeit und baut auf dem Bergabstück wieder Geschwindigkeit auf. Da man unterschiedlich lange auf den bergauf und bergab Teilstücken ist, bekommen die Teilstücke bei einer zeitbasierten Rechnung ein unterschiedliches Gewicht. Zusammen mit einer nicht zeitsynchronen Zuordnung der Watt-Werte führt jede kleine Welle zu einem verzerrten CdA-Wert. Längere Strecken mit mehr Wellen verfestigen diesen Fehler nur. Er wird nicht ausgeglichen.
3) GPS-Daten haben bei mir den größten Zeitversatz. Wenn man die Teststrecke anhand der GPS-Koordinaten bestimmen will, dann sind die "out" und "back" Abschnitte bei meinen Messungen im Mittel um 8 Sekunden zu einander verschoben. Im Mittel läuft mein GPS z. B. 4 Sekunden hinter meiner Lap-Taste. Wenn man dann in jede Richtung einen Versatz von 4 Sekunden zum "wahren" Punkt hat, sind die out und back Strecken sogar um 8 Sekunden zueinander verschoben.

Die ausreichend exakte Höhenkarte ist momentan meine größte Baustelle. Auch wenn ich alle statistischen Tricks anwende, die mir eingefallen sind, gefällt mir meine Lösung noch nicht. Bei meinem letzten Test mit dem Cptn hatten wir beide zur gleichen Zeit auf der gleichen Strecke unseren AP kalibriert und sind danach die gleiche Teststrecke gefahren. Eine einfache Strecke war ca. 1,5 Km lang. Wenn ich meine Daten auswerte, dann finde ich zwischen der höchsten und der tiefsten Stelle einen Höhenunterschied von 4,7 Metern. Wenn ich die Daten vom Cptn mit dem gleichen Skript auswerte, dann finde ich nur 3,2 Meter Höhenunterschied. Das klingt jetzt nach keinem großen Problem, aber in Verbindung mit dem Streckenprofil entspricht das einem Unterschied von ca. 10 Watt (bei 40 Kmh) pro Richtung. Der Fehler mittelt sich zwar einigermaßen aus, wenn man in beide Richtungen fährt, aber nach der Erfahrung mit dem Sensor-Lag bin ich mir nicht sicher, wie weit sich dieser Fehler ausmittelt.
Wenn ich auf einer Strecke bei verschiedenen Windrichtungen und auch mal bei Windstille getestet habe, dann lässt sich aus den kombinierten Daten vermutlich eine ausreichend genaue Höhenkarte basteln. Das bedeutet dann aber auch, dass genaue Tests nur auf der vorher ausgemessenen Teststrecke möglich sind.

Die verschiedenen Sensor-Lags habe ich dagegen recht gut in den Griff bekommen. Hier konnte ich viele "was wäre wenn" Bedingungen durchspielen, die sich bei bestimmten Ausprägungen beängstigend genau mit den Messwerten gedeckt haben. Allerdings hat mich dabei überrascht, dass die Lags nicht stabil sein müssen. Mein GPS und mein PM konnten je nach Teilstück mal eine Sekunde und mal 3 Sekunden auseinander laufen. Das heißt für mich, dass ich nicht einfach einen Konstanten zeitlichen Versatz zwischen den verschiedenen Sensoren annehmen kann, sondern für jeden Testabschnitt einen neuen Versatz berechnen muss.

Ich halte es immer noch für möglich, mit dem AP und einem PM eine sehr gute CdA Berechnung durchzuführen, aber der Aufwand ist noch mal gewaltig gestiegen. Wenn man auf etwa 10 Watt genau sein will, dann reichen in etwa die Informationen, mit denen Aerotune et al. arbeiten. Wenn man dagegen bei 2 Watt landen will, braucht man erheblich genauere Daten.