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

[Christoph Moder]

Sie wird also bei 18,27km auf die gemessene Geschwindigkeit gesetzt, aber wie bereits gezeigt, wird dies nicht gezeichnet:

Naja, doch. Wird, wie gesagt, auf die gemessene Geschwindigkeit initialisiert – und dann nach oben oder unten verschoben, um den Leistungsüberschuss oder -mangel zu verringern. Und da kommt einfach dann ein höherer Wert heraus.

Durch welches Ereignis oder welche Berechnung erfolgt dann bei 18,37 der Knick nach unten:

Weiß ich nicht. Da fällt mir auch nichts ein.

Jedenfalls scheint es so zu sein, dass an diesem Punkt die gemessene Geschwindigkeit schon ganz gut die Leistungsbilanz erklärt, und jede Erhöhung/Erniedrigung der Geschwindigkeit den Fehler größer machen würde. Während das bei den Nachbarpunkten anders ist; dort wächst die berechnete Geschwindigkeit wieder an.

Ich weiß auch nicht, wie man das nachvollziehen könnte. Ist ja nicht eine einzige Formel, sondern die Berechnung wird in einer Schleife oft durchgeführt – also nicht so einfach per Hand zu machen. Ich könnte jetzt natürlich Debug-Ausgaben auf die JavaScript-Konsole schreiben; aber das dürfte auch nur zu einer Datenflut führen, wo man die Nadel im Heuhaufen suchen muss.

Ich überlege mir, die Leistungsbilanz irgendwie anzuzeigen; und zwar auch für die berechnete Geschwindigkeit. Dann sollte man besser verstehen, was passiert.

Du erinnerst dich was für ein Schrott beim Polar bei höheren Geschwindigkeiten heraus kam?
ANT+ traue ich auch nicht, da es nur jede viertel Sekunde überträgt, wir aber dieser Zeit bei 80km/h mal drei oder mal vier Radumdrehungen haben. Außerdem sollte es ja ohne Powermeter-System gehen.

Ich glaube nicht, dass diese Probleme prinzipbedingt sind. Eine kurze Suche nach Bluetooth-Sensoren zeigt, dass offenbar mit jeder Übertragung die Zahl der Umdrehungen und die Zeitdifferenz gemeldet werden. Damit sollte die Geschwindigkeit schon sehr genau sein; gerade bei hohen Geschwindigkeiten sind die Beschleunigungen ja gering, d.h. da macht es nichts aus, über mehrere Umdrehungen zu mitteln. Ich vermute, dass das bei ANT+ ähnlich ist. Und, wie gesagt, es gibt überhaupt keinen Grund, warum die Geschwindigkeitsauflösung so mies wie beim Polar-Tacho sein muss.

Wie lautet der Ausdruck welcher P_brake erzeugt?

Siehe hier.

Ist es erforderlich mit '===' auf Identität zu '0' abzufragen? Ist P_brake denn keine Gleitkommazahl?

Doch, schon. Aber die Leistungsbilanz kann positiv oder negativ sein; und wenn negativ, wird sie auf 0 gesetzt. D.h. wenn ich auf 0 teste, weiß ich, dass sie wahrscheinlich negativ war, d.h. sicher nicht gebremst wurde.

Ich habe übrigens den aktuellen Stand nach Gitlab hochgeladen; hier kann man anhand der Commits leichter nachvollziehen, was ich wie geändert habe.

 

[labella-baron]

Siehe hier.

P_brake = Math.max((P_down + P_decel) - (P_air + P_roll + P_up + P_accel), 0);
Vielleicht bringt ein zusätzliches 'var' etwas - aber ich überblick es nicht.
Macht es eigentlich einen Unterschied ob man 'null' oder '0' schreibt?

Edit: Ein Lob bezüglich deiner Code-Kommentierungen

 

[labella-baron]

Eine kurze Suche nach Bluetooth-Sensoren zeigt, dass offenbar mit jeder Übertragung die Zahl der Umdrehungen und die Zeitdifferenz gemeldet werden. Damit sollte die Geschwindigkeit schon sehr genau sein; gerade bei hohen Geschwindigkeiten sind die Beschleunigungen ja gering, d.h. da macht es nichts aus, über mehrere Umdrehungen zu mitteln. Ich vermute, dass das bei ANT+ ähnlich ist. Und, wie gesagt, es gibt überhaupt keinen Grund, warum die Geschwindigkeitsauflösung so mies wie beim Polar-Tacho sein muss.

