DIY Telemetrie / Data Acquisition System

[nollak]

@timmeygasmus Sehr geil!
Das sieht an der Hardware Front definitiv um einiges weiter aus als der Kabelverhau, den ich in mein Gehäuse gequetscht habe! Wofür sind eigentlich die ganzen Stecker, also was liest du ausser den Wegsensoren noch aus?

Die Stecker sind Lutronic 0831. Verhältnismäßig günstig, mit Kappe bzw. gesteckt IP67.

Die hatte mich mir tatsächlich schon angeschaut für den nächsten Schritt. M8 Stecker fand ich da irgendwie ganz passend, vor allem da man die gut bekommt und auch nicht die Welt kosten. Lemo hatte ich mir noch angeschaut, aber da wirds halt bei Dichtigkeit auch schnell teuer.

Ist nervig aber meiner Erfahrung nach bekommt man an einem Tag, je nach Trail, maximal 5 - 8 Messungen hin. Um da aussagefähige Daten zu erzeugen, muss der Fahrer konstant unterwegs sein, darf sich also nicht zu sehr verausgaben und braucht ausreichend Pausen, das Setup muss ohne Zweifel sein, also lieber einmal mehr als weniger kontrollieren.

Jap, ich plane das hauptsächlich im Bikepark oder beim shuttlen zu benutzen und möchte mir den Schritt mit dem aufschrauben sparen. Ich denke so alle 2 Runs je nach Fahrer sollte möglich sein mal nachzuschauen. Aber ich glaub das ist auch sehr individuell. Nicht jeder kann halt konstant auf xx% Linien fahren.
Bietet der Teensy da kein WLAN/BLE Interface? Ich hab mich mit denen ehrlich gesagt noch nicht wirklich auseinander gesetzt. Ich hab eher Richtung ESP32 geschielt bevor ich den RasPi Pico gefunden hatte. Wahlweise noch einen Nordic nRF Chip, aber bei BLE wirds mit der Gegenstelle wieder ein wenig schwerer. Wenn das WLAN TCP/IP Sockets unterstützt habe ich da schneller eine Gegenstelle gebaut. Aber das liegt eher daran das ich mich beruflich die letzten Jahre viel im embedded Linux/QNX Umfeld bewegt habe und dort mit verteilten Systemen gearbeitet habe.

Besser und einfach mit wäre es aber definitiv, wie gesagt, der ganze Prozess (Messen, auswerten, einstellen, fahren) beinhaltet relativ viele Einzelschritte und ist störanfällig. Wenn man da Sachen vereinfachen kann, hilft das auf jeden Fall.

Ja ich denke auch das macht es halt einfacher, wenn man die Daten herunterladen könnte. Daher hab ich auch so eine Mini Gui mit 5 Knöpfen gemacht, damit man nicht dauernd die Scripte per Hand aufrufen muss. Ich hab da tendenziell kein Problem mit, aber wenn ich das 5-10x am Tag machen muss bin ich auch froh über alles, was es vereinfacht.


Da ich wegen Krankheit am Wochenende jetzt statt zu Hause geblieben bin statt zum Patenkind zu fahren werde ich auch mal schauen ob ich es geistig schaffe mich um die Kombination aus SD Karten lesen und WiFi zu kümmern. Das scheint wie schon erwähnt mit dem aktuellen SDK Release mit der Library, welche ich für die SD Karte nutze nicht zu funktionieren. Da läuft der Controller immer in den Hard Fault. Ich vermute das es da einen Interrupt oder Resourcen Konflikt gibt.
Heisst ich muss endlich mal den Debugger gescheit aufsetzten oder das ganze über eine andere Schnittstelle lösen.
Der RasPi hat noch den Vorteil von Programmierbarer Logik, heisst man kann darüber auch eine SD Schnittstelle abbilden. Da hab ich aber noch gar nicht rein geschaut. Nur letztens gesehen das es ein Beispiel für die SDIO gibt. Wenn man das mit einer FatFS Lib vereinen kann und dann das WiFi nebenher geht wäre auf der FW Seite das gröbste durch. Dann müsste ich nur noch weitere Sensoren integrieren.

Ansonsten sind heute auch meine 3D Druck Teile verschickt worden, heisst ich kann nächste Woche mal Testweise an meinem Kavenz montieren.

Wie sieht das eigentlich bei euch so aus? Nutzt ihr PLA Filamente für die Sachen am Bike? Ich hatte eigentlich vor eher Richtung PETG zu gehen, aber die einfachen Drucker für PLA sind halt auch schön günstig. Da bin ich ein wenig hin und her gerissen gerade.

 

[write-only]

Wie sieht das eigentlich bei euch so aus? Nutzt ihr PLA Filamente für die Sachen am Bike? Ich hatte eigentlich vor eher Richtung PETG zu gehen, aber die einfachen Drucker für PLA sind halt auch schön günstig. Da bin ich ein wenig hin und her gerissen gerade.

