Moin Axel!
Christoph ist mir zuvor gekommen! :) Er ist in jedem Fall der Mann der Wahl, wenn es Programme geht, die die Dateiformate erkennen und lesen. s.o.. . Ich würde dann wie jeder andere die Programme von Christoph nutzen.

Ich steige dann ein, wenn Deine Daten dann in Textform ( csv, txt, .. ) vorliegen, um sie dann einzulesen und zu analysieren. Ich gucke sie mir mal am WE an.
Ansonsten: Ende Mai / Anfang Juni, so bis 10.6 ist bei mir dann Schicht - wegen Prüfungen *seufz* davor und danach gibt es immer wieder mal Zeitfenster... Sag mal an, wenn Du konkrete Dateien hast.. Man müsste dann genau definieren, was man mit den Daten machen möchte :

Anzeigen / Darstellen, mit Modellen vergleichen, statistische Schwankungen untersuchen.... wir könnten, wenn es denn soweit ist, z.B. mal eine Zoom-Konferenz machen - geht vielleicht schneller als zu texten... Bei Interesse einfach Bescheid sagen, dann sprechen wir mit Christoph ab, ob und wer wie was wo wann.... "Mein" aktuelles Programm : ich bastel gerade an der Version mit zwei Velos und versuche den geschwindigkeitsabhängigen cwa-Wert mit zu berücksichtigen. Die Programmierumgebung, die ich da gewählt habe, ist so beschränkt, dass ich für weitergehende Ansprüche ( z.B. verschiedene Steigungen hintereinander) die komplette Umgebung wechseln / von vorne anfangen muss... Wenn Du aber ein Segment hast, bei dem die Steigung halbwegs konstant ist, dann könnte ich gegebenenfalls mein Programm so umbauen, dass Du Deine Daten einlesen kannst und mit dem Modell vergleichen kannst... Ich werde wohl am WE nochmal ein Update zu meinem Programm machen, dann kommt noch ein weiterer Update, um eigene Daten einzulesen und dann noch ein Update, um die theoretische Leistung während des Anstiegs zu variieren / vorzugeben - letzteres kann Christophs Programm z.B. auch: Wenn Du ständig wechselnde Steigungen hast, dann empfehle ich Dir sowieso Christophs - Programm.

Ich muss nach den besagten Updates die komplette Programmierung umstellen : Ich bemerke, dass die Anwendung, die ich gerade verwende ( Geogebra) für solch komplexen Sachen nicht gemacht ist. D.h. ich würde dann ähnlich wie Christoph auch auf Javascript wechseln, allein schon deswegen, weil man da nichts installieren muss und es im Browser läuft.. ist 1000mal besser... - ich bin da allerdings auch 1000mal langsamer als .... *smile* (*).

(*) Hmmm..glaube, ich habe den Namen "Christoph" so etwa 100mal geschrieben.. :unsure: :)

Im Zweifel IM... ?

Schöne Grüße,

Schaltnix
 
Zuletzt bearbeitet:
Aber hier in der Simulation ist alles berechnet. Daher ist vollkommen klar, dass die Werte gleich sein sollten, da sie aus den selben Zahlen stammen.

Warum das hier anscheinend nicht so ist, habe ich mir noch nicht genau überlegt. Vielleicht ein Ergebnis der zappelnden Geschwindigkeitskurve.
Aber das ist ja hier anders, hier im Simulator wird die Leistung nicht aus gemessener Geschwindigkeit berechnet, sondern alles aus der Tretleistung bzw. Höhenprofil. Darum sollte es da keine Abweichungen geben.
Ich möchte eine Energiebetrachtung machen zum vereinfachten Fall mit den 20 Höhenmetern die auf einer Strecke von 3km ohne zu treten heruntergerollt werden. Da zappelt dann ja auch keine Geschwindigkeitskurve:
Screenshot_20210505-003438_Firefox.jpg
Der Antrieb erfolgt aus der Höhenenergie mit dem Gesamtgewicht von 105kg.
Diese ist also 105*9,81*20 = 20601 Wattsekunden
Für den Rollwiderstand werden 105*9,81*0,005*3000 = 15451Ws benötigt. (Der dynamische ist winzig und zu vernachlässigen)
Dies sind 89% der Leistung und da es sich in der gleichen Zeit abspielt auch 89% der Energie. 100% sind damit 17361Ws.
Nun hat das VM nach den 3km eine Endgeschwindigkeit von 20,9 km/h und somit eine Bewegungsenergie von 105/2*(20,9/3,6)² = 1769Ws
17361+1769 = 19130Ws. Da fehlen 1471 auf die 20601 Ws.
Da nicht getreten wird können die auch nicht im Antrieb verloren gegangen sein.

