Störsignale Drehzahlmessung filtern

[Konrad B. (kobrasoft)]

Hallo,

ich erhalte bei meiner Drehzahlmessung Störsignale. Diese Störsignale 
verursachen Fehlmessungen.
Als Drehzahlsensor dient ein LJ18A3-8-Z/BX. Die "Schaltnocken" an der 
Welle sind ausreichend hoch, eine Metallerkennung zwischen den Nocken 
möchte ich ausschließen. Der Drehzahlsensor hat eine eigene (exklusive) 
Spannungsversorgung und ist per Optokoppler (PC817) an die Steuerung 
(ESP Devkit V4) angebunden. Siehe beiliegendes Bild.
Ebenso habe ich ein Foto von meiner Oszi Messung angehängt. Diese Peaks 
sehe ich sowohl vor dem Optokoppler als auch danach. Ein Tausch des 
Drehzahlsensors brachte keine Änderung. Das Kabel zum Sensor ist ca 1m 
lang und ungeschirmt. Des weiteren hängt noch eine Waage (HX711) an der 
Steuerung dran, die aber tadellos funktioniert.

Wie kann ich diese Peaks verhindern oder ausfiltern?

[Michael B. (laberkopp)]

Konrad B. schrieb:
> Wie kann ich diese Peaks verhindern oder ausfiltern?

An der Quelle.

Dem Sensor.

Die Störsignale erfolgen dermassen regelmässig, dass es kein 
elektrisches sondern ein mechanisches Problem sein wird. Der Sensor wird 
getriggert.

[Gerd E. (robberknight)]

Was hängt denn da noch an der 12V-Stromversorgung von diesem Sensor mit 
dran? Ist da vielleicht ein Motor mit dran oder etwas anderes was solche 
Störungen erzeugen könnte?

[Konrad B. (kobrasoft)]

Michael B. schrieb:
> Die Störsignale erfolgen dermassen regelmässig, dass es kein
> elektrisches sondern ein mechanisches Problem sein wird. Der Sensor wird
> getriggert.

Nein die Störsignale sind nicht regelmäßig. Ich habe wohl nicht das 
optimale Bild ausgewählt. Hier ein anderes.

Ich habe den Sensorabstand variiert, die Breite der High und der Low 
Pegel veränderte sich, aber die Peaks blieben.

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Kannste auch im Programm filtern, indem du prüfst, ob die Länge des pos. 
Pulses eine Mindestlänge hat. Kürzer wird verworfen.

[Mi N. (msx)]

Konrad B. schrieb:
> Wie kann ich diese Peaks verhindern oder ausfiltern?

"Verhindern" läßt sich nicht beurteilen, da mußt Du selber suchen. Aber 
ein passender Kondensator am Eingang des Controllers beseitigt den 
kurzen Impuls hinreichend.

[N. M. (mani)]

12V Drehzahlmeldung lässt mich vermuten das ist im Auto.

Ist dem so?
Sag mal mehr zu der Applikation.

[Konrad B. (kobrasoft)]

Matthias S. schrieb:
> Kannste auch im Programm filtern, indem du prüfst, ob die Länge des pos.
> Pulses eine Mindestlänge hat. Kürzer wird verworfen.

Habe ich versucht:

  durationHigh = pulseIn(DrehzahlsensorPin, HIGH, 40000);
     mb.task();

  durationLow = pulseIn(DrehzahlsensorPin, LOW, 50000);
     mb.task();

  if (durationHigh > 10){
    samples.add(durationHigh + durationLow);        // nur gute Werte werden hinzugefügt
  }

Es filtert zwar die kurzen Peaks aus, da aber durch den Highpeak das 
Lowsignal geteilt wird (es werden die Flanken ausgewertet) sind die 
Lowsignale zu kurz.

[Konrad B. (kobrasoft)]

Mi N. schrieb:
> ein passender Kondensator am Eingang des Controllers beseitigt den
> kurzen Impuls hinreichend.

Werde ich versuchen. Ich vermute der Kerko soll zwischen Eingang und 
Masse. Siehe beiliegender Schaltplan.
Welche Größe könnte euren Erfahrungen nach passen?

[Konrad B. (kobrasoft)]

Gerd E. schrieb:
> Was hängt denn da noch an der 12V-Stromversorgung von diesem Sensor mit
> dran? Ist da vielleicht ein Motor mit dran oder etwas anderes was solche
> Störungen erzeugen könnte?

Nein das ist nichts mit dran, der Sensor wird exklusiv von einem 
Netzteil versorgt.

[Rainer W. (rawi)]