PLA geht sicher gut für n Gehäuse oder ne Befestigung, ist halt sehr spröde. Drucker die nur PLA können heißt was bei dir? Kein beheiztes Druckbett? Gibt's das noch?

Nen Ender 3 gibt's für unter 200€ und der druckt alles was unter 250°C flüssig wird.
Pappschachtel drüber und es geht sogar ABS und ASA, was ja mein Favorit für Teile am Rad ist.


Ansonsten, cooles Projekt, hatte auch mal mit dem Gedanken gespielt was in die Richtung zu basteln aber der Preis für die Linearsensoren hat mich dann angehalten, war mir dann doch zu viel für ein Wochenendprojekt.

 

[nollak]

PLA geht sicher gut für n Gehäuse oder ne Befestigung, ist halt sehr spröde. Drucker die nur PLA können heißt was bei dir? Kein beheiztes Druckbett? Gibt's das noch?

Nen Ender 3 gibt's für unter 200€ und der druckt alles was unter 250°C flüssig wird.
Pappschachtel drüber und es geht sogar ABS und ASA, was ja mein Favorit für Teile am Rad ist.

Joa preislich sind die Ender da echt geil! Mit auseinander setzen muss ich mich eh mal, evtl bestell ich aber auch einfach mal
einen.
Danke für die Infos!

aber der Preis für die Linearsensoren hat mich dann angehalten,

Ja war bei mir auch lange ein Grund das ganze nicht zu machen.

 

[timmeygasmus]

Das mit dem Teensy bei mir hat sich auch ein bisschen aus der Historie heraus ergeben... Ich hab da am Anfang mit einem ATMega328 experimientiert, das war nicht so richtig erfolgreich und mit meinem damaligen Approach auch von der Performance knapp. Ich hab mich dann nach Alternativen umgeschaut, die Teensy 4.1 waren recht neu, performant, verhältnismäßig günstig (glaub 25 Euro rum, 2020) und hatten SD an Bord. Drahtlose Schnittstelle um die Daten zu schieben schien mir mit meinem Kenntnisstand nur mit großen Aufwand realisierbar, daher war das nicht wirklich auf der Agenda... Denke der 2040 ist eine gute Wahl, werd die Tage mal eine handvoll bestellen.

Bzgl. der 8 Plätze, wir haben in der Konzeptphase überlegt, was man alles messen könnte, in welcher Kombination das Sinn macht usw., da ist dann final bei rausgekommen, dass mehr als 8 wirklich unwahrscheinlich ist. Wie man sicher schon gemerkt hat bin ich ein Freund von 'Haben ist besser als brauchen' und so sinds dann auch die 8 geworden. Wir haben auch schon Temperaturmessungen gemacht, mit Beschleunigungsaufnehmern zur qualitativen Bewertung von Setups gearbeitet, planen da demnächst was mit Dehnmessstreifen (kann leider noch nix genaues sagen, wird auf jeden Fall spannend!). Ist aber natürlich schon aus dem Spektrum raus, was "normale" Endanwender machen. Wäre da trotzdem nicht zu geizig, bestücken muss man ja letztenendes nicht, wenn man keine Anwendung hat.

Drucker und Filament: PLA ist nix für mechanisch belastete Teile. U.a. 'crackt' das an Punkten, wo hohe Flächenpressungen herrschen (unter Schrauben bspw.). Mein Gehäuse ist aus PETG, das passt. Die Sollbruchstelle bei mir ist im Halter, der reißt bei Überlast aus.
Schließe mich grundsätzlich der Ender 3-Empfehlung an, PETG macht der ohne Probleme und Preis/Leistung unschlagbar.

 

[nollak]

Teensy 4.1 waren recht neu, performant, verhältnismäßig günstig (glaub 25 Euro rum, 2020) und hatten SD an Bord. Drahtlose Schnittstelle um die Daten zu schieben schien mir mit meinem Kenntnisstand nur mit großen Aufwand realisierbar, daher war das nicht wirklich auf der Agenda... Denke der 2040 ist eine gute Wahl, werd die Tage mal eine handvoll bestellen.

Hab mir den gestern mal angeschaut. Performance mäßig ist der ja schon ordentlich. Denke aber auch mehr als man braucht. Aber haben uns brauchen

8 Eingänge sind ja tendenziell nicht schlecht wenn man die frei belegen kann.

Bin heute mal mit dem WiFi bissle weiter gekommen. Irgendwie scheint da die Kombination aus WiFi, SD Karte und GPIO Interrupt für die Knöpfe das Problem zu sein. Ich werd morgen mal ne Alternative für die Knopf Entprellung bauen.
Dann gehts auch an der Wireless Sache weiter.

Bewertung von Setups gearbeitet, planen da demnächst was mit Dehnmessstreifen (kann leider noch nix genaues sagen, wird auf jeden Fall spannend!).

