Raddrehung erkennen und zum PC schicken

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.

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?

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.

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).

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.

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

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). ^^

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.

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.