elektronische Federungsoptimierung

Registriert
11. Oktober 2014
Reaktionspunkte
8
Vor nicht allzulanger Zeit wurde das ShockWiz System vorgestellt. Dieses dient zur optimierung der Federung von Luftgabeln.
Da ich technisch nicht ganz unbegabt bin dachte ich mir, das geht universeller.
Lange Rede kurzer Sinn, nun bin ich an dem Punkt angelangt, wo der erste Prototyp fertig und am Bike montiert ist.

Beschreibung:
- Sensoren messen die auftretenden Kräfte
- Mikrocontroller ließt Sensoren aus
- RTC (Uhr) für Zeitstempel
- Speichern der Zeit und der Daten auf einer SD Karte
- Fernbedienbar per Lenker (Start/Stop)
- diverse LED Anzeigen für den Betriebsmodus

Vorerst werden die Daten per Excel Diagramm visualisiert, in Zukunft übernimmt dies eine APP.
Erste Tests wurden erfolgreich überstanden, nächste Woche steht der erste Bikepark Test an.

Nun seid Ihr gefragt:
- welche zusätzlichen Funktionen würdet ihr Euch wünschen?
- konstuktive Kritik?

Freu mich über Feedback
 
Interessantes Projekt, welche Sensoren sind denn dran? Linearpotentiometer für den Hub und Drucksensor, nehme ich an. Welchen Microcontroller verwendest du? Mich würden die Federkennlinie sowie Dämpfungskennwerte interessieren, aber Letzteres könnte schwierig werden. Dir steht nicht zufällig ein Dynamometer zur Verfügung?
 
die Sensorik zu bauen ist ja nur der kleinere, einfache Teil :)
in einem der letzten Pinkbike-Artikel dazu hatte jemand kommentiert, dass das ja jeder macht, nur um ein paar "wobbly lines for impressing your opponents" zu haben.
Das interessante ist ja, aus den Messungen Erkenntnisse Richtung Fahrwerksabstimmung zu gewinnen. Wenn da über meinetwegen Bremswellen ein paar höhere Zacken in den Graphen sind, bedeutet das mehr Druck, mehr Token, weniger (HS/(LS) Druckstufe, weniger (HS/LS) Zugstufe oder irgendwie alles ein bisschen anders? Und das am Dämpfer und/oder Gabel? Und wie ist's dann ein paar Meter weiter durch ein Wurzelfeld, über das Roadgap?

Und in Anbetracht der Parameter die ich an einem Rad verstellen kann (Federhärte, Dämpfung, Luftdruck, jeweils vorne/hinten + ggf. Token, LS/HS Dämpfung) und wenn ich will noch Vorbau-Länge/Höhe, Reifenbreite + ggf. Geometrie-Verstellung des Rahmens, bleibt da ne Menge Testaufwand.

Der Transfer von den Messwerten auf "besseres" Fahrgefühl (was auch immer dann besser ist, weniger Armpump, schnellere Zeiten, keine Durchschläge mehr/99% genutzter Federweg) ist ja das, wo beim shock-wiz das Know-how drinsteckt, die Mechanik ist simpel.
 
Dazu braucht man eben für alle Anwendungsfälle einzelne Kriterien. ZB im Steinfeld Kontaktverlust zwischen Reifen und Boden → Rebound schneller machen. Roadgap: Hub 100% ausgenutzt → Druckstufe und Luftdruck erhöhen etc. pp. Nachher kommen sowieso nur Richtlinien raus, der Weisheit letzter Schluss bestimmt die eigene Vorliebe und das vorliegende Streckenprofil. Erst mal verlässliche Messwerte zu haben ist doch ein sehr guter Anfang :)
 
Erst mal verlässliche Messwerte zu haben ist doch ein sehr guter Anfang :)

Jo, Messwerte sind ein guter Anfang :) Dann hat man meinetwegen in der Spitze mehrfach Beschleunigungen von 75g an der Vorderradnabe und 85g am Hinterrad gemessen. Ist das gut? Zu viel? Geht da noch mehr? Oder ist das u.u. nicht relevant, weil Kraft-Weg Messung an Gabel und Hinterbau aussagekräftiger sind? Einfach nur bunte Linien in Excel malen ist schick, aber mal ein paar ;) Tage im Bikepark gezielt konstante Runden fahren, dann Fahr-Eindrücke + Graphen korrelieren um dann am Ende vom Tag das auch mal Rückwärts machen zu können, das bringt den echten Mehrwert.
 