DMS klingt interessant, die Idee kam beim Rudelfully Projekt auch auf um die Flexstreben zu vermessen.
Muss mir nochmal überlegen wie man das in der Software modular auslegen kann verschiedene Sensor Typen zu supporten.
Wenn die alle über nen Bus angebunden sind könnte man da recht easy was zu machen.

Schließe mich grundsätzlich der Ender 3-Empfehlung an, PETG macht der ohne Probleme und Preis/Leistung unschlagbar.

Den hab ich tatsächlich gestern abend noch bestellt. Ne Rolle PLA und PETG zum einrichten dazu.

 

[theller]

Hallo, ich verfolge die Diskussion hier mit (rein theoretischem) Interesse. Bezüglich Sensoren für die Wegmessung: Ich finde die Idee genial die im ShockWiz implementiert wurde, die Auslenkung der Dämpferelemente wird hier, nach Kalibrierung, über den Druck gemessen. Wäre das nicht eine relativ preiswerte Alternative, die obendrein viel Bastelei an der Gabel / bzw. dem Dämpfer erübrigt? Der Drucksensor wird einfach über einen Schlauch an das Ventil angeschlossen.

Ergänzung: Geht natürlich bei Coil-Dmpfern nicht...

 

[nollak]

Ich finde die Idee genial die im ShockWiz implementiert wurde, die Auslenkung der Dämpferelemente wird hier, nach Kalibrierung, über den Druck gemessen.

Ich habs nie ausprobiert aber der ShockWiz gibt ja meines Wissens erstmal nur Setup Empfehlung soweit ich das weiss. (Lasse mich da gerne berichtigen.)

Shoxk Wiz betrachtet ja auch nur ein Element und nicht Gabel&Dämpfer.
Die Genauigkeit über den Druck letztendlich die Achsbewegung/Geschwindigkeiten zu messen halte ich für fraglich. Da sind die Wegmesser einfach genauer.
Davon ab ist der Druck der da herrscht ja auch nicht ohne. Die Sensorkammer zu bauen ist da auch Aufwand.
Applikation ist natürlich extrem einfach bei ShockWiz, das stimmt.

 

[nollak]

Ein wenig Nachforschung und Bastelei spaeter bin ich zumindest mit dem WiFi weiter.

Aus einem mir immer noch fraglichen Grund funktioniert die Mischung aus SD Karte, WiFi Modul und GPIO Interrupt nicht. Da gehen immer nur 2/3 obwohl die 3 Module unterschiedliche Interrupts nutzen sollten.
Die Mischung aus SD Karte, WiFi Modul und Timer Interrupt scheint aber zu laufen, also hab ich das Entprellen der Taster jetzt erstmal mit dem Timer geloest. Dadurch geht jetzt auch erstmal die AccessPoint Funktionalitaet vom Pico.

Zum Glueck gibt es da auch viele Beispiele von Raspberry direkt, heisst die DHCP/DNS Funktionalitaet werde ich wohl 1:1 aus den Beispielen uebernehmen. Den TCP Server um die Daten dann via WiFi zu uebertrage werd ich selbst schreiben, bzw. das Beispiel modifizieren. Dadurch waere dann auch die letzte groessere Huerde was Usability angeht genommen. Also wenn das laeuft, das ist aber eher etwas fuer naechste Woche, fuer dieses Wochenende reicht es mir dann jetzt doch erstmal

Ich halte euch auf dem laufenden. Code ist natuerlich auch im Github.

 

[Finnito]

Hallo zusammen, da schalte ich mich doch gerne dazu. Sitze nähmlich auch dran bei so einem System gerade die mechanische Seite zu entwickeln. Die gesamte Software und ersten Prototypen wurde von Toma entwickelt. Hier das Repository wie zu sehen ist die Enwtwicklung auf Softwareseite schon sehr weit vorrangeschritten:

• Basis der Datensammlung mit einer Raspberry Pi Pico W und sdkarte
• Upload der Daten über Wlan (Handy Hotspot) zum backend
• Anschluss der Pico über USB als Massenspeicher am PC möglich
• Postprocessing der Daten im backend und Visualisierung per HTML
• Wie in dem Screenshot zu sehen bereits sehr umfangreiche Aufbereitung und Visualisierung der Daten.
• Backend kann auf jedem Linuxsystem realisiert werden (Werde es jetzt per Docker in meine PI4 integrieren) ist aktuell noch langsam auf "schwächeren" Systemen, da das Postprocessing in Echtzeit abläuft. Toma ist gerade dabei das Postprocessing beim Import der Daten zu implementieren)
• Die Sensoren basieren gerade auf dem AS5600 Rotary sensor der in 12 Bit (4096 Punkte) pro 360° auflöst. Vorteil ist hier das ein Sensor ca. 1€ kostet und somit das gesamte System echt bezahlbar bleibt. Auflösung an der Gabel habe ich beim aktuellen Design bei 170 mm Federweg auf 0,1 mm Abstrastung realisiert. Drucke gerade die Teile deswegen weiß ich nicht wie Fehleranfällig das System ist. Ich habe noch eine andere Idee mit Linearführung, Zahnschiene und Zahnrad aber das wäre Anfällig für Dreck und ist insgesamt komplexer ist. Vielleicht habt Ihr gute Ideen.

