DIY Telemetrie / Data Acquisition System

[nollak]

Hat schon jemand überlegt 2 Beschleunigungssensoren zu verwenden?
Also einen an der Gabelkrone/Standrohren, den anderen an den Tauchrohren.

Aus der Differenz der Beschleunigung zwischen den beiden lässt sich ja auch die Geschwindigkeit, mit der eingefedert wird und der Relative Weg berechnen.
Der Absolute Wert, wie tief man im Federweg steht ist zwar nur schlecht auswertbar. Aber mit den anderen die man bekommt, lässt sich sicher auch einiges am Fahrwerk analysieren:

Beschleunigung die auf die ungefederte Masse wirkt
Beschleunigung die auf die gefederte Masse wirkt
Geschwindigkeit mit der die Gabel einfedert
Weg, der dabei zurückgelegt wird
Steigung/Gefälle
Änderung des Lenkwinkels durch das Einfedern.

Die Überlegungen hatte ich schon mit 2 Beschleunigungssensoren, gerade für einige, aus den Wegmessungen, abgeleitete Werte könnte das Interessant sein. Würde das aber tatsächlich eher als Zusatz sehen. Gerade die Daten was Federwegsausnutzung und dynamischen SAG angeht würde ich immer als erstes heranziehen um die passende Federrrate in den Elementen einzustellen, die fehlt dann halt komplett. Das wäre aber immer der Startpunkt für eine Einstellung. Gerade wenn man mal jemand unbedarften vermisst der evtl sein Fahrwerk noch nie richtig eingestellt hat.

@nollak mit dem ESP32 hatte ich auch Probleme mit den AD-Wandlern. Die gingen bei mir erst bei 0,15V oder so los, wodurch einige Millimeter gefehlt haben - also komplett ausgefahrene Linearpotis im Anfangsbereich.

Hmm schade, der wäre mit WiFi und Bluetooth eben auch ein interessanter Kandidat gewesen. Am vernünftigsten wäre vermutlich ein externer ADC per SPI angebunden. Da sollte es ja präzise Bausteine geben und Geschwindigkeitsmäßig ist man per SPI ja auch nicht wirklich begrenzt. Aktuell fehlt mir eher an vielen Ecken die Zeit um das Projekt weiter zu führen, Ideen sind genug da.

 

[sbradl]

Die Überlegungen hatte ich schon mit 2 Beschleunigungssensoren, gerade für einige, aus den Wegmessungen, abgeleitete Werte könnte das Interessant sein. Würde das aber tatsächlich eher als Zusatz sehen. Gerade die Daten was Federwegsausnutzung und dynamischen SAG angeht würde ich immer als erstes heranziehen um die passende Federrrate in den Elementen einzustellen, die fehlt dann halt komplett. Das wäre aber immer der Startpunkt für eine Einstellung. Gerade wenn man mal jemand unbedarften vermisst der evtl sein Fahrwerk noch nie richtig eingestellt hat.


Hmm schade, der wäre mit WiFi und Bluetooth eben auch ein interessanter Kandidat gewesen. Am vernünftigsten wäre vermutlich ein externer ADC per SPI angebunden. Da sollte es ja präzise Bausteine geben und Geschwindigkeitsmäßig ist man per SPI ja auch nicht wirklich begrenzt. Aktuell fehlt mir eher an vielen Ecken die Zeit um das Projekt weiter zu führen, Ideen sind genug da.

STM32 hatte bei dafür dann auf Anhieb funktioniert

 

[nollak]

STM32 hatte bei dafür dann auf Anhieb funktioniert

Ja gut, da ich die aktuell beruflich nutze wären die nicht die verkehrte Grundlage. Vor allem weiss ich mit Sicherheit das die ADCs da gut und performant funktionieren. Zumindest bei den Derivaten ohne Bluetooth.

Hast du da Erfahrung mit den BLE Varianten?

Mit nem G4 Nucleo wäre aber ein Test Setup vermutlich schnell da. Daten dann halt per SD Karte oder Serieller Schnittstelle runterladen.

 

[sbradl]