Klar, ohne Linearpotentiometer an Gabel/Dämpfer und ev. ein paar DMS hier und da aus Spaß an der Freude würde ich das eh nicht anfangen, Beschleunigungssensoren sind nur bedingt hilfreich.
 
schonmal vielen Dank für Euer Feedback.
Ich bin ein wenig überrascht, das es anscheinend doch schon ne menge Leucht gibt, die die gleiche Idee wie ich hatte :)

Was genau spricht denn gegen Beschleunigungssensoren??
Vielleicht denke ich da zu naiv, aber per Software lässt sich das sicher entsprechend auswerten, da ich neben den Sensor Werten auch die Zeit der Messung mitlogge.
 
Wenn du nur die verwendest solltest du den einen oder anderen Filter drüberlaufen lassen, ansonsten hast du viele Spitzen durch Vibrationen ohne große Aussagekraft. Ob das dann verwertbar ist sei dahingestellt, ich würde sie jedenfalls in Verbindung mit einer anderen Sensorart (Hubsensor) verwenden. Aber sag mal an, welche Sensoren und welcher Microcontroller sind überhaupt dran?
 
- konstuktive Kritik?
Beschreibung:
- Sensoren messen die auftretenden Kräfte
- Mikrocontroller ließt Sensoren aus
- RTC (Uhr) für Zeitstempel
- Speichern der Zeit und der Daten auf einer SD Karte
- Fernbedienbar per Lenker (Start/Stop)
- diverse LED Anzeigen für den Betriebsmodus
- integrierter Fahrspaß trotz Microcontroller
 
Ich bin ein wenig überrascht, das es anscheinend doch schon ne menge Leucht gibt, die die gleiche Idee wie ich hatte :)

naja, zumindest bei nicht so direkt. Ich bau schon lange an Federelementen herum (ohne Datenlogger) und auch ohne Datenlogger hast du zwei Teile des Problems:
- welche mechanische Veränderung beeinflusst welche Eigenschaft deines Dämpfers
- wie wirkt sich diese Eigenschaft auf das Fahrverhalten aus

Mehr Preload durch eine Spiralfeder auf einen Shimstack macht mehr HSC, das ist eher trivial. Ein dickerer Stack/moar Shimz auch.
Die spannende Frage: was fährt sich besser(TM) wenn ich mehr HSC brauche?

Bzw. umgekehrt: ich fahre eine bestimmte Strecke mit einem Base-Tune vom Hersteller. Bekomme ich es hin zu beschreiben, was mir daran nicht gefällt oder was ich gerne besser hätte (geht zu sehr auf die Unterarme, Traktionsverlust, zu viel/wenig Federweg genutzt) und kann ich im 2. Schritt daraus möglichst zielgerichtet Veränderungen ableiten (weniger HSC, weniger LSR, mehr Druck)?

Was genau spricht denn gegen Beschleunigungssensoren??
Vielleicht denke ich da zu naiv, aber per Software lässt sich das sicher entsprechend auswerten, da ich neben den Sensor Werten auch die Zeit der Messung mitlogge.

klingt nach Hammer und Nagel Problem: wenn du nen Hammer hast, sehen alle Probleme wie Nägel aus :)

Du hast de facto mit deinem Datenlogger dasselbe Problem: du misst erstmal abstrakte Größen über die Zeit. Und ja, du bekommst die Beschleunigung über die Zeit, mit genug Geld auch mehr als fein genug aufgelöst.

Aber was sagen dir die Werte, in welche Richtung optimierst du das?
Extrembeispiel: du nutzt auf einer Abfahrt genau einmal 100% des Gabel-Federwegs, bei einem eher stumpfen Drop. Sieht an sich gut aus. Dank viel zu vieler Token und wenig Druck in der Gabel aber hängt die im Mittel viel zu weit im Federweg, zu viel Zugstufe macht's noch schlimmer, mehr Durchschläge gibt's nur nicht, weil so viele Token in der Gabel stecken. Fährt sich hochgradig schlecht, der genutzte Federweg sieht auf den ersten Blick gut aus (oh, ein Durchschlag, das ist ok)
Das ist von außen ohne Datenlogger auch relativ einfach festzustellen, sehr viele Token und wenig Druck sind schon mal suspekt^^

Anhand welcher Messwerte aber machst du das fest? Wann ist eine Gabel "im Mittel zu weit im Federweg"? Was sagen dir in so einem Fall deine Beschleunigungssensoren? sind da 10g, 50g oder 100g zu viel des Guten?

