GPS/Leistungsmesser-Daten als Diagramm (Luftwiderstand, Rollwiderstand, ...)

Noch etwas ist mir aufgefallen:
Mir fällt auch auf, dass wohl gps-Daten nicht genau genug sind und dadurch Schwankungen der Höhe rein kommen können - sehe ich das richtig? Offensichtlich scheint mir das, da mein Speed-sensor und gps bei der Geschwindigkeit kaum mal zusammen passen.
Ganz am Anfang fehlt ein Abschnitt; dort bewegt sich nämlich die GPS-Position nicht, aber die Geschwindigkeit ist größer 0. Was tun?
  • Wenn die GPS-Koordinaten einfach fehlen würden, könnte man die Entfernung berechnen, indem man die Geschwindigkeit mit der Zeit multipliziert. Aber wenn Koordinaten da sind – woher wissen, dass sie falsch sind?
  • Grundsätzlich erscheint mir die Geschwindigkeit vom Tacho verlässlicher, weil sie viel weniger schwankt als die aus den GPS-Koordinaten errechnete Geschwindigkeit (gestrichelte blaue Linie). Und wenn beide da sind, hat man ja einen Vergleich, ob sie gut zusammenpassen.
  • Ich habe aber auch schon erlebt, dass das Tacho-Signal unzuverlässig war. Lag an einer Batterie mit schlechtem Kontakt. Man kann also nicht grundsätzlich sagen, dass dieser Wert besser ist.
  • Vielleicht wäre eine Möglichkeit, zu vergleichen, ob einer der Werte 0 ist; und z.B. wenn nur eine der Geschwindigkeiten 0 ist, dann die andere nehmen; oder wenn die GPS-Entfernung 0 ist, dann die Entfernung aus der Geschwindigkeit berechnen.
 
Bei mir funktioniert der Sensor - wie an anderer Stelle schon berichtet - aus dem hinteren Radkasten ganz gut. Das ist ein Lagesensor ohne Magnetkontakt. Ich denke, der wird bis auf ein paar Artefakte immer zuverlässiger sein als gps. Toll wäre, wenn man jetzt noch auf einer Karte schauen könnte, wo man welche Daten hat, weil ich mir gerne Stellen merke, die eine Art Referenz sind und somit eine bessere Vergleichbarkeit über verschiedene Fahrten möglich wäre.
Das Mitteln der Leistungsdaten fände ich als Option sehr gut, weil die Sprünge oft schon wirklich groß sind, selbst auf rel. ebenen Strecken. Da geht es aber eher um eine Datenbasis für eine Fahrzeugoptimierung.
 
Noch was vergessen:
Dementsprechend hat mir der Berg beim rollen mit 765 Watt zu 43 km/h verholfen.
Nein, das ist falsch. Wie man am Diagramm sieht, ist das die höchste Antriebsleistung; aber die Geschwindigkeit nimmt danach noch weiter zu, d.h. da gibt es kein Gleichgewicht zwischen Antriebsleistung und Luft-/Rollwiderstand, sondern ein großer Anteil geht auch in die Beschleunigung.

Dass die 765 W in der Mitte der Abfahrt sind, ist kein Wunder; es ist zwar schon vorher genauso steil, aber mit zunehmender Geschwindigkeit wird auch der Höhenverlust pro Zeit größer. Was mich wundert ist die steile Abnahme der Antriebsleistung und der Geschwindigkeit, obwohl es weiter bergab geht – hast du da gebremst?
 
Bei mir funktioniert der Sensor - wie an anderer Stelle schon berichtet - aus dem hinteren Radkasten ganz gut. Das ist ein Lagesensor ohne Magnetkontakt. Ich denke, der wird bis auf ein paar Artefakte immer zuverlässiger sein als gps.
Ja, bei mir ist es mit dem Magnetsensor ähnlich gut. Da gab es nur einmal Probleme, als sich die Batterie wohl etwas losgerüttelt hat und mit hoher Feuchtigkeit (kondensierend) wohl einfach der Kontakt schlecht war. Batteriefach auf, drübergewischt, wieder rein und zu, und seitdem wieder total unauffällig.
Toll wäre, wenn man jetzt noch auf einer Karte schauen könnte, wo man welche Daten hat, weil ich mir gerne Stellen merke, die eine Art Referenz sind und somit eine bessere Vergleichbarkeit über verschiedene Fahrten möglich wäre.
Muss mal überlegen, wie man das darstellen könnte. Bei GoldenCheetah geht es zumindest.
 
