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

Kein Wunder, daß @labella-baron Probleme hat. Ich habe ihm ein paar meiner Daten zum Rumspielen zur Verfügung gestellt. Richtig, bei denen fehlen die Höhendaten (Radcomputer defekt), STRAVA repariert das beim Import mit SRTM-Höhendaten.
Hmmm ... bei deinen Daten, die du mir damals geschickt hattest, gab es aber ein anderes Problem; letztendlich waren einfach manche Daten nicht vorhanden (war das Puls?), und dadurch war die Reihenfolge in der GPSBabel-Ausgabe anders, und das hatte mein Perl-Skript verwirrt. Das sollte nicht mehr vorkommen.

Fehlende Höhendaten sollten eigentlich kein Problem sein, denn das GPS hat ja gerne mal Aussetzer. Aber vielleicht geht es schief, wenn überhaupt gar keinen Höhendaten vorhanden sind.
[SRTM-Daten] Die dürften für die Auswertung der gesamten Bremsenergie zu ungnau sein.
Naja, besser als nichts. Ob die GPS-Höhendaten so viel besser sind, weiß ich nicht. Nach meiner Erfahrung sind absolute GPS-Höhenangaben ungenau, aber die relativen Höhenunterschiede schon brauchbar; bei SRTM ist es eher umgekehrt, denn da sieht der Beginn eines Waldes gerne mal wie eine Geländestufe aus.

Bei PBP ist das Gelände ja eher flach wellig; SRTM ist vor allem dann problematisch, wenn man in engen Tälern unterwegs ist, und ein Datenpunkt, der 50 m neben der Straße liegt, schon deutlich höher liegen kann. (Wenn man dann das Höhenprofil von Flüssen abfragt, sieht es so aus, als würde der Fluss zwischendrin bergauf fließen.) Also erwarte ich bei PBP eigentlich eine gute SRTM-Qualität, jedenfalls wenn es gut geglättet ist.
 
Vielleicht ist es schon zu spät:
Screenshot_20200119-001952_Firefox.jpg
Ich komme nicht dahinter, warum die Wattzahlen nicht zu den Prozenten passen.
Edit: Ach so, man muss das so lesen: das sind x% der Eingangleistung bzw. y% der Ausgangsleistung.
 
Zuletzt bearbeitet:
Bei den Daten von HoSe kommt "Eingabedaten konnten nicht verarbeitet werden"
Funktioniert jetzt.

Die Dateien waren schlicht zu groß; damit mir niemand den Server abschießt, hatte ich Speicherlimits gesetzt. GPSBabel braucht rund 48 MB, aber reserviert offenbar mehr, so dass das Limit von 100 MB nicht reichte. Und danach das Perl-Skript ist noch schlimmer, das braucht über 200 MB RAM (ist kein Wunder, da dort keine echten Arrays, sondern verkettete Listen verwendet werden, die viel Overhead bedeuten). Ich habe jetzt die Limits etwas hochgedreht.

Aber das nächste Problem ist der Browser. Bei mir ist das dann so zäh, dass es kaum zu benutzen ist. Ich habe jetzt mal die maximale Diagramm-Größe heruntergesetzt (d.h. der Scroll-Bereich ist kleiner); aber letztendlich dürfte das Problem sein, dass das Chart.js-Framework immer mit allen Daten arbeitet.

Ich denke, da führt letztendlich kein Weg dran vorbei, die Dateien aufzuteilen.
Ich komme nicht dahinter, warum die Wattzahlen nicht zu den Prozenten passen.
Edit: Ach so, man muss das so lesen: das sind x% der Eingangleistung bzw. y% der Ausgangsleistung.
Ja, ist etwas unintuitiv. Aber:
  • Eingangs- und Ausgangsleistung passen nicht gut zusammen; die Tretleistung ist berechnet, und die anderen Dinge hängen von den angenommenen Parametern ab. Daher macht es nicht so viel Sinn, die miteinander zu vergleichen – außer, die Ein- und Ausgabeleistung sind nahezu gleich.
  • Prozentzahlen: Dort wollte ich, dass auch die Antriebsverluste berücksichtigt sind. Die Tretleistung ist also entsprechend reduziert.
  • Bei den Watt-Zahlen wollte ich dagegen die echte Tretleistung anzeigen; der Kreuzotter-Rechner addiert statt dessen einfach die Antriebsverluste obendrauf, so dass man sieht, wie viel man treten muss, um eine bestimmte Geschwindigkeit zu erreichen. Ist ok – aber hier im Diagramm will ich sehen, wie viel ich tatsächlich getreten habe, statt ein angenommener Netto-Wert, der auf der Straße ankommt.
 