Ich hatte ein STM32F401 probiert, weil preiswert im 3er Pack. Bluetooth hatte ich ein HM-10 drangebaut, weil ich davon einige hatte.

 

[nollak]

Ich hatte ein STM32F401 probiert, weil preiswert im 3er Pack. Bluetooth hatte ich ein HM-10 drangebaut, weil ich davon einige hatte.

Evtl schau ich dann mal das ich alles an die Nucleos dran tüdel.
Da ist grad zumindest ne schnelle ADC Abarbeitung und FreeRTOS Nutzung schonmal da. SD Karten schreiben und für erste Tests sollte es ja reichen.
Die F401 waren dann vermutlich diese Bluepill Dinger oder?

Man könnte ja auch mehrere Targets aufsetzten. Blöd ist eher das ich das alles im IAR hab falls das wer nach kompilieren will.

 

[sbradl]

Evtl schau ich dann mal das ich alles an die Nucleos dran tüdel.
Da ist grad zumindest ne schnelle ADC Abarbeitung und FreeRTOS Nutzung schonmal da. SD Karten schreiben und für erste Tests sollte es ja reichen.
Die F401 waren dann vermutlich diese Bluepill Dinger oder?

Man könnte ja auch mehrere Targets aufsetzten. Blöd ist eher das ich das alles im IAR hab falls das wer nach kompilieren will.

Blackpill

Meine ersten Versuche hatte ich mit einem Arduino Nano gemacht und selbst der reicht vollkommen aus. Weiß gar nicht mehr, was da das Problem war, glaube mir gingen die IOs aus. Aber selbst mit dem Nano konnte ich problemlos von beiden Sensoren mit 1000Hz Daten sammeln und auf SD-Karte schreiben. Glaub selbst 2000Hz waren möglich.

Glaube für den GPS Sensor sind mir dann die IOs ausgegangen

 

[nollak]

Glaube für den GPS Sensor sind mir dann die IOs ausgegangen

Der ist doch auch nur an ner Uart oder nicht? Zumindest der den ich immer genutzt habe.
Aber weiss nich wie die Arduino da so sind. Find das System zwar ganz nett für Einsteiger aber irgendwie fehlt mir da viel was ich ausm Berufsalltag von C und ner richtigen Programmierungebung kenne

 

[thrashfuture]

leute.. ich bin gerade etwas verwirrt.. ich habe nun nen multiplexer angeklemmt um die beiden vl53lox zu betreiben, soweit alles wunderbar, jetzt habe ich etwas optimiert und das kann doch nicht sein das ich jetzt ernsthaft bei 333hz bin? grüße schonmal

 

[thrashfuture]

leute.. ich bin gerade etwas verwirrt.. ich habe nun nen multiplexer angeklemmt um die beiden vl53lox zu betreiben, soweit alles wunderbar, jetzt habe ich etwas optimiert und das kann doch nicht sein das ich jetzt ernsthaft bei 333hz bin? grüße schonmal

aaahhh. fehler im timestamp. jo dann eben nur 33hz.

 

[nollak]

jo dann eben nur 33hz.

Für beide oder pro? Ein einzelner Sensor sollte ja nur 20Hz haben.

Ohne den jetzt zu kennen kann es natürlich sein das du den schneller Abfragen kannst aber das alte Ergebnis bekommst.

 

[thrashfuture]

Für beide oder pro? Ein einzelner Sensor sollte ja nur 20Hz haben.

Ohne den jetzt zu kennen kann es natürlich sein das du den schneller Abfragen kannst aber das alte Ergebnis bekommst.

ich meine ich habe vor ein paar tagen gelesen, das der vl53l0x in der lage ist 50hz auszugeben.

Für beide oder pro? beide zusammen im datensatz und die datensätze haben exakt +30ms zum vorigen.

 

[thrashfuture]

Was ist deine Erfahrung mit dem MPU6050 bzgl. Auflösung und Sensitivität?

zumindest reagiert er auf bewegungen. ich hab leider keine erfahrung mit diesem sensor. ich hoffe das ich die tage mal zum biken komme und ein paar testdaten sammeln kann.

 

[thrashfuture]

hab noch n paar bilder..

 