Konrad B. schrieb:
> Ich habe den Sensorabstand variiert, die Breite der High und der Low
> Pegel veränderte sich, aber die Peaks blieben.

In welchem Bereich bewegt sich die Breite der Störpeaks?

Konrad B. schrieb:
> Als Drehzahlsensor dient ein LJ18A3-8-Z/BX. Die "Schaltnocken" an der
> Welle sind ausreichend hoch, eine Metallerkennung zwischen den Nocken
> möchte ich ausschließen.

Warum verwendest du einen kapazitiven Sensor für Schaltnocken einer 
Welle und nicht einen Hall-Sensor? Aus welchem Material ist die Welle?
Wie ist die Versorgungsspannung vom Sensor abgeblockt? Sind die 
Störungen auch auf der Versorgung zu sehen?

[Mi N. (msx)]

Konrad B. schrieb:
> Welche Größe könnte euren Erfahrungen nach passen?

Auf Deinem Foto kann ich keine Informationen über Zeitbasis und 
Amplitude erkennen. 100 nF ist immer ein guter Wert ;-)
Alternativ kann man auch immer den längeren '1' Pegel durch mehrfache 
Abtastung auswerten. Aber bei der mickymouse-Programmiersprache kann man 
wohl keine Aussage zum realen Timing treffen.

Rainer W. schrieb:
> Warum verwendest du einen kapazitiven Sensor für Schaltnocken einer
> Welle und nicht einen Hall-Sensor?

Das ist doch wurscht!

[Konrad B. (kobrasoft)]

Mi N. schrieb:
> Auf Deinem Foto kann ich keine Informationen über Zeitbasis und
> Amplitude erkennen.
Die Amplitude ist ca 3 V. Ich vermute "M: 10ms" ist die Zeitbasis. Das 
Ergäbe eine Periodendauer von ca 30 ms. Es sind zwei Schaltnocken auf 
der Welle (wegen Vermeidung von Unwucht) das ergäbe eine Drehzahl von 
1000 rpm. Dies ist die Höchstdrehzahl der Maschine

> 100 nF ist immer ein guter Wert ;-)
Danke

[Konrad B. (kobrasoft)]

N. M. schrieb:
> 12V Drehzahlmeldung lässt mich vermuten das ist im Auto.
>
> Ist dem so?
> Sag mal mehr zu der Applikation.

Es handelt sich um eine fette Wirbelstrombremse deren Spulen mit einem 
150A IGBT angesteuert werden. Die Bremse kann einen Traktor mit 250 PS 
mühelos abwürgen. Die Spulen der Bremse wurden zum Zeitpunkt der 
Drehzahlmessung jedoch nicht angesteuert.

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Konrad B. schrieb:
> Habe ich versucht:  durationHigh = pulseIn(DrehzahlsensorPin, HIGH,
> 40000);
>      mb.task();
>   durationLow = pulseIn(DrehzahlsensorPin, LOW, 50000);
>      mb.task();
>   if (durationHigh > 10){
>     samples.add(durationHigh + durationLow);        // nur gute Werte
> werden hinzugefügt
>   }

Was ist das für eine Sprache?

Ich würde da einen Timer benutzen, wie bei der Abfrage eines Buttons.
https://www.mikrocontroller.net/articles/Entprellung

[Konrad B. (kobrasoft)]

> Was ist das für eine Sprache?
Ich habs mit der Arduino IDE 2.x geschrieben.
Die Funktion "pulseIn()" habe ich bei einem früheren Projekt schon 
benutzt und brachte die besten Ergebnisse. Dort hatte ich allerdings 
nicht mit diesen Peaks zu kämpfen
> Ich würde da einen Timer benutzen, wie bei der Abfrage eines Buttons.
> https://www.mikrocontroller.net/articles/Entprellung
Das habe ich soeben durchgelesen.

Für einen RC Entpreller bräuchte ich (wenn ich den Text richtig 
verstanden habe) noch einen zusätzlichen Widerstand. Die Werte müsste 
ich noch berechnen.

Zur Abfrage mit einem Timer habe ich folgendes gefunden:
https://github.com/khoih-prog/ESP32_New_TimerInterrupt/blob/main/examples/RPM_Measure/RPM_Measure.ino
Dort kann man einen DEBOUNCING_INTERVAL_MS einstellen. Auch dass muss 
ich mir noch genauer anschauen

[Veit D. (devil-elec)]

Hallo,

die Sprache nennt sich in Fachkreisen C++.

[Veit D. (devil-elec)]

Konrad B. schrieb:
> Habe ich versucht:
>

  durationHigh = pulseIn(DrehzahlsensorPin, HIGH, 40000);