Ja ok, wenn die Zeitdifferenzen mit rüber kommen und nicht nur die Anzahl der Impulse.
Dann müssten bei 80km/h entsprechend der Anzahl der Radumdrehungen mal drei Zahlen und mal vier Zahlen übertragen werden. ANT+ benötigt anscheinend nochmal weniger Energie als BLE und irgendwo wird man dann wohl woanders Kompromisse machen müssen - deshalb meine Skepsis.
Hatte mich ja damals schon versucht, wie das bei ANT+ funktioniert, bin aber nicht weiter gekommen. Der darin enthaltene Link zum 'ANT Message Protokoll' funktioniert noch immer !

 

[Christoph Moder]

Ich überlege mir, die Leistungsbilanz irgendwie anzuzeigen; und zwar auch für die berechnete Geschwindigkeit. Dann sollte man besser verstehen, was passiert.

So, das habe ich jetzt implementiert. Jetzt gibt es zwei zusätzliche Kurven in der Mitte des Diagramms – eine grüne, die die Leistungsbilanz anhand der gemessenen Geschwindigkeit zeigt, und eine rote, die sie anhand der berechneten Geschwindigkeit anzeigt.

Die Bremsleistung P_brake ist dabei nichts anderes als der positive Teil der grünen Leistungsbilanzkurve, dort, wo die Tretleistung vernachlässigbar klein ist (kleiner als MIN_PEDAL_POWER = 10 W).

Ach ja, und dann habe ich den Tooltip-Modus wieder auf index gestellt und hitRadius erhöht; jetzt werden nicht mehr mehrere Punkte auf einmal im Tooltip angezeigt, und der Tooltip erscheint etwas leichter (auch wenn man weiter weg vom Datenpunkt ist).

Vielleicht bringt ein zusätzliches 'var' etwas - aber ich überblick es nicht.

Nein, braucht man nicht. Außer, es geht um Arrays; die muss man zuerst deklarieren.

Macht es eigentlich einen Unterschied ob man 'null' oder '0' schreibt?

Ja. 0 ist eine Zahl, null bedeutet, dass kein Wert zugewiesen ist. Sieht man z.B. im Diagramm bei der Höhe: Dort, wo keine Werte existieren, lauten die Array-Einträge null; entsprechend wird dort keine Linie gezeichnet. Stünde dort 0, wäre die Kurve auf Meereshöhe gezeichnet.

Bei C ist de facto NULL == 0, aber es ist jedenfalls kein guter Stil, das zu vermischen. Wenn man meint, dass ein Zeiger uninitialisiert ist, sollte er NULL heißen. Bei Skriptsprachen gibt es diese Gleichheit meistens nicht; da sie nicht strikt typisiert sind, kann man implizit null zu 0 umwandeln, aber es ist trotzdem nicht das Gleiche.

Edit: Ein Lob bezüglich deiner Code-Kommentierungen

Danke!

 

[labella-baron]

So, das habe ich jetzt implementiert. Jetzt gibt es zwei zusätzliche Kurven in der Mitte des Diagramms – eine grüne, die die Leistungsbilanz anhand der gemessenen Geschwindigkeit zeigt, und eine rote, die sie anhand der berechneten Geschwindigkeit anzeigt.

Durchaus interessant:

Eine weitere Erkenntnis will sich bei mir aber noch nicht einstellen

 

[Christoph Moder]

Eine weitere Erkenntnis will sich bei mir aber noch nicht einstellen

Jetzt habe ich erst verstanden, wo diese Stelle mit dem gezackten Verlauf der berechneten Geschwindigkeit ist: nämlich in Neufarn. Östlich davon ist ein Hügel, und auf der anderen Seite am Fuß ist der Ortseingang. Mich hatte damals bergauf kurz vor der Kuppe ein Auto überholt, und dann unten ausgebremst, weil ich bergab natürlich schneller als 50 km/h gefahren bin und das auch innerorts beibehalten wollte. Ich glaube, ich habe ihn dann innerorts noch überholt, und musste dann doch an der roten Ampel an der Kreuzung anhalten (hätte ich vielleicht noch geschafft, wenn er mich nicht ausgebremst hätte). Soviel zum Kontext. Hier habe ich definitiv gebremst, aber zwischendrin auch noch mal beschleunigt.

 