Ich habe Mal ein paar Bilder und Screenshots angehängt. Ich finde Tomas Ansatz und Umsetzung bis jetzt sehr cool und freue mich wenn wir es schaffen vielleicht die Besten Ideen und Möglichkeiten in einem gemeinsamen Projekt umsetzen können.

Ich muss jetzt Mal wieder arbeiten und lese mir den Thread heute Abend nochmal in Ruhe durch!

Viele Grüße

Finn

 

[nollak]

Hallo zusammen, da schalte ich mich doch gerne dazu. Sitze nähmlich auch dran bei so einem System gerade die mechanische Seite zu entwickeln. Die gesamte Software und ersten Prototypen wurde von Toma entwickelt. Hier das Repository wie zu sehen ist die Enwtwicklung auf Softwareseite schon sehr weit vorrangeschritten:

Top!

Das Repo vom Toma (Kennst du ihn persoenlich?) Hatte ich auch schon gefunden.

Das hatte mich dazu inspiriert das Bokeh mal auszuprobieren. Ansonsten nutzt aber zumindest auch die selbe SD Lib wie ich. Das Projekt von ihm find ich auch mega spannend!

Die Idee mit dem Backend find ich auch spannend, da war mir aber die lokale Verarbeitung irgendwie lieber.

 

[Ale_Schmi]

Das Backend kann natürlich noch für andere Themen interessant werden.
Wenn mehr Leute Daten auswerten möchten, wird es teils schwer, da es ja unterschiedliche Charakter für die Auslegung gibt.
Ein Enduro wird etwas anders ausgelegt als ein DH und ein lebendiges Fahrverhalten benötigt eine andere Auslegung als eine "klebrige" bodenwegsaugende Auslegung.

Die grafische Aufbereitung finde ich sehr gut! Da ist wirklich alles drin! Großes Lob von mir!


Wenn ihr exportierte Daten von BYB haben wollt, so könnt ihr euch gerne melden! @Finnito
Da wäre es ja sonst mal möglich die Oberfläche zu erweitern, oder?


Zu den dargestellten Daten:

• stimmen die maximalen Reboundwerte? Oder liegt es an der an der Abtastfrequenz?
• Werden Federgeschwindigkeiten = 0 berücksichtigt oder gefiltert in der dargestellten avg Geschwindigkeit?

Edit:
Jetzt habe ich mich mal ein wenig auf der grafischen Oberfläche umgeschaut: Ein paar Funktionen könnte man noch ergänzen, aber viel fällt mir da auch nicht mehr zu ein. Das, was mir noch einfällt, wären mit Berechnungen im Hintergrund machbar.

 

[sghctoma]

Hi everybody,

Would it be OK to post here in English? I'm Toma, the author of the Sufni Suspension Telemetry project @Finnito linked here. I don't speak German, but would like to answer some questions in this thread. Apologies if it's not OK.

@nollak : Regarding the problem with WiFi and the SD library: I'm uploading files from the SD card via WiFi using the same library, so it should work. Haven't looked at your code yet, but if you are using pico_cyw43_arch_lwip_threadsafe_background, I suggest trying pico_cyw43_arch_lwip_poll, since the threadsafe is not really threadsafe (at least I reliably get deadlocks with it). I've also found that if I connect to the WiFi on boot, and keep that connection, things do not work very well (random deadlocks, failing TCP connections). So I connect/disconnect on demand. I suspect there are also some other locking issues in the Pico LwIP codebase as well, because a few sleeps here and there dramatically improves WiFi throughput.

@Ale_Schmi :

• No, those maximum rebound values are not correct. I've had some weird spikes in the data that skewed statistics. The screenshot is of a previous version. In more recent versions some AS5600 parameters and initial data filtering is adjusted. Now I'm getting 1300-1600 mm/s maximums on rebound.
• Airtimes, and other obvious idle parts were filtered out for calculations, but those do no account for all the zeros. In more recent versions I split data into compression and rebound strokes (i.e. sections with continuous positive or negative velocity), and every calculation is based on these strokes. So zeroes are now filtered out. But even with this new approach, I get way less average velocities than what Motion Instruments suggests as good values in one of their blog posts. The reason could be different sampling rates, different resolutions, or just simply that I'm a big guy (around 110 kg ready to ride), and stock tunes are not for me, I don't know. I don't have any experience, have never used any other telemetry systems, have no clue what the "good values" are That's why it would be awesome if some more experienced riders would try my system, or even compare it side-by-side with BYB, Motion Instruments, etc.

I'm in the middle of a big performance upgrade, after that I will implement a feature that would allow opening/syncing video recordings, and there's a lot more to do to make the system user friendly, but I'm also open to any suggestions, new features.

