AW: Sigma Data Center 2.0
Warum bei den bisherigen Toureinträgen andere min/Max-Steigungen stehen, als im Logbuch, weiß ich allerdings nicht.
Weil bei den "Tour"- bzw. Speicher Einträge, die min/max Werte eingetragen werden, wie sie in der Anzeige vom ROX während der Fahrt angezeigt werden. Bei kurzen Rampen ist diese Anzeige im Regelfall deutlich zu niedrig. Im Log ist es dann deutlich näher an der Wirklichkeit, ob die Steigungswerte in den Logdaten des Rox gespeichert oder beim Auslesen errechnet werden, entzieht sich meiner Kenntnis. Wie auch immer, bei der momentan aktuellen Version sind die min/max Werte im Log falsch. Weiterhin sind die Werte für die Gesamtstrecke falsch, unter bestimmten Voraussetzungen auch die Bergauf- und Bergabstrecken, wobei der Fehler bei den letzenn beiden unbedeutend ist, da man über die Definition von Bergauf/-ab sicherlich unterschiedlicher Meinung sein kann.
Beispiel: Eine Fahrt über welliges Terrain, Strecke ca. 70 km.
Max Steigung/Gefälle in DC 1.1b aus Tour(Speicher): +9 / -8 <- zu niedrig
dito aus Log dieser Tour: +16 / -10 <- das passt in diesem Fall
Max. Steigung/Gefälle in DC 2.01-001 aus selber Tour: +9 / -8 <- wie 1.1b
dito aus Log dieser Tour: +16 / -14 <- Blödsinn, -14 kommen nicht vor! Fehler!
Gesamtstrecke:
Radumfang: 2114 mm, Anzahl Radumdrehungen lt. csv-Export: 36392
zurückgelegte Strecke nach Adam Riese resp. Taschenrechner oder was auch immer: 76.932,69 m
in DC 1.1b werden angezeigt 76,93 km <- kann man mit leben..
in DC 2.01-001 werden angezeigt 76,87 km <- UPS!!
mit aus DC 1.1b importierten Daten werden angezeigt: 76,86 km <- na supi:blabla:
Was sagen wir da: Herzlichen Glühstrumpf oder so..
Die Ursache habe ich über den Export der csv-Daten gefunden (für die slf-Daten gilt das gleiche):
Die Anzahl Radumdrehungen der aus 1.1b importierten Daten beträgt nur 36360, also 32 Umdrehungen zu niedrig, in der Summe macht das dann 76.865,04 m, das sind abgeschnitten die obigen 76,86 km und aufgerundet die obigen 76,87 km.
Ursache: der Speichensensor die einzelnen Klicks und speichert exakt 1 kB, also 1024 Zählwerte, da er bei 0 zu zählen beginnt, gibt es bei 1024 einen Überlauf, 1024 wird wieder zu 0.
Die Version 1.1 hat sich um diesen Zählerstand nicht weiter gekümmert, die hat nur die vom ROX ermittelte Anzahl relative Umdrehungen, also Umdrehungen pro Logintervall aufsummiert.
Seit DC 2.0 wird aber auch der Zählerstand mit ausgelasen und ggfls exportiert, und in allen exportierten Daten befindet sich in den Datensätzen, die auf einen Satz mit einem Zählerstand = 0 folgen, eine relative Umdrehungsanzahl = 0, warum auch immer.
Jedenfalls sind die von DC >= 2.0 ermittelten rel Radumdrehungen bei autretenden Überläufen null, die daraus berechneten Summen falsch und somit die Entfernungen.
Auch bei hochqualizierten Informatikern können solche Fehler auftreten, so im Eifer des Gefechtes verliert man schon mal den Durchblick. bei einer pre-alpha Version ist sowas möglich. Wenn alle kollektiv pennen, kann sowas auch in eine Beta rutschen. Aber dabei sollte das eigentlich auffallen.
Das riecht nach extern vergebener Programmierung, ein dutzend Leutchen war mit der Kolportierung des Pflichtenheftes beschäftigt und ein einziger Dummer durfte das dann umsetzen..getestet hats niemand!