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

Systemgewicht somit 114-119 Kg.
Danke dir!
Damit fehlen an dieser Stelle jetzt nur 253 - 162,3/75%*100% = 36,6W.
Screenshot_20200220-104502_Firefox.jpg
Seltsam ist, dass wir dort jetzt 20cm höher sind - ein Rundungsproblem?

Viel gravierender ist ist der Bereich vor der "Unstetigkeitsstelle" auch mit dem neuen Gewicht:Screenshot_20200220-105832_Firefox.jpg
Es fehlen 908,2-(122,4+128,1+54,1) = 603,6W. Da stimmt irgendetwas noch überhaupt nicht!
 
Zuletzt bearbeitet:
Es fehlen 908,2-(122,4+128,1+54,1) = 603,6W. Da stimmt irgendetwas noch überhaupt nicht!
Schauen wir doch mal: Es geht bergab, die mögliche Geschwindigkeit ist sehr hoch, die reale Geschwindigkeit viel niedriger, der Straßenzustand unbekannt ... kombiniere: Da muss jemand gebremst haben! P_accel kann ja trotzdem >0 sein, man kann ja hunderte Watt wegbremsen und trotzdem schneller werden.
 
Es muss irgendwie mit P_decel zusammen hängen. Immer wenn verzögert und gebremst wird läuft die Leistungsbilanz auseinander:
Screenshot_20200220-125816_Firefox.jpg
 
Es muss irgendwie mit P_decel zusammen hängen. Immer wenn verzögert und gebremst wird läuft die Leistungsbilanz auseinander:
Ja logisch. Das Bremsen wird ja nicht gemessen, sondern nur angenommen (aus der Veränderung der Geschwindigkeit und Leistungsbilanz). Die berechnete Geschwindigkeit weiß ja nichts vom Bremsen, darum läuft es dort auseinander.
Seltsam ist, dass wir dort jetzt 20cm höher sind - ein Rundungsproblem?
Kann sein. Erstens werden die Daten bei der Konvertierung nach JSON gerundet, einfach um die Datenmenge zu verringern. Niemand braucht Dezimalstellen, die sowieso nichts zum Ergebnis beitragen. Und zweitens wird, glaube ich, bei der Anzeige noch einmal gerundet.
 
