RPM PIGPIO falsche Werte "entprellen"

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Meine Ausgabe:

    Und in wiefern entspricht das jetzt mehr oder weniger deinen Anforderungen?

  • Wenn ich eine Taste drücke:


  • Ich hab lower_limit, higher_limit usw nur von dir übernommen. Ob das so richtig ist hab ich nicht weiter durchleuchtet, da ist nun deine Mithilfe erforderlich


    http://codepad.org/xwQ5HDgU

    Jetzt geht es, ich möchte das ausgiebig testen und melde mich nachher dann noch mal.

    Das funzt aber schon 100x besser als meins! Super vielen Dank.

    Was noch nicht passt, ich brauch ja die durchschnittlichen rpm, das count zählt immer höher.

    ein realistischer Wert liegt so wischen 20 und 100 RPM. Ich hoffe ich hab das so richtig ausgedrückt? (also count ja, aber als Durchschnitt pro Minute)

    Einmal editiert, zuletzt von Landixus (9. Mai 2017 um 20:07)


  • Ich hab lower_limit, higher_limit usw nur von dir übernommen. Ob das so richtig ist hab ich nicht weiter durchleuchtet, da ist nun deine Mithilfe erforderlich
    http://codepad.org/xwQ5HDgU

    Also die Powerausgabe soll 0 sein wenn die RPM kleiner als 20 RPM ist, oder wenn die RPM größer als 120 ist. Da man ja keine 120 RPM schafft mit dem Crosstrainer. (Habs versucht... bremsen ist dann voll doof!)

    Zitat von meigrafd


    Umdrehungen pro Minute


    Müssten wir jetzt nicht die rpm ( Umdrehungen pro Minute) erste noch anhand der pulses errechnen? (rpm = 1/impulse * 60) und dann (return rpm)? Und dann wird anhand von level und rpm die power berechnet.
    Nicht lachen ich will es nur versuchen. :daumendreh2:

    Was mir noch aufgefallen ist: Wenn ich die btnPlus oder btnMinus Taste drücke zählt es die Level hoch, oder runter. Bei Tastendruck soll zwar ein Level höher, oder runter gewählt werden, soll dann aber da verbleiben, bis wieder gewählt wird.

    ich glaub das ist jetzt gut erklärt, oder?
    Hab auch nix am code gefummelt!

    Einmal editiert, zuletzt von Landixus (9. Mai 2017 um 23:12)

  • Um einen Durchschnitt pro Minute zu haben muss es erst mal eine Minute laufen :fies:

    Dass das Script noch nicht die endgültige Fassung ist, habe ich glaube schon 3x erklärt. Wir arbeiten uns Schritt für Schritt voran.

    Gemäß deiner Ausgabe schafft du 20-30 Impulse in nur 2 Sekunden:

    counter: 0
    counter: 22
    counter: 54
    counter: 84
    counter: 112
    counter: 142
    counter: 168

    Zwischen jeder Ausgegebenen Zeile sind 2 Sekunden vergangen.
    Insofern ist die Aussage denk ich nicht korrekt: " Da man ja keine 120 RPM schafft mit dem Crosstrainer. ". Oder das Erfassen an sich ist noch fehlerhaft - eben aus dem Grund weil du einen Reed-Switch verwendest (wieso das ein Problem sein könnte wurde hier auch schon paar mal erwähnt)

    Bisher haben wir nur einen reinen Impulszähler gebaut. Um jetzt "Rotations per Minute" beziehungsweise "Revolutions per Minute" bzw U/min zu erhalten brauchen wir auch noch eine Zeiteinheit. Wir müssen also eine Anzahl von Vorgängen pro Zeiteinheit ermitteln.

    Nun gäbe es denk ich mehrere Möglichkeiten:
    1. Entweder wir ermitteln die Zeit die für insg. 10 Umdrehungen benötigt wurde.
    2. Oder wir merken uns die Zeit für jede einzelne Umdrehung und berechnen jede 10te.
    3. Wenn man RPM wörtlich nimmt, zählt man 60 Sekunden lang die Impulse, nutzt die Anzahl und resettet danach "count" wieder.

    Allgemein könnte diese Berechnung so aussehen:
    Start_Zeit merken.
    10 Impulse zählen.
    End_Zeit merken.
    10 Impulse geteilt durch (End_Zeit minus Start_Zeit)
    ... ergibt glaub ich die Frequenz ...

  • Nein. Eine bouncetime wirkt der Erfassung entgegen.
    In deinem Fall wird ein GPIO ziemlich schnell nacheinander ausgelöst, dh. eine "bouncetime" ist für dich störend, denn, findet ein Flankenwechsel statt und innerhalb von "bouncetime" noch einer, wird dieser ignoriert. "bouncetime" ist eine Softwareseitige Entprellung.

    Dein Erfassungsproblem, sofern eins besteht, liegt wenn dann nur am Sensor. Und nicht daran das zu wenige erfasst werden, sondern zu viele ;) Regelt man das via Software ist es letztlich nur ein Glücksspiel ob die Werte dann tatsächlich noch der Realität entsprechen.

    Für Taster nutzt man "bouncetime" um eine Mehrfachauslösung zu schnell hintereinander zu verhindern.


  • Nein. Eine bouncetime wirkt der Erfassung entgegen.

    Für Taster nutzt man "bouncetime" um eine Mehrfachauslösung zu schnell hintereinander zu verhindern.


    Also ich kenn das so, das der Magnet am reed Kontakt vorbei kommt und diesen für einen Moment anzieht(schliesst), das ist dann für mich eine Umdrehung.
    Das mit dem richtigen erfassen habe ich mit diesem script(Nicht hauen war nur zum testen) ja getestet:



    Nur damit du weisst das der reed OK ist. Ich kann auch gerne die Ausgabe posten, die das script bringt wenn gewünscht.

    Einmal editiert, zuletzt von Landixus (10. Mai 2017 um 11:40)

  • Und woher weißt du das Dieses Script absolut fehlerfrei funktioniert wenn du 20-30 Umdrehungen pro 2 Sekunden machst? Rechne das mal runter auf Millisekunden und wie viele dann in die bouncetime fallen und somit ignoriert werden...
    Selbst wenn man 2 / 20 rechnet wäre das jeder 2. Auslöser der durch eine bouncetime von 200ms ignoriert werden würde

    Teste Das Script mal ohne bouncetime und vergleich die Ergebnisse. Mal davon abgesehen dass das Script "wheel radius" benötigt was du aber gar nicht verwendest/angibst


  • Und woher weißt du das Dieses Script absolut fehlerfrei funktioniert wenn du 20-30 Umdrehungen pro 2 Sekunden machst? Rechne das mal runter auf Millisekunden und wie viele dann in die bouncetime fallen
    Teste Das Script mal ohne bouncetime und vergleich die Ergebnisse. Mal davon abgesehen dass das Script "wheel radius" benötigt was du aber gar nicht verwendest/angibst

    Ob das absolut fehlerfrei arbeitet weiss ich nicht, aber wenn sich die Ausgabe auf der Konsole mit der an dem Crosstrainer deckt, kann sie ja so falsch nicht sein.


    Da ist aber immer noch das Verständnissproblem?, oder ich bring das falsch rüber. Ich schaffe doch nie 20 - 30 Umdrehungen pro Sekunde, das schafft keiner :)
    Hier siehst du die Scheibe und den Magnet:

    F8PSGE0IFJWO8C1.MEDIUM.jpg

    Der Durchschnittsfahrer hat so eine RPM von 60, also 1 Umdrehung pro Sekunde. (Da ordne ich mich mal ein, im Trainingsmode)

    So ein Profi kommt schon ma für ein paar Sekunden auf 225 RPM , das sind dann 3,75 pro Sekunde. (Dann hat der aber auch Beine wie ein Pferd). :danke_ATDE:

  • Servus Landixus,


    ...
    Also ich kenn das so, das der Magnet am reed Kontakt vorbei kommt und diesen für einen Moment anzieht(schliesst), ...


    Hintergrund (falls Du es nicht vielleicht schon ergurgelt hast):
    mechanische Kontakte neigen dazu kein einmaliges, sauberes LOW->HIGH (oder auch HIGH->LOW) Signal auszugeben, sondern für einen kurzen Zeitraum zwischen zwei Zuständen zu "schwingen". Das nennt man dann eben prellen.
    Eine Software, die auf Impulse eines Eingangs reagiert, registriert eben auch dieses "Schwingen" jeweils als einzelnen Schaltimpuls. Das sind die von meigrafd erwähnten Mehrfach-Auslöser.
    Das ist so nicht sinnvoll, denn wenn ich einen Taster abfrage, den ich, für mich als Mensch gefühlt, einmal betätige, dann soll die Software auch nur einen Impuls registrieren und nicht 17.
    Deshalb werden mechanische Kontakte "entprellt". Das geschieht jetzt entweder per Hardware ( RC-, LRC-Glied, Schmitt-Trigger, ...) oder eben per Software.
    Per Software verwendet man eben eine "bounce-time" bzw. "debounce-time" die schlicht nichts anderes bewirkt, als dass alle in diesem Zeitraum zusätzlich auftretenden Impuls einfach ignoriert werden.
    Das geht aber nur so lange gut, wie die debounce-time kleiner ist als der Zeitraum, in dem "echte" Impulse auftreten. Wird sie grösser, werden auch "richtige" Impulse ignoriert was z.B. falsches zählen zur Folge hat.

    ciao,
    -ds-

  • Du könntest die Gelegenheit nutzen und dabei was lernen :)
    Nur dasitzen und sagen "Komm, schreib mir mal den Code, bis ich's gut finde" ist nicht so toll (ich weiß, so meinst du es nicht, aber glaub mir, du kannst dich mehr drüber freuen, wenn du sagen kannst, dass es deine Arbeit war).

    Pfff...

    LG


  • Du könntest die Gelegenheit nutzen und dabei was lernen :)
    Nur dasitzen und sagen "Komm, schreib mir mal den Code, bis ich's gut finde" ist nicht so toll (ich weiß, so meinst du es nicht, aber glaub mir, du kannst dich mehr drüber freuen, wenn du sagen kannst, dass es deine Arbeit war).
    LG

    das habe ich ausgiebig erklärt, sei mir bitte nicht böse, aber magste dich raus halten? (Ich mein das auch nicht so). :danke_ATDE:

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!