[Finnito]

So der letzte Bikepark- und Testtag ist zwar über einen Monat her, aber ich dachte ich poste die Ergebnisse dann trotzdem hier bevor ich Sie gar nicht poste. Im Grunde hat die Elektronik und Software ohne Probleme funktioniert und ich konnte fleißig Daten auf den Runs sammeln. Toma hat eine Android App entwickelt, die auf dem Web frontend basiert und das hat gut geklappt, da kann man den zeitlichen Verlauf nicht einsehen aber alle Histogramme. Und im Lift die Ergebnisse des letzten Runs zu checken ist natürlich sehr cool.
Leider klappt bei mir die Synchronisation von der App auf das backend nicht, aber man kann die Daten dann noch manuell hoch laden, wenn noch Bedarf besteht. Man kann die Daten auch direkt von der DAQ aufs backend laden aber die Verbindung ist leider nicht so zuverlässig.

Mir ist aber die obere Mount an der Gabel mehrfach gebrochen, auf dem Bild seht ihr die aktuelle Iteration der Konstruktion, ich hoffe das Sie jetzt haltbar genug ist.

Hier ist ein Abschnitt aus der illegalen DH line in Klino. Im Grunde bin ich mit dem Setup zufrieden, aber habe beim Dämpfer LSC 4/16 klicks geschlossen, HSC 2/2 geschlossen und den Rebound 6/6 geöffnet. Ist ein TTX22m

Bei der Gabel habe ich LSC 6/8 Klicks geschlosse, HSC 2/4 Klicks geschlossen und den Rebound 4/10 offen. Ist eine Manitou Mezzer Pro

Bei der Federrate bin ich soweit eig. zufrieden, in die IRT der Manitou könnte noch ein bisschen mehr rein aber insg ist das ja schonmal sehr ausgeglichen. Was denkt ihr denn dazu?

 

[Ale_Schmi]

Dämpfer:
Druckstufe sieht gut aus, wenn es Radgeschwindigkeiten sind.
Zugstufe könnte noch etwas

Federgabel:
Druck und Zugstufe kann noch etwas vertragen.

Welche Richtung lasse ich mal offen. Beim Dämpfer muss eventuell umgeshimmt werden (Zugstufe).

Federweg:
Da bräuchte ich aktuell noch andere Grafiken. Hinten passt, da es so in etwa für ein Titan stimmt (wenn ich noch recht im Kopf habe). Vorne würde ich den dynamischen SAG reduzieren und dafür ein Token entfernen. Das würde ich zumindest für eine 2-Kammer Luftfeder sagen. Mit der Mezzer habe ich gerade keine Erfahrungen bzw. habe da noch einen Test offen (Kammerverhältnis 1:1.8, bisher 1:1.45). Daher kann das sogar passen. Da müsste du dir das Integral des gesamten genutzten Federwegs anzeigen lassen. Dann solltest du es recht schnell sehen.

 

[Finnito]

Sind Radgeschwindigkeiten, in dem Fall auch nur Vertikale, sprich bei der Gabel wird der Lenkkopfwinkel einbezogen.

Die Integration des Federwegs über die Zeit würde ja nur ein von der länge der Fahrt abhängigen Summenwert ergeben? Wenn ich den durch die Zeit teile (Normierung) habe ich den dynamischen SAG? Der ja angegeben ist, das verstehe ich nicht ganz.

Ist ein G1 mit 162 mm Federwerg hinten. Und Mezzer mit 170 mm.

Dämpfung:
Okay, beim Dämpfer bin ich auch zu dem Schluss gekommen das die Zugstufe ein leichteren Shimstack braucht.
Gut zu wissen das beim Dämpfer in der Kompression sinnvolle Geschwindigkeiten erreicht werden. Dann würde ich die HSC der Gabel weiter öffnen.
Aber warum kann bei der Gabel die Zugstufe noch ein bisschen, langsamer würde kein Sinn ergeben wenn der Dämpfer noch schneller könnte. Also kann die noch schneller, da bin ich aber ehrlich gesagt auch überfragt, wenn es um Sinnvolle maximale und durchschnittliche Geschwindigkeitswerte des Systems geht.

