Drehzahl messen

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

    bin neu hier.


    Mein ersten Projekt AIS-Daten Lieferant habe ich erfolgreich seit Monaten am laufen.

    Jetzt brauche ich für ein zweites Projekt jemanden, der mich "auf die richtige Spur setzt".

    Es soll die Drehzahl einer Welle gemessen werden. Eine Lichtschranke ist vorhanden und montiert, sie liefert 12 V. Das Tastverhältnis kann ich beliebig ändern. (Breiten oder schmalen Reflexstreiben auf die Welle aufbringen). Die Umdrehungszahl wird unter 4.000 Umin^-1 also deutlich unter 100 Hz liegen.

    Meine Fragen sind:
    Kann mir jemand einen Optokoppler empfehlen? Idee ist, an der Eingangsseite mit einem Vorwiederstand die (interne LED zum leuchten zu bringen). Ist dieser auf seiner Ausgangsseite einfach mit dem GPI (in) mit dem RASP zu verbinden?

    Sind die zu erwartenden Ereignisse "langsam" genug, damit der RASP sie zählen kann, oder habe ich eine zu erwartende Grenzfrequenz überschritten.

    Um auf eine Geschwindigkeit zu kommen muß ich die gezählten Umdrehungen durch die Vergangene Zeit teilen. Der RASP hat keine RTC, die brauche ich auch nicht, sondern nur eine stetig forlaufende Zahl, wie z.B. Sekunden seit dem Einschalten. Ist solch eine Zeit abfragbar und kennt jemand die Genauigkeit?

    Vielen Dank an Euch,
    ich werde über den Fortgang berichten.

  • Der RasPi ist so flink, da kannst Du in den kHz bereich gehen. Um so mehr Reflektorabschnitte die Scheiben haben, um so genauer wird das Ergebnis. Aber selbst ein Reflektorabschnitt reicht. Bei den Frequenzen macht auch das Threading von Linux nichts aus. Nach einem Optokoppler schau ich mal. Aber ich denke bei der Konstellation kannst du beinahe jeden nehmen.

  • Hallo mheuer,

    Dein Unterfangen ist möglicherweise nicht ganz so einfach, wie es auf den ersten Blick scheint. Prinzipiell stehen Dir zwei Wege offen. Du mißt a.) die Zeit zwischen zwei Impulsen oder Du mißt b.) die Impulse über einer Zeit.

    a.) bedingt jedoch, daß Du den Triggerzeitpunkt Deiner Lichtschranke mit dem Raspi exakt erfassen kannst. Rechnen wir mal...
    4000min-1 = 67s-1. D.h. Dir stehen 15ms für eine Umdrehung zur Verfügung. Nehmen wir mal an Du teilst sie auf in 2x7,5ms, damit Du ein schönes symmetrisches Signal erhälst. Deine Aufgabe besteht nun darin, den Triggerpunkt von einem Umlauf zum nächsten möglichst jitterarm zu messen. Und genau da liegt der Hund begraben! Verpaßt Du so einen Triggerpunkt um 1ms, dann beträgt Dein Fehler 100%*1ms/15ms = 6,7%. Ein usleep() allein bringt auf einem Raspbian bereits mittlere Jitter von 100µs. Zudem hast Du keine Gewähr, daß der Scheduler Dir aufgrund höher priorer Tasks nicht mal einfach die CPU entzieht und dann bist Du einige ms "blind". Einige kann dabei sogar Werte von bis zu 600ms (kein Schreibfehler - 0,6s) bedeuten. Jedenfalls waren das die größten Ausreißer, welche ich gemessen hatte.
    Nun könnte man meinen, daß eine höhere Scheduling-Prio das Problem löst. Tut sie aber nicht. Sie verschiebt das Problem nur dahingehend, daß die Probleme "unwahrscheinlicher" werden, sprich seltener auftreten. Gut, dann legen wir uns eben nicht schlafen und "verheizen" einen Core eines Pi2 (den wir uns dann gönnen) und pollen so schnell wir eben können. Das nimmt der Scheduler jedoch auch übel. Wird sched_rt_runtime_us nämlich überschritten, dann gibt's eine Zwangspause für hochpriore RT Threads und die niedrigen kommen für die Dauer von sched_rt_period_us dran. Und wiederum ist's Essig. Der Grund für dieses zunächst unerwartete Verhalten ist recht einfach. Bei nicht-RT Systemen unterstellt man, daß die Bedienbarkeit unter Last eben noch gegeben sein muß. Läuft ein unter RT scheduling policy laufender Thread amok, dann muß es noch möglich sein, eine Konsole zu öffnen und diesen zu killen. Das geht aber nur, wenn das Prioritätsprinzip in solch einem Fall bewußt "verletzt" wird.
    Um es vorweg zu nehmen - gegen das Ausplanen kannst Du nichts machen ohne einen echten RT-Kernel als Basis zu haben. Was Du hingegen machen kannst ist, Du kannst feststellen, daß Du in ein Problem des unfreiwilligen "ausgeplant-werdens" hineingefallen bist und dann die Messung verwerfen. Im nächsten Umlauf bestimmst Du Dir dann wieder einen Triggerpunkt und fängst von vorn an.
    Das ganze habe ich praktisch beim messen der Drehzahl einer Turbine hinter mir. Hier mußte der Generator dem Stromnetz bei einer genauen Drehzahl zugeschaltet werden, damit die Phasenlage bei Einkopplung nicht allzulange asynchron läuft. Hier ist (ganz unten) etwas über die Turbine nachzulesen.
    Kurz vor Fertigstellung der Lösung hatte ich meine Zwischenergebnisse inklusive der Meßreihen zusammengefaßt, um mir selbst klarer darüber zu werden, worin die verbliebenen Probleme wohl lägen. Die Meßreihen kannst Du hier einsehen. Zur Simulation der Turbine diente mir eine Bohrmaschine welche einen Magnet über einem Hallsensor drehte. Die Pulsbreite lag bei ungefähr 3ms (steht aber auch im Dokument). Gemessen hatte ich per MCP3208 (also analog), da meine Elektronik einen Tiefpaß besitzt, der mir die doch erheblichen Störimpulse des 30kW Generators wegfiltert. Andernfalls hätte ich u.U. "Funken" gezählt. Zudem ist der SPI-Bus auch schneller, als der alternative MCP23017 (I2C).

    b.) Hier ist der zeitliche Anspruch an den Raspi erheblich niedriger. Die Probleme sind jedoch immer noch die gleichen (nur eben unwahrscheinlicher als unter a.)). Allerdings handelst Du Dir bei diesem Ansatz ein, daß Du u.U. recht lange benötigst, um dann eine gemittelte Drehzahl zu bekommen. Von besonderem Übel sind hier die langsamen Drehzahlen.

    Die sauberste Lösung für dieses Problem ist m.E. die einer echten HW-Messung, wie sie BarnyFeuerstein beschreibt. Die SW-Lösung mag taugen oder auch nicht. Das kommt auf Deinen Einsatzzweck an und wieviel Gehirnschmalz Du in den Algorithmus steckst. Anstelle herauszufinden, ob Du vom Scheduler in's Koma befördert wurdest und dann den Meßwert zu verwerfen, könntest Du ihn auch in einen Medianfilter laufen lassen und diesen die "Filterung" vornehmen lassen. Sauber oder resourcenschonend ist das nicht - nur einfach. Einen Median ermittelt man eben nicht in O(n)...

    So, ich hoffe, ich konnte Dich ein wenig für die zu erwartenden Probleme sensibilisieren, ohne gleich entmutigend zu wirken... ;)

    Schöne Grüße

    schnasseldag

  • wow ... unser schnasseldag :thumbs1:

    Ich hätte da vielleicht auch etwas, um die Laufzeit-Problematik (Latenz-Zeiten) zu minimieren ...
    der -> EMLID-RTOS Kernel <- (den gibts auch als Komplett-Image ... dazu steht was im letzten Teil des Beitrags).

    cu,
    -ds-


  • Ich hätte da vielleicht auch etwas, um die Laufzeit-Problematik (Latenz-Zeiten) zu minimieren ...
    der -> EMLID-RTOS Kernel <- (den gibts auch als Komplett-Image ... dazu steht was im letzten Teil des Beitrags).


    dreamshader: Hat Dir schon mal jemand gesagt, daß Du ein ganz übler Bursche bist? :)
    Ich hatte Deinen verlinkten Beitrag schon vor einiger Zeit gelesen und mir gedacht, Menschenskinder, das auszuprobieren macht doch viel mehr Spaß, als Fenster und Türen tauschen, Wasserrohre im Haus verlegen und sonst aller Krimskrams, den ein Altbau halt so fordert. Damals war ich standhaft und mein Haus hat mittlerweile neue Fenster, Türen usw.
    Und nun kommst Du schon wieder mit dieser "Droge" daher, .... und ich kann nicht in's Bett, weil mein erster Kernel nun builded :)
    Ich kann doch schlecht die arme Seele so mutterseelenallein um 3Uhrsonstnochwas das Licht der Welt erblicken lassen und ich bin im Bett - oder?
    Mal sehen, was so dabei rauskommt... Das Ganze ist erst mal ohne configures und patches - man fängt halt mal vorsichtig an...

    Den Emlid Kernel hab' ich auch mal kurz angetestet mit einem Pi2. Gemäß Deinem Script kamen die folgenden Latenzen raus:
    # Total: 000846412
    # Min Latencies: 00011
    # Avg Latencies: 00026
    # Max Latencies: 00108
    Das entsprich auch ungefähr Deinen Messungen.

    Mittels dieses Kernels eröffnen sich tatsächlich neue Wege, Code unter verschiedenen Ansätzen zu entwickeln. Aber mal eine Frage, weißt Du, ob ich insbesondere für die Synchronisationsobjekte nicht andere Header benötige? Die Jungs und Mädels vom Linuxkernel werden ja wohl nicht ein anderes Laufzeitverhalten in die gleichen Synchronisationsobjekte gesteckt haben - oder? Es gibt zwar für beides sein Für und Wider... Mir fehlt's da noch mächtig an Wissen. Da muß Mr. Google wohl noch viel nachliefern.

    Und um die Antwort zu geben, wieso ich diesmal nicht standhaft bin - ich hatte im Urlaub noch Experimente mit einem 433MHz-Modul gemacht und dank http://www.maltepoeggel.de/data/usbfunk/sc5262.pdf und https://forum-raspberrypi.de/Funksteckdosen.htm das Protokoll der Intertechno-Funksteckdosen auf einem GPIO bitbanged. Irgendwo las ich, daß man das zu sendende Wort 2xwiederholen muß, damit die angesprochene Steckdose den Wert übernimmt. Experimentell stelle ich jedoch die Notwendigkeit einer 3-maligen Wiederholung fest. Zwar ist der Empfänger der Steckdose ziemlich "bitlängentolerant" (Bitzyklen von 270-500µs) werden akzeptiert, jedoch würde ich das Ganzen doch noch mal gern unter einem echten RT-Kernel ausprobieren. Auch, wenn es vielleicht nur dazu dient, die eigenen Messungen und Vermutungen zu bestätigen und ich mir nicht wirklich andere Ergebnisse verspreche.


    Hab' noch mal vielen Dank Für Deinen verlinkten Beitrag! Zumindest hab' ich meine "Hemmungen" verloren, mal den einen oder anderen Abstecher vom "Mainstream" Kernel zu machen und sei es nur deshalb, um meinen Code mal unter verschiedenen Gesichtspunkten zu betrachten.

  • Hallo Schnasseldag, hallo Dreamshader,

    psssst! Mit solchen Beiträgen auf diesem Niveau entwickelt sich das Forum vom Lagerraum für Nachmach-Tutorials zu einem Who-is-Who der RPi-Freaks!

    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

    Einmal editiert, zuletzt von Andreas (3. Oktober 2015 um 10:00)

  • @Andreas/Dreamshader: Ok, dann will ich mal klein und ganz leise weiterflüstern.
    Das Baby erblickte 2:47 Uhr (unserer Zeit) das Licht der Welt, heißt Jessie und hatte die folgenden Eckdaten:

    Linux raspberrypi 4.1.9-v7+ #1 SMP PREEMPT Sat Oct 3 00:47:01 UTC 2015 armv7l GNU/Linux
    # Total: 000108994
    # Min Latencies: 00011
    # Avg Latencies: 00031
    # Max Latencies: 00599

    Meinen Schnellschuß, den Kernel auf meiner Windowsmaschine (mit der ich ansonsten Cross-Compiliere) zu bauen, hab' ich mal ganz schnell wieder aufgegeben. Ein wenig schade, weil der Kernel schon ein Weilchen braucht, bis er mal fertig ist. Ich hab mir mal nen neuen RT-Patch für Jessie von https://www.kernel.org/pub/linux/kernel/projects/rt/4.1/ gezogen. Der Patch selbst lief erst mal durch. Derweil' gerade die neue RT-Schwester für Jessie builded, will ich mal diszipliniert an meine eigentliche Hasuarbeit gehen. :)
    Meine o. gestellte Frage zu den Symbolen hab' ich mir mittlerweile selbst beantwortet - es müssen die gleichen Symbole mit geändertem Verhalten sein. Man lernt eben täglich dazu - juchhu. :)

  • Hallöle,


    ... dreamshader: Hat Dir schon mal jemand gesagt, daß Du ein ganz übler Bursche bist? :)
    ...


    :thumbs1: ...


    ...
    Aber mal eine Frage, weißt Du, ob ich insbesondere für die Synchronisationsobjekte nicht andere Header benötige? ...
    ...


    also das glaub' ich ehrlich gesagt nicht - kann das aber nur vermuten. Da die Minimierung der Latenzzeiten praktisch ausschliesslich im Kernel stattfindet, dürften dafür keine Sonderlocken notwendig sein ...
    cu,
    -ds-

  • So, das hier wäre das (unerwünschte) Ergebnis mit gepatchtem Kernel:

    Linux raspberrypi 4.1.9-rt8-v7+ #1 SMP Sat Oct 3 12:56:41 UTC 2015 armv7l GNU/Linux
    # Total: 000106442
    # Min Latencies: 00011
    # Avg Latencies: 00037
    # Max Latencies: 01017
    # Histogram Overflows: 00085
    # Histogram Overflow at cycle number:
    # Thread 0: 01252 02059 02292 03303 06304 07308 08322 09326 11359 12361 16487 17348 17506 21708 22719 24760 25797 26850 27853 28918 30924 34970 36004 37053 38085 39123 40131 42186 43181 47285 51314

    dreamshader: Also der gleiche Murks, wie er auch bei Dir rauskam.

    Ich glaube zu wissen, woran das Problem liegt. Der Kernel muß nach dem Patchen noch konfiguriert werden (.config File editieren oder mit menueconfig machen). Sonst ist standardmäßig nämlich immer noch kein RT Scheduler ("Fully preemptable kernel (RT)" - Option) eingeschaltet. Auch das Power-Management muß stillgelegt werden, der Schedulertakt ggf. hochgedreht werden (hab' ihn mal auf 1kHz gestellt).

    Und dann gibt es noch eine ganz böse sowjetische Falle.
    make zImage modules dtbs
    erzeugt nämlich wieder ein neues Default .config File. Damit sind die ganzen lieben Config-Einstellungen dann wieder zum Teufel. Ich hab' jetzt nicht lange rumgesucht, sondern mein config-File ro gemacht. Der Build scheint dennoch zu laufen. Warten wir mal ab, was in 5 Stunden hinten rausgepurzelt kommt. Das wird dann aber auch mein letzter Versuch sein - mein schlechtes Gewissen wächst so langsam...
    Automatisch zusammengefügt:
    Nachtrag zum Thema Header.
    Es werden mit ziemlicher Sicherheit keine neuen Header benötigt. Ich hab' mal in den RT-Patch Code geschaut. Da werden Synchronisationsprimitive einfach gegen andere Primitive ausgetauscht. Es handelt sich dabei also nicht um diejenigen Synchronisationsobjekte, welche man aus dem POSIX Layer her kennt. Zudem müßte das cyclictest Programm ja dann in 2 Kompilaten vorliegen, um brauchbare Ergebnisse zu liefern. Das dem so nicht ist, zeigt die gleichzeitige Lauffähigkeit auf EMLID- und Standard-Kernel. Das hätte ich mir eigentlich auch denken können... :s

  • Hi,
    ja genau ... das mit dem Konfigurieren des Kernels hatte ich auch nicht gemacht. Das dürfte in der Tat für den "Murks" verantwortlich sein.
    Ich hab' halt dann das Image von denen genommen (obwohl die Rum-Experimentiererei wesentlich mehr Spass macht) ... das läuft perfekt :thumbs1;

    cu,
    -ds-

  • Hallöchen,

    sodele, das wäre vollbracht:
    Linux raspberrypi 4.1.9-rt8-v7+ #2 SMP PREEMPT RT Sat Oct 3 20:33:46 UTC 2015 armv7l GNU/Linux# Total: 000141607
    # Min Latencies: 00013
    # Avg Latencies: 00025
    # Max Latencies: 00103
    # Histogram Overflows: 00000
    # Histogram Overflow at cycle number:
    # Thread 0:

    ...und fertig ist der RT Kernel. Patchen allein hilft tatsächlich nicht. Anbei die Config-Einstellungen, welche ich vorgenommen habe.

    Config-Einstellungen per ~/linux/make menuconfig:
    - Kernel Features/Preemption model (Fully Preemptible Kernel (RT)) // Das ist vermutlich die wichtigste Einstellung.
    - Kernel Features/Timer frequency -> 1000Hz // Vermutlich besser geeignet im RT-Geschäft, als kleinere Werte (https://lwn.net/Articles/145973/).
    - CPU Power management/CPU frequency scaling/Default CPUFreq governor (performance)
    // Darin lediglich "performance governor" und "userspace governor" angewählt, alle anderen abgeschaltet (https://www.kernel.org/doc/Documentat…q/governors.txt)

    Um nun ein "seriöses" RT-Image zur Verfügung zu stellen, müßte man jetzt eigentlich die ganzen Config-Settings durchackern. Für den Hausgebrauch zum Softwaretest reicht's mir aber auch so. Es ist schon interessant, an was man so alles beim Konfigurieren rumfummeln kann. Der Neugierige möge mal einen Blick reinwerfen - da kann man stundenlang Zeit verblasen :)

    Guats Nächtle

    schnasseldag


  • Und dann gibt es noch eine ganz böse sowjetische Falle.
    make zImage modules dtbs
    erzeugt nämlich wieder ein neues Default .config File.

    Hier muß ich mich revidieren!

    Das (z.B. durch 'make bcm2709_defconfig' erstellte) '~/linux/.config file' wird nicht mehr von 'make zImage modules dtbs' verändert. Make erstellt lediglich daraus das '~/linux/include/config/auto.conf' file, welches dann im Buildprozess als weitere Quelle dient.

    Ich baue mir übrigens noch mal einen Kernel - diesmal jedoch ohne jedwedes Powermanagement. Sicher ist erst mal sicher...

  • Moin! Das kompilieren ist ja nicht jedermanns Sache. Wenn Ihr ein allgemeines fertig habt könnten wir das als Image auf unserer Seite zum freien Download anbieten? Wir habe uns ehrlich gesagt nur kurz mit dem fertigen Image von Emlid beschäftigt, aber unsere Zeit ist einfach zu knapp, um uns wirklich mit allem ausbiebig zu beschäftigen.

  • Hallöchen noch mal.

    ich wollte das Thema der Latenzmessung noch zum Abschluß bringen, wenngleich die Meßreihen nur begrenzte Aussagefähigkeit besitzen. Ursache ist hierbei vermutlich der Umstand, daß der Kernelsource nicht 100%ig zu dem verwendeten RT-Patch paßt. Zwar ergaben die Patches entweder keine Fehler oder nur "Hunk succeeded", jedoch ist eben ein erfolgreicher Hunk immer noch ein Hunk =(

    Dennoch sind die Messungen nicht uninteressant:

    4.1.10-rt8-v7+ (inkl. patch-4.1.7-rt8.patch) Scheduler Modell: "No forced preemption (Server)"
    # Total: 008735268
    # Min Latencies: 00010
    # Avg Latencies: 00056
    # Max Latencies: 05174

    4.1.10-rt8-v7+ (inkl. patch-4.1.7-rt8.patch) Scheduler Modell: "Voluntary Kernel preemption (Desktop)"
    # Total: 001826714
    # Min Latencies: 00011
    # Avg Latencies: 00047
    # Max Latencies: 01312

    4.1.10-rt8-v7+ (inkl. patch-4.1.7-rt8.patch) Scheduler Modell: "Preemptible Kernel (Basic RT)"
    # Min Latencies: 00008
    # Avg Latencies: 00041
    # Max Latencies: 01466 <- unerwartet im Hinblick auf das Ergebnis von "Voluntary Kernel preemption (Desktop)"
    dieses Kompilat friert nach wenigen Minuten hoher CPU-Last ein

    4.1.10-rt8-v7+ (inkl. patch-4.1.7-rt8.patch) Scheduler Modell: "Fully preemptible Kernel (RT)"
    dieses Kompilat friert nach wenigen Sekunden hoher CPU-Last ein daher anbei nochmals der Meßwert vom Kernel 4.1.9
    Linux raspberrypi 4.1.9-rt8-v7+ #2 SMP PREEMPT RT Sat Oct 3 20:33:46 UTC 2015 armv7l GNU/Linux
    # Min Latencies: 00013
    # Avg Latencies: 00025
    # Max Latencies: 00103

    1. Man erkennt deutlich, daß die Servervariante hinsichtlich der maximalen Latenz erheblich größere Zeiten mit sich bringt, als die nächste Stufe - die des "Voluntary Kernel preemption (Desktop)".
    2. Unerwartet ist das Latenzverhalten des "Preemptible Kernel (Basic RT)" und zwar in doppelter Hinsicht. Zum einen liegt der Latenzwert um mehr um den Faktor 10 schlechter, als der des "Fully preemptible Kernel (RT)", zum anderen suggeriert es zwar ein besseres Latenzverhalten, als der "Voluntary Kernel preemption (Desktop)" - was aber auch nicht stimmt.
    3. Der "Fully preemptible Kernel (RT)" scheint Voraussetzung zu sein, will man App's mit härterem Echtzeitverhalten implementieren.
    4. Stellt sich die Frage, wie man einen stabilen Kernel baut und diesen anschließend testet? Ob es hinreichend ist, den richtigen Patchstand zum richtigen Source zu haben, vermag ich leider nicht zu sagen, da ich für Jessi keine passenden RT-Patches zu den entsprechenden Git-Tags des Kernel Source fand. Bei Wheezy sieht das besser aus, jedoch habe ich das nicht mehr getestet.

    Wenn ich mir die Sache recht betrachte, dann steht man sich als Anwender vermutlich besser, auf einen "kommerziellen" Kernel auszuweichen, wenn das Projekt im Vordergrund steht und nicht der Erkundungsdrang, wie in meinem Fall. Oder aber, man beut sich den Kernel selbst, kennt die Schrauben an denen man gedreht hat und ist sensibilisiert, wenn die eigene App absonderliches Zeitverhalten zeigt.

    raspiprojekt: Ich finde es toll, wenn sich Leute wie Du so engagieren und sogar bereit erklären Ihre Infrastruktur bereitzustellen, um der Gemeinde zu helfen. Allerdings glaube ich nicht, daß man der Gemeinde mit "aus der Hüfte compilierten" Kernels wirklich einen guten Dienst erweist. Ich glaube, daß lassen wir mal besser :) Trotzdem noch mal vielen Dank.

    Schöne Grüße

    schnasseldag

    PS: Noch mal vielen Dank auch an dreamshader für die gute Vorarbeit und die "Infektion"! :thumbs1:


  • Es soll die Drehzahl einer Welle gemessen werden. Eine Lichtschranke ist vorhanden und montiert, sie liefert 12 V. Das Tastverhältnis kann ich beliebig ändern. (Breiten oder schmalen Reflexstreiben auf die Welle aufbringen). Die Umdrehungszahl wird unter 4.000 Umin^-1 also deutlich unter 100 Hz liegen.
    ich werde über den Fortgang berichten.

    Dank an Euch alle für die Feedbacks, ich bin das Thema in soweit angegangen, als das ich das Zählen nun doch nicht dem Pi, sondern lieber einem DS2423 "4kbit 1-Wire RAM with Counter" überlasse, dieser wird vom Pi via 1-wire Bus ausgelesen. So habe ich das Problem fehlender Messwerte hoffentlich nicht. Am heimischen Schreibtisch funktioniert es schon.

  • ...ich bin das Thema in soweit angegangen, als das ich das Zählen nun doch nicht dem Pi, sondern lieber einem DS2423 "4kbit 1-Wire RAM with Counter" überlasse, dieser wird vom Pi via 1-wire Bus ausgelesen. So habe ich das Problem fehlender Messwerte hoffentlich nicht. Am heimischen Schreibtisch funktioniert es schon.

    Möchtest Du nun die Drehzahl oder aber die Anzahl der Umdrehungen messen? Darin kann - je nach Anwendung - ein kleiner aber feiner Unterschied bestehen.

    Falls Du zählsicher (also ohne Impulsverlust) die Anzahl der Umdrehungen jedoch ohne deren näherer zeitlicher Berücksichtigung der tatsächlich aktuellen Anzahl zum Zeitpunkt des Auslesens (also ohne Berücksichtigung des Jitters) erfassen willst, dann ist der Zähler eine gute Sache.
    Wenn Du die Drehzahl jedoch zeitnah (also ohne längere Integration der Impulse / Zeiteinheit) ermitteln willst, dann ist die Zwischenschaltung eines 1Wire-Busses der Sache extrem abträglich.

Jetzt mitmachen!

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