Kein Wunder, daß @labella-baron Probleme hat. Ich habe ihm ein paar meiner Daten zum Rumspielen zur Verfügung gestellt. Richtig, bei denen fehlen die Höhendaten (Radcomputer defekt), STRAVA repariert das beim Import mit SRTM-Höhendaten.
Da war tatsächlich noch ein Bug; irgendwo war die GPS-Entfernung zwischen zwei Punkten 0; in so einem Fall kann die Entfernung aus der Geschwindigkeit berechnet werden. Aber die war dort gar nicht definiert, und dadurch ist das Skript abgestürzt. Funktioniert jetzt, und ist auch im Git repariert.
 
Funktioniert jetzt.
Die Daten von @HoSe enthalten offenbar die komplette Hin- bzw. Rückfahrt.
Da kommt jetzt 20200119_115800.jpg

Bei der ersten Datei von @Guzzi erscheinen jetzt offenbar weder Höhen- noch Geschwindigkeitsdaten.
Wie sind eigentlich darin die 'P_break: 39%' zu verstehen? Wie wird P_break berechnet?

Edit: Geschwindigkeitsdaten sind doch drin, kleben aber unscheinbar auf der Abszisse.
 
Zuletzt bearbeitet:
Aber das nächste Problem ist der Browser. Bei mir ist das dann so zäh, dass es kaum zu benutzen ist. Ich habe jetzt mal die maximale Diagramm-Größe heruntergesetzt (d.h. der Scroll-Bereich ist kleiner); aber letztendlich dürfte das Problem sein, dass das Chart.js-Framework immer mit allen Daten arbeitet.
Bei dem Screenshot in #46 mit Leistungsprozenten zuckt der Kasten wenn überhaupt ewig rum.
Im Gegensatz zum Windows 7 Rechner mit Pentium 4 zuletzt. Am Tablet jetzt mit Android 9 und OktaCore-Prozessor kann es eigentlich nicht liegen. Sind die Subsysteme unter Android so ineffizient, oder findet der Algorithmus bei dem jetzt breiteren Bildschirmformat einfach keinen vernünftigen Platz mehr zur Darstellung? Kästchen und Schrift etwas kleiner machen?
 
Sag ich doch: der Browser ist zu langsam, kommt mit der Datenmenge nicht zurecht.
Bei der ersten Datei von @Guzzi erscheinen jetzt offenbar weder Höhen- noch Geschwindigkeitsdaten.
Höhendaten nicht, weil die auch gar nicht vorhanden sind, die Geschwindigkeit bei mir aber sehr wohl.
Wie sind eigentlich darin die 'P_break: 39%' zu verstehen? Wie wird P_break berechnet?
  • Aus der Veränderung der Geschwindigkeit wird eine Beschleunigungsleistung berechnet.
  • Wenn die Geschwindigkeit größer wird, dann muss der Fahrer oder der Höhenunterschied sie aufwenden.
  • Wenn die Geschwindigkeit kleiner wird, wird Leistung frei.
  • Von dieser Leistung wird Luftwiderstand, Rollwiderstand und Kletterarbeit abgezogen.
  • Was übrig bleibt, muss dann in der Bremse vernichtet worden sein. Das ist P_brake.
Im Gegensatz zum Windows 7 Rechner mit Pentium 4 zuletzt. Am Tablet jetzt mit Android 9 und OktaCore-Prozessor kann es eigentlich nicht liegen. Sind die Subsysteme unter Android so ineffizient, oder findet der Algorithmus bei dem jetzt breiteren Bildschirmformat einfach keinen vernünftigen Platz mehr zur Darstellung? Kästchen und Schrift etwas kleiner machen?
Weiß nicht. Aber 8 Kerne machen es nicht unbedingt schneller; die helfen ja nur bei gut parallelisierbaren Rechenaufgaben, also wenn mehrere Prozesse unabhängig gleichzeitig laufen. Ich bezweifle, dass das bei JavaScript irgendwie genutzt werden kann. Und Mobil-Prozessoren sind auf jeden Fall langsamer (niedrigere Taktfrequenz); sie liefern zwar mehr Rechenleistung pro Strom, aber insgesamt weniger.