>      mb.task();
> 
>   durationLow = pulseIn(DrehzahlsensorPin, LOW, 50000);
>      mb.task();
> 
>   if (durationHigh > 10){
>     samples.add(durationHigh + durationLow);        // nur gute Werte 
> werden hinzugefügt
>   }
>

> Es filtert zwar die kurzen Peaks aus, da aber durch den Highpeak das
> Lowsignal geteilt wird (es werden die Flanken ausgewertet) sind die
> Lowsignale zu kurz.

Du filterst doch falsche Werte raus. Wie können diese in die Auswertung 
gelangen?

[Rainer W. (rawi)]

Mi N. schrieb:
> Das ist doch wurscht!

Offensichtlich nicht - sonst würde es im Automobilbereich Hersteller 
geben, die kapazitive Sensoren für die Erfassung der Nockenwellendrehung 
einsetzen.

[Mi N. (msx)]

Rainer W. schrieb:
> Mi N. schrieb:
>> Das ist doch wurscht!
>
> Offensichtlich nicht - sonst würde es im Automobilbereich Hersteller
> geben, die kapazitive Sensoren für die Erfassung der Nockenwellendrehung
> einsetzen.

Lenk doch nicht vom Thema ab. Der TO hat diese Sensoren und sie liefern 
u.a. die benötigten Impulse.

Konrad B. schrieb:
> Für einen RC Entpreller bräuchte ich (wenn ich den Text richtig
> verstanden habe) noch einen zusätzlichen Widerstand. Die Werte müsste
> ich noch berechnen.

Du hast schon zwei Widerstände in der Schaltung; die sollten reichen.
Probieren reicht hier völlig aus und sollte längst passiert sein.

[Konrad B. (kobrasoft)]

Veit D. schrieb:
>> [/c]
>> Es filtert zwar die kurzen Peaks aus, da aber durch den Highpeak das
>> Lowsignal geteilt wird (es werden die Flanken ausgewertet) sind die
>> Lowsignale zu kurz.
>
> Du filterst doch falsche Werte raus. Wie können diese in die Auswertung
> gelangen?
Ich filtere nur die HighPeaks aus. Ich müsste aber den ganzen Zyklus 
(Bestehend aus Highsinal, dem Lowsignal bis zum Peak, den Highpeak 
selbst und den Rest des Lowsignals) verwerfen. Habe aber keine Idee, wie 
ich das Bewerkstelligen sollte.
Am Sinnvollsten wäre die Ursache zu beseitigen, da mir das aber nicht 
gelingt, werde ich versuchen die Peaks herauszufiltern.

[Jens G. (jensig)]

Konrad B. schrieb:
> selbst und den Rest des Lowsignals) verwerfen. Habe aber keine Idee, wie
> ich das Bewerkstelligen sollte.
> Am Sinnvollsten wäre die Ursache zu beseitigen, da mir das aber nicht
> gelingt, werde ich versuchen die Peaks herauszufiltern.

Dann nimm einen anderen Sensor, anstatt an den Symptomen herum zu 
doktor'n. Das wird doch hinten und vorne sonst nichts Gescheites.

[Konrad B. (kobrasoft)]

Mi N. schrieb:
> Du hast schon zwei Widerstände in der Schaltung; die sollten reichen.
> Probieren reicht hier völlig aus und sollte längst passiert sein.

Werde ich bald möglichst probieren. Das ist aber leider nicht so 
einfach:
1. Muß die Bremse aufgebaut und ein Traktor angeschlossen werden
2. Liege ich gerade im Krankenhaus, bekomme jetzt dann Abführmittel und 
habe morgen eine Magen und Darmspiegelung

[Chris S. (Firma: hier&da) (keiningenieur)]

Nun ich hätte die Last eher in den Kollektorkreis gelegt.

Hintergrund befindet sich die LAst im Emitterkreis muss die Basis auch 
deutlich höher mit Spannung angesteuert werden. Da das aber nur ein 
einfacher  Optokoppler ist wird das hier schwierig.

Befindet sich die Last hingegen im Kollektorkreis kann man interne 
Pullups nutzen und das Steuersignal an der Basis bleibt recht identisch 
mit 0,6-0,7V

[Konrad B. (kobrasoft)]

Jens G. schrieb:
> Dann nimm einen anderen Sensor, anstatt an den Symptomen herum zu
> doktor'n. Das wird doch hinten und vorne sonst nichts Gescheites.

Welcher Sensor ist was Gescheites?

[Jens G. (jensig)]

Chris S. schrieb:
> Nun ich hätte die Last eher in den Kollektorkreis gelegt.
>
> Hintergrund befindet sich die LAst im Emitterkreis muss die Basis auch
> deutlich höher mit Spannung angesteuert werden.