GoldenCheetah geht es zumindest
Klappt bei mir nicht. Ich müsste auf OSM umstellen, hab das aber noch nicht recherchiert. Aber vmtl hat Du Recht und die Auswertung bei GC genügt dafür. Bei Deinem Ansatz sind momentan noch viele Unbekannte. Da könnten Einzeltests weiterhelfen, wie der Mini-Rolltest, ein schneller Rolltest, Messung am Antriebsstrang und was sonst noch einfällt.
 
Vielleicht wäre eine Möglichkeit, zu vergleichen, ob einer der Werte 0 ist; und z.B. wenn nur eine der Geschwindigkeiten 0 ist, dann die andere nehmen; oder wenn die GPS-Entfernung 0 ist, dann die Entfernung aus der Geschwindigkeit berechnen.

Ich habe das jetzt für die Entfernung so implementiert; bei der Geschwindigkeit müsste man die GPS-Geschwindigkeit noch ordentlich glätten. Hier ein Ausschnitt aus der Datei von @roland65 ; am Anfang besteht kein GPS-Empfang (sieht man u.a. daran, dass die gestrichelte Kurve der GPS-Geschwindigkeit nicht existiert), und entsprechend wurde dieser Teil vorher weggelassen. Aber die Geschwindigkeitsdaten sind da, darum wird die Entfernung jetzt daraus berechnet. In diesem Beispiel fängt das Diagramm jetzt 1.5 km früher an:

Bildschirmfoto von 2019-12-18 08-10-02_s.png
Das Mitteln der Leistungsdaten fände ich als Option sehr gut, weil die Sprünge oft schon wirklich groß sind, selbst auf rel. ebenen Strecken. Da geht es aber eher um eine Datenbasis für eine Fahrzeugoptimierung.
Muss mal überlegen, wie man das am besten machen kann. Eine Glättung ist ja oft auch eine Verfälschung der Daten; zumindest bei der Tretleistung bin ich mir sicher, dass die tatsächlich so stark schwankt; dagegen kann man die Höhe problemlos glätten, weil ich ja genau weiß, dass die Straße glatt ist, statt so wellig, wie manche Höhenprofile suggerieren.
 
Wobei ich hier nicht (primär) die vom GPS ermittelte Geschwindigkeit meinte, sondern Roland und ich haben zusätzliche Geschwindigkeitssensoren – er hat einen auf der Nabe, der die Beschleunigung misst; ich habe einen mit Magnet.

Stimmt schon, die Geschwindigkeiten auf dem GPS sind erfahrungsgemäß immer sehr gut; lediglich das Anhalten kann anscheinend daraus nicht so gut detektiert werden. Aber was in den Dateien nachher drinsteht, sind ja keinesfalls Rohdaten, sondern da sind ja auch schon etliche Processing-Schritte gelaufen – und daher ist die Frage, wie gut man welchem Datensatz vertrauen kann. Fehlerbalken kommen ja leider nicht mit.
 
Stimmt schon, die Geschwindigkeiten auf dem GPS sind erfahrungsgemäß immer sehr gut; lediglich das Anhalten kann anscheinend daraus nicht so gut detektiert werden. Aber was in den Dateien nachher drinsteht, sind ja keinesfalls Rohdaten, sondern da sind ja auch schon etliche Processing-Schritte gelaufen – und daher ist die Frage, wie gut man welchem Datensatz vertrauen kann. Fehlerbalken kommen ja leider nicht mit.

Hey Christoph,

da hast Du aber ein feines Stück Software gebastelt. Eine Karte könnte ich Euch evtl. dazu programmieren. Ich erzeuge so auch meine Telemetriedaten für meine Webseite.

Für ein GPS heißt es nicht, dass wenn man an einem Ort verbleibt, auch gleichzeitig steht. Vor einiger Zeit habe ich einen Film mit Telemetriedaten aus einem Garmin Edge 1000 unterlegt. Zu meinem Erstaunen fuhr ich an einer Ampel wartend etwa 10 km/h. Irgendwer hat mir dann mal gesagt, dass Garmin angeblich auch die Erdrotation als Geschwindigkeit aufzeichnet. Ich halte mich lieber daran, dass die Geräte einfach nur ungenau sind.
Ob die Daten jedoch aufbereitet und geglättet werden, das wäre mir tatsächlich neu. Ich meine, ich beschäftige mich nahezu immer nur mit der Ausgabe... aber wie soll das Gerät glätten oder die Daten manipulieren, sodass die Daten zwischen zwei Punkten plausibel werden? Als ich meinen Hammerhead Karoo bekommen habe, hat der beim Einrichten, einen Messfehler beim Geschwindigkeitssensor gehabt. Der hat mir die Fahrt gleich mit ner Durchschnittsgeschwindigkeit von 75 km/h angegeben. Leider habe ich die Fahrt verworfen. Aber das Verhalten spricht eigentlich dagegen, dass Daten geglättet oder Prozesse auf Plausibilität durchlaufen.