[labella-baron]

Wieso erscheint hier kein Zahlenwert für P_resid?

 

[Christoph Moder]

Wieso erscheint hier kein Zahlenwert für P_resid?

Sorry, war mein Fehler. Früher gab es keine negativen Werte.

 

[labella-baron]

Warum wird hier speed_calc angepasst?

 

[Christoph Moder]

Warum wird hier speed_calc angepasst?

Das ist echt seltsam.

Um das zu verstehen, habe ich mal eine Debug-Möglichkeit eingebaut; wie unter diesem Link zu sehen, kann man den Parameter debug setzen; dann werden Informationen auf der JavaScript-Konsole ausgegeben (vermutlich geht das auf dem Tablet dann gar nicht, weiß ich nicht). Wenn der Wert 1 ist, werden Daten nur an jedem Punkt ausgegeben; wenn der Wert 2 ist, dann wird auch jede Iteration der Berechnung von speed_calc ausgegeben – dazu muss aber sehr weit reingezoomt werden, weil es ansonsten quälend langsam wird (und die Datenmenge auch unbeherrschbar groß, so dass man nichts darin findet).

Jedenfalls sieht man, dass scheinbar aus dem Nichts die Abbrems-Leistung sich verzehnfacht; und diese Verschlechterung von P_resid führt natürlich dazu, dass die Geschwindigkeit doch nicht angepasst wird.

Aber dieser Effekt tritt nur auf, wenn die Tretleistung relativ stark geglättet wird. Daher in Zukunft bitte immer den Link mit den ganzen Einstellungen posten, weil es sonst unmöglich nachzustellen ist.

 

[labella-baron]

Das sind die Parameter zum Bild:

Geglättet wurde nichts!

 

[labella-baron]

Um das zu verstehen, habe ich mal eine Debug-Möglichkeit eingebaut; wie unter diesem Link zu sehen, ka man den Parameter debug setzen; dann werden Informationen auf der JavaScript-Konsole ausgegeben (vermutlich geht das auf dem Tablet dann gar nicht, weiß ich nicht).

Vermutlich bei mir nicht. Wo soll diese Info erscheinen? Auch mit debug=1 sehe ich nichts.
Maschinen-Code wird ja nicht erzeugt. Käme man an den Zwischen-Code heran - vielleicht liefert der einen Hinweis.

 

[labella-baron]

Jedenfalls sieht man, dass scheinbar aus dem Nichts die Abbrems-Leistung sich verzehnfacht; und diese Verschlechterung von P_resid führt natürlich dazu, dass die Geschwindigkeit doch nicht angepasst wird.

Verstehe ich nicht - sie wurde doch angepasst:

 

[Christoph Moder]

Vermutlich bei mir nicht. Wo soll diese Info erscheinen? Auch mit debug=1 sehe ich nichts.

In der Browser-Konsole. Heißt “error console” oder so. Haben aber Mobil-Browser wohl nicht.

Verstehe ich nicht - sie wurde doch angepasst:

Nein. Die berechnete Geschwindigkeit hat ja eine riesige Lücke in der Leistungsbilanz (dieser hohe rote Peak); eigentlich sollte die berechnete Geschwindigkeit so angepasst werden, dass dieser Peak verschwindet. Tut er aber nicht.

Die Ursache ist der Übergang von einer Geschwindigkeitskurve zu einer anderen; als Ergebnis gibt es eine große Geschwindigkeitsdifferenz zum vorigen Punkt, und entsprechend ist P_accel oder P_decel unnatürlich groß. Ich denke, ich sollte hier die Beschleunigungsleistung an diesen Punkten einfach auf 0 setzen, denn die Geschwindigkeitsdifferenz zum vorigen Punkt kann nicht besonders groß sein. Da kann man sie hier ausnahmsweise unter den Tisch fallen lassen. Zumindest besser, als hier einen viel zu großen Berechnungs-Artefakt zu verwenden.

=> Muss mir noch überlegen, wie man das am geschicktesten implementiert.

Geglättet wurde nichts!

Mag sein. Bei mir tauchte der Effekt nur mit Glättung auf. Du hast wahrscheinlich andere Parameter genommen (habe ich jetzt nicht im Detail verglichen), aber das sind Artefakte, die nur unter ganz bestimmten Bedingungen auftreten. Und daher brauche ich idealerweise den Link, so dass ich das per Mausklick nachvollziehen kann.

 