Einem Fototransistor ist das vollkommen wurscht, ob die Last in der C- 
oder E-Leitung liegt. Und für die nötige Basisspannung sorgt der 
Fotostrom ...

[Jens G. (jensig)]

Konrad B. schrieb:
> Welcher Sensor ist was Gescheites?

Weiß ich nicht. Aber offensichtlich ist Dein Fabrikat wohl nichts wert.
Die Dinger soll es ja auch von unterschiedlichen Herstellern geben (bei 
gleicher Bezeichnung). Da wäre es halt eine Idee, mal nach anderen 
Herstellern/Fabrikaten zu schauen.
Oder die mechanische/geometrische Anordnung der beteiligten Teile ist 
bei Dir möglicherweise arg ungünstig.

[Mi N. (msx)]

Konrad B. schrieb:
> 2. Liege ich gerade im Krankenhaus, bekomme jetzt dann Abführmittel und
> habe morgen eine Magen und Darmspiegelung

Es reicht, wenn Du das am Abend zuvor nimmst!

[Peter D. (peda)]

pulseIn() ist nicht für Drehzahlmessung geeignet und entprellt auch 
nicht.
Wie der Name schon sagt, mißt sie die Pulsdauer, Du aber willst die 
Periodendauer. Sie ist außerdem blockierend programmiert, d.h. die 
Ausführung bleibt für die Messung stehen oder rennt ins Timeout.

Du solltest erstmal anzeigen, wie lang die Störnadeln typisch sind, bei 
der gewählten Auflösung ist das nicht zu erkennen.
Und dann sagen oder anzeigen, in welchem Bereich (min/max) Du die 
Drehzahl messen willst. Dann kann man sinnvolle Filterregeln aufstellen.

Der 100nF kann richtig oder falsch sein, das kann man nicht erkennen. 
Eine Filterung in Software ist in jedem Fall besser, er ist also 
überflüssig.

[Mi N. (msx)]

Peter D. schrieb:
> Eine Filterung in Software ist in jedem Fall besser,

Banales Filtern? Autokorrelation ist angesagt!
Auf keinen Fall die Ursache mit 100 nF 'bekämpfen'. Das wäre viel zu 
einfach und würde göttliche Entprellroutinen deklassieren.

[Konrad B. (kobrasoft)]

Hallo,
das Projekt musste krankheitsbedingt eine Weile ruhen.

Ich habe mir das Signal primärseitg (vor dem Optokoppler) mit dem Oszi 
angesehen, siehe Oszi3.jpg. Das 0 Signal ist nicht stabil.

Vermutlich enthält der Näherungssensor nur einen (Feldeffekt?)Transistor 
der die Signalleitung auf Masse schaltet oder eben nicht. Ich habe 
deshalb einen zusätzlichen Widerstand (1 kOhm) eingebaut der das 0 
Signal auf 12V zieht. Einen 100 nF Kerko habe ich ihr auch spendiert, 
siehe schaltplan1.png.

Jetzt sieht das Signal besser aus (Oszi4.jpg)

[Michael B. (laberkopp)]

Konrad B. schrieb:
> Vermutlich enthält der Näherungssensor nur einen (Feldeffekt?)Transistor
> der die Signalleitung auf Masse schaltet oder eben nicht.

Natürlich.

> Ich habe
> deshalb einen zusätzlichen Widerstand (1 kOhm) eingebaut der das 0
> Signal auf 12V zieht. Einen 100 nF Kerko habe ich ihr auch spendiert,
> siehe schaltplan1.png.
> Jetzt sieht das Signal besser aus (Oszi4.jpg)

Ach.

Jens G. schrieb:
> Dann nimm einen anderen Sensor, anstatt an den Symptomen herum zu
> doktor'n.

Jens G. schrieb:
> Konrad B. schrieb:
>> Welcher Sensor ist was Gescheites?
>
> Weiß ich nicht. Aber offensichtlich ist Dein Fabrikat wohl nichts wert.

Oh Mann. Jetzt hast du ihm gegeben. Alle doof ausser dir.

Auch das zuvor gestörte Signal lässt sich mit minimalen Kenntnissen im 
Programmieren softwaretechnisch zuverlässig auswerten. Man muss halt 
programmieren können.

Nun, das saubere Signal, geht sogar bei naiver Programmierung.

[Jens G. (jensig)]

Michael B. schrieb:
> Oh Mann. Jetzt hast du ihm gegeben.

Und das stellst Du nach paar Wochen erst fest?

> Alle doof ausser dir.