I've attached some more recent screenshots.

 

[Ale_Schmi]

• No, those maximum rebound values are not correct. I've had some weird spikes in the data that skewed statistics. The screenshot is of a previous version. In more recent versions some AS5600 parameters and initial data filtering is adjusted. Now I'm getting 1300-1600 mm/s maximums on rebound.

Hi Toma,
it is quite difficult to find the "correct" or good target value. And in the end nearly no one will give you a clear answere to that. There are some hints at the internet but it takes a lot of work and time to find them and also to try them.
Only a small hint from my side: Max rebound speed is too slow. Try to achieve a higher value.
But at this point the problems are starting. How to achieve higher rebound values?
Only with the help of the lowspeed rebound needle? --> rises the average value also
Or with a special shimstack? --> lots of work is necessary...

• Airtimes, and other obvious idle parts were filtered out for calculations, but those do no account for all the zeros. In more recent versions I split data into compression and rebound strokes (i.e. sections with continuous positive or negative velocity), and every calculation is based on these strokes. So zeroes are now filtered out. But even with this new approach, I get way less average velocities than what Motion Instruments suggests as good values in one of their blog posts. The reason could be different sampling rates, different resolutions, or just simply that I'm a big guy (around 110 kg ready to ride), and stock tunes are not for me, I don't know. I don't have any experience, have never used any other telemetry systems, have no clue what the "good values" are That's why it would be awesome if some more experienced riders would try my system, or even compare it side-by-side with BYB, Motion Instruments, etc.

There is not so much difference regarding the BYB system. I can send you a measurement from the BYB system and you can check the values.

My ready to ride weight (without bike) is between 90-93 kg. Normally a good fork (Fox Grip2 or Manitou) should be adjustable to achieve a nice damping.


Last Question:
Do you have the feeling, if you are jumping, that your bike gets sometimes a forwardrotation or you have to lean more to the rearwheel during the initial phase of jumping?

 

[nollak]

Welcome @sghctoma !

Nice that you joined for this thread! Your system is for sure more advanced than mine currently. I had a look at the code when I found it on github and was impressed nice work!

Regarding the problem with WiFi and the SD library: I'm uploading files from the SD card via WiFi using the same library, so it should work. Haven't looked at your code yet, but if you are using pico_cyw43_arch_lwip_threadsafe_background, I suggest trying pico_cyw43_arch_lwip_poll, since the threadsafe is not really threadsafe (at least I reliably get deadlocks with it). I've also found that if I connect to the WiFi on boot, and keep that connection, things do not work very well (random deadlocks, failing TCP connections). So I connect/disconnect on demand. I suspect there are also some other locking issues in the Pico LwIP codebase as well, because a few sleeps here and there dramatically improves WiFi throughput.

Yeah I had a look at your code and it seems to work. I tried using the *_poll methods but currently I can't really get it to work. I updated the SDK at some point which I would normally not do but afterwards I had some major issues with the combination of WiFi/SD Card/GPIO Interrupts.
I couldn't initialize the CYW43 chip properly when using the SD Card or vice versa. I then found out that SD Card and CYW43 is ok if I don't use GPIO interrupts which is also strange. As a workaround I now use a polling routine in a timer interrupt for button handling. But I need to look into that issues as I wanted to initialize/deinitialize the WiFi on demand similiar to your approach.
Just that I wanted to initialize a AccessPoint, where the pico example is working just fine but when I try to integrate that into my code it is not. So I will try to build something from that example now to check where my issue currently is.
Although the thought of a hosted dashboards keeps growing on me. But my Python & Bokeh experience is limited.

I'm in the middle of a big performance upgrade, after that I will implement a feature that would allow opening/syncing video recordings, and there's a lot more to do to make the system user friendly, but I'm also open to any suggestions, new features.

Sounds nice, from my point of view your system is already looking pretty advanced! I did a small GUI in Python for data handling but I guess thats not really needed for your system to get it more user friendly.

 

[Ale_Schmi]

The GUI is already very good and handy in my opinion! More details than BYB!

Some minor points could be improved but overall avery very nice starting point.
At the moment it is my favourite GUI under all versions and companys!

 

[sghctoma]

Hi Toma,
it is quite difficult to find the "correct" or good target value. And in the end nearly no one will give you a clear answer to that. There are some hints at the internet but it takes a lot of work and time to find them and also to try them.

Yup, sure, I meant ballpark values when I wrote good values. And I'm trying to search for those ballpark values not necessarily to tune my suspension, but just to see if measurements from my system are somewhere around measurements from other telemetry solutions. Just to make sure I didn't make some silly mistake somewhere This is why it bothered me that Motion Instrument suggests 500-600 mm/s average velocities, which is around the double of my values.

Only a small hint from my side: Max rebound speed is too slow. Try to achieve a higher value.
But at this point the problems are starting. How to achieve higher rebound values?
Only with the help of the low-speed rebound needle? --> rises the average value also
Or with a special shim stack? --> lots of work is necessary...