Möglicherweise verschlechtern die Vibrationen der Hülle deren Cw-Wert doch - andererseits munkelt man immer wieder, dass nicht-laminare sondern mikroturbulente Strömung den Strömungswiderstand reduzieren könne; wir wissen noch so wenig :(
Das mit dem Wissen ist so eine Sache - was man nicht weiß erkennt man ja oft gar nicht. :D Ich würde die mikroturbulente Strömung nur hinten erzeugen wollen, wo die Verhältnisse zu leicht wechseln. Von vorne würde ich laminar anstreben. Da macht es wohl schon eine Menge aus, ob man Reibungsdämpfer drin hat oder Elastomer quasi ohne Losbrechmoment - wir hören das eher, als dass wir es anders messen können, denn es rumpelt einfach mehr. Aktuell kenne ich einen Fahrer, der ein Setup auf nur einer Seite fährt und den Unterschied deutlich wahrnimmt. Wenn die Oberfläche vibriert, wird das sicher keine ruhige Strömung erzeugen und wird bremsen.
Ich stimme Christoph zu, dass die so gerne genannten Fabelwerte zu erreichen sind, aber eben nur unter allerbesten Bedingungen.

Ich sehe schon, ich muss beizeiten mal wieder eine Fahrt hochladen und mit den aktuellen Stand anschauen.
 
So, habe jetzt noch was ergänzt; jetzt wird auch von der berechneten Geschwindigkeitskurve die Durchschnittsgeschwindigkeit und die daraus resultierende Netto-Fahrzeit angezeigt. So kann man schauen, wie viel Zeit man sparen könnte, wenn die Aerodynamik oder der Rollwiderstand besser wäre.

Und dort läuft es dann wieder zusammen, obwohl sowohl gebremst als auch verzögert wird:
Gute Frage. Muss ich mir mal anschauen; spontan habe ich keine Idee. Das könnte auch ein Bug sein.
Wie erklärt sich denn diese Bilanz bei praktisch identischem speed_calc ?
Spontan fällt mir nichts ein. Da müsste sich aber eine Erklärung finden; hier ist ja weder Geschwindigkeit noch Höhenprofil irgendwie verdächtig.

Nachtrag:
Ist auf jeden Fall interessant! Bisher habe ich die Qualität der Parameter nur anhand der Übereinstimmung Tretleistung/Fahrwiderstände betrachtet, aber das wäre ein zweites Kriterium – die Parameter sind richtig, wenn nicht nur die Tretleistung gleich der Verlustleistung ist, sondern auch an möglichst wenigen Stellen getreten und gebremst wird.
Das hatte ich mal ausprobiert – aber die Zahl der Stellen, an denen getreten wird und anscheinend gebremst (= die Bilanz stimmt nicht) verändert sich recht wenig mit unterschiedlichen cWA und cR (selbst wenn diese grundfalsch sind). Ebenso, wenn man auch noch die Amplitude mit rein multipliziert. Ist also kein geeignetes Kriterium.
 
Zuletzt bearbeitet:
Nachfolgende Screenshots sind bei leicht veränderten und hoffentlich realistischeren Werten CwA=0,07 und vwind=10km/h entstanden.
Spontan fällt mir nichts ein. Da müsste sich aber eine Erklärung finden; hier ist ja weder Geschwindigkeit noch Höhenprofil irgendwie verdächtig.
Vielleicht ein +-1-Adressierungsfehler, da die beiden benachbarten Punkte teils anders aussehen:
Screenshot_20200221-112333_Firefox.jpg Screenshot_20200221-115113_Firefox.jpg Screenshot_20200221-112541_Firefox.jpg
Gute Frage. Muss ich mir mal anschauen; spontan habe ich keine Idee. Das könnte auch ein Bug sein.
Mit den oben genannten veränderten Parametern sieht diese Stelle jetzt ganz anders aus:
Screenshot_20200221-115542_Firefox.jpg Screenshot_20200221-115542_Firefox.jpg Screenshot_20200221-115908_Firefox.jpg
Achtung: am Schluss ist die Reihenfolge etwas durcheinander gegangen
 

Anhänge

  • Screenshot_20200221-115733_Firefox.jpg
    Screenshot_20200221-115733_Firefox.jpg
    157,4 KB · Aufrufe: 23
Zuletzt bearbeitet:
Habe jetzt noch Zoom-Parameter nachgerüstet, so dass man gleich beim Laden der Datei einen kleinen Ausschnitt anzeigen kann. Also beispielsweise für die Screenshots hier könnte man zoom_min=229 und zoom_max=233 angeben, dann wird nur dieser Teil gezeichnet; da nicht die Berechnung der Leistungsdaten, sondern das Zeichnen des Diagramms die Performance kostet, macht das große Dateien viel besser handhabbar (vorausgesetzt, man weiß, welchen Teil man sich anschauen will). Dann kann man auch sämtliche Datenfelder aktiviert lassen, ohne dass es unerträglich langsam wird.

Zudem habe ich ergänzt, dass man mit den Pfeiltasten nach links/rechts den gezoomten Bereich verschieben kann (um 1/4 der Breite). Muss also dafür nicht mehr heraus- und wieder hineinzoomen.

Jetzt zu den Anmerkungen:
Und dort läuft es dann wieder zusammen, obwohl sowohl gebremst als auch verzögert wird:
Gute Frage. Muss ich mir mal anschauen; spontan habe ich keine Idee. Das könnte auch ein Bug sein.
Genau verstanden habe ich es noch nicht; aber es dürfte an folgendem Mechanismus liegen:
  • An jedem Punkt wird die Eingangsleistung mit der Ausgangsleistung verglichen, und die berechnete Geschwindigkeit ausgehend von der gemessenen Geschwindigkeit entsprechend nach oben oder unten korrigiert, bis die Abweichung möglichst klein ist.
  • In die berechnete Leistung geht allerdings auch die Beschleunigung/Abbremsung von der berechneten Leistung am vorherigen Datenpunkt ein.
  • Wenn also an einem Punkt die berechnete Leistung noch auf der gemessenen Leistung steht, aber dort zufällig die Leistungsbilanz genau passt, dann wird die Geschwindigkeit nicht weiter verändert.
Die Lösung dürfte also sein, die berechnete Geschwindigkeit nicht an jedem Punkt neu ab der gemessenen Geschwindigkeit zu berechnen, sondern nur eine begrenzte Variation der vorherigen berechneten Geschwindigkeit zuzulassen.
Vielleicht ein +-1-Adressierungsfehler, da die beiden benachbarten Punkte teils anders aussehen:
Da ist mir nicht so ganz klar, auf was du eigentlich hinaus willst. Dass die Leistungsbilanz unvollständig ist? Klar, mit Fehlern in der gemessenen Tretleistung kann man das nicht erklären, weil dort die Tretleistung null ist.

Ich glaube, der springende Punkt ist: Die Bremsleistung wird nur aus der Geschwindigkeitsverminderung berechnet, nicht aus dem Höhenverlust. Wenn jemand bergab mit schleifender Bremse fährt, so dass die Geschwindigkeit gleich bleibt, ist die angezeigte Bremsleistung null, aber trotzdem ist eine riesige Lücke in der Leistungsbilanz.

Lösung? Natürlich könnte ich die gesamte Differenz in der Leistungsbilanz pauschal als Bremsleistung annehmen. Das Problem ist eben, wir haben null Informationen darüber, ob gebremst wurde; d.h. es ist vollkommen unklar, ob die Differenz in der Leistungsbilanz vom Bremsen kommt, oder weil die Parameter vollkommen falsch sind. Die Bremsleistung ist also der fudge factor, in den man alles reinpacken kann, was man nicht erklären kann.
 
Die Lösung dürfte also sein, die berechnete Geschwindigkeit nicht an jedem Punkt neu ab der gemessenen Geschwindigkeit zu berechnen, sondern nur eine begrenzte Variation der vorherigen berechneten Geschwindigkeit zuzulassen.
Ich habe das jetzt mal implementiert:
Ergebnis: Es ist nicht wirklich besser. Natürlich sind die Geschwindigkeitssprünge weg; aber dafür passt die berechnete Geschwindigkeit viel schlechter.

Das Problem ist eben die mangelnde Information über das Bremsen. Wenn man, so wie in der neuen Version, die Bremsleistung komplett ignoriert, dann laufen die Geschwindigkeiten immer weiter auseinander, weil immer mehr Energie dazukommt. In bergigem Gelände geht das nicht lange gut. Wenn man dagegen annimmt, dass jede Differenz in der Leistungsbilanz durch Bremsen verursacht wird, dann ist die berechnete Geschwindigkeit automatisch identisch zur gemessenen.
 
Da ist mir nicht so ganz klar, auf was du eigentlich hinaus willst.
Im Bild 230,98km ist P_down 783W und in der Bilanz fehlen 266W.
Die Parameter sind so gewählt, dass z.B. einen Kilometer zuvor noch gute Übereinstimmung zwischen der gemessenen und der gerechneten Geschwindigkeit herrscht.
Eine Sekunde weiter im Bild 230,99km sind die Werte für diese Leistungen weitgehend gleich. Allerdings ist sprunghaft die Bremsleistung und vorallem die Verzögerungsleistung hinzugekommen und in der Bilanz fehlen jetzt 684W.

Deshalb meinte ich, dass da fehlerhaft referenziert wurde.
Aber vielleicht liegt es ja daran, dass schnelle Änderungen auf Grund der sekündlichen Erfassung nicht genau zugeordnet werden können.
 
Aber vielleicht liegt es ja daran, dass schnelle Änderungen auf Grund der sekündlichen Erfassung nicht genau zugeordnet werden können.
Das glaube ich nicht. Die Kurven von Geschwindigkeit und von Höhe sind glatt, also müssen es die daraus berechneten Daten auch sein.
Eine Sekunde weiter im Bild 230,99km sind die Werte für diese Leistungen weitgehend gleich. Allerdings ist sprunghaft die Bremsleistung und vorallem die Verzögerungsleistung hinzugekommen und in der Bilanz fehlen jetzt 684W.
Ganz verstehe ich immer noch nicht, welche Bilder bzw. welche Leistungsbilanzen du jetzt vergleichst.

Ich glaube, die Bremsleistung ist einfach irreführend bzw. schwierig zu interpretieren:
  • Definition meiner Bremsleistung: Die Leistung, die aus der Geschwindigkeitsverminderung kommt, und nicht durch die sonstigen Fahrwiderstände aufgefressen wird.
  • Die ursprüngliche Idee war, die Leistungen einfach in entsprechende „Töpfe“ umzuverteilen, damit nichts doppelt gezählt wird. Deshalb wird hier im Quellcode auch die Bremsleistung von der Bergab-Leistung abgezogen.
  • Später habe ich dann die Statistik hinzugefügt; und damit verbunden die Leistungen in Eingangs- und Ausgangsleistungen gruppiert, und ebenfalls alle Eingangsleistungen und Ausgangsleistungen im Diagramm getrennt gestapelt. Aber so gesehen macht es überhaupt keinen Sinn mehr, die Bremsleistung (also eine Ausgangsleistung) von der Bergab-Leistung (eine Eingangsleistung) abzuziehen.
  • => Ich sollte die Bremsleistung neu definieren: die Leistung, die zwischen Eingangs- und Ausgangsleistung fehlt, wenn nicht getreten wird. Oder die Bremsleistung gleich ganz weglassen.
Identische speed_calc bei um 338W höherer Eingangsleistung !
Klingt so, als wäre genau die Bremsleistung von der Eingangsleistung umverteilt worden. Da die gemessene Geschwindigkeit abnimmt, die berechnete aber nicht, ist ein starker Hinweis, dass tatsächlich gebremst wurde. Die berechnete Geschwindigkeit weiß davon nichts, sieht aber überschüssige Leistung, und beschleunigt weiter.
 
  • Deshalb wird hier im Quellcode auch die Bremsleistung von der Bergab-Leistung abgezogen.
  • Später habe ich dann die Statistik hinzugefügt; und damit verbunden die Leistungen in Eingangs- und Ausgangsleistungen gruppiert, und ebenfalls alle Eingangsleistungen und Ausgangsleistungen im Diagramm getrennt gestapelt. Aber so gesehen macht es überhaupt keinen Sinn mehr, die Bremsleistung (also eine Ausgangsleistung) von der Bergab-Leistung (eine Eingangsleistung) abzuziehen.
  • => Ich sollte die Bremsleistung neu definieren: die Leistung, die zwischen Eingangs- und Ausgangsleistung fehlt, wenn nicht getreten wird. Oder die Bremsleistung gleich ganz weglassen.
Das wäre schade: gerade aus der Bremsleistung kann man folgern, wie es effizienter gehen könnte.

Den Quell-Code hab ich mir angesehen - überblicke es jedoch nicht:
Bergab-Leistung ist also nicht P_down, sondern P_decel? Ich verstand P_decel als Leistung aus der Verzögerung (=Geschwindigkeitsabnahme).
 
Bergab-Leistung ist also nicht P_down, sondern P_decel? Ich verstand P_decel als Leistung aus der Verzögerung (=Geschwindigkeitsabnahme).
Doch, du hast schon Recht.
=> Ich sollte die Bremsleistung neu definieren: die Leistung, die zwischen Eingangs- und Ausgangsleistung fehlt, wenn nicht getreten wird.
Genau das habe ich jetzt mal testweise gemacht:
  • Bremsleistung stammt jetzt nicht nur aus der Geschwindigkeitsverminderung, sondern auch aus der Bergabfahrt, und davon abgezogen wird jetzt auch die Beschleunigungsleistung. (Das ist kein Problem, weil je nach Geschwindigkeits- oder Höhenänderung nur entweder Bergab- oder Bergauf-Leistung und entweder Geschwindigkeitsverminderung oder Beschleunigung größer 0 ist. Die Beschleunigungsarbeit kann also nicht aus Abbremsung stammen, und die Kletterarbeit nicht aus Bergabfahrt.)
  • Die Geschwindigkeitsverminderung (P_decel) wird jetzt komplett angezeigt, statt um die Bremsleistung verringert.
  • Als Bremsleistung wird nur jene Überschuss-Leistung gewertet, wenn nicht gleichzeitig getreten wurde (bzw. weniger als 10 W).
  • Zudem wird die berechnete Geschwindigkeit nicht ausgehend von der gemessenen Geschwindigkeit variiert, sondern ausgehend von der vorherigen berechneten Geschwindigkeit – außer, es wurde gebremst; dann wird von der gemessenen Geschwindigkeit ausgegangen.
Ergebnis: Version mit Demo-Datei
  • Die berechnete Geschwindigkeit ist nicht wirklich besser; es treten genauso Sprünge auf.
  • Bei den Demo-Daten ist die Bilanz ziemlich gleich. Kein Wunder, denn es ist eine flache Strecke, wo bergab nicht gebremst wird (bzw. nur, um anzuhalten).
 
Zurück
Oben Unten