Keine Ahnung, was man da machen kann. Ob es da irgendwelche schnelleren JavaScript-Engines gibt. An Android selber liegt es mE nach ziemlich sicher nicht.
 
Gut, aber was sind die 39% in der Statistik - 39% wovon genau?
Und Mobil-Prozessoren sind auf jeden Fall langsamer (niedrigere Taktfrequenz);
Naja - bedenke: gegenüber einem Pentium 4 mit auch nur 2GHz !
Ist schon lustig: das schwarze Kästchen mit den Werten springt mehrmals an verschiedene Stellen bis es sich beruhigt hat, obwohl der Mauszeiger (über Touchpad) völlig ruhig steht. Seltsamer Algorithmus.
 
Gut, aber was sind die 39% in der Statistik - 39% wovon genau?
Von allen Ausgangsleistungen (Luftwiderstand, Rollwiderstand, Kletterarbeit, Bremsenergie). Die Beschleunigungsarbeit fehlt, da die Geschwindigkeit am Beginn und Ende immer null ist, d.h. netto gibt es dort keinen Gewinn oder Verlust. Dagegen sind Luft- und Rollwiderstand immer ein Verlust, und wenn es netto bergauf ging, auch die Kletterarbeit.

Anhand der Geschwindigkeit kann Roll- und Luftwiderstand berechnet werden; aber mangels Höhendaten fehlt die Kletterarbeit komplett. Daher sieht es für die Software so aus, als würde jedes Mal, wenn es bergauf geht und die Geschwindigkeit sinkt, gebremst werden.
 
Wie kann man so eine fit-Datei zerstückeln z.B. die ersten 50km, um die Auswertung zu üben?
Gute Frage. Ich habe auf Anhieb kein Programm gefunden; hatte gehofft, dass GPSBabel das kann, ist aber nicht der Fall. Was man machen könnte: GPSBabel konvertiert die Datei erst einmal zu einer CSV-Tabelle, und dort könnte man dann Punkte weglassen. Da ist nur die Frage, wie man dem Server sagt, welchen gewünschten Datenausschnitt man denn haben will. Man kann natürlich immer den Code runterladen und das bei sich selber laufen lassen.

Aber laut deinen Erkenntnissen ist das Problem ja nicht das Vorhandensein der vielen Daten, sondern dass sie gezeichnet werden; und da ist wohl der beste Workaround, alles erst einmal auszuschalten.

Außerdem habe ich die Vorschläge zur Performance-Verbesserung eingebaut.
 
Ich versuche jetzt einmal das Zusammenspiel von JavaScript-Chart auf meinem Samsung Tablet darzustellen, da ich immer noch die Hoffnung habe, dass man diese geniale Software wie auf einem Desktop-PC ohne einen solchen nutzen kann.

Die Darstellung des Demo-Chart sieht so aus:

Screenshot_20200211-232719_Samsung Internet.jpg
Mit ausgeklappten Parametern:
Screenshot_20200211-233212_Gallery.jpg
Dass man so keine Schaltflächen bedienen kann ist klar.
Nun kann man das Ganze ja zoomen:
Screenshot_20200211-233212_Gallery.jpg
Hierbei verschwindet der rechte Teil, auch die Ordinate.