Thanks, I will keep that in mind! It's really interesting to see how settings affect each other, and it sure is not an easy task to achieve a desired result without messing up some other characteristic.

There is not so much difference regarding the BYB system. I can send you a measurement from the BYB system and you can check the values.

That's good to hear, and sure, I would love to see some measurements from BYB. It would be great if you could send some to [email protected]. Do you have them in some raw format? I'm asking because one of my plans for the future is a sort-of plugin system that would allow importing data from arbitrary data acquisition systems.

My ready to ride weight (without bike) is between 90-93 kg. Normally a good fork (Fox Grip2 or Manitou) should be adjustable to achieve a nice damping.

I love how my Mezzer and Mara behaves, but I just don't have enough experience to necessarily differentiate between a good enough and an excellent setup. I've only been riding for ~1.5 years, and had ridden only the Mara, Mezzer, and a Durolux EQ.

last question:
Do you have the feeling, if you are jumping, that your bike gets sometimes a forward rotation or you have to lean more to the rearwheel during the initial phase of jumping?

Nope, but I'm not a good jumper, my jumps are pretty small. Are you asking this because my shock rebound velocities are a bit higher than on the fork?

Welcome @sghctoma !

Nice that you joined for this thread! Your system is for sure more advanced than mine currently. I had a look at the code when I found it on github and was impressed nice work!

Thanks, appreciated!

Yeah I had a look at your code and it seems to work. I tried using the *_poll methods but currently I can't really get it to work. I updated the SDK at some point which I would normally not do but afterwards I had some major issues with the combination of WiFi/SD Card/GPIO Interrupts.
I couldn't initialize the CYW43 chip properly when using the SD Card or vice versa. I then found out that SD Card and CYW43 is ok if I don't use GPIO interrupts which is also strange. As a workaround I now use a polling routine in a timer interrupt for button handling. But I need to look into that issues as I wanted to initialize/deinitialize the WiFi on demand similar to your approach.
Just that I wanted to initialize an AccessPoint, where the pico example is working just fine but when I try to integrate that into my code it is not. So I will try to build something from that example now to check where my issue currently is.

I suspect it will be some locking issue. Good luck, I hope you'll manage to debug it! I've also built up a lot of the code from the examples.

Although the thought of a hosted dashboard keeps growing on me. But my Python & Bokeh experience is limited.

Initially I wanted everything locally in a cross-platform application, but the good graphing libraries I could find are all HTML-based, and I wanted some interactivity (e.g. dynamically doing calculations for a selected range), so static HTML pages were out of the question. So even for a desktop app, I would've needed a local web server. And this approach also allows evaluating data on the track on a mobile phone without a dedicated mobile application.

Sounds nice, from my point of view your system is already looking pretty advanced! I did a small GUI in Python for data handling but I guess thats not really needed for your system to get it more user friendly.