Das ist Deine Interpretation.
Aber wenn ein Sensor solch komische Spikes liefert, dann würde ich solch 
einen Sensor oder die ganze Anordnung nun nicht unbedingt als 
zuverlässig betrachten, womit auch der versuchte Workaround nicht 
unbedingt zuverlässig sein könnte.

Konrad B. schrieb:
> Vermutlich enthält der Näherungssensor nur einen (Feldeffekt?)Transistor
> der die Signalleitung auf Masse schaltet oder eben nicht. Ich habe

Dann hätten wir saubere 0V ...

> deshalb einen zusätzlichen Widerstand (1 kOhm) eingebaut der das 0
> Signal auf 12V zieht.

???

Die IRED im OK würde übrigens lt. Schaltplan niemals leuchten, eher 
kaputt gehen ...

[Konrad B. (kobrasoft)]

> Die IRED im OK würde übrigens lt. Schaltplan niemals leuchten, eher
> kaputt gehen ...
Stimmt, ich habe im Schaltplan die Pins des PC817 vertauscht. Die reelle 
Schaltung funktioniert.

[Konrad B. (kobrasoft)]

Peter D. schrieb:
> pulseIn() ist nicht für Drehzahlmessung geeignet und entprellt auch
> nicht.
Richtig. Er liefert(e) zwar teilweise Schrottwerte, aber mein Sensor 
prellt nicht.
> Wie der Name schon sagt, mißt sie die Pulsdauer, Du aber willst die
> Periodendauer.
// Schlaumeiermodus on //

Die Summe der Pulsdauern einer Umdrehung ist doch der Kehrwert der 
Periodendauer der Umdrehung

// Schlaumeiermodus off //

> Sie ist außerdem blockierend programmiert, d.h. die
> Ausführung bleibt für die Messung stehen oder rennt ins Timeout.
*Das ist richtig. Deshalb habe ich das Programm umgeschrieben, siehe 
unten.*

> Und dann sagen oder anzeigen, in welchem Bereich (min/max) Du die
> Drehzahl messen willst. Dann kann man sinnvolle Filterregeln aufstellen.
>
> Der 100nF kann richtig oder falsch sein, das kann man nicht erkennen.
> Eine Filterung in Software ist in jedem Fall besser, er ist also
> überflüssig.
Der 100nF bleibt drin, schaden tut er bestimmt nicht.

Als Filter habe ich mich für RunningMedian entschieden.

Hier das (verkürzte) Programm (in Mickey Maus Sprache geschrieben :-)

#include <RunningMedian.h>
RunningMedian samples = RunningMedian(5);

unsigned long Nocken_time = 0;  
unsigned long last_Nocken_time = 0; 
unsigned long letzte_Nocken_time;
unsigned long rotation_time = 4294967295; 
unsigned long previousMillis = 0;
uint32_t rpm;            // rpm

byte zaehler = 0; 
const long interval = 1000; 
const byte Nocken = 2; 

void IRAM_ATTR isr() {
 
  zaehler ++;
  if (zaehler >= Nocken){                     // ganze Umdrehung erreicht?
  Nocken_time = micros();
  rotation_time = Nocken_time - last_Nocken_time;
  last_Nocken_time = Nocken_time;
  zaehler = 0;
   }
}

void setup() {
    Serial.begin(115200);
    pinMode(35, INPUT_PULLUP);
    attachInterrupt(35, isr, FALLING);
 
}

void loop() {

  // Serial.println(rotation_time);
    unsigned long currentMillis = millis();
  if (currentMillis - previousMillis >= interval) {
    previousMillis = currentMillis;
    samples.add(rotation_time);
     if (Nocken_time == letzte_Nocken_time) {  // hat der Interrupt ausgelöst?
      rpm = 0;
    } else {
      rpm = 60000000  / samples.getMedian();
    }
    Serial.println(rpm);
    letzte_Nocken_time = Nocken_time;
  }

}

[Michael B. (laberkopp)]

Jens G. schrieb:
> Und das stellst Du nach paar Wochen erst fest?

Er liefert jetzt halt den Beleg, dass dein Vorwurf, es läge am von ihm 
gewählten schlechten zu billigen  Sensor, falsch und unbegründet war, 
denn es lag am vergessenen pull up Widerstand.

Vorher konnte man auch schon ahnen dass dein Vorwurf völlig aus der Luft 
gegriffener Unsinn war, aber nun hat man halt den Beleg.

[Jens G. (jensig)]

Michael B. schrieb:
> denn es lag am vergessenen pull up Widerstand.

Ich sehe nur Workarounds, und keinen vergessenen R ...