Ich würde die Elektronik und den Datenlogger erstmal links liegen lassen und versuchen zu verstehen bzw. herauszufinden, wie andere das Optimieren. Oder eine sehr einfache und billige Lösung nur für die Gabel bauen und dann eingehend testen, Sprich ausreichend viel Zeit in einem Bikepark auf einer Strecke verbringen und dann pro Abfahrt: Gabel-Setting, Fahreindruck, Datenlogger-Datensatz speichern und schauen ob man das korreliert bekommt und sich Schlussfolgerungen daraus ableiten lassen.
 
naja, zumindest bei nicht so direkt. Ich bau schon lange an Federelementen herum (ohne Datenlogger) und auch ohne Datenlogger hast du zwei Teile des Problems:
- welche mechanische Veränderung beeinflusst welche Eigenschaft deines Dämpfers
- wie wirkt sich diese Eigenschaft auf das Fahrverhalten aus

Mehr Preload durch eine Spiralfeder auf einen Shimstack macht mehr HSC, das ist eher trivial. Ein dickerer Stack/moar Shimz auch.
Die spannende Frage: was fährt sich besser(TM) wenn ich mehr HSC brauche?

Bzw. umgekehrt: ich fahre eine bestimmte Strecke mit einem Base-Tune vom Hersteller. Bekomme ich es hin zu beschreiben, was mir daran nicht gefällt oder was ich gerne besser hätte (geht zu sehr auf die Unterarme, Traktionsverlust, zu viel/wenig Federweg genutzt) und kann ich im 2. Schritt daraus möglichst zielgerichtet Veränderungen ableiten (weniger HSC, weniger LSR, mehr Druck)?



klingt nach Hammer und Nagel Problem: wenn du nen Hammer hast, sehen alle Probleme wie Nägel aus :)

Du hast de facto mit deinem Datenlogger dasselbe Problem: du misst erstmal abstrakte Größen über die Zeit. Und ja, du bekommst die Beschleunigung über die Zeit, mit genug Geld auch mehr als fein genug aufgelöst.

Aber was sagen dir die Werte, in welche Richtung optimierst du das?
Extrembeispiel: du nutzt auf einer Abfahrt genau einmal 100% des Gabel-Federwegs, bei einem eher stumpfen Drop. Sieht an sich gut aus. Dank viel zu vieler Token und wenig Druck in der Gabel aber hängt die im Mittel viel zu weit im Federweg, zu viel Zugstufe macht's noch schlimmer, mehr Durchschläge gibt's nur nicht, weil so viele Token in der Gabel stecken. Fährt sich hochgradig schlecht, der genutzte Federweg sieht auf den ersten Blick gut aus (oh, ein Durchschlag, das ist ok)
Das ist von außen ohne Datenlogger auch relativ einfach festzustellen, sehr viele Token und wenig Druck sind schon mal suspekt^^

Anhand welcher Messwerte aber machst du das fest? Wann ist eine Gabel "im Mittel zu weit im Federweg"? Was sagen dir in so einem Fall deine Beschleunigungssensoren? sind da 10g, 50g oder 100g zu viel des Guten?

Ich würde die Elektronik und den Datenlogger erstmal links liegen lassen und versuchen zu verstehen bzw. herauszufinden, wie andere das Optimieren. Oder eine sehr einfache und billige Lösung nur für die Gabel bauen und dann eingehend testen, Sprich ausreichend viel Zeit in einem Bikepark auf einer Strecke verbringen und dann pro Abfahrt: Gabel-Setting, Fahreindruck, Datenlogger-Datensatz speichern und schauen ob man das korreliert bekommt und sich Schlussfolgerungen daraus ableiten lassen.


Vielen Dank :)

Ganz unwissend im Bereich der Federelemente bin ich nicht, nur an den Shim Stack hab ich mich bisher noch nicht heran getraut.

Mein aktuelles System hat 2 Beschleunigungssensoren. Einer sitzt am Casting, einer am Standrohr zwischen den Kronen.
Die Idee dahinter, das Delta der Sensoren gibt aufschluss über die Bewegung der Gabel und deren aktuelle Position.
Vorerst werden die Sensoren per Arduino (ja ich weiß, ein BAstel Controller :) )ausgelesen und die Daten geloggt, später kommt ein Basic Tiger Industrie Controller zum Einsatz.