Wo ist mein Rechen- oder Gedankenfehler?
 
Zuletzt bearbeitet:
Wo ist mein Rechen- oder Gedankenfehler?
Sehe ich spontan nicht.

Aber ich habe ein paar Dinge im Diagramm hinzugefügt:
  • nicht nur die Summe der Tretleistung, sondern auch der potenziellen Energie
  • bei den Summen werden im Tooltip auch die exakten (also nicht gerundeten Werte) angezeigt
  • bei den Input- bzw. Output-Prozenten rechts werden im Tooltip auch die absoluten Werte angezeigt
Und da sieht man, dass du mit dem Rollwiderstand zu niedrig liegst; hier wird die Summe 16845 J angezeigt.
 
Sehe ich spontan nicht.
Aber ich habe ein paar Dinge im Diagramm hinzugefügt:
  • bei den Summen werden im Tooltip auch die exakten (also nicht gerundeten Werte) angezeigt
  • bei den Input- bzw. Output-Prozenten rechts werden im Tooltip auch die absoluten Werte angezeigt
Wenn ich nur endlich wüsste, wie das im Firefox auf dem Android-Tablet funktioniert :(
Und da sieht man, dass du mit dem Rollwiderstand zu niedrig liegst; hier wird die Summe 16845 J angezeigt.
Ich hatte den dynamischen Rollwiderstand bei Endgeschwindigkeit mit einer Kraft von nur 0,58N abgeschätzt und deshalb als zu vernachlässigen betrachtet. Aber auf die 3000m Rollstrecke kommt da bei der Durchschnittsgeschwindigkeit doch einiges zusammen, was wohl die Differenz erklärt.
 
Wenn ich nur endlich wüsste, wie das im Firefox auf dem Android-Tablet funktioniert :(
Soweit ich weiß gibt es keine Möglichkeit, Tooltips auf einem Touchscreen anzuzeigen. D.h. man müsste eigene Tooltips entwickeln, so dass z.B. bei längerem Druck auf eine Stelle dort eine Einblendung auftaucht.

Aber ob die Bedienung auf dem Touchscreen so ideal ist, bezweifle ich auch.

Du könntest einfach eine Maus anschließen. USB-OTG-Adapter, und dort eine ganz normale USB-Maus anschließen. Eine Bluetooth-Maus müsste auch funktionieren, habe ich aber noch nie selber ausprobiert.
 
Ist es schon, wenn m, g, cR konstant sind.
cR ist es halt nur fast.
Aber das Rätsel ist ja in #45 bereits gelöst.
Nein, man soll müde nicht so'n Zeugs machen, fiel mir beim Einschlafen noch ein:
Diese Überlegung gilt doch nur für den Spezialfall, dass v ausschließlich von Epot und cr abhängt! In Wahrheit rollst du aber in die "Wand" von cw rein.
Oder anders gesagt, jeden einzelnen Iterationsschritt kannst du so rechnen, wenn du in der Energiebilanz die Luftreibung und die Zunahme der kinetischen Energie mitrechnest. Da die Geschwindigkeit bei konstantem Gefälle eine Kurve zwischen Wurzel 3 (Luftwiderstand) und Wurzel 2 macht, ist der Energiverlust durch Rollreibung anteilig höher als wenn sie linear zunehmen würde, einfach weil du vom Ende her betrachtest meist länger "schnell" bist, als bei einer gleichförmigen Beschleunigung.
 
Da die Geschwindigkeit bei konstantem Gefälle eine Kurve zwischen Wurzel 3 (Luftwiderstand) und Wurzel 2 macht, ist der Energiverlust durch Rollreibung anteilig höher als wenn sie linear zunehmen würde, einfach weil du vom Ende her betrachtest meist länger "schnell" bist, als bei einer gleichförmigen Beschleunigung.
Habs nicht genau verstanden.
Es ging um die Rollreibung und mit erster Näherung gilt für deren Energie zur Überwindung immer noch E = F[N ]* s[m] in [Nm]
 
Da habt ihr wohl recht, ich war gedanklich ganz schön in meiner zeitbasierten Auswertung verhaftet...
 
Wie kommt es zu der blauen "Geschwindigkeitsfläche" ab 0,5km ?
Jetzt muss ich mir noch überlegen & messen, wie eine sinnvolle Geschwindigkeitskorrektur aussehen könnte. Wo die Schritte nicht zu klein sind, das Ergebnis aber trotzdem konvergiert.
Ich glaube, das habe ich halbwegs gelöst:
Bildschirmfoto von 2021-05-07 06-38-37.pngBildschirmfoto von 2021-05-07 07-06-00.png
Hier gibt es eine unrealistisch starke Steigung von 30%, die aus dem Stand mit 200 W hochgefahren wird.
  • Während die Kurve vorher stark gezappelt hat, ist sie jetzt gerade.
  • Vorher war dort die Beschleunigung sehr hoch, jetzt nicht mehr.
  • Die benötigte Leistung ist dort deutlich niedriger.
  • Allerdings ist in dem steilen Abschnitt die Berechnung immer noch fehlerhaft:
    • die Leistungskurve übersteigt die Tretleistung
    • die Leistungsbilanz ist nicht 0, sondern P_resid (im Tooltip) zeigt, dass 73.6 W fehlen
  • => Ich denke, dass es für realistische Szenarien (also mit Steigungen bei Geschwindigkeiten über 3 km/h) richtig sein müsste.
  • => Wenn an einer Stelle P_resid deutlich ungleich 0 ist, heißt das, dass die Berechnung dort falsch ist.
Wer sich für die Details interessiert, siehe hier.
Eine Ungenauigkeit besteht darin, dass ich an jedem Punkt mit der aktuellen Geschwindigkeit rechne; eigentlich müsste man z.B. den Durchschnittswert mit der Geschwindigkeit am vorherigen Punkt verwenden. Das sollte ich wohl noch ändern.
Die Aufsummierung ist noch nicht geändert; im Diagramm sieht man ganz am Anfang einen kleinen Sprung in der Geschwindigkeit, weil die Steigung relativ zum vorherigen Punkt berechnet wird, so dass sie am Anfang 0 ist, und darum wird in der ersten Sekunde noch beschleunigt. Der Fehler ist aber klein.
Und in/out ist 146% obwohl als Antriebsverluste nur 8% voreingestellt sind!
Aber hier in der Simulation ist alles berechnet. Daher ist vollkommen klar, dass die Werte gleich sein sollten, da sie aus den selben Zahlen stammen.
Nein, ich glaube, die Gesamtleistungsbilanz ist auch hier sinnvoll:
  • Dass sie um den Antriebsverlust abweicht, gilt ja nur bei Antrieb mit Muskelkraft.
  • Wenn man bergab rollt, sollte die Bilanz immer 100% sein.
  • Und bei einer Mischung aus Bergabfahrt und Tretantrieb entsprechend ein Mittelwert.
  • Im zweiten Bild sieht man, dass die Bilanz hier nur 85% ist. Das würde ganz gut zu der Leistungskurve links passen, wo die Bergauf-Leistung die Tretleistung übersteigt. Demnach fehlen hier 15% der Energie, um die gezeigte Ausgabeleistung zu erzeugen.
 
Nicht dass du denkst, ich wollte dich ärgern!

Nein, ich glaube, die Gesamtleistungsbilanz ist auch hier sinnvoll:
  • Dass sie um den Antriebsverlust abweicht, gilt ja nur bei Antrieb mit Muskelkraft.
  • Wenn man bergab rollt, sollte die Bilanz immer 100% sein.
  • Und bei einer Mischung aus Bergabfahrt und Tretantrieb entsprechend ein Mittelwert.
  • Im zweiten Bild sieht man, dass die Bilanz hier nur 85% ist. Das würde ganz gut zu der Leistungskurve links passen, wo die Bergauf-Leistung die Tretleistung übersteigt. Demnach fehlen hier 15% der Energie, um die gezeigte Ausgabeleistung zu erzeugen.
Screenshot_20210507-161212_Firefox.jpg Screenshot_20210507-162002_Firefox.jpg
Vielleicht solle man ein negatives P_resid für die Darstellung mit auswerten.
Wieso allerdings die Leistung dort nur ein Watt ist, wo doch NP 190W ist, weiß ich nicht - wegen der geringen Geschwindigkeit?
 

Anhänge

  • Screenshot_20210507-161212_Firefox.jpg
    Screenshot_20210507-161212_Firefox.jpg
    93,4 KB · Aufrufe: 2
Wieso allerdings die Leistung dort nur ein Watt ist, wo doch NP 190W ist, weiß ich nicht - wegen der geringen Geschwindigkeit?
NP bezieht sich auf die gesamte Strecke.

Hier ist die Geschwindigkeit wieder sehr niedrig (0.1 km/h = Mindestgeschwindigkeit), d.h. null Bewegungsenergie, gleichzeitig ist die Steigung hoch, d.h. mit zunehmender Geschwindigkeit steigt der Leistungsbedarf massiv an. Darum konvergiert die Simulation nicht; kleine Änderungen in der Geschwindigkeit sorgen nicht für noch kleinere Änderungen in der Leistung, so dass man das Leistungsdefizit nach und nach wegkorrigieren könnte, sondern die Geschwindigkeitsänderungen sorgen für vergleichsweise starke Leistungssprünge.

D.h. dass die Kurve hier zappelt ist ein Zeichen, dass die Berechnung nicht konvergiert ist.

Und 1 W gilt auch nur an diesem einen Punkt; gleich nebenan dürfte es viel mehr sein. Und so gibt es immer abwechselnd viel Leistungsabgabe, Beschleunigung, viel Bewegungsenergie, daher wenig Leistungsabgabe, starke Abbremsung ...

Ich weiß nicht, ob man das mit dem momentanen Ansatz, in jedem Punkt nur die aktuelle Leistungsbilanz auszuwerten, nennenswert besser machen kann. Das ginge wohl nur, wenn man Wissen über die Nachbarpunkte einbezieht. Z.B. indem man die Steigung der Leistungskurve berechnet, und daraus die Geschwindigkeitskorrektur bestimmt, statt nur über die Fehl-Leistung selbst.
 
Und wieso steht da 0km und als Zeit 0:01?
Da kenne ich die Ursache, aber mir ist noch keine Abhilfe eingefallen.

Also:
  • Die Kurven sind Arrays; jedes Element entspricht einem Datenpunkt.
  • Für die berechneten Kurven gilt: jede Sekunde = ein Datenpunkt.
  • Die Input-Kurven haben viel weniger Punkte; bei dir beispielsweise 4 Punkte (Anfang und Ende, und 2 hinzugefügte in der Mitte).
  • Die Tooltips sind so eingestellt, dass alle Werte mit der gleichen horizontalen Position dargestellt werden.
Jetzt ist das Problem: Wenn man den Input-Datenpunkt erreicht, dann hat der den Index 1, was einer Zeit 0:01 entspricht, und einer entsprechend geringen Entfernung. Ich habe schon versucht, hier stattdessen die Entfernung/Zeit eines anderen Datenpunkts im Diagramm anzuzeigen, aber bisher noch ohne Erfolg – anscheinend bekommen auch die anderen Datensätze an dieser Stelle die falsche Entfernung/Zeit verpasst.

EDIT: Und auch der Filter-Callback vom Chart.js-Tooltip tut nicht so ganz das, was die Dokumentation erwarten lässt.
 
Zuletzt bearbeitet:
  • Die Tooltips sind so eingestellt, dass alle Werte mit der gleichen horizontalen Position dargestellt werden.
Jetzt ist das Problem: Wenn man den Input-Datenpunkt erreicht, dann hat der den Index 1, was einer Zeit 0:01 entspricht, und einer entsprechend geringen Entfernung.
OK
Habe mühsam noch einen Screenshot mit höher Auflösung erzeugt:
Screenshot_20210507-211035_Firefox.jpg
Vielleicht ergibt dieser ja noch irgendeine Idee.
 
Er ist in jedem Fall der Mann der Wahl, wenn es Programme geht, die die Dateiformate erkennen und lesen. s.o.. . Ich würde dann wie jeder andere die Programme von Christoph nutzen.
Im ersten Schritt geht es mir darum, meine P2Max und die Garmin Vector 3 abzugleichen. Dazu werde ich die Pedale und die P2M bei ein und derselben Fahrt mit zwei verschiedenen Fahrradcomputer aufzeichnen.

Am Ende möchte ich nur wissen, ob die Leistungsdaten annähernd gleich sind, um sie dann in zwei verschiedenen VM einsetzen zu können.
Ich möchte ungern ständig die Leistungsmesspedale von dem Einen ins andere VM Schrauben. Die Community will natürlich bei den Vergleichsfahrten annähernd identische Messsysteme haben. Das Thema ist halt hochsensibel und die Messfehler sollten so klein wie möglich gehalten werden.


Gruß
Axel
 
Im ersten Schritt geht es mir darum, meine P2Max und die Garmin Vector 3 abzugleichen. Dazu werde ich die Pedale und die P2M bei ein und derselben Fahrt mit zwei verschiedenen Fahrradcomputer aufzeichnen.
Das kriegen wir hin! Ich konvertiere die Daten mit fitdump und zeichne sie, und wenn nötig können wir dann noch genauer schauen, z.B. nach Ausreißern.
 
Zurück
Oben Unten