Hallo zusammen, ich messe mit einem Raspberry Pi eine Drehzahl indem ich Interrupts zähle und dann auf U/Min umrechne. Anbei ein beispielhafter Verlauf der Drehzahl (oben) und der Interrupts (unten). Das Problem ist, dass die Messwerte sehr stark zappeln. Ich glaube das kommt daher, dass man von einem sehr kurzen Zeitraum in dem man die Interrupts zählt (ca. 100-150 ms) auf eine Minute hochrechnet. Der Intervall muss aber kurz sein, da ich eine flüssige Anzeige möchte. Aber ein Interrupt mehr oder weniger macht dann in U/Min viel aus. Ich habe versucht das ganze mit einem Tiefpass zu glätten. Sowohl die Drehzahl selbst, als auch die Interrupts. Allerdings wird das Ganze viel zu träge bevor das Signal genug geglättet ist. Gibts da eine zielführendere Methode der Signalfilterung? Oder vielleicht überhaupt einen anderen Ansatz? Vielen Dank und schönen Abend noch!
Angehängte Dateien:
-
Drehzahlverlauf.PNG
130 KB
Simple moving average oder exponential moving average.
SP90 schrieb: > Anbei ein beispielhafter Verlauf der Drehzahl (oben) und der > Interrupts (unten). Jetzt fehlt nur noch eine vernünftige Zeitachse, um beurteilen zu können, wie die Dynamik der Daten in Relation zu deiner gewünschten Zeitauflösung steht. Was verwendest du als Interruptquelle? Und warum zählst du nur die Interrupts, statt jedem Interrupt einen Timestamp zuzuordnen?
Du musst Dir klar werden, warum die Messwerte zappeln. Ein Verlorener Interrupt geht gar nicht --> dann ist die Messung wertlos. Vermutlich musst Du Dich mit "Fehlerrechnung" bzw. "Auflösung" beschäftigen. Meist zappeln die Werte, weil die Auflösung der Messung (z.B. 1ms) und der Messjitter (z.B. Verzögerung des Interrupts) zu groß sind. Dass musst Du herausfinden/messen und Dir vergegenwärtigen (ausrechnen/aufmalen). (Was macht eine Einheit mehr oder weniger aus) (Der Mess-Jitter ist etwas anderes als Genauigkeit, da der Wert in der einen loop zu lang, in der nächsten dann vermutlich zu kurz wird) Glätten kannst Du erst dann und nur nachdem Du Dir klar wirst, was Du sehen willst und was nicht.
SP90 schrieb: > Gibts da eine zielführendere Methode der Signalfilterung? Kannst du akausale Filter verwenden oder muss der geglättete Wert für die Drehzahl live zur Verfügung stehen?
Ich könnte mir vorstellen daß der Interrupt-Jitter hier einiges ausmacht. Ein normales Linux ist halt kein Echtzeit-OS. Vorschlag: nimm einen Mikrocontroller, z.B. irgendeinen kleinen STM32 den Du grad zur Hand hast. Dort auch keine Interrupts nehmen, sondern 2 Timer. Der eine als Referenz, hochgezählt mit dem Takt des Mikrocontrollers (oder einem Teiler davon), der andere zählt immer bei Deinen Umdrehungspulsen eins hoch. Dann alle n Events des Referenzzählers den Umdrehungszähler auslesen und an den Raspi senden (z.B. per UART). Am besten Timer verwenden die in Hardware koppelbar sind, also der Referenzzähler löst das Auslesen des Pulszählers in der Hardware aus. Dann ist es taktgenau. Aber ob das wirklich nötig ist hängt von den zu messenden Frequenzen ab. Alternativ geht auch Input-Capture. Also der Zähler im Mikrocontroller zählt mit dem Takt des Controllers hoch. Immer wenn Dein Umdrehungs-Event kommt, wird der aktuelle Zählerstand in ein Register gespeichert. Jetzt kannst Du das Register per Interrupt auslesen oder per DMA in einen Puffer schreiben lassen. Das ist bei langsameren Events (im Verhältnis zur Controllerfrequenz) besser geeignet.
:
Bearbeitet durch User
SP90 schrieb: > ch glaube das kommt daher, dass man von > einem sehr kurzen Zeitraum in dem man die Interrupts zählt (ca. 100-150 > ms) auf eine Minute hochrechnet. Das denke ich auch. Wenn sich dein Hauptbereich der Interrupts in so einem Zeitintervall im Bereich 5 bis 10 abspielt, ist das einfach eine zu geringe Auflösung. Das wirst du mit Filterung nur sehr begrenzt kompensieren können. Die Frage ist, ob du mechanisch dafür sorgen kannst, dass nicht nur ein Interrupt pro Umdrehung ausgelöst wird.
Was für einen Sensor bzw. Messwertaufnehmer benutzt du denn? Wenn du einen Winkelsensor hast, ginge das ganze über Differenzieren des überstrichenen Winkels und Abtasten in festem Intervall eventuell besser. Wenn du bei interruptbasierter Auswertung und im Prinzip Zeitmessung bleibst, bringt's vielleicht ein Dezimationsfilter innerhalb des festen Zeitrasters? Die Erfassung geht ja prinzipbedingt schneller als die Anzeige und Weiterverarbeitung. mfg mf
SP90 schrieb: > Ich glaube das kommt daher, dass man von > einem sehr kurzen Zeitraum in dem man die Interrupts zählt (ca. 100-150 > ms) auf eine Minute hochrechnet Dann ist schon die Messung ungeeignet, da helfen Filter nicht mehr viel. In so einem Fall zählt man nicht Impulse, sondern misst den Abstand zwischen den Impulsen - also Periodendauer statt Frequqnz, das macht man auch bei Frequenzmessungen so. Die Periodendauer lässt sich praktisch beliebig genau messen, das hängt nur von der Hardware ab, während die Zählung von Perioden in einem festen Intervall prinzipiell beschränkt ist durch die Dauer des Intervalls und die Zahl der darin auftretenden Impulse, daran kann man nichts ändern ausser längere Intervalle zu nehmen. Georg
SP90 schrieb: > Ich glaube das kommt daher Das solltest du ändern und in Gewissheit umwandeln. > Das Problem ist, dass die Messwerte sehr stark zappeln. Welche Sensorik hast du denn? Was für Werte bekommst du, wenn sich die Geschwindigkeit nicht ändert? Und was sagt ein Oszilloskop zum Sensorsignal?
Gerd E. schrieb: > Ich könnte mir vorstellen daß der Interrupt-Jitter hier einiges > ausmacht. Ein normales Linux ist halt kein Echtzeit-OS. Genauso ist es. Der typische Linux Scheduler Takt sind 100Hz bei Static Systick. ( früher waren es 10Hz) Du hast also mindestens 10% Jitter bei deinem Zeitintervall, alleine durch die Scheduler Auflösung. Wenn dein Linux Dynticks macht wirds noch ekeliger. Von parallelen Interrupten (z.B. MMC) usw wollen wir gar nicht erst sprechen. Dann wurde oben schon die Anzahl der Ereignisse/Zeitfenster angesprochen. Die einfache Zählmethode steuert einen Fehler von 1/Anzahl Ereignisse bei. Besser wäre es daher die Zeitabstände zwischen n Interrupten (n darf durchaus auch 1 sein) zu messen und daraus dann die Drehzahl zu bestimmen. (Reziproke Frequenzmessung) Bei Python vermutlich der einfachste Weg einer der beiden folgenden: http://abyz.me.uk/rpi/pigpio/index.html http://abyz.me.uk/lg/py_lgpio.html Scheint so als ob der RPI keine Timer mit Capture Inputs hat, ergo eigentlich die falsche Platform dafür. Zumindest ist da wohl nichts dokumentiert, kann gar nicht glauben, dass der das nicht kann.
Hallo, und vielen Dank für die zahlreichen Antworten. Ich werd versuchen das genauer zu erklären bzw. drauf einzugehen. Mein Programm ist in C# programmiert und läuft als UWP auf Windows IoT am Raspberry. Ich verwende einen DispatcherTimer um die GUI zu refreshen. Der ist nicht allzu genau, muss er dazu aber auch nicht. Daher kommt mein Intervall von ca. 100-150 ms. Daher läuft eine (genaue bzw. genauere) Stopwatch. Diese misst die Zeit zwischen den Timer-Ticks und wird mit jedem Tick wieder auf Null gesetzt und gestartet. Aus dieser Zeit und den Interrupts wird die Drehzahl in U/Min berechnet. A. S. schrieb: > (Was macht eine Einheit mehr oder weniger aus) Ein Interrupt mehr oder weniger macht bei dem Intervall 200-300 U/Min aus. MaWin schrieb: > Simple moving average oder exponential moving average. Das werd ich auf jeden Fall mal ausprobieren Wolfgang schrieb: > Jetzt fehlt nur noch eine vernünftige Zeitachse, um beurteilen zu > können, wie die Dynamik der Daten in Relation zu deiner gewünschten > Zeitauflösung steht. Ja stimmt, die Zeit würde nicht schaden. Da aber der Intervall in etwa konstant ist würde sich die Achse nur als ganzes dehnen oder stauchen. Die Aufzeichnung war nur gedacht zur Bestimmung der Dämpfung des Tiefpassfilters. Werde ich noch ergänzen. Wolfgang schrieb: > Was verwendest du als Interruptquelle? Am Ende der Schaltung is ein Transistor BC547B. Wolfgang schrieb: > Kannst du akausale Filter verwenden oder muss der geglättete Wert für > die Drehzahl live zur Verfügung stehen? Ich brauch die Drehzahl möglichst in Echtzeit. Gerd E. schrieb: > Vorschlag: nimm einen Mikrocontroller, z.B. irgendeinen kleinen STM32 > den Du grad zur Hand hast. Dort auch keine Interrupts nehmen, sondern 2 > Timer. Der eine als Referenz, hochgezählt mit dem Takt des > Mikrocontrollers (oder einem Teiler davon), der andere zählt immer bei > Deinen Umdrehungspulsen eins hoch. Dann alle n Events des > Referenzzählers den Umdrehungszähler auslesen und an den Raspi senden > (z.B. per UART). War ursprünglich der Plan, den Arduino zu verwenden. Zusammen mit anderen Messdaten kommt der Wert über UART aber viel zu langsam (dürfte ein Windows Problem sein). Daher jetzt direkt am Raspi. Rolf M. schrieb: > SP90 schrieb: >> ch glaube das kommt daher, dass man von >> einem sehr kurzen Zeitraum in dem man die Interrupts zählt (ca. 100-150 >> ms) auf eine Minute hochrechnet. > > Das denke ich auch. Wenn sich dein Hauptbereich der Interrupts in so > einem Zeitintervall im Bereich 5 bis 10 abspielt, ist das einfach eine > zu geringe Auflösung. Das wirst du mit Filterung nur sehr begrenzt > kompensieren können. Die Frage ist, ob du mechanisch dafür sorgen > kannst, dass nicht nur ein Interrupt pro Umdrehung ausgelöst wird. Ja stimmt, die Auflösung ist zu gering. Ich bekomm aber Systembedingt nur zwei Interrupts pro Umdrehung. Georg schrieb: > SP90 schrieb: >> Ich glaube das kommt daher, dass man von >> einem sehr kurzen Zeitraum in dem man die Interrupts zählt (ca. 100-150 >> ms) auf eine Minute hochrechnet > > Dann ist schon die Messung ungeeignet, da helfen Filter nicht mehr viel. > In so einem Fall zählt man nicht Impulse, sondern misst den Abstand > zwischen den Impulsen - also Periodendauer statt Frequqnz, das macht man > auch bei Frequenzmessungen so. Die Periodendauer lässt sich praktisch > beliebig genau messen, das hängt nur von der Hardware ab, während die > Zählung von Perioden in einem festen Intervall prinzipiell beschränkt > ist durch die Dauer des Intervalls und die Zahl der darin auftretenden > Impulse, daran kann man nichts ändern ausser längere Intervalle zu > nehmen. > > Georg Das klingt sehr interessant. Da wären wir wieder beim Vorschlag von Wolfgang jedem Interrupt einen Timestamp zuzuordnen, oder? Bzw. bei der "reziproken Frequenzmessung"? Nur wie mach ich das programmtechnisch? Da müsst ich mit der Stopwatch die Zeit zwischen den Interrupts messen und hab dann die Zeit pro halber Umdrehung die ich dann wieder in U/min umrechnen kann. Lothar M. schrieb: >> Das Problem ist, dass die Messwerte sehr stark zappeln. > Welche Sensorik hast du denn? Was für Werte bekommst du, wenn sich die > Geschwindigkeit nicht ändert? Und was sagt ein Oszilloskop zum > Sensorsignal? Ein Transistor, der den Pegel zwischen GND und 3,3 V schaltet. Genau so schauts am Oszi auch aus, also das passt soweit. Auch bei konstanter Drehzahl hab ich das "gezapple". Und alles zum Thema Jitter übersteigt jetz mein Verständnis leider ein wenig. Vielen Dank und schöne Grüße!
SP90 schrieb: > Bzw. bei der > "reziproken Frequenzmessung"? Nur wie mach ich das programmtechnisch? Ich würde bei so einer Aufgabe einen Controller programmieren, wahrscheinlich mit einer Interruptroutine in Assembler, insofern kann ich dir mit Raspbi und C nicht viel weiterhelfen. Die Aussage mit der reziproken Frequenzmessung bleibt aber richtig, ergänzt um die Aussage dass der Raspbi zur Frequenzmessung weniger geeignet ist als so ziemlich jeder andere Microcontroller. Daher findet man auch wenig zum Thema, aber hier ist die letzte Antwort interessant: https://forum-raspberrypi.de/forum/thread/39413-frequenzmessung-mit-dem-raspberry-pi/ Ob der Raspbi eine Funktion hat zur Messung von Periodendauern, die nicht von Taskwechseln beeinträchtigt wird, weiss ich nicht, anscheinend nicht, sonst hätte das jemand erwähnt. Die meisten empfehlen einen anderen Controller oder einen eigenen kleinen Controller für die Frequenzmessung. Georg
SP90 schrieb: > Auch bei konstanter Drehzahl hab ich das "gezapple". Aber das würde ja dann zusammenpassen, ein bissel Versatz beim Scheduler, ein bissel Versatz bei dir und schon hast du ein "gezapple" bei den berechneten Werten (bei gleicher Drehzahl). Wahrscheinlich wird nicht jeder meiner Meinung sein, aber wie wäre es mit folgender Idee: Du nimmst dir nen kleinen µC der auf die Interrupts reagiert und die Berechnung durchführt. Diese Werte sendest du dann an dein Raspi und fertig.
Georg schrieb: > Die meisten empfehlen einen anderen Controller oder einen eigenen kleinen > Controller für die Frequenzmessung. Bei so seltenen Ereignissen kommt man mit einer Frequenzmessung nicht weiter. Es ist besser, den Zeitabstand der Pulse zu messen und die Frequenz daraus zu berechnen.
SP90 schrieb: > Und alles zum Thema Jitter übersteigt jetz mein Verständnis leider ein > wenig. Hausaufgabe für Dich: Du schreibst ein kleines Test-Progrämmchen, das z.B. für 20 Sekunden alle Interrupts sammelt. Bei jedem Interrupt liest Du Deinen (Mess-) Timer aus. Der Timer läuft ungestört durch. Du stoppst ihn nicht. Du merkst Dir also für jeden Interrupt den Zeitpunkt. D.h. Du sammelst eine Liste von Zeitstempeln. Dann misst Du für die gewünschte Zeit eine konstante Drehzahl. Diese Zeitstempel überführst Du nun in Dein gnuplot, Matlab, Python oder was auch immer Du benutzt. Dazu berechnest Du zu jedem Zeitstempel die Differenz zum vorherigen Zeitstempel (Delta). Du bekommst natürlich eine Differenz weniger, als Zeitstempel vorhanden sind. Nun plotest Du auf der X-Achse mit der Zeit, zu jedem Zeitstempel auf der Y-Achse das Delta (Differenz zum vorhergehenden Zeitstempel). Das was Du nun siehst, ist der Jitter. Wäre nett, wenn Du das hier auch postest.
Wolfgang schrieb: > Bei so seltenen Ereignissen kommt man mit einer Frequenzmessung nicht > weiter Was genau verstehst du an "reziproker Frequenzmessung" nicht? Georg
Faulenzer schrieb: > Nun plotest Du auf der X-Achse mit der Zeit, zu jedem Zeitstempel auf > der Y-Achse das Delta (Differenz zum vorhergehenden Zeitstempel). Ach Blödsinn. Einfach auf der X-Achse für alle Zeitstempel das Delta auf der Y-Achse plotten. Also nicht die X-Position eines Punktes aus dem Wert des Zeitstempels bestimmen, sondern aus seiner laufenden Nummer.
SP90 schrieb: > ich messe mit einem Raspberry Pi eine Drehzahl indem ich Interrupts > zähle und dann auf U/Min umrechne. Typisch macht man das nicht so. Man mißt die Zeit zwischen 2 Interrupts, d.h. die Periodendauer und rechnet sie in Drehzahl um. Viele Timer habe dafür einen extra Capture Mode, der den Timestamp unabhängig von der Softwarelaufzeit abspeichert. Bei höheren Drehzahlen kann man auch die Zeit für n Perioden messen.
SP90 schrieb: > Mein Programm ist in C# programmiert und läuft als UWP auf Windows IoT > am Raspberry. OMG. Hier kommen zu den Unwägbarkeiten des Task-Scheduling des OS (generelles Problem im Userspace) ja auch noch die Unwägbarkeiten des temporal extrem nichtdeterministischen Backends der Mono-Runtime hinzu. Dieses Konstrukt ist völlig unbrauchbar zur Erfassung von Messwerten im für dich relevanten Bereich zeitlicher Auflösung. Zumindest in dieser Form. Du musst entweder die eigentliche Messung auf externe Hardware auslagern oder irgendwas von der intern verfügbaren Hardware des Raspi (UART oder SPI) mit deterministischem Timing zweckentfremdet verwenden. Anders geht's nicht.
Georg schrieb: > Ich würde bei so einer Aufgabe einen Controller programmieren, > wahrscheinlich mit einer Interruptroutine in Assembler Wozu solche Künsteleien. Eigentlich fast jeder uC besitzt Timer, mit denen man per Input Capture den Zeitpunkt eines Impulses erfassen kann - ganz ohne Software. Danach hat man alle Zeit der Welt, um das Timerregister auszulesen. Man muss es nur rechtzeitig vor dem nächsten Impuls erledigt haben.
Wolfgang schrieb: > Wozu solche Künsteleien. Eigentlich fast jeder uC besitzt Timer, mit > denen man per Input Capture den Zeitpunkt eines Impulses erfassen kann - > ganz ohne Software. Ja, nur ist halt das Target des TO ein RaspBerry Pi. Und der hat sowas halt leider nicht. Zumindest ist es nicht "leicht benutzbar". Ich bin fast sicher, dass die Hardware das könnte. Aber davon ausgesperrt zu sein, ist halt das Los all derer, die irgendwelche Abstraktionen der Hardware benutzen, sei es im Kontext eines OS-Treibers oder irgendeines dubiosen "Framework"s auf dem Level unterhalb eine eines richtigen OS. Wer alles aus der Hardware herausholen will, muss BareMetal-Programmieren. Und wer dann auch noch alles aus der Software herausholen will, muss Assembler programmieren. Es geht bei diesen beiden Ansätzen natürlich jeweils "etwas" Komfort verloren...
Ein Zähler ic wie mos 4020 und daran einen billigen uC der einen externen Quarz hat und ms zählt. Dann einfach bei jeder Anfrage den ic auslesen und die Drehzahl ausrechnen und dann die Zähler zurück setzen.
Christian F. schrieb: > einen billigen uC Der braucht keinen externen Zähler, der kann das gut selber. Georg
Christian F. schrieb: > Dann einfach bei jeder Anfrage den ic > auslesen und die Drehzahl ausrechnen und dann die Zähler zurück setzen. Wozu den Zähler zurück setzen? Der ausgelesene Zählerstand ist bereits der Bezugszeitpunkt für die nächste Messperiode. Eine Subtraktion wird der auslesende uC doch wohl hin kriegen ;-)
Wolfgang schrieb: > Eine Subtraktion wird der auslesende uC doch wohl hin kriegen ;-) Hast recht. Wobei der irgendwann überläuft. Georg schrieb: > Der braucht keinen externen Zähler, der kann das gut selber. Der externe Zähler hat den Vorteil dass der nie unterbrochen wird und von Vorgängen im uC nicht abhängig ist.
Angehängte Dateien:
-
Drehzahlverlauf2.PNG
91 KB -
Drehzahlverlauf2.PNG
91 KB
Hallo Leute, ich hab jetzt mal die Software umgeschrieben und das Ergebnis schaut schon mal gut aus :) Vorher hatte ich in der Interrupt-Methode ja nur einen Zähler hochgezählt. Die Stopwatch lief im Timer der GUI. Die hat eigentlich nur die Zeit der Timer-Ticks gestoppt, in denen die gezählten Interrupts ausgeweret wurden. Jetz konnte es aber sein, dass während eines Ticks genau 5 Interrupts gezählt wurden oder mann schon kurz vorm sechsten war. In beiden Fällen aber immer nur 5 Interrupts, aber mit unerschiedlichen Zeiten. Das war der Fehler. So hat man quasi bis fast einem Interrupt unterschied und das war genau das gezapple um die ca. 200 U/min. Jetzt läuft die Stopwatch in der Interrupt-Methode und wird mit jedem Interrupt neu gestartet. Also die Dauer seit dem letzten Interrupt wird gemessen und aufsummiert wie die Interrupts selbst. Das Ergebnis hab ich angefügt. Mit einem leichten Tiefpass schaut das schon mal gut aus, obwohl ich noch weitere Test machen muss. Bei den Interrupts scheint es manchmal ausreßende Spitzen zu geben, aber das muss von der Hardware kommen. Sicherlich stimmt das was ihr über die Fähigkeiten der Hardware und des Betriebssystems schreibt, aber erstmal scheint die Messung genau genug. Ich werd mich aber doch noch mit den anderen Filtern beschäftigen. Die sind durchaus interessant können auch nochmal nützlich sein... LG
Ich musste oft stark streuende Sensordaten auswerten und die dahinter liegenden Zusammenhänge herausfinden. "Fertige" Filterlösungen haben den Nachteil, dass sie zwar universell anwendbar sind, aber selten zu der aktuellen Aufgabe passen. Als erster Ansatz hat sich bei mir folgende Vorgehensweise bewährt: Ich habe die Messwerte in eine Excel-Tabelle geladen. Dann habe ich den Mittelwert der Messwerte gebilet. Weil aber schon ein stark verfälschter Messwert den Mittelwert verschiebt, habe ich dann die Streubreite der Messwerte berechnen lassen. Dann habe ich alle die Messwerte, die mehr als die Streubreite vom Mittelwert entfernt waren, unberücksichtigt gelassen und den Mittelwert der restlichen Messwerte gebildet. Mit dem Unterschied zwischen den beiden Mittelwerten und der Information, wie die Messwerte, die für den zweiten Mittelwert unberücksichtigt blieben, habe ich dann das weitere Vorgehen überlegt. Interessant ist beispielsweise, ob die unberücksichtigen Messwerte verstreut lagen, oder ob sie dicht beieinander lagen. Dann war es nämlich keine Messunsicherheit, sondern die Abweichung musste einen Grund haben, der irgendwann auftrat und danach wieder verschwunden ist. Kein Tool kann eigenes Denken und Verständnis ersetzen.
SP90 schrieb: > Bei den Interrupts scheint es > manchmal ausreßende Spitzen zu geben Klar, weil der Rasbpi bzw. sein Betriebssystem ja nicht echtzeitfähig ist. Da müsste man nicht einfach filtern, sondern intelligent klassifizieren, wenn wie zu vermuten die meistem Messungen eng beieinander liegen und einzelne weit davon weg, weil das System dazwischen spuckt. Da könnte z.B. eine 3Sigma-Filterung helfen, die weit abweichende Werte eliminiert. Georg
Georg schrieb: > Klar, weil der Rasbpi bzw. sein Betriebssystem ja nicht echtzeitfähig > ist. Da müsste man nicht einfach filtern, sondern intelligent > klassifizieren, wenn wie zu vermuten die meistem Messungen eng > beieinander liegen und einzelne weit davon weg, weil das System > dazwischen spuckt. Da könnte z.B. eine 3Sigma-Filterung helfen, die weit > abweichende Werte eliminiert. Genau so etwas habe ich ja vorgeschlagen, aber nicht einfach nur nach 3 Sigma oder so gefiltert, sondern die Filterung angepasst und vorher einzelne "Ausreißer" herausgenommen, da diese die Filterungsergebnisse schlechter machen. Die Streubreite ist übrigens ein "Gütekriterium". Wenn man an der Abtastung Änderungen vornimmt, kann man an der Streubreite deren Wirksamkeit beurteilen. Und durch Anpassung des Schwellenwertes (Abweichung der einzelnen Messwerte vom ersten groben Mittelwert) kann man die Vorsiebung schwächer oder stärker machen - je nach Bedarf.
SP90 schrieb: > Also die Dauer seit dem letzten Interrupt wird gemessen und aufsummiert > wie die Interrupts selbst. Das Ergebnis hab ich angefügt. Mit einem > leichten Tiefpass schaut das schon mal gut aus, obwohl ich noch weitere > Test machen muss. Bei den Interrupts scheint es manchmal ausreßende > Spitzen zu geben, aber das muss von der Hardware kommen. Läuft da denn ein RT-PREEMPT-Kernel? Damit wird das wesentlich stabiler, und die Ausreißer sollten verschwinden. Sieh dir mal die Diagramme unter https://elinux.org/images/d/d8/Rpi-rt-linux.pdf an. Christian F. schrieb: > Wolfgang schrieb: >> Eine Subtraktion wird der auslesende uC doch wohl hin kriegen ;-) > > Hast recht. Wobei der irgendwann überläuft. Das ändert am Ergebnis aber nichts. Es funktioniert trotzdem.
Rolf M. schrieb: > Läuft da denn ein RT-PREEMPT-Kernel? Das Prinzip, erstmal lesen was schon alles gesagt wurde, ist wohl aus der Mode, wie? Statt dessen einfach mal in der Gegend rumquaken...
Ich würde zunächst versuchen den Sensor und die Übertragung der Meßwerte zu verbessern. Eine konstante Drehzahl sollte auch solche liefern. Wie sieht der Sensor aus? Ist dieser überhaupt geeignet? Welche Maßnahmen wurden gesetzt um Störungen zu unterdrücken? Im nachhinein Signale zu verbessern ist schwieriger.
Einer schrieb: > Statt dessen einfach mal in der Gegend rumquaken... Dann lass es doch einfach bleiben. Warum sind hier in letzter Zeit eigentlich so viele Trolle unterwegs, die einfach nur andere beschimpfen, ohne selbst überhaupt irgendwas zur Diskussion beizutragen? Ist den Kids in der Ferienzeit so langweilig?
SP90 schrieb: > ich messe mit einem Raspberry Pi eine Drehzahl indem ich Interrupts > zähle Wie viele Interrupts müssen pro Sekunde gezählt werden?
Christian F. schrieb: > Hast recht. Wobei der irgendwann überläuft. > > Georg schrieb: >> Der braucht keinen externen Zähler, der kann das gut selber. > > Der externe Zähler hat den Vorteil dass der nie unterbrochen wird und > von Vorgängen im uC nicht abhängig ist. Das ist nicht böse gemeint: Ich nehme an, Du hast selber noch nie einen fortlaufenden Zähler verwendet. Das ist OK. Falls doch, solltest Du Deine Ansichten nochmal durchdenken, zur Not hier fragen.
SP90 schrieb: > Mein Programm ist in C# programmiert und läuft als UWP auf Windows IoT > am Raspberry. Rolf M. schrieb: > Warum sind hier in letzter Zeit eigentlich so viele Trolle unterwegs, > die einfach nur andere beschimpfen, ohne selbst überhaupt irgendwas zur > Diskussion beizutragen? Ist den Kids in der Ferienzeit so langweilig? Am 11.8. hat "SP90" klargestellt, dass er Windows auf dem RPi verwendet. Und Du kommst 4 Tage später mit dem Linux-Kernel an? Preis-Frage: Was nützt das "SP90" --> Gar nichts! Zweite Preis-Frage: Wer ist der Troll der neben seinen Stiefeln läuft? --> Du!
Einer schrieb: > SP90 schrieb: >> Mein Programm ist in C# programmiert und läuft als UWP auf Windows IoT >> am Raspberry. Ja, das hat er irgendwo dazwischen mal erwähnt, und ich hab nicht mehr daran gedacht, da ich > 4 Tage später auch nicht mehr die vollständige Diskussion im Kopf habe. Warum du deshalb so aggressiv auftrittst und beleidigend wirst - wohlgemerkt ohne dabei auch nur im entferntesten irgendwas zum Thema beigetragen zu haben, hast du nur leider nicht erklärt.
Rolf M. schrieb: > Warum du > deshalb so aggressiv auftrittst und beleidigend wirst Sorry. War ein hässlicher Zug von mir. Tut mir leid.
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.