Erstmal ist das ganze ein privates Projekt, um Erfahrungen zu sammeln. Es ist immer schön wenn sich das Hobby mit dem Beruf verbinden lässt:)
Jedoch habe ich den ansporn ein möglichst kleines, kompaktes System zu entwickeln, welches einem beim optimieren von Federelementen unterstützt.
 
Die Idee dahinter, das Delta der Sensoren gibt aufschluss über die Bewegung der Gabel und deren aktuelle Position.
In der Theorie ist das ganz einfach aber in der Praxis wirst du da einige Probleme haben weil du zwei mal differenzieren musst und anschließend auch noch die Differenz aus den beiden Werten bilden musst. Dadurch wird aber vor allem das Rauschen extrem verstärkt. Damit das funktioniert muss man gewaltig über abtasten (min. Faktor 100-1000) und sehr stark filtern.

Wenn man allerdings die aufgezeichneten Daten im Nachhinein mit Hilfe des Streckenprofils vergleicht, kann man mit den Beschleunigungen direkt schon einiges anfangen. Allerdings würde ich da auch die Beschleunigungen auf den Fahrer mitnehmen, ansonsten bekommt ein aktiver Fahrer möglicherweise ein zu weiches Fahrwerk ohne Feedback.
 
Zuletzt bearbeitet:
In der Theorie ist das ganz einfach aber in der Praxis wirst du da einige Probleme haben weil du zwei mal differenzieren musst und anschließend auch noch die Differenz aus den beiden Werten bilden musst. Dadurch wird aber vor allem das Rauschen extrem verstärkt. Damit das funktioniert muss man gewaltig über abtasten (min. Faktor 100-1000) und sehr stark filtern.

Wenn man allerdings die aufgezeichneten Daten im Nachhinein mit Hilfe des Streckenprofils vergleicht, kann man mit den Beschleunigungen direkt schon einiges anfangen. Allerdings würde ich da auch die Beschleunigungen auf den Fahrer mitnehmen, ansonsten bekommt ein aktiver Fahrer möglicherweise ein zu weiches Fahrwerk ohne Feedback.

In der Theorie ist alles einfach und Probleme sind da um gelöst zu werden :)
Wenn das ganze einfach und ohne Probleme machbar wäre, würde es auf dem Markt von solchen Projekten wimmeln.

Aktuell bin ich ja noch am Anfang, die Hardware und die Programmierung des Messsystems läuft, nun heißt es erstmal im Bikepark testen bis zum umfallen. Ob die Daten was taugen und über ein komplexes Programm per PC oder Smartphone überhaupt auswertbar sind, wird sich zeigen. Vielleicht ist mein System aktuell noch viel zu langsam, oder brauche genauere Sensoren, oder vielleicht sogar nen FRam Speicher statt ne SD Karte...
Der aktuelle Aufbau soll erstmal lediglich als eine Art Machbarkeitsanalyse fungieren.

Evtl wird das ganze später wesentlich "professioneller" im Rahmen meines Techniker Studiums umgesetzt.

Zum Ende dieses Beitrags möchte ich mich für die sehr anregende und informative Beteiligung bedanken:daumen:

Anbei 2 Bilder für interessierte :)

DSC01216.JPG

DSC01217.JPG
 

Anhänge

  • DSC01216.JPG
    DSC01216.JPG
    129,6 KB · Aufrufe: 48
  • DSC01217.JPG
    DSC01217.JPG
    164,8 KB · Aufrufe: 46
Die Datenrate sollte kein Problem sein.
Ich nehme den MPU6050 her und der hat am I2C vom RaspberryPi 1 über 100Hz und ich meine den könnte man auch noch schneller betreiben.

Das ganze Gejammer wegen der Nachbearbeitung kann ich nicht nachvollziehen. Vor 10 Jahren hätte ich vielleicht auch Bedenken gehabt, aber heute kann man so Sachen wie Gradientenanalyse mit jedem Laptop erschlagen. Alles was sich in einer Tasse Kaffee ausrechenen lässt, nehme ich als instantan an. :-)

Klar fängt man sich nen Fehler ein, aber was solls.

Schau erst mal wie schlimm es mit den Spikes in den Rohdaten wirklich ist. Ich würde mal zum Anfang einen gliding average in verschiedenen Intervallen drüber laufen lassen.
Mich würde eine FT von den Beschleunigungsdaten interessieren um mal zu sehen was so typische Werte sind.
Was können die Sensoren? sind das reine 3 Achsen Accelerometer oder auch Gyros? wenn du noch nen gyro übrig hast, kannst du den am hinterbau befestigen. Darüber ließe sich dann auch der travel hinten bestimmen.