Federweg:
Bei der Gabel nutze ich ja schon mehr Federweg und habe wenn dann auch vorne Durchschläge. Akt. Ist der dynamische SAG mit 36% vorne und hinten ja sehr ausgeglichen. Wenn ich jetzt den Luftdruck in der IRT reduziere (Token rausnehmen) verliere ich Progression und kassiere noch mehr Durchschläge. Akt fahre ich 47/68 PSI, also 1:1,45. Da hätte ich eher in IRT noch 5 PSI raufgegeben und ja nach dyn. Sag dann in der main reduziert.

Edit: Zufällig ein Tipp wer mein TTX servicen und umshimmen würde?

 

[treloid]

Hallo zusammen,

Ich melde mich auch mal kurz zu Wort (war bisher ein stiller Mitleser). Ich bin aktuell auch dabei, ein Telemetriesystem zu bauen, da mein Wunschprodukt (System 2) leider von Spezi vermutlich eingestampft wurde. Aktuell bin ich noch mit dem Datenlogger auf ESP32 Basis beschäftigt. Logging Output basiert aktuell auf dem nötigen "normalized input" von Sufni.

Aktuell nutze ich noch einen Arduino Nano ESP32, werde aber in naher Zukunft auf Bee Datalogger wechseln, da er Hardwaretechnisch eigentlich alles eingebaut hat, was ich brauche (RTC, LiPo Ladekreis, Micro SD Slot etc.)
Gespiesen wird das Ganze von einem 1S LiPo und gesteuert über ein WebInterface auf dem ESP32. FileDownload und Accesspoint Modus laufen auch schon ;-)

Aktuell frage ich mich gerade zwei Dinge:

Ist 1000Hz Logging wirklich nötig? Würden 500Hz nicht auch schon gut ausreichen?

Woher habt ihr die Linkage Curves für eure Bikes? Aktuell kann ich nur die Federelemente auswerten, da mir diese Kurven fehlen um eine schlaue Berechnung der Radgeschwindigkeiten/-Wege zu machen.

Ach ja, Python ist mir nur bedingt geläufig, ich nutze beruflich Java und C++.

Grüsse an alle anderen Tüftler!

 

[nollak]

werde aber in naher Zukunft auf Bee Datalogger wechseln

Den kannte ich noch nicht, schaut aber auch erstmal solide aus.

Ist 1000Hz Logging wirklich nötig? Würden 500Hz nicht auch schon gut ausreichen?

Eher Erfahrungswerte der anderen genutzt und das genauso implementiert. Mit der höheren Datenrate sind die Filter dann evtl auch besser anwendbar.

Woher habt ihr die Linkage Curves für eure Bikes? Aktuell kann ich nur die Federelemente auswerten, da mir diese Kurven fehlen um eine schlaue Berechnung der Radgeschwindigkeiten/-Wege zu machen.

Ich hab mir einzelne Punkte ein ein anderes Format gepackt und dann wieder interpoliert. Bin mir unsicher ob man mit der großen Lizenz die Werte exportieren kann. Ich hatte mir nur mal das Linkage Datenformat angeschaut und dann schnell wieder zu gemacht.

Ach ja, Python ist mir nur bedingt geläufig, ich nutze beruflich Java und C++.

Ist aber fix gelernt

 

[arthur80]

Hallo zusammen,

Ich melde mich auch mal kurz zu Wort (war bisher ein stiller Mitleser). Ich bin aktuell auch dabei, ein Telemetriesystem zu bauen, da mein Wunschprodukt (System 2) leider von Spezi vermutlich eingestampft wurde. Aktuell bin ich noch mit dem Datenlogger auf ESP32 Basis beschäftigt. Logging Output basiert aktuell auf dem nötigen "normalized input" von Sufni.

Aktuell nutze ich noch einen Arduino Nano ESP32, werde aber in naher Zukunft auf Bee Datalogger wechseln, da er Hardwaretechnisch eigentlich alles eingebaut hat, was ich brauche (RTC, LiPo Ladekreis, Micro SD Slot etc.)
Gespiesen wird das Ganze von einem 1S LiPo und gesteuert über ein WebInterface auf dem ESP32. FileDownload und Accesspoint Modus laufen auch schon ;-)

