- Beiträge
- 3.485
Ja; beziehungsweise, die Leistung steigt kubisch. Die Berechnung ist von Kreuzotter übernommen, analysiert und beschrieben habe ich die Formeln hier.Hast Du berücksichtigt, daß der Luftwiderstand quadratisch ansteigt?
Follow along with the video below to see how to install our site as a web app on your home screen.
Anmerkung: This feature currently requires accessing the site using the built-in Safari browser.
Ja; beziehungsweise, die Leistung steigt kubisch. Die Berechnung ist von Kreuzotter übernommen, analysiert und beschrieben habe ich die Formeln hier.Hast Du berücksichtigt, daß der Luftwiderstand quadratisch ansteigt?
Danke dir!Systemgewicht somit 114-119 Kg.
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 fehlen 908,2-(122,4+128,1+54,1) = 603,6W. Da stimmt irgendetwas noch überhaupt nicht!
Das grüne P_brake ist ja eingeschaltet - warum wird im Fenster dann davon nichts angezeigt?man kann ja hunderte Watt wegbremsen und trotzdem schneller werden.
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.Es muss irgendwie mit P_decel zusammen hängen. Immer wenn verzögert und gebremst wird läuft die Leistungsbilanz auseinander:
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.Seltsam ist, dass wir dort jetzt 20cm höher sind - ein Rundungsproblem?
Das mit dem Wissen ist so eine Sache - was man nicht weiß erkennt man ja oft gar nicht. 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.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
Gute Frage. Muss ich mir mal anschauen; spontan habe ich keine Idee. Das könnte auch ein Bug sein.Und dort läuft es dann wieder zusammen, obwohl sowohl gebremst als auch verzögert wird:
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.Wie erklärt sich denn diese Bilanz bei praktisch identischem speed_calc ?
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.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.
Vielleicht ein +-1-Adressierungsfehler, da die beiden benachbarten Punkte teils anders aussehen: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.
Mit den oben genannten veränderten Parametern sieht diese Stelle jetzt ganz anders aus:Gute Frage. Muss ich mir mal anschauen; spontan habe ich keine Idee. Das könnte auch ein Bug sein.
Und dort läuft es dann wieder zusammen, obwohl sowohl gebremst als auch verzögert wird:
Genau verstanden habe ich es noch nicht; aber es dürfte an folgendem Mechanismus liegen:Gute Frage. Muss ich mir mal anschauen; spontan habe ich keine Idee. Das könnte auch ein Bug sein.
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.Vielleicht ein +-1-Adressierungsfehler, da die beiden benachbarten Punkte teils anders aussehen:
Ich habe das jetzt mal implementiert: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.
Im Bild 230,98km ist P_down 783W und in der Bilanz fehlen 266W.Da ist mir nicht so ganz klar, auf was du eigentlich hinaus willst.
Das glaube ich nicht. Die Kurven von Geschwindigkeit und von Höhe sind glatt, also müssen es die daraus berechneten Daten auch sein.Aber vielleicht liegt es ja daran, dass schnelle Änderungen auf Grund der sekündlichen Erfassung nicht genau zugeordnet werden können.
Ganz verstehe ich immer noch nicht, welche Bilder bzw. welche Leistungsbilanzen du jetzt vergleichst.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.
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.Identische speed_calc bei um 338W höherer Eingangsleistung !
Bild 230,98km mit Bild 230,99kmGanz verstehe ich immer noch nicht, welche Bilder bzw. welche Leistungsbilanzen du jetzt vergleichst.
Das wäre schade: gerade aus der Bremsleistung kann man folgern, wie es effizienter gehen könnte.
- 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.
Doch, du hast schon Recht.Bergab-Leistung ist also nicht P_down, sondern P_decel? Ich verstand P_decel als Leistung aus der Verzögerung (=Geschwindigkeitsabnahme).
Genau das habe ich jetzt mal testweise gemacht:=> Ich sollte die Bremsleistung neu definieren: die Leistung, die zwischen Eingangs- und Ausgangsleistung fehlt, wenn nicht getreten wird.