Nun gibt es einen DEX-Modus, welcher PC-ähnliches arbeiten erlaubt:
Screenshot_20200211-233655_Samsung Internet.jpg
Das sieht schon mal ganz gut aus.
Die Diagramme lassen sich horizontal schieben, auch am grauen Schiebebalken unten erkennbar und die Schaltflächen bleiben wo sie sind:
Screenshot_20200211-233932_Samsung Internet.jpg
Klappt man nun die Parameter auf, so passiert etwas ganz lustiges:
Screenshot_20200211-234148_Samsung Internet.jpg
Die Schaltflächen befinden sich plötzlich unten!
Screenshot_20200211-234148_Samsung Internet.jpg
Wählt man einen Streckenpunkt an, so wird in der Karte der Standort nicht aktualisiert (nur im Demo-Chart).
Screenshot_20200211-234555_Samsung Internet.jpg
Wählt man ein kleineres Fenster zur Darstellung, so sind Parameter und Schaltflächen untereinander:
Screenshot_20200212-001442_Samsung Internet.jpg
Klappt man die Parameter aus, so verschwinden die Schaltflächen:
Screenshot_20200212-002013_Samsung Internet.jpg

Was dann mit Pfeiltasten in Kombination mit Ctrl bzw. Alt passiert, lässt sich nicht kompakt beschreiben.
Ich vermute, dass da noch viel freiwillige Arbeit bei JS-Script notwendig ist. Aber vielleicht gibt es ja einen work-around.
 

Anhänge

  • Screenshot_20200211-232934_Samsung Internet.jpg
    Screenshot_20200211-232934_Samsung Internet.jpg
    86,9 KB · Aufrufe: 35
Die Darstellung des Demo-Chart sieht so aus:
Interessant. Das könnte mit dem Mobil-Modus zu tun haben, denn normalerweise sollte das Diagramm über die volle Fensterhöhe gehen; da wird im Code explizit die Fensterhöhe abgefragt und die Diagrammfläche auf diese Größe gesetzt.

Wenn ich mich richtig erinnere, habe ich das auch schon mal auf dem Tablet so gesehen; im Firefox sah es normal aus, im Chrome so wie bei dir. Aber keine Ahnung, warum.
Die Schaltflächen befinden sich plötzlich unten!
Ja, das liegt daran, dass die Einstellungen (links) und die Legende (rechts) zwei unabhängige Elemente sind, die via „float“ angeordnet sind – also wie Fließtext. Wenn der Platz zu schmal ist, wird die Zeile umgebrochen (d.h. die Einstellungen sind das erste Wort in der Zeile, die Legende ist das zweite Wort, das in einer neuen Zeile landet). Mir ist nichts besseres eingefallen, denn wenn beide Elemente auf dem Bildschirm fixiert sind (d.h. nicht mit dem Diagramm mitscrollen), würde der rechte Rand sonst abgeschnitten, wenn er nicht auf den Bildschirm passt. Und da die Legende von Chart.js erzeugt wird, kann ich das auch nicht so einfach beeinflussen; möglicherweise geht es, mit etwas CSS, aber da bin ich kein Experte.
Nun gibt es einen DEX-Modus, welcher PC-ähnliches arbeiten erlaubt:
Das sieht doch wie auf dem PC aus.

Dazu muss man wissen, dass es eigentlich zwei Zoom-Modi gibt:
  • Die Diagrammfläche wird so hoch wie der Fensterinhalt gemacht, aber sehr viel breiter. Dadurch kann man problemlos mit dem Scrollbalken hin und her fahren. Würde das Diagramm nur so schmal wie das Fenster gemacht werden, würde man viel weniger erkennen.
  • Bei langen Fahrten reicht das aber nicht, weil die maximale Diagrammfläche begrenzt ist; ist das Diagramm größer, wird einfach gar nichts mehr angezeigt. Ich musste die Breite also limitieren. Um dann trotzdem noch hineinzoomen zu können, habe ich den Tastatur/Pinch-Zoom eingerichtet, der nur einen Ausschnitt des Diagramms zeichnet – mit dem Scrollbalken kann man darum nicht mehr durch die ganze Strecke scrollen, sondern nur noch durch den momentanen Ausschnitt. Um den Rest zu sehen, muss man rauszoomen, an die andere Stelle fahren, und ggf. dort reinzoomen.
Wählt man einen Streckenpunkt an, so wird in der Karte der Standort nicht aktualisiert (nur im Demo-Chart).
Ja, das ist Absicht. Wollte aus Datenschutzgründen nicht meinen kompletten Arbeitsweg reinstellen, und habe daher die Koordinaten rausgelöscht. Aber ein Kompromiss wäre besser, wo nur Anfang/Ende fehlen.
 
Zurück
Oben Unten