Hallo, ich suche Folgendes: Erkennen einer Umdrehung eines Rades (Ergometer) und senden dieser Information zum PC per USB-Schnittstelle, notfalls auch drahtlos via Bluetooth. Am liebsten wäre mir sowas als fertige Lösung, aber ich konnte nichts finden. Derzeitiger Plan: Fahrradcomputer kaufen, Tachosignal in µC/FPGA auswerten und per FTDI zum PC. Der Aufwand ist allerdings verhältnismäßig groß(mit Gehäuse, Software, Firmware und Befestigung rechne ich ~10 Arbeitsstunden), deswegen dachte ich, frag doch mal nach ob es da Ideen gibt wie man es vereinfachen kann oder ob jemand doch so etwas von der Stange kennt. Danke und Gruß
Ich habe keine persönliche Erfahrung damit, aber ich weiss das es ein offizielles Bluetooth 4.0 Profil für "Cycling Speed and Cadence" und entsprechende käufliche Sensoren gibt, die glaube ich für genau sowas da sind. Google mal nach "bluetooth cadence", ob Du da was findest. https://www.amazon.de/OCATO-Radfahren-Cadence-Bluetooth-Technologie-Geschwindigkeit/dp/B01CNOZCNK/
Wenn man nicht so aggressiv wäre, dann könnte man z.b. erklären wie das gehen soll. Ich kenne die Bausteine nur als rs232 zu USB Brücke, Steuerpins hab ich nie benutzt. Ganz von abgesehen, das ich derzeit nur ein rs232 zu usb Kabel mit FTDI in der Mitte und ein FPGA Board mit FTDI hardverdrahtet am FPGA(nur TX und RX Pins) direkt hier habe, deswegen lag das nahe eins davon zu verwenden. >> Google mal nach "bluetooth cadence", ob Du da was findest. sieht ganz ok aus, danke. Ich werde mal suchen ob man das problemlos an einen PC bekommt.
Iulius schrieb: > Wenn man nicht so aggressiv wäre, dann könnte man z.b. erklären wie das > gehen soll. Der lebt in seiner eigenen Welt. Scheinbar sehr intelligent/bewandert - nur die konkreten Umsetzungen sind mir bisher entgangen. Ich würde einen Magneten ankleben und per Hall-Sensor die Umdrehungen messen und - wie auch immer - diese an den PC weiter geben. Das geht natürlich auch optisch ... aber in diesem Fall scheint mir der Hall-Sensor die praktikabelste Möglichkeit zu sein. Ich kenne den FTDI-Chip nicht (habe das Datenblatt nicht gelesen) - ggf. kann man den ja wirklich direkt nutzen - als Doofie würde ich schlicht einen Arduino Nano (China-Billig-Clone) nutzen um das Signal zu übertragen (oder etwas eigenes stricken - aber dazu wäre ich zu faul :-) ).
c-hater schrieb im Beitrag #4921665: > Iulius schrieb: > > Erkennen einer Umdrehung eines Rades (Ergometer) und senden dieser > Information zum PC per USB-Schnittstelle, notfalls auch drahtlos via > Bluetooth. > Am liebsten wäre mir sowas als fertige Lösung, aber ich konnte nichts > finden. > Derzeitiger Plan: Fahrradcomputer kaufen, Tachosignal in µC/FPGA > auswerten und per FTDI zum PC. > > OMG... > > Wie blöd muss man eigentlich sein, um nicht auf die Idee zu kommen, > gleich einen der Steuerpins des FTDI zu benutzen... Ich würde trotzdem einen Mikrocontroller verwenden. Dann macht auch das Geschwindigkeiten berechnen kein Problem. Man kann zwar die Pins des FTDI auslesen, aber garantiert nicht echtzeitfähig! Möglichst viele kleine Magnete an das Rad kleben. Über einen oder zwei Hall-Switch am Mikrocontroller einlesen. Wenn der ein Quadratur Encoder Interface hat langweilt der sich zu Tode. Wenn er dann noch USB hat, fällt der FTDI ganz weg.
Dieter F. schrieb: > Ich kenne den FTDI-Chip nicht (habe das Datenblatt nicht gelesen) - ggf. > kann man den ja wirklich direkt nutzen - Ja, das kann man machen. > als Doofie würde ich schlicht einen Arduino Nano (China-Billig-Clone) > nutzen um das Signal zu übertragen So doof ist das gar nicht. Auf dem Ding kann man den Reedkontakt entprellen, einen Zähler laufen lassen und den Zählerstand bequem vom PC aus abfragen. Ohne daß der PC irgendwelche Wechsel am RSR232-Steuerpin übersieht, weil er gerade mal wieder meint, die Festplatte zu bügeln, sei wichtiger. Und billiger ist es wahrscheinlich auch noch.
:
Bearbeitet durch User
Iulius schrieb: >>> Google mal nach "bluetooth cadence", ob Du da was findest. > > sieht ganz ok aus, danke. > Ich werde mal suchen ob man das problemlos an einen PC bekommt. Falls Du nix fertiges findest: Alles wissenswerte zum "Cycling Speed and Cadence Service" ist auf den Webseiten etc. von bluetooth.org ausführlich dokumentiert. In der Praxis wird es Dir vermutlich genügen, die Bluetooth 4.0-Charakteristik 0x2A5B (org.bluetooth.characteristic.csc_measurement) zu subscriben und die Daten zu parsen. Das Protokoll scheint vglw. simpel zu sein: https://www.bluetooth.com/specifications/gatt/viewer?attributeXmlFile=org.bluetooth.characteristic.csc_measurement.xml Mit einer passenden Software-Library für Bluetooth 4.0 dürfte das wenig Aufwand sein. Wenn Du z.B. node.js und das "noble"-Modul benutzt, würde ich auf ca. 20-40 Zeilen Code tippen.
Joachim S. schrieb: > In der Praxis wird es Dir vermutlich genügen, die Bluetooth > 4.0-Charakteristik 0x2A5B (org.bluetooth.characteristic.csc_measurement) > zu subscriben und die Daten zu parsen. Scharf - kannst Du das für Unbedarfte (wie mich) allgemein verständlich erklären?
Hi Wenn statt Reed-Kontakt ein Hall-Sensor verwendet wird, sollte das Prellen auch kein Problem mehr sein. MfG
Dieter F. schrieb: > Joachim S. schrieb: >> In der Praxis wird es Dir vermutlich genügen, die Bluetooth >> 4.0-Charakteristik 0x2A5B (org.bluetooth.characteristic.csc_measurement) >> zu subscriben und die Daten zu parsen. > > Scharf - kannst Du das für Unbedarfte (wie mich) allgemein verständlich > erklären? Ich weiss nicht, ob das schon genügt, aber hier einfach mal ein kleines dokumentiertes Codefragment, wie man auf einen entsprechendesn Bluetooth 4.0 "Cycling Speed and cadence"-Sensor per "Web Bluetooth API" zugreifen könnte:
1 | // Suche nach einem in der Nähe befindlichen Bluetooth 4.0-Device, das den "GATT-Service" mit der ID 0x1816 (="Cycling Speed and Cadence") anbietet |
2 | navigator.bluetooth.requestDevice({filters: [{services: [0x1816]}]})
|
3 | // Ein entsprechendes Gerät wurde gefunden; versuche mit dem Gerät zu verbinden |
4 | .then(device => device.gatt.connect()) |
5 | // Verbindung zum Gerät bzw. dessen GATT-Server aufgebaut. Den GATT-Service 0x1816 (="Cycling Speed and Cadence") anfordern |
6 | .then(server => server.getPrimaryService(0x1816)) |
7 | // Vom "Cycling speed and cadence"-Service die Characteristic 0x2A5B (="Cycling Speed and Cadence Measurement") anfordern, über die die eigentlichen Messdaten des Sensors übertragen werden |
8 | .then(service => service.getCharacteristic(0x2A5B)) |
9 | // Auf diese Characteristic subscriben |
10 | .then(characteristic => characteristic.startNotifications()) |
11 | .then(characteristic => {
|
12 | characteristic.addEventListener('characteristicvaluechanged', function(event) {
|
13 | // Diese Funktion wird nun immer aufgerufen, wenn neue Daten vorliegen |
14 | var value = event.target.value; |
15 | console.log('Received ' + value);
|
16 | // value ist ein ca. 11 Byte langes Byte-Array, das nun nur noch gemäss https://www.bluetooth.com/specifications/gatt/viewer?attributeXmlFile=org.bluetooth.characteristic.csc_measurement.xml geparst werden muss |
17 | }) |
18 | }) |
Hab mit Bluetooth bisher garnichts gemacht, deswegen ist die Einarbeitungszeit sicher größer als der sonstige Entwicklungsaufwand ;) Scheint mir insgesamt aber trotzdem die einfachste Variante, einfach weil der Mechanik Teil wegfällt. Preislich dürfte ein Hall-Sensor + bestehendes Evalboard natürlich nicht zu schlagen sein... Schade das es die Speed und Cadence Geräte oder ähnliches nicht einfach als rs232 gibt.
Iulius schrieb: > Hab mit Bluetooth bisher garnichts gemacht, deswegen ist die > Einarbeitungszeit sicher größer als der sonstige Entwicklungsaufwand ;) > [...] > Schade das es die Speed und Cadence Geräte oder ähnliches nicht einfach > als rs232 gibt. Benutzt Du Linux? Falls ja, könnte eine vglw. einfache Möglichkeit darin bestehen, das extra für Bluetooth 4.0 gemachte Tool "gatttool" im nicht-interaktiven Modus zu benutzen um auf die besagte GATT-Characteristic zuzugreifen, und die Ausgabe dieses "gatttool"s dann per pipe als Eingabe eines eigenen kleinen Scripts zu benutzen, das die Rohdaten dann per STDIN erhält und nur noch parsen muss, ohne sich mit der eigentlichen Bluetooth-Kommunikation beschäftigen zu müssen. Habe ich bislang nie selbst ausprobiert, aber falls ich diese Webseite: http://www.humbug.in/2014/using-gatttool-manualnon-interactive-mode-read-ble-devices/ richtig interpretiere, dann könnte das klappen.
Iulius schrieb: > Hallo, > > ich suche Folgendes: > > Erkennen einer Umdrehung eines Rades (Ergometer) und senden dieser > Information zum PC per USB-Schnittstelle, notfalls auch drahtlos via > Bluetooth. Warum USB? Was willst du denn am PC damit? Braucht ja auch einen Treiber um das ganze auszuwerten. Einfacher wärs die Geschwindigkeit Analog zum PC zu übertragen. Rs232 ist auch einfacher umzusetzen an beiden Enden.
Fabian F. schrieb: > Rs232 ist auch einfacher umzusetzen an beiden Enden. FTDI und Co. ist RS232. Die braucht man, da die PC-Hersteller die richtige RS232 weitestgehend wegrationalisiert haben.
Ich hab eine PCIe-Karte mit 2x Seriell im PC. Im gegensatz zu den USB-Rs232-Adaptern hatte ich damit noch nie Timing-Probleme.
Fabian F. schrieb: > Ich hab eine PCIe-Karte mit 2x Seriell im PC. Im gegensatz zu den > USB-Rs232-Adaptern hatte ich damit noch nie Timing-Probleme. Das hatte ich mit den FTDI o.ä. auch noch nicht. Das Timingproblem was ich oben meinte entsteht dadurch, dass das Tasksystem vom PC irgendwann dran kommt und merkt das neue Bytes angekommen sind. Zusätzlich hat man keinen Zeitstempel zu den empfangenen Bytes. Dadurch hat man, wenn man auf PC Seite die Geschwindigkeit / Beschleunigung berechnen wollte, Schwierigkeiten zu differenzieren (zuverlässige Zeit fehlt).
Man könnte natürlich auch CAN verwenden. Da kann man dann den Zeitstempel zu jedem Messwert packen. USB-CAN adapter gibb's für kleines Geld...
Frank schrieb: > Zusätzlich hat man keinen Zeitstempel zu den > empfangenen Bytes. Dadurch hat man, wenn man auf PC Seite die > Geschwindigkeit / Beschleunigung berechnen wollte, Schwierigkeiten zu > differenzieren (zuverlässige Zeit fehlt). Das ist genau der Punkt, weswegen man nicht einfach bei jeder Radumdrehung irgend ein vereinbartes Zeichen schickt, sondern besser den Sensor eine Datenstruktur pflegen läßt wie die weiter oben für Bluetooth gezeigte. Einmal einen Zähler für Umdrehungen - dann funktioniert das mit dem Auslesen auch dann noch, wenn der Empfang mal kurz gestört war. Und den Zeitpunkt des letzten Events (gemessen mit einem Zeitgeber im Sensor natürlich). Die schickt der Sensor dann entweder regelmäßig oder auf Anforderung zum PC. Der Zeitzähler läuft (in der BT-Implementierung) alle 64 Sekunden über. Deswegen muß man mindestens alle 64 Sekunden einmal pollen. Dann kann man aus den Zeitstempeln und dem Umdrehungszähler ganz einfach die Strecke und Geschwindigkeit ausrechnen. Man könnte z.B. einen Arduino nano nehmen und mit dessen UART über den vorhadenen USB-serial Chip mit dem PC kommunizieren. Ein einfaches Protokoll reicht ja. Z.B. PC->Arduino: "g" Arduino->PC: <Datenstruktur wie oben> Alternativ oder zusätzlich kann man auch noch eine Variante einbauen, wo der Arduino die Daten im Klartext (ASCII) sendet. Dann kann man das auch schnell mal mit einem Terminalprogramm testen.
Axel S. schrieb: > Das ist genau der Punkt, weswegen man nicht einfach bei jeder > Radumdrehung irgend ein vereinbartes Zeichen schickt, sondern besser den > Sensor eine Datenstruktur pflegen läßt wie die weiter oben für Bluetooth > gezeigte. Einmal einen Zähler für Umdrehungen - dann funktioniert das > mit dem Auslesen auch dann noch, wenn der Empfang mal kurz gestört war. > Und den Zeitpunkt des letzten Events (gemessen mit einem Zeitgeber im > Sensor natürlich). Die schickt der Sensor dann entweder regelmäßig oder > auf Anforderung zum PC. Klar, entweder er muss simultan den Quadraturencoder Zähler UND einen Zeitstempel latchen, oder er berechnet gleich noch die Geschwindigkeit mit. Axel S. schrieb: > Der Zeitzähler läuft (in der BT-Implementierung) alle 64 Sekunden über. > Deswegen muß man mindestens alle 64 Sekunden einmal pollen. Dann kann > man aus den Zeitstempeln und dem Umdrehungszähler ganz einfach die > Strecke und Geschwindigkeit ausrechnen. Wenn er die Geschwindigkeit gleich mitberechnet entfällt diese Einschränkung. Man hat immer richtige Werte. Axel S. schrieb: > Man könnte z.B. einen Arduino nano nehmen und mit dessen UART über den > vorhadenen USB-serial Chip mit dem PC kommunizieren. Ein einfaches > Protokoll reicht ja. Z.B. > PC->Arduino: "g" > Arduino->PC: <Datenstruktur wie oben> Wenn man das noch etwas aufgebohrt, könnte man auch leicht noch das gewünschte Abtastintervall, Filterzeiten, Sendeintervalle usw einstellbar machen. Ich würde ihn übrigens zyklisch von selbst senden lassen. Dann hängt das auch wieder hart an der Echtzeit wenn es das gegenüberliegende System kann.
Thomas E. schrieb: > Auf dem Ding kann man den Reedkontakt entprellen, einen Zähler laufen > lassen und den Zählerstand bequem vom PC aus abfragen. Ohne daß der PC > irgendwelche Wechsel am RSR232-Steuerpin übersieht, weil er gerade mal > wieder meint, die Festplatte zu bügeln, sei wichtiger. OMG. Es geht um die Drehzahl eines Ergometer-Rades! Da verpasst du garantiert nichts Wesentliches, wenn du den Scheiss-Reedkontakt einfach an einen der vier Steuer-Inputs eines FTDI legst und die mittels COMM-API abfragst. Und wenn du klug genug bist, die "Abfrage" nicht als solche (also im Sinn von nasenpopelnden Polling im GUI-Thread) zu implementieren, sondern die von vom API gebotenen asynchronen Callbacks verwendest, reicht die erzielbare Genauigkeit noch sehr weit darüber hinaus (ungefähr drei Größenordnungen), was hier für dieses blöde Ergometer nur nötig ist...
Iulius schrieb: > Wenn man nicht so aggressiv wäre, dann könnte man z.b. erklären wie das > gehen soll. Ich kenne die Bausteine nur als rs232 zu USB Brücke, > Steuerpins hab ich nie benutzt. Jede typische UART hat vier Eingänge, die völlig unabhängig von der eigentlichen seriellen Datenübertragung sind (aber teilweise benutzt werden können, um für die eigentliche serielle Übertragung eine Flusssteuerung zu implementieren). Man kann sie aber halt auch einfach so verwenden und den eigentlichen seriellen Kanal einfach links liegen lassen hat also im Endeffekt einen parallelen Input-Port mit vier Pins. Übrigens: auf die gleich Art kann man auch drei parallele Ausgabe-Pins nutzen (wobei einer davon allerdings starken Restriktionen unterliegt). Die FTDI bieten (wie praktisch jeder andere UART-USB_CDC-Wandler auch) ebenfalls diese vier Eingänge und auch die drei Ausgänge. Gegenüber echter Hardware gibt es allerdings Restriktionen zu beachten, die aus dem USB-Protokoll entstehen, welches eine Zykluszeit (FullSpeed) von 1ms hat. Sprich: man kann damit nur Frequenzen <500Hz abtasten. Das reicht für ein Ergometer aber mehr als aus. Den Sportler möchte ich sehen, der seine Ergometer-Scheibe mit mehr als 500*60=30.000 U/min betätigt und auch das Ergometer, was das rein mechanisch aushalten würde... > Ganz von abgesehen, das ich derzeit nur ein rs232 zu usb Kabel mit FTDI > in der Mitte und ein FPGA Board mit FTDI hardverdrahtet Vergiss den FPGA. Sowas nimmt man, wenn man, wenn man im MHz-Bereich agieren muss, aber nicht bei so einer Popel-Kacke.
c-hater schrieb: > Gegenüber > echter Hardware gibt es allerdings Restriktionen zu beachten, die aus > dem USB-Protokoll entstehen, welches eine Zykluszeit (FullSpeed) von 1ms > hat. Sprich: man kann damit nur Frequenzen <500Hz abtasten. > > Das reicht für ein Ergometer aber mehr als aus. Den Sportler möchte ich > sehen, der seine Ergometer-Scheibe mit mehr als 500*60=30.000 U/min > betätigt und auch das Ergometer, was das rein mechanisch aushalten > würde... Vor lauter Arroganz und dummem Gelaber hast du wohl nicht bedacht, dass der Impuls des Hallsensors bzw. Reed-Relais nur sehr kurz ist (auch bei langsamen Drehzahlen). Da ist ein billiger Arduino, der das ganze mit Input Capture erfasst, die bessere Lösung.
chris schrieb: > Vor lauter Arroganz und dummem Gelaber hast du wohl nicht bedacht, dass > der Impuls des Hallsensors bzw. Reed-Relais nur sehr kurz ist (auch bei > langsamen Drehzahlen). Und du hast wohl vergessen, dass man dieses Problem auch ohne µC oder gar FPGA vor dem FTDI lösen könnte, durch einen simplen Monoflop, z.B. einen mit einem dämlichen 555er... Mann, du bist so glatt, du würdest sogar auf 100er-Schleifleinen noch ausrutschen...
Danke schon einmal für die vielen Hinweise und Tipps. Habe mir jetzt ein kleines Hall Board mit digital und analog Ausgang und LEDs für einen ersten Test bestellt und werde damit mal spielen, denke das bekomme ich hin. Die Bluetooth Lösung wäre zwar insoweit nett, allerdings teurer und der Lerneffekt besteht dann nur im Bluetooth Interface, was aber eigentlich für die Applikation nur Mittel zum Zweck wäre. Wenn ich etwas fertig habe, dann melde ich mich hier nochmal zurück.
Frank schrieb: > Axel S. schrieb: >> Der Zeitzähler läuft (in der BT-Implementierung) alle 64 Sekunden über. >> Deswegen muß man mindestens alle 64 Sekunden einmal pollen. Dann kann >> man aus den Zeitstempeln und dem Umdrehungszähler ganz einfach die >> Strecke und Geschwindigkeit ausrechnen. > > Wenn er die Geschwindigkeit gleich mitberechnet entfällt diese > Einschränkung. Man hat immer richtige Werte. Das ist kein signifikanter Vorteil. Es macht aber den Sensor aufwendiger - statt eines simplen Zählers muß der jetzt auch noch dividieren können. Die Geschwindigkeit ist darüber hinaus eine redundante Information. Der Umdrehungszähler wird für die Erfassung der Fahrstrecke ohnehin gebraucht. Und der Timestamp ist überaus hilfreich, um den Stillstand des Rads zu erfassen, z.B. für die Anzeige "Zeit in Bewegung". Könnte man zwar alles auch dem Umdrehungszähler oder der Geschwindigkeit extrahieren, aber warum mit abgeleiteten Daten arbeiten, wenn man die Rohdaten bekommen kann? > Axel S. schrieb: >> Man könnte z.B. einen Arduino nano nehmen und mit dessen UART über den >> vorhadenen USB-serial Chip mit dem PC kommunizieren. Ein einfaches >> Protokoll reicht ja. > Ich würde ihn übrigens zyklisch von selbst senden lassen. Ich nicht. Denn zum einen bekommen wir genau wieder das gleiche Problem: das anzeigende/aufzeichnende System muß echtzeitfähig sein, sonst verpaßt es Datenpunkte. Wenn es die Daten selber anfordert, kann es auch sicherstellen, daß es die Daten nachher auch abholen und verarbeiten kann. Das zweite Problem ist praktischer Natur. Aus verschiedenen Gründen will man die Anzeige von Geschwindigkeit/Strecke etc. nicht zu oft updaten. Zum einen, weil Displays ohnehin nur eine begrenzte Updaterate haben, vor allem aber, weil das Auge/Hirn den Updates auch folgen können muß. Mehr als ca. 3 Updates pro Sekunde kann ein Mensch nicht erfassen. Schon gar nicht, wenn er auf den Fahrrad sitzt und nebenher auch noch auf den Verkehr achten muß (Ausnahme: analog angezeigte Information: einem Zeigerausschlag kann das Hirn schneller folgen als einer Zahlenanzeige) Dann sagst du jetzt vielleich: "na gut, lassen wir den Sensor halt nur zweimal pro Sekunde senden". Dann kommt jetzt das praktische Problem: wenn man außerdem noch die Zeit anzeigen will und das gar noch mit Sekunden, dann will man zeitlich exakte Sprünge der Sekundenanzeige haben. Es ist sehr irritierend, wenn die Sekundenanzeige merklich unregelmäßig springt. Da die Events vom Sensor und die Uhrzeit aber asynchron sind, ist es gar nicht zu vermeiden, daß Sekundensprünge und Sensordaten ebenfalls asynchron sind. Was wiederum bedeutet, daß wir entweder veraltete Sensordaten anzeigen müssen oder die Sekundenanzeige erratisch springt. Wenn das anzeigende System die Daten aber selber anfordert, kann es den ganzen Trouble vermeiden. Einfach beim Sekundensprung die Daten anfordern und dann anzeigen. Es gibt eine kurze Latenz, aber so lange diese Latenz konstant ist, fällt sie nicht auf.
So, ich melde mich mal wieder, der Hardware Teil ist(bis auf die Mechanik) abgeschlossen. Aufbau: Magnet (8x3mm Neodym) -> Hall Sensor Modul -> Analog Pin eines Arduino Nano -> Serial Port per USB -> C# -> SMPlayer Hier wird auch klar daas es kein "anzeigendes System" in dem Sinne gibt. Die RPM wird nicht dem Nutzer angezeigt, sondern wird genutzt ein Video (Helmkamera einer Radtour) schneller oder langsamer abzuspielen, ggf. anzuhalten. Zu diesem Zweck erkenne ich die Umdrehungen pro Sekunde und schicke diese zum PC genau einmal pro Sekunde. Je nachdem wie das in der Praxis läuft wird es ggf auch 100ms oder so. Wann das in der Realität ankommt ist mir dann egal, weil nur die Updaterate der Videogeschwindigkeit schwankt. Wenn auf dem PC kein Mist läuft habe ich eh nur Schwankungen im einstelligen ms Bereich und das bei 9600er Baud. Danke nochmal an alle für die Hinweise. Wenn jemand Interesse an Code hat, dann meldet euch einfach kurz. Sind aber eh nur Projekte der Größe einer Bildschirmseite... Bis Bald
Hi Iulius schrieb: > wird genutzt ein Video > (Helmkamera einer Radtour) schneller oder langsamer abzuspielen Die Nutzung klingt interessant - stelle mir dann die Wiedergabe aber irgendwie seltsam vor, wenn das Umfeld quasi in Zeitlupe abläuft und Du 'gemächlich' den Steilhang runter fährst. Hast Du ein so in der Zeit korrigiertes Video zur Hand? MfG
Iulius schrieb: > > Hier wird auch klar daas es kein "anzeigendes System" in dem Sinne gibt. > Die RPM wird nicht dem Nutzer angezeigt, sondern wird genutzt ein Video > (Helmkamera einer Radtour) schneller oder langsamer abzuspielen, ggf. > anzuhalten. > > Bis Bald Hey, Die Idee hat was. Irgendwie ganz witzig, da Ergometer sonst relativ langweilig sind und so (bei mir zumindest) die Motivation immer recht niedrig ist. Erzähl mal wie das funktioniert hat und wie das mit VR-Brille rüberkommt (sofern genutzt). ^^
Hi Aaah, Das könnte der Kern sein - dann gibt's natürlich kein Video dazu, da die Geschwindigkeit ja nur beim selber treten relevant ist - hatte mich schon gewundert. Ein schönes Projekt auf jeden Fall! MfG
VR wäre natürlich sehr nett, ist aber derzeit nicht vorgesehen :) Habe heute einige Testläufe gestartet und es funktioniert soweit ganz gut. Der SMPlayer wird dabei immer in der Geschwindigkeit gesteuert, je nach aktueller Drehzahl. Das wirkt manchmal etwas komisch, weil eben alles schneller/langsamer wird und nicht nur das Fahrrad bzw das eigene Ich, z.b. Passanten, Lenk- und Kopfbewegungen. Das ist aber mMn vertretbar, der Spaß überwiegt wenn man z.b. den Anstieg mit eigener Kraft beschleunigen kann oder in der Abfahrt mit 1.5 bis 2 facher Geschwindigkeit alles richtig vorbeirauscht. Die Motivation ist dadurch deutlich höher mehr zu geben. Aktuell gibt es noch ein paar Probleme: - Da die Videos typischerweise auf 25 Hz basieren sind diese mit unter 100% Leistung ruckelig. Ich muss mal ein paar 60 Hz Videos finden oder ggf 25 Hz mit Zwischenbildern in 60Hz umrechnen. - Leider schafft es der SMPlayer auch nicht immer ruckelfrei die Geschwindigkeit anzupassen, gerade bei Full-HD Videos und großen Unterschieden(z.b. von 100 auf 150%). Habe deshalb die maximalen Sprünge auf 10% Änderung alle 100 ms beschränkt. Nachteil: etwas träge, aber so oft ändert sich die Geschwindigkeit eh nicht sprunghaft. - die volle Umdrehungszahl pro Sekunde ist zu ungenau/träge, werde wohl doch die Zeit zwischen 2 Events verschicken, das sind dann auch nur 5-15 Messwerte pro Sekunde.
Hi Wenn Du diese Ivents so auslegst, daß Dir jeder Sensor-Impuls 'ein Bild weiter' schaltet? Mir ist allerdings nicht bekannt, wie die Einzelbilder in einem Video versteckt sind, wird wohl nur alle x Frames ein Bild komplettes neu vorhanden sein. Hat man bei einer Helm-Kamera eine Art Zeitlupen-Funktion? Denke da an die Werbeclips zu neuen Handys, und viel mehr als doppelte Geschwindigkeit wird man wohl kaum brauchen - stellt ja nicht Jeder nen Mopped auf den Heim-Trainer :O MfG
Naja, mehr als 15 Umdrehungen pro Sekunde habe ich nicht geschafft, dann ist die Kette abgeflogen :) Prinzipiell kann der SMPlayer das sogar, vielleicht wäre das tatsächlich eine Alternative, nur dann halt mit 3-5 Bildern pro Event.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.