Vorerst werden die Daten per Excel Diagramm visualisiert
Freu mich über Feedback
DAS ist eine Sünde und sollte unterlassen werden. Tu dir und allen anderen Menschen einen Gefallen und nimm was vernünftiges wie z.B. Origin her. Wenn Du an ner Uni bist, dann habt ihr bestimmt Lizenzen.

In der Theorie ist das ganz einfach aber in der Praxis wirst du da einige Probleme haben weil du zwei mal differenzieren musst und anschließend auch noch die Differenz aus den beiden Werten bilden musst. Dadurch wird aber vor allem das Rauschen extrem verstärkt. Damit das funktioniert muss man gewaltig über abtasten (min. Faktor 100-1000) und sehr stark filtern.

Wenn man allerdings die aufgezeichneten Daten im Nachhinein mit Hilfe des Streckenprofils vergleicht, kann man mit den Beschleunigungen direkt schon einiges anfangen. Allerdings würde ich da auch die Beschleunigungen auf den Fahrer mitnehmen, ansonsten bekommt ein aktiver Fahrer möglicherweise ein zu weiches Fahrwerk ohne Feedback.

Ich finde keinen Grund warum er differenzieren müsste.
Folgendes Gedankenexperiment: Ich fahre mit konstanter Geschwindigkeit im 90° winkel auf eine Bordsteinkante und absorbiere diese vollständig im Ferderweg.
Was sehe ich?
Sensor unten: je nach lage der Accels werden zwei, vermutlich aber alle drei achsen einen Ausschlag geben. Erst positiv und dann negativ, ein und ausfedervorgang, in jedem Fall wirds irgendwann einen vorzeichenwechsel geben. Den ausfedervorgang lass ich erst mal beiseite und schau mir nur den ersten teil an. In diesem fall kann ich einfach die werte vom accel aufsummieren und habe die beschleunigung in richtung der standrohre. mit s=1/2gt² kann ich jetzt punktweise integrieren. fertig.
Am berg muss man für die Vorwärtsbeschleunigung und die hangneigung korrigieren, sollte aber kein problem darstellen.
 
Ich finde keinen Grund warum er differenzieren müsste.
Das bezog sich auch rein auf sein Vorhaben an Hand der Beschleunigungswerte auf die Position rückzuschließen. Das würde ich gerne sehen, wie du das ohne abzuleiten schaffst.

EDIT:
Sorry, hatte einen Knoten in der Gehirnwindung, man muss ja nur integrieren nicht differenzieren. Da bleibt dann nur das Problem des unbekannten Offsets im DC Bereich, aber den SAG korrekt einzustellen dürfte jetzt keine große Herausforderung sein.
 
Zuletzt bearbeitet:
[QUOTE="Reisi0, post: 14625593, member: 127941"
EDIT:
Sorry, hatte einen Knoten in der Gehirnwindung, man muss ja nur integrieren nicht differenzieren. Da bleibt dann nur das Problem des unbekannten Offsets im DC Bereich, aber den SAG korrekt einzustellen dürfte jetzt keine große Herausforderung sein.[/QUOTE]

Was ist der DC Bereich?
 
DAS ist eine Sünde und sollte unterlassen werden. Tu dir und allen anderen Menschen einen Gefallen und nimm was vernünftiges wie z.B. Origin her. Wenn Du an ner Uni bist, dann habt ihr bestimmt Lizenzen.

Bitte um aufklärung, was ist Orgin? :)
Die Messdaten werden aktuell in einem CSV File auf der SD Karte geloggt.
Außer Excel fällt mir spontan kein anderes Programm ein.


Die Sensoren sind 3 Achsen Beschleunigungssensoren, Messdaten per I2C, in 14 bit Auflösung (1-32er sample), mit max 800hz, 2G/4G/8G Modus, verschiende weitere Modi,...

Die Idee mit dem zusätzlichen Gyro ist interessant, jedoch brauch ich dafür nen größeren Microcontroller.
 