Gruß Dirk
 
Im NMEA-Protokoll steht im VD-Satz: 'Velocity Sensor, Doppler, other/general'
Das hat nichts zu sagen. Ich gehe schon davon aus, dass über NMEA die gleichen Werte geliefert werden, wie sie auch in die Datei geschrieben werden. Bei einem NMEA-Datenstrom kann man lediglich ausschließen, dass zwischen den Werten interpoliert wird, weil jeder Wert ohne Verzögerung ausgegeben wird. Aber ich könnte mir vorstellen, dass bei so etwas z.B. ein Kálmán-Filter zum Einsatz kommt, bei dem der Fehler des aktuellen Datenwerts mit Hilfe der vorigen Datenwerte reduziert werden kann.

Diese Datenbearbeitung ist nur ein Verdacht von mir; ich sehe eben, dass bei heutiger Technik (z.B. Digitalkameras) die Rohdaten fürchterlich schlecht sind – und was man als Fotos kennt, ist das Ergebnis einer massiven Nachbearbeitung in der Kamera. (Das ist auch gar nicht negativ gemeint.) Und bei einem GPS hat man es mit extrem schwachen Funksignalen zu tun, die mit winzigen Antennen in ungünstiger Einbaulage und bei massiven Dämpfungen/Reflexionen durch die Umgebung empfangen werden müssen. Das kann doch gar nicht problemlos funktionieren; und wenn ich an die GPS-Geräte vor 20 Jahren zurückdenke, was die alles für bizarre Artefakte produziert haben ... einmal zwischen Hochhäusern durchfahren ergibt einen Zacken von mehreren Kilometer Abweichung im Track. Dass das heute nicht mehr passiert, schiebe ich nicht auf bessere Empfänger, sondern bessere Datennachbearbeitung – durchaus gleich im IC, bevor das Display/NMEA/PC die Daten überhaupt zu Gesicht bekommt.

Aber IMHO ist das Problem: Angenommen man hat ein GPS; dieses misst die Geschwindigkeit, zudem gibt es einen externen Geschwindigkeitssensor. In den Daten sieht man aber nur einen Geschwindigkeitswert – aber weder, woher er kommt, noch, mit welchen Fehlern er behaftet ist. Ein GPS könnte bei Regenwetter im dichten Wald Probleme haben, ein Magnetsensor könnte wegen eines verrutschten Magnets die Impulse nur unzuverlässig mitbekommen – wie findet man heraus, welche Datenquelle gerade besser ist? In der Praxis wird es sicher gut genug funktionieren, aber wie wäre es denn richtig – statt nur zufällig funktionierend?
Irgendwer hat mir dann mal gesagt, dass Garmin angeblich auch die Erdrotation als Geschwindigkeit aufzeichnet.
Naja, muss ja auch so sein. Die Satelliten bewegen sich ja unabhängig von der Erdrotation, d.h. wenn man nicht die Satellitenbahnen sehr genau messen würde und damit die Relativbewegung rausrechnen könnte, käme sowieso nur Müll heraus. Und mit Hilfe von Fehlerkorrekturen (DGPS) kommt man ja auf Genauigkeiten, mit denen man die Plattentektonik und Verformungen der Erdkruste messen kann.
Ob die Daten jedoch aufbereitet und geglättet werden, das wäre mir tatsächlich neu.
Wie gesagt, das halte ich sogar für sehr wahrscheinlich, und zwar bei den meisten modernen elektronischen Geräten.
da hast Du aber ein feines Stück Software gebastelt. Eine Karte könnte ich Euch evtl. dazu programmieren. Ich erzeuge so auch meine Telemetriedaten für meine Webseite.
Danke!

Die Karte sollte ich auch selber hinkriegen – die Frage ist nur, wo unterbringen. Die Anzeige ist sowieso schon überladen.
 
Das Mitteln der Leistungsdaten fände ich als Option sehr gut, weil die Sprünge oft schon wirklich groß sind, selbst auf rel. ebenen Strecken. Da geht es aber eher um eine Datenbasis für eine Fahrzeugoptimierung.
Habe das jetzt mal eingebaut, via URL-Parameter: der Parameter avg_muscle gibt an, über wie viele Punkte davor und danach gemittelt werden soll; z.B. 0 bedeutet kein Mitteln (wie vorher), 3 (wie im vorigen Link) bedeutet mitteln über 7 Punkte (ursprünglicher Punkt + je drei davor und danach).

Wenn man URL-Parameter angibt, dann merkt sich die Seite diese, und übergibt sie ins Diagramm, nachdem man die Datei ausgewählt hat (d.h. der Parameter ist dann auch im Diagramm vorhanden).
 