[labella-baron]

Und daher brauche ich idealerweise den Link, so dass ich das per Mausklick nachvollziehen kann.

Nachlieferung:
https://christoph-moder.de/fahrrad/powermeter2diagram.php?demo=&HR=0&HR_synth=0&cwa=0.05&cr=0.003&mrider=75&mbike=30&dtr=7&vwind=0&crdyn=0.07&p_hr_slope=0.262&p_hr_t=97.3&default_ele=250&default_temp=20&avg_muscle=0&avg_speed=0&avg_ele=0&P_down=0&P_roll=0&P_air=0&P_uphill=0&speed_gps=0&P_accel=0&zoom_min=15&zoom_max=19.85&P_decel=0#show
M. E. haben die Abwrtssprünge bei km 17,38 und 18,39 sowie folgende dieselbe für mich mysteriöse Ursache:

https://christoph-moder.de/fahrrad/powermeter2diagram.php?demo=&HR=0&HR_synth=0&cwa=0.05&cr=0.003&mrider=75&mbike=30&dtr=7&vwind=0&crdyn=0.07&p_hr_slope=0.262&p_hr_t=97.3&default_ele=250&default_temp=20&avg_muscle=0&avg_speed=0&avg_ele=0&speed_gps=0&zoom_min=15&zoom_max=19.85&P_down=0&P_decel=0&P_roll=0&P_air=0&P_uphill=0&P_accel=0&P_resid=0&P_brake=0#show

 

[labella-baron]

Versehentlicher Doppel-post

 

[labella-baron]

die Abwärtssprünge bei km 17,38

=> Muss mir noch überlegen, wie man das am geschicktesten implementiert.

Gut, diese Anpassung von speed_calc ist dort jetzt verschwunden.

Aber warum passiert bei 26,44km keine Anpassung von speed_calc, obwohl ordentlich gebremst wird, hingegen kurz vor dem Ende schon?

https://christoph-moder.de/fahrrad/powermeter2diagram.php?demo=&HR=0&HR_synth=0&speed_gps=0&cwa=0.05&cr=0.003&mrider=75&mbike=30&dtr=7&vwind=0&crdyn=0.07&p_hr_slope=0.262&p_hr_t=97.3&default_ele=250&default_temp=20&avg_muscle=0&avg_speed=0&avg_ele=0&P_down=0&P_decel=0&P_uphill=0&P_accel=0&zoom_min=0&zoom_max=30&P_air=0&P_roll=0&debug=0&P_resid=0

 

[labella-baron]

Es lässt mich doch nicht los:
Wieso ist hier P_resid=72W und wenn man die Einzelwerte nachrechnet kommt 89,6W heraus?
https://christoph-moder.de/fahrrad/powermeter2diagram.php?demo=&HR=0&HR_synth=0&cwa=0.05&cr=0.003&mrider=75&mbike=30&dtr=7&vwind=0&crdyn=0.07&p_hr_slope=0.262&p_hr_t=97.3&default_ele=250&default_temp=20&avg_muscle=0&avg_speed=0&avg_ele=0&speed_gps=0&zoom_min=13.79&zoom_max=18.64&debug=0#show

 

[labella-baron]

Es geht nochmal um die Aufzeichnung Paris-Brest bei km 226,38:

Hier ist die hohe grüne P_brake Spitze bei ca. 740W wenn man die Rasterlinien abzählt.

Ausgegeben werden jedoch nur 622,8W:

Obwohl P_Roll mit 116,1W konsistent angezeigt wird.

Durch was kann dies entstehen?

https://christoph-moder.de/fahrrad/powermeter2diagram.php?cwa=0.04&cr=0.008&crdyn=0.1&mrider=78&mbike=41&dtr=6&vwind=5&default_ele=250&default_temp=20&p_hr_slope=0.262&p_hr_t=97.3&zoom_min=225&zoom_max=230&speed_gps=0&P_down=0&P_decel=0&P_air=0&P_uphill=0&P_accel=0&HR=0&HR_synth=0&avg_muscle=2&avg_speed=0&avg_ele=0&debug=0#show

 

[labella-baron]

Hier ist die hohe grüne P_brake Spitze bei ca. 740W wenn man die Rasterlinien abzählt.

Nee, die grüne Spitze ist um P_roll angehoben - sorry