Aktuell frage ich mich gerade zwei Dinge:

Ist 1000Hz Logging wirklich nötig? Würden 500Hz nicht auch schon gut ausreichen?

Woher habt ihr die Linkage Curves für eure Bikes? Aktuell kann ich nur die Federelemente auswerten, da mir diese Kurven fehlen um eine schlaue Berechnung der Radgeschwindigkeiten/-Wege zu machen.

Ach ja, Python ist mir nur bedingt geläufig, ich nutze beruflich Java und C++.

Grüsse an alle anderen Tüftler!

Laut Aussagen von www.chickadeehill.de sollten es min. 1000Hz sein.
Kurven gibt es hier: https://linkagedesign.blogspot.com/

 

[treloid]

Laut Aussagen von www.chickadeehill.de sollten es min. 1000Hz sein.
Kurven gibt es hier: https://linkagedesign.blogspot.com/

Für einen Federelemente-Entwickler kann ich mir das gut vorstellen, der muss ja auch sehr ins Detail gehen. Mir würde es vorwiegend darum gehen das Bike vorne und hinten in Balance zu bringen und verschiedene Dynamic SAG Setups zu testen. Aktuell logge ich mit 1000Hz (Alles erst im Prototypstadium), habe aber noch nicht geprüft, ob es auch "wahre" 1000Hz sind oder das dem ESP zu viel wird ;-)

Danke für den Link, das hilft mir sehr weiter! Auch wenn ich jetzt verwirrt bin, dachte immer mein Heckler SL hätte eine progressive Kurve...

Sieht für mich doch ziemlich linear aus Lerne aber gerade auch viel neues über das Ganze Thema.

Den kannte ich noch nicht, schaut aber auch erstmal solide aus.

Eher Erfahrungswerte der anderen genutzt und das genauso implementiert. Mit der höheren Datenrate sind die Filter dann evtl auch besser anwendbar.

Ich hab mir einzelne Punkte ein ein anderes Format gepackt und dann wieder interpoliert. Bin mir unsicher ob man mit der großen Lizenz die Werte exportieren kann. Ich hatte mir nur mal das Linkage Datenformat angeschaut und dann schnell wieder zu gemacht.

Ist aber fix gelernt

Basics sind vorhanden, aber ist ein klassischer Fall von "Was nicht benutzt wird, wird aus dem Speicher gelöscht"

Der Arduino würde es auch tun, aber da müsste halt alles extern drangebaut werden. Das Bienchen sollte bald geliefert werden

Bin noch ein Modus am schreiben, der die Daten passend für deine Software loggt. Hast du evtl. Beispieldaten rumliegen?

 

[Finnito]

Hallo zusammen,

Ich melde mich auch mal kurz zu Wort (war bisher ein stiller Mitleser). Ich bin aktuell auch dabei, ein Telemetriesystem zu bauen, da mein Wunschprodukt (System 2) leider von Spezi vermutlich eingestampft wurde. Aktuell bin ich noch mit dem Datenlogger auf ESP32 Basis beschäftigt. Logging Output basiert aktuell auf dem nötigen "normalized input" von Sufni.

Aktuell nutze ich noch einen Arduino Nano ESP32, werde aber in naher Zukunft auf Bee Datalogger wechseln, da er Hardwaretechnisch eigentlich alles eingebaut hat, was ich brauche (RTC, LiPo Ladekreis, Micro SD Slot etc.)
Gespiesen wird das Ganze von einem 1S LiPo und gesteuert über ein WebInterface auf dem ESP32. FileDownload und Accesspoint Modus laufen auch schon ;-)

Aktuell frage ich mich gerade zwei Dinge:

Ist 1000Hz Logging wirklich nötig? Würden 500Hz nicht auch schon gut ausreichen?

Woher habt ihr die Linkage Curves für eure Bikes? Aktuell kann ich nur die Federelemente auswerten, da mir diese Kurven fehlen um eine schlaue Berechnung der Radgeschwindigkeiten/-Wege zu machen.

Ach ja, Python ist mir nur bedingt geläufig, ich nutze beruflich Java und C++.

Grüsse an alle anderen Tüftler!

Ein port der sufni pi pico software wäre sicher auch cool und die handy app ist auch sehr praktisch.

 

[Ale_Schmi]

Einfach 1000hz. Dann bleibt für spätere Spielereien genügend "Fleisch" übrig. Sonst gehen da echt ein bisseln Genauigkeit verloren.

 

[nollak]

Bin noch ein Modus am schreiben, der die Daten passend für deine Software loggt. Hast du evtl. Beispieldaten rumliegen?

Öh müsst ich mal schauen ich hab da länger nix dran gemacht weil mir Zeit/Muße fehlt, was wohl auch in der vorrausschaubaren Zukunft so bleibt. Seitdem ich das Projekt angefangen habe hat sich an meinen Lebensumständen so einiges getan.
Daher ist eher fraglich ob das was bringt oder ob du dich eher ans Snufi lehnst, hab das nicht weiter verfolgt, aber glaube da passiert mehr.

Hatte das ja eh binär abgespeichert und würde da wenn eher darauf gehen das auch in einem eher lesbareren Format zu nutzen in bzw. von dem man schnell konvertieren kann. Also irgendwas in CSV vermutlich.

 

[Datenwurm]

Für einen Federelemente-Entwickler kann ich mir das gut vorstellen, der muss ja auch sehr ins Detail gehen. Mir würde es vorwiegend darum gehen das Bike vorne und hinten in Balance zu bringen und verschiedene Dynamic SAG Setups zu testen. Aktuell logge ich mit 1000Hz (Alles erst im Prototypstadium), habe aber noch nicht geprüft, ob es auch "wahre" 1000Hz sind oder das dem ESP zu viel wird ;-)

Danke für den Link, das hilft mir sehr weiter! Auch wenn ich jetzt verwirrt bin, dachte immer mein Heckler SL hätte eine progressive Kurve...
Anhang anzeigen 2114675

Sieht für mich doch ziemlich linear aus Lerne aber gerade auch viel neues über das Ganze Thema.




Basics sind vorhanden, aber ist ein klassischer Fall von "Was nicht benutzt wird, wird aus dem Speicher gelöscht"

Der Arduino würde es auch tun, aber da müsste halt alles extern drangebaut werden. Das Bienchen sollte bald geliefert werden

Bin noch ein Modus am schreiben, der die Daten passend für deine Software loggt. Hast du evtl. Beispieldaten rumliegen?

Progressiv meint das Absinken der Übersetzung im Federwegsverlauf. Hier von ~3,25 auf ~2,3.
Linear wäre ein mehr oder weniger konstantes Verhältnis von zB 2,8.

 

[treloid]

So, mein Konstrukt ist ready für die erste Testfahrt am Wochenende. Werde ein paar Runs von einem kurzen Trailstück gleich hinter meinem Haus machen und schauen, was die Daten zeigen. Kalibriert ist das Zeuch schonmal und Anzeigen tuts auch was ;-) Das Aufzeichnungsformat könnte in Sufni importiert werden um einen Vergleich zu machen, habe allerdings Sufni noch nicht zum laufen gekriegt (Dockerkenntnisse = 0).
Die Idee, das "Hirn" per Fidlock zu montieren hat auch geklappt. Habe allerdings ein original Fidlock mount genommen, da die vorhandenen Designs auf printables etc. nicht auf die originale Fidlock Basis passen. Halten tut das wohl auch am besten...

@Datenwurm
Danke dir, habs inzwischen verstanden, da ich mich zwangsläufig mehr mit dem Thema auseinandergesetzt habe.

Habt ihr allgemein noch gute "Literatur"-/Videoempfehlungen zum Thema? Gerade was das Auswerten / die Schlussfolgerungen der gesammelten Daten angeht finde ich irgendwie keine schlauen Ressourcen. Aktuell habe ich mir das Knowhow vorwiegend mit den Motion Instruments Blogposts und den Vorsprung TuesdayTune Videos angeignet.