@Christoph Moder: Die Mischfarben machen es für mich schwer, die einzelnen Komponenten auseinanderzuhalten. Lassen sich die Leistungssenken nach unten ins Negative stapeln statt wie die Leistungsquellen nach oben?
Toll wäre, wenn man jetzt noch auf einer Karte schauen könnte, wo man welche Daten hat, weil ich mir gerne Stellen merke, die eine Art Referenz sind und somit eine bessere Vergleichbarkeit über verschiedene Fahrten möglich wäre.

Diese beiden Dinge habe ich jetzt mal implementiert, nämlich testweise hier.

Ich hatte versucht, die Leistungsdaten, wie von @Fanfan vorgeschlagen, nach unten zu spiegeln; das war dann aber irgendwie viel Gebastel, in der Umrechnerei waren noch ein paar Vorzeichenfehler drin, und es sah auch irritierend aus, dass für die Leistungsdaten die Nulllinie in der Mitte war, aber die anderen Daten (Geschwindigkeit, Höhe, Puls) ihre Nulllinie unten hatten. Man hätte natürlich deren Nulllinie auch nach oben verschieben können, aber dann hätten sie nur die halbe Höhe ausgenutzt; das macht das Höhenprofil noch schwerer zu erkennen. Jedenfalls habe ich dann gesehen, dass man eine Achse einfach umdrehen kann; und jetzt sind eben die Input-Leistungen oben und die anderen unten. Ob das so toll ist, bin ich mir noch nicht sicher; aber jedenfalls verdecken sich die Farben nicht mehr gegenseitig. Und deshalb könnte ich eigentlich auch die Transparenz reduzieren.

Jetzt hätte ich gerne noch mehr Performance; beispielsweise, indem nicht immer das ganze Diagramm gezeichnet wird, sondern nur der aktuelle Ausschnitt. Dann könnte man auch schön zoomen (momentan stößt man da schnell an die maximale Diagrammgröße).
 
Ob das so toll ist, bin ich mir noch nicht sicher; aber jedenfalls verdecken sich die Farben nicht mehr gegenseitig.
Für mich: Ist jetzt schneller zu erkennen, aber nicht anschaulicher. Wenn man es erstmal verstanden hat, ist die alte Variante vielleicht besser.
Habe ich p_brake bisher übersehen? Wo kommt denn die Größe her?
 
Habe ich p_brake bisher übersehen? Wo kommt denn die Größe her?
Ja, musst du übersehen haben.

Woher? Energiebilanz. Ich nehme an, dass niemand gleichzeitig tritt und bremst. D.h. ich rechne die Energiebilanz aus; wenn mehr Energie frei wird (durch Bergabfahren und/oder Geschwindigkeitsreduktion) als verbraucht wird (für Roll- und Luftwiderstand und evtl. Anstieg (wenn die Energie nur aus dem Abbremsen kommt, nicht aus der Abfahrt)), dann nehme ich an, dass der Rest in der Bremse vernichtet wird.
 
Mit einer neuen Installation und firefox - mit der alten kann ich das nicht mehr prüfen - hängt das Fenster sehr, dass den jeweiligen Punkt (mit Daten) anzeigt. Sonst wirklich toll - Karte, vergrößern/verkleinern. (y)
 
ich habe eine FIT-Datei von Paris-Brest-Paris bekommen mit 355KB.
Sofort nach dem hochladen erscheint folgendes Bild:
Screenshot_20200118-174648_Firefox.jpg
Was mache ich falsch?
Ich bediene auf einem Android-Tablet.
 
Was mache ich falsch?
Möglicherweise nichts; denn so sieht das statische HTML aus. Der Rest wird erst dynamisch durch JavaScript erzeugt.

Wahrscheinlich geht bei der Konvertierung irgend etwas schief. Das war bei dem Beispiel von @Guzzi genauso; dort waren die Daten in einem unerwarteten Format, und deshalb war dann letztendlich die JSON-Datenstruktur leer, und damit kam dann das JavaScript nicht klar.

Ich glaube, ich habe mal Code hinzugefügt, der bei einer leeren Datenstruktur eine Fehlermeldung ausgibt. Aber es kann durchaus sein, dass irgend etwas anderes falsch läuft, so dass das JavaScript abbricht und kein Diagramm zeichnet.

=> Du könntest mal im Browser in der JavaScript-Konsole schauen, was dort schief läuft. Und zusätzlich im Seitenquelltext, ob die Datenstruktur "data" sinnvoll aussieht (d.h. mit dem Demo-Modus vergleichen, wie sie aussehen sollte). Oder mir einfach die Datei zuschicken, dann schaue ich sie mir mal an.
 
Zurück
Oben Unten