I meant stuff like easy initial setup (I don't have a UI for that at the moment), UI to manage various setups and calibrations, proper access control, maybe separate user profiles, adding a leverage ratio database, etc. These are not really interesting topics, and I can live without them, but if anybody else wish to use the system, these issues need to be addressed

The GUI is already very good and handy in my opinion! More details than BYB!

Some minor points could be improved but overall a very nice starting point.
At the moment it is my favorite GUI under all versions and companies!

Thanks, that's really great to hear! If you could summarize those minor points, I'll update my TODO list

 

[nollak]

I suspect it will be some locking issue. Good luck, I hope you'll manage to debug it! I've also built up a lot of the code from the examples.

Yeah I guess. It is a bit odd. I had a look at your Code and it looks like I wanted to build it and it is working I guess
I will spend some time on the weekend hoping to get it fixed. The examples from raspberry are actually pretty good from what I have seen.

Initially I wanted everything locally in a cross-platform application, but the good graphing libraries I could find are all HTML-based, and I wanted some interactivity (e.g. dynamically doing calculations for a selected range), so static HTML pages were out of the question. So even for a desktop app, I would've needed a local web server. And this approach also allows evaluating data on the track on a mobile phone without a dedicated mobile application.

Yeah I am trying building something Python based which then generates the Bokeh Dashboard. Although the idea of an upload is growing on me. Biggest Problem here ist maybe the lack of reception in some parts of the woods but If you ran all on a Raspi which acts as an AccessPoint. Maybe I will try that as an alternative.

I meant stuff like easy initial setup (I don't have a UI for that at the moment), UI to manage various setups and calibrations, proper access control, maybe separate user profiles, adding a leverage ratio database, etc. These are not really interesting topics, and I can live without them, but if anybody else wish to use the system, these issues need to be addressed

Yeah I put all that stuff in a GUI recently as many bike buddies already asked if we can try the system on their bikes and I don't want to do everything by hand.
Its a really simple GUI to input the data into the database I use in the background (which is similar to yours). You can either input the data or import JSON files. Although I am currently thinking of using YAML files for the config as they are a bit easier to read and write. I attached some screenshots.

I'm asking because one of my plans for the future is a sort-of plugin system that would allow importing data from arbitrary data acquisition systems.

That would be great! I really like your Dashboard for the data!

 

[Ale_Schmi]

@sghctoma : after 1.5 year of driving the rebound speed is ok. I do not know how fast you are driving. This has also a big impact on it!

I have sent you some data. Setup is not final and was only at a very early stage. Some more work has to be done, but you can use it and have a look. You can write me your results via mail.

If you have implemented it to your system. Give me a "call". Then I can check it also and compare it to BYB.

 

[sghctoma]

Yeah I guess. It is a bit odd. I had a look at your Code and it looks like I wanted to build it and it is working I guess
I will spend some time on the weekend hoping to get it fixed. The examples from raspberry are actually pretty good from what I have seen.

Yep, the examples are good, as well as the documentation. Clear, and well-organized.

Yeah I am trying building something Python based which then generates the Bokeh Dashboard. Although the idea of an upload is growing on me. Biggest Problem here ist maybe the lack of reception in some parts of the woods but If you ran all on a Raspi which acts as an AccessPoint. Maybe I will try that as an alternative.

Cell reception is a concern, yes. Processing data on a Pi 3 B+ was pretty slow for me, but that will soon change. I hope I can do enough improvement to run even on a Pi Zero, which I could just package into the same box the Pico is in. @Finnito thought about running the whole backend on an Android phone, which could also be a good alternative, but I've not yet tried if it can be set up.

Yeah I put all that stuff in a GUI recently as many bike buddies already asked if we can try the system on their bikes and I don't want to do everything by hand.
Its a really simple GUI to input the data into the database I use in the background (which is similar to yours). You can either input the data or import JSON files. Although I am currently thinking of using YAML files for the config as they are a bit easier to read and write. I attached some screenshots.

Looks cool! My biggest problem with the HTML based graphing libraries is that I'm kinda forced to work with HTML and CSS for the UI elements, which I really-really hate. I have a thin HTTP API layer on top of the database, so maybe I'll just write these setup UI stuff as a desktop application - it's not something that often needs changing on the trail anyway.

That would be great! I really like your Dashboard for the data!

Writing a converter that reads raw travel data and puts it into the format my system uses should be pretty trivial. @Ale_Schmi sent me some BYB data, I'll write a converter for that, and after that I can do the same for your output format.

@sghctoma : after 1.5 year of driving the rebound speed is ok. I do not know how fast you are driving. This has also a big impact on it!

Thanks for the info! I'm not too fast, I'm more comfortable on slow chunky stuff.
Also thanks for the e-mail, I'll play with the data, and get back to you.

 

[nollak]

Cell reception is a concern, yes. Processing data on a Pi 3 B+ was pretty slow for me, but that will soon change. I hope I can do enough improvement to run even on a Pi Zero, which I could just package into the same box the Pico is in. @Finnito thought about running the whole backend on an Android phone, which could also be a good alternative, but I've not yet tried if it can be set up.

Cell reception might be a problem for me as not too far away are some great trails but zero to none cell reception

Is it cause of the Python data handling? I mean that‘s already kinda slow ob my laptop so it wouldn‘t suprise me if it is slow on a raspi. But I guess a part of it could be done in C an will run a lot faster. Ar least that‘s what I already thought about. If it could run on a RasPi Zero it would be great!

Writing a converter that reads raw travel data and puts it into the format my system uses should be pretty trivial. @Ale_Schmi sent me some BYB data, I'll write a converter for that, and after that I can do the same for your output format.

Yeah that should be pretty straight forward if you know the input and output format.

Looks cool! My biggest problem with the HTML based graphing libraries is that I'm kinda forced to work with HTML and CSS for the UI elements, which I really-really hate. I have a thin HTTP API layer on top of the database, so maybe I'll just write these setup UI stuff as a desktop application - it's not something that often needs changing on the trail anyway.

Thanks! Yeah My biggest problem with bokeh currently is making it look pretty and behave the way I want to as I have never worked with it.
I did some stuff with PyQT and matplotlib a while back so thats something I still have in mind. Or using another plotting Library to make it a bit prettier than matplotlib. But in the end it‘s data I want to read. Having somethin pretty is optional.

 

[sghctoma]

Is it cause of the Python data handling? I mean that‘s already kinda slow ob my laptop so it wouldn‘t suprise me if it is slow on a raspi. But I guess a part of it could be done in C an will run a lot faster. Ar least that‘s what I already thought about. If it could run on a RasPi Zero it would be great!

Yup, Python can be really slow for some things, and I think the piwheels numpy packages are not built with all the optimizations. For some reason creating Bokeh models, especially ColumnDataSources is also slow, at least according to the performance profiling I've done. I do most of the heavy lifting with a Go application already, but can't pre-calculate everything if I want interactivity.

Thanks! Yeah My biggest problem with bokeh currently is making it look pretty and behave the way I want to as I have never worked with it.

It can be a fight, yes, I have had moments when I hated Bokeh But now I'm OK with how the dashboard looks like.

I did some stuff with PyQT and matplotlib a while back so thats something I still have in mind. Or using another plotting Library to make it a bit prettier than matplotlib. But in the end it‘s data I want to read. Having somethin pretty is optional.

I used to love Qt, but I wrote an app last year to extract jump data from my Garmin 530 in Qt5 with QML, and I really did not like this mix of C++ and JavaScript.

 

[nollak]

Yup, Python can be really slow for some things, and I think the piwheels numpy packages are not built with all the optimizations. For some reason creating Bokeh models, especially ColumnDataSources is also slow, at least according to the performance profiling I've done. I do most of the heavy lifting with a Go application already, but can't pre-calculate everything if I want interactivity.

Yeah it is slow. I never timed thing's but I guess processing takes arount 10-20s where 50% is numpy/Pandas and 50% is Bokeh. The ColumnDataSource seems to be really slow especially the scatter plots and regresion lines for Compression/Rebound Speeds seem to really take some time.
I've seen that you use a Go app. I have never used Go so I haven't had a look at the code. I think when I know what I really need I will try to have a small C application for calculations to speed things up a bit.

It can be a fight, yes, I have had moments when I hated Bokeh But now I'm OK with how the dashboard looks like.

I think I have barely scratched the surface but it looks like a capable tool and somehow I like the look of it. An especially with the ColumnDataSource it's pretty fast to show some data nicely.

I used to love Qt, but I wrote an app last year to extract jump data from my Garmin 530 in Qt5 with QML, and I really did not like this mix of C++ and JavaScript.

I have only used the PyQT stuff so far as the last years everything I programmed was headless and only some datafiles came out of it. For quick and easy GUIs it's ok. But it can be a pain if you try to do something out of the ordinary.

 

[nollak]

So laenger nix passiert hier, aber das lag weniger daran das ich untaetig war, sondern simpel ein wenig an mangelnder Zeit und mechanisch Konstruktivem Unvermoegen.

Ich hab in letzter Zeit erstmal versucht, das System zu fahren. Die erste Fahrt am Rudelfully ist auf dem halben Trail damit geendet, das sowohl Daempfer, als auch Gabelbefestigung sich verabschiedet haben.
Naja alles ins Auto gepackt und dann so gefahren.

Nachdem die Halterung am Kavenz aehnlich war hab ich mich dann nochmal hingesetzt und geschaut was man besser machen kann.
Am. Kavenz hab ich dann eine Halterung gebaut, welche sich an der unteren Daempfer Befestigung/Buchse abstuetz und am AGB.
An der Gabel habe ich den Winkel oben angepasst und ein Teil gedreht um das ganze vernuenftig fest ziehen zu koennen.

Am letzten Wochenende war dann in Lac Blanc die Testfahrt. Soweit hat alles gut funktioniert, ich konnte nur dank fehlender Fitness keine kompletten Runs machen, aber hab zumindest mal die Teilabschnitte aufzeichnen koennen.
Bei Interesse kann ich mal den Google Drive Ordner zu den Bokeh Dashboards hier verlinken.

Die Daten sahen erstmal gut aus, ich wollte eigentlich diese Woche weiter rein schauen und ein wenig schauen was verbessert werden kann. Also sowohl an meinem Setup als auch an der Software, allerdings hab ich mir in Lac dann ne fette Erkaeltung eingefangen und war die Woche erstmal krank. Daher hatte ich nicht den Kopf um an irgendwas zu arbeiten.

Aber erste Funktionstest laufen und es sah vielversprechend aus.

Ausserdem hab ich von @timmeygasmus noch einen anderen GPS Sensor, eine IMU und Magnetsensoren fuer Bremshebel bekommen, welche ich noch ins System integrieren will.
Aktuell ist bzw. wird der Fokus aber erstmal darauf sein mit den letzten Testdaten zu arbeiten und am naechsten Langen Wochenende noch mehr Daten aufzunehmen.
Passenderweise hab ich bis dahin auch einen neuen Rahmen da. Also muss ich eh was am Setup machen. Da kann ich dann mal meine Gefuehle mit den Daten abgleichen. Das Kavenz war schonmal auf Gefuehl abgestimmt und sah auch recht ok aus. Der Daempfer war noch etwas hinter der Gabel her aber das hat mein Gefuehl bestaetigt und die Daten so auch wieder gegeben.

 

[timmeygasmus]

Zeig her!

 

[nollak]

Zeig her!

Alles klar!

https://drive.google.com/drive/folders/1EMoDKCVfaYNVZU3FTamcWkjOdx5FJxHH
Ich dachte erst das GPS funktioniert nich aber hat doch ganz gut funktioniert.

Ich werd wohl die Woche selbst nochmal reinschauen. Stellenweise muss ich an der Darstellung auf jeden Fall noch was machen.