Ich denke, die Beschleunigungssensoren sind ein nice-to-have, aber nicht der Kernpunkt. Ich finde da den Ansatz von Sussmybike ohnehin interessanter als Shockwiz, abgesehen davon, dass ich mir nicht so sicher bin, dass ihr System schnell genug ist. Ein Linearpotentiometer wie es auch an den ganzen Bikes der Profis zur Datenanalyse eingesetzt wird ist da auf jeden Fall die bessere Lösung. Ich habe vor ein paar Monaten mal angefangen sowas ähnliches zu basteln, allerdings mit einem Drehencoder, ein Zwischending aus Linearpoti und Sussmybike. Aus Zeitgründen ist das ganze aber mal pausiert..
Der Vorteil eines Selbstbaus gegenüber einem fertig-System ist (neben dem Preis) auf jeden Fall, dass man an die Rohdaten kommt - ich glaube gerade die paar "wobbly lines for impressing your opponents" sind dabei der größte Vorteil. Allein schon, um ein ungefähres Gefühl für das Fahrwerk zu bekommen. Natürlich ist es sehr schwer wirklich genau aus den Diagrammen zu lesen, was wie angepasst werden muss, aber mit ein bisschen Erfahrung, Übung und Sachverstand sollte es doch möglich sein Tendenzen zu erkennen. Und das wäre mir die Sache auf jeden Fall wert.


Wie viel g schafft das Ding max?
800hz sind wohl eher ein schlechter Witz.. bei einer Kolbengeschwindigkeit von 7m/s (5-10 sollen realistisch sein) ist das ein knapper Zentimeter der da dazwischen rumflitzt. Damit werden dann aus den "wobbly lines" wahrscheinlich sehr miese Treppen.
 
Matlab? Gibts als Privatperson für 120€ und für Studenten für 35, falls zutreffend.
Matlab ist für solche Probleme nicht zielführend. Da liegt der fokus eher auf computation und nicht auf Meßdatenauswertung. Kann man natürlich auch hernehmen, ist aber irgendwie overkill.
Origin ist ein Programm zur auswertung von meßdaten und bringt jede menge tools zur visualisierung und nachbearbeitung mit und ist sehr gut dokumentiert.


Ich denke, die Beschleunigungssensoren sind ein nice-to-have, aber nicht der Kernpunkt. Ich finde da den Ansatz von Sussmybike ohnehin interessanter als Shockwiz, abgesehen davon, dass ich mir nicht so sicher bin, dass ihr System schnell genug ist. Ein Linearpotentiometer wie es auch an den ganzen Bikes der Profis zur Datenanalyse eingesetzt wird ist da auf jeden Fall die bessere Lösung. Ich habe vor ein paar Monaten mal angefangen sowas ähnliches zu basteln, allerdings mit einem Drehencoder, ein Zwischending aus Linearpoti und Sussmybike. Aus Zeitgründen ist das ganze aber mal pausiert..

Wie viel g schafft das Ding max?
800hz sind wohl eher ein schlechter Witz.. bei einer Kolbengeschwindigkeit von 7m/s (5-10 sollen realistisch sein) ist das ein knapper Zentimeter der da dazwischen rumflitzt. Damit werden dann aus den "wobbly lines" wahrscheinlich sehr miese Treppen.

Linearpotis sind für testruns sicher der goldstandard. Das zeug von Süssmywasweisich finde ich ne frechheit.
1000 cm/s wären das äquivalent zu einem 5m huck to flat. Für einen DH race run müsste man vielleicht auf SPI interface wechseln, aber für den normalen trail reichen die 800 Hz locker. Die treppen sind egal, man müsste nur n paar mal die durchschläge simulieren und dann schauen wie man interpolieren muss.
Die 8G einstellung würde ich mal testen. die ist von sich aus schon grober, was einem den hassle mit dem rauschen erleichtert.
 
Gibt es inzwischen Erfahrungen zu berichten? Sind die Daten verwertbar? Sind 800 Hz wirklich notwendig? Welche Sensoren sind eigentlich verbaut?
-Fragen über Fragen-
 
Ein Langzeittest konnte ich leider nicht durchführen, da mir mein Bike incl Messsystem aus meiner Garage geklaut wurde.
Habe an 5 Biketagen Messungen vornehmen können.
Im Groben konnte ich schon Rückschlüsse aus der Auswertung ziehen, zb sind die neuen Einstellungen besser oder schlechter sind als vorher.

Um jedoch dem Nutzer Empfehlungen an die HAnd zu geben (Zb 2 Klicks mehr HSC), muß die Auswertung noch kräftig optimiert werden und verschiedene Dämpfermodelle vermessen werden.
 
Zurück