Unruhige Anzeige bei Drehzahlmesser für Zweitaktmotor

[Searcher]

Hallo,

ich habe eine Motorsense und eine Motorsäge. Beide mit einem Zweitakt Benzinmotor angetrieben. Die sind schon in die Jahre gekommen und nach einem Membran- und Dichtungstausch im Vergaser möchte ich die nun wieder einstellen bzw Einstellung kontrollieren.

Das geht für den Leerlauf indem man mit der L Schraube auf maximale Drehzahl im Leerlauf einstellt und dann das Gemisch noch eine Idee fetter einstellt. Mit Standgasschraube die Drehzahl senken bis auskuppeln plus Sicherheitsabstand. Problem ist die Maximaldrehzahl bei Vollgas richtig einzustellen. Dazu bräuchte man eigentlich einen Drehzahlmesser. Die sind heute gar nicht mehr so teuer aber warum nicht selber bauen?

Im Mikrocontroller.net fand ich eine Schaltung zur einfachen Zündimpulsabnahme mit einem Draht vom Zündkabel: https://www.mikrocontroller.net/topic/81838#685809

Nachgebaut (27k an Pin 12 gegen 47k getauscht und um eine Zenerdiode an Pin 8 erweitert -> mein Meßbereich damit 1000Upm bis ca. 17000Upm - 2700min bis 13500max benötigt) und zur Berechnung der Drehzahl einen ATtiny2313 über einen 1k Widerstand an Pin 3 des (TC)4093 angschlossen. Es soll später noch eine Siebensegmentanzeige angeschlossen werden. In der Testphase sende ich die gemessene Drehzahl über RS232 an einen PC.

Funktioniert soweit ABER die gemessenen Werte schwanken doch relativ stark um den angepeilten einzustellenden Wert. Bei einer neuen Maschine, noch vom Werk eingestellt auf hoffentlich auf 2700Upm messe ich zB 2500 bis 3100Upm. Das ist mir deutlich zu unruhig und kann damit keine befriedigende Einstellung vornehmen.

Blauäugig hatte ich zunächst per ICP mit dem, mit 1MHz laufenden 16Bit Timer die Zeit zwischen den Zündimpulsen auf 1µs genau gemessen, Drehzahl auf eine Minute hochgerechnet (Upm=60000000/Meßwert in µs) und die zur Displayupdatezeit (jede 1/2 Sekunde) den gerade aktuellen Wert angezeigt: Sehr, sehr unruhige Anzeige

Nach ein paar Versuchen die angezeigte Drehzahl ruhiger zu bekommen, zB auch mit Zählung der Zündimpulse innerhalb einer feste Torzeit von zB einer Sekunde, bin ich nun bei folgender Lösung angelangt:
Displayupdate von etwas über einer Sekunde. Innerhalb dieser Sekunde werden die Zeiten zwischen den Zündimpulsen per ICP gemessen und aufaddiert. Mit der Anzahl der aufgetretenen ICP-Interrupts (Anzahl der Zünimpulse) wird dann der einfache Mittelwert ausgerechnet und zu Anzeige gebracht. Zu Beginn des nächsten Anzeigeintervalls sind alle Meßwerte gelöscht und es beginnt eine komplett neue Drehzahlmessung und Berechnung. Probeweise ist da noch eine SW-Hysterese aktiv, die eine veränderte Drehzahl von einer zur anderen Sekunde nur anzeigt, wenn sich der Wert um 10Upm gegenüber der vorherigen geändert hat.

Das Ganze ist mir aber immer noch zu unruhig. Nach vielen Versuchen mit der Abnahme des Zündimpulses würde ich ein Problem dort fast ausschließen. Timingfehler im Programm auch, da mit Frequenzgenerator überprüft und dort im Bereich von 1000Upm bis 16000Upm stabile Werte angezeigt werden. Die Motoren laufen im Leerlauf leicht unruhig (mit Oszi den Zündimpuls beobachtet) und mit der Messung über Sekundenintervalle auf Umdrehungen pro Minute umzurechnen erkläre ich mir die unruhige Anzeige des Drehzahlmessers.

So, Luftholen für die Fragen nach dem vielen Text:
Wie krieg ich eine ruhige aber doch aktuelle Anzeige für eine Vergasereinstellung hin? Wie wird das bei den professionellen Drehzahlmessern gemacht? Wird da einfach über einen größeren Zeitraum gemittelt und/oder Ausreißer ignoriert? Hat jemand konkrete Werte dazu?

Gruß
Searcher

gegenwärtiges Testprogramm:

$regfile = "ATtiny2313.DAT"
$framesize = 24
$swstack = 24
$hwstack = 34
$crystal = 8000000
$baud = 57600
$lib "mcsbyteint.lbx"

Dim Icr_new As Word
Dim Icr_old As Word
Dim Icr_difference As Word
Dim Upmd As Dword
Dim Upm As Word
Dim Tov_count As Byte
Dim Accumul_difference As Dword
Dim Averaged_ign_time As Dword
Dim Icp_events As Word
Dim Icp_alive As Byte
Dim Upm_o As Word                                           'Upm old
Dim Upm_h As Integer                                        'Upm Hysteresis

Print "Drehzahlmessung Upm"

Tccr1b = Bits(cs11 , Ices1)                                 'prescaler = 8, 1µs timer steps, icp event on rising edge

On Timer1 Update_display                                    'timer1 overflow
Enable Timer1

On Icp1 Get_icr                                             'ignition spark occured
Enable Icp1

Enable Interrupts

Do
Loop

Get_icr:
   Icr_new = Icr1
   Icr_difference = Icr_new - Icr_old
   Icr_old = Icr_new
   Accumul_difference = Accumul_difference + Icr_difference
   Incr Icp_events
   Icp_alive = 1
Return

Update_display:
  Incr Tov_count
  If Tov_count = 15 Then                                    '15 makes about 1s display interval
    Averaged_ign_time = Accumul_difference / Icp_events
    Upmd = 60000000 / Averaged_ign_time                     'Icr_difference
    Upm_h = Upmd - Upm_o
    If Abs(upm_h) > 10 Then                                 'SW-hysteresis
      Upm_o = Upmd
      If Icp_alive = 0 Then Upm_o = 0                         'no ignition detected -> Upm=0
      Print "     " ; Chr(13) ; Upm_o ; Chr(13);
    End If
    Accumul_difference = 0
    Tov_count = 0
    Icp_events = 0
    Icp_alive = 0
  End If
Return

[witkatz]

Ich stelle mal eine Vermutung an.
Kann es sein, dass sich die beiden Interruptroutinen für Timer1 und Icp1 gegenseitig stören? Das Get_icr muss für exakte Messung auch immer die selbe Latenzzeit haben und darf nicht auf irgendwelche Display-Updates mit und Drehzahlberechnungen warten müssen.

[Searcher]

Kann es sein, dass sich die beiden Interruptroutinen für Timer1 und Icp1 gegenseitig stören

Hallo,
danke fürs Anschauen. Daß sich die Interrupts in die Quere kommen würde ich ausschließen. Ich weiß, daß es verpönt ist, Print-Ausgaben in einer ISR zu machen da eine ISR so schnell wie möglich gemacht werden soll. Bin das Risiko aber kalkuliert eingegangen und kann das später noch korrigieren. Der Tiny hat wenig SRAM und beim Programmieren hatte ich zwischendurch OUT OF SRAM Probleme wegen zu vieler zu großer Variablen beim Print in der Hauptschleife. Ist halt noch ein Testprogramm.

Bei vielen AVR, hier beim ATtiny2313 gibt es ein eigenes 16Bit ICR Register (Input Capture Register). Dort wird bei Auftreten eines Pegelwechsels am ICP Pin der Timerstand des 16Bit TIMER1 hineinkopiert. Gleichzeitig wird ein Interruptflag für den ICP Interrupt gesetzt. Ob die ISR zum ICR Register sichern sofort oder etwas später ausgeführt wird ist egal, da der Timerwert im ICR vorerst sicher ist. Die ISR muß jedoch vor dem nächsten Input Capture Event durchgeführt werden, da das ICR dann überschrieben wird. Bei PICs gibt es vermutlich Ähnliches.

Ich habe gerade nochmal die "Update_display" ISR im Simulator laufen lassen. Braucht 0,18075ms (1446 Zyklen). Die angepeilte, maximal zu messenden Drehzahl von 16-, 17000Upm entspricht einer Capture Frequenz von 17000/60=ca. 284Hz. 284Hz haben eine Periodendauer von 1/284=ca.3,5ms. Bei der höchsten zu messenden Umdrehungszahl bleiben also noch 3,5ms minus 0,18075ms = reichlich Luft. Ich weiß nicht, ob der Simulator das Senden der Zeichen mit dem Print richtig berechnet. Wenn 12 Zeichen (5 Leerzeichen, max. 5 Ziffern des Meßwertes und die beiden CR) mit 57600 Baud gesendet werden dauert das ca. 2ms. Plus der 0,18075ms Rechenzeit bleiben bis zu den 3,5ms immer noch reichlich "Luft". Bei den Messungen im Leerlauf der Motorsäge bei um die 2700Upm (45Hz Capture Frequenz) also noch gar kein Thema falls ich nicht doch etwas übersehen habe. Mit Testfrequenzen über Generator gibt es in der Hinsicht auch kein Problem.

Gruß
Searcher

[wkrug]

Leg doch einfach mal an den Eingang deiner Schaltung einen Frequenzgenerator an.
Wenn dann die Verhältnisse stabil sind werden eventuell über deinen Abgriff aus der Zündspule Fehlimpulse mitgezählt.
Irgendwo müsste in deiner Schaltung wohl auch eine Art Schmitt Trigger zu finden sein.
Die Impulse dahinter sollten sauber und gleichmässig sein ( Bei konstanter Drehzahl ).

[Klebwax]

Im Mikrocontroller.net fand ich eine Schaltung zur einfachen Zündimpulsabnahme mit einem Draht vom Zündkabel: https://www.mikrocontroller.net/topic/81838#685809

Nachgebaut (27k an Pin 12 gegen 47k getauscht und um eine Zenerdiode an Pin 8 erweitert -> mein Meßbereich damit 1000Upm bis ca. 17000Upm - 2700min bis 13500max benötigt) und zur Berechnung der Drehzahl einen ATtiny2313 über einen 1k Widerstand an Pin 3 des (TC)4093 angschlossen. Es soll später noch eine Siebensegmentanzeige angeschlossen werden. In der Testphase sende ich die gemessene Drehzahl über RS232 an einen PC.

Mit der Schaltung hab ich so meine Probleme. Eigentlich kann sie nicht funktionieren, eine Spannung kann man nicht mit einem Anschluß Messen bzw. weiterverarbeiten. Man braucht immer zwei Anschlüsse. Eine Spannung ist per Definition eine Potentialdifferenz, es gehören also zwei Potentiale dazu. Die Masse der Schaltung müsste mit der Masse des Motors verbunden werden, so wie auch der andere Anschluß der Zündspule. In Praxis kann es natürlich durch kapazitive Kopplung der Massen trotzdem gehen. Zum Zweiten enthält sie ein Monoflop. Diese sind nicht umsonst in professionellen Schaltungen verpönt bis verboten, da sie notorische Störimpuls-Verstärker und Verlängerer sind. Aber auch das muß im Einzelfall keine Rolle spielen.

Die professionellen Zündimpulsabnehmer, die ich kenne (ist aber schon eine Weile her), arbeiten Induktiv. Dazu wird ein geschlossener Ferritkern um das Zündkabel gelegt, auf dem eine Abnehmerspule ist. Für den praktischen Betrieb ist das ein Klappkern in einer Zange. Das Ganze hat den Vorteil, daß der Ausgang galvanisch vom Motor getrennt und niederohmig ist. Auch kann man ein abgeschirmtes Kabel verwenden, seine Kapazität würde bei einem kapazitiven Abnehmer das Signal kurzschließen. Zum Ausprobieren kann man eine Entstördrossel auf einem Ringkern nehmen, durch den das Zündkabel passt.

Wenn das Signal bei deinem Aufnehmer bei allen Drehzahlen auf dem Scope sauber aussieht, vergiss meinen Text wieder, dann ist alles gut.

Funktioniert soweit ABER die gemessenen Werte schwanken doch relativ stark um den angepeilten einzustellenden Wert. Bei einer neuen Maschine, noch vom Werk eingestellt auf hoffentlich auf 2700Upm messe ich zB 2500 bis 3100Upm. Das ist mir deutlich zu unruhig und kann damit keine befriedigende Einstellung vornehmen.

Blauäugig hatte ich zunächst per ICP mit dem, mit 1MHz laufenden 16Bit Timer die Zeit zwischen den Zündimpulsen auf 1µs genau gemessen, Drehzahl auf eine Minute hochgerechnet (Upm=60000000/Meßwert in µs) und die zur Displayupdatezeit (jede 1/2 Sekunde) den gerade aktuellen Wert angezeigt: Sehr, sehr unruhige Anzeige

Nach ein paar Versuchen die angezeigte Drehzahl ruhiger zu bekommen, zB auch mit Zählung der Zündimpulse innerhalb einer feste Torzeit von zB einer Sekunde,

Das Signal ist für eine Torzeitmessung zu langsam. Die Einheit, um die es geht ist U/min. Um eine Auflösung von 10 Umdrehungen zu bekommen, muß man eine Torzeit von mindestens 1/10 Minute, also 6 Sekunden haben. In der Zeit kann sich aber die Drehzahl des Motors geändert haben, Es ist also prinzipiel keine stabile Anzeige möglich.

bin ich nun bei folgender Lösung angelangt:
Displayupdate von etwas über einer Sekunde. Innerhalb dieser Sekunde werden die Zeiten zwischen den Zündimpulsen per ICP gemessen und aufaddiert

Ich habe mal einen gebaut und das auch so gemacht. Ein kleines Problem dabei ist, daß der Timer ab und an mal überläuft. Das kann man bei der Bestimmung der Zeit berücksichtigen. Im ersten Versuch hab ich den Fall einfach ignoriert. Wenn also der aktuelle Timerwert kleiner als der vorige war, ein Überlauf aufgetreten ist, hab ich den Wert verworfen. Ich war zu faul mir zu Überlegen, wie das mit Überläufen mit unsigned Variablen (ich benutze C) so geht. Am Ende hab ich das nie korrigiert. Hier mal der Code (in C):

long Time = 1;
volatile int Tout;

void _ISR __attribute__((no_auto_psv)) _IC3Interrupt(void) {
    static long old_timer = 0;
    unsigned long new_timer;

    _IC3IF = 0;                     // das Interruptflag muß händisch gelöscht werden
    new_timer = IC3BUF;             // das Inputcapture Register
    if (new_timer > old_timer) {    // kein Überlauf
        Time = new_timer - old_timer;
    }
    if (Time <= 0) {    // Time nie 0 werden lassen
        Time = 1;
    }
    old_timer = new_timer;
    Tout = 0;
}

Bei meinem µC hab ich einen 32-Bit Timer, daher long Variable. Falls beim Weiterverarbeiten mal durch Time geteilt wird, vermeide ich den Wert 0, reine Paranoia. Zur Variable Tout sag ich später noch was.

Mit der Anzahl der aufgetretenen ICP-Interrupts (Anzahl der Zünimpulse) wird dann der einfache Mittelwert ausgerechnet und zu Anzeige gebracht. Zu Beginn des nächsten Anzeigeintervalls sind alle Meßwerte gelöscht und es beginnt eine komplett neue Drehzahlmessung und Berechnung.

Das ist eigentlich suboptimal. Man muß viele Messwerte speichern und die Anzeige wird langsam. Eigentlich braucht man einen Tiefpass auf die Messwerte, so wie es früher analoge Anzeigen inherent hatten. In Software lässt sich das leicht realisieren. Man nimmt einfach den letzten Messwert, addiert den aktuellen und teilt durch zwei. Das Ergebniss zeigt man an und merkt es sich als letzten Messwert. Das geht sehr schnell (eine Addition und teilen durch zwei) und benötigt nur eine Variable. Ich bin nicht so der große DSP Experte, das nennt sich wohl IIR-Filter. Wenn ich Messwerte im Interrupt bekomme, rechne ich das häufig gleich mit und entscheide später, ob ich mit dem Originalwert oder dem geglätteten weiterarbeite. Das mal so als Pseudocode (in meinem Drehzahlmesser hab ichs nicht gebraucht)

int Messwert;
int Geglättet;

void Messinterrupt()
    static AlterWert;

    Messwert = GetMesswer();
    Geglättet = (AlterWert + Messwert) / 2;
    AlterWert = Geglättet;
}

Ich hab das bei meinem Drehzahlmesser nicht gebaucht, daher ist das ohne Gewähr aus dem Kopf aufgeschrieben. Aber hier der Rest meines Drehzahlmessers.

int TachoMain(){
    Tout = 0;
    
    while (1) {
        Tout++;
        if (Tout > 50) {
            ShowValue(UNDEFINED, 0);  // keine Drehzahl messbar
            Time = 1;
        } else {
            ShowValue(INT, (int)(375300L / Time));
        }
        delay(50);
    }   
}

Gut, ShowValue() geht auf die Anzeige und ist hier nicht zu sehen, da beliebig HW-abhängig. Wenn lange kein Interrupt gekommen ist, läuft Tout hoch und zeigt, daß kein gültiger Messwer vorliegt. Als "undefined" zeige ich alle horizontalen Segmente, das kann man auch gut aus den Augenwinkel erkennen, wenn man gerade irgend etwas einstellt. Im Wert "375300L" stecken die CPU Clock und alle Prescaler. Den Wert müsste man ändern, wenn mehr als ein Puls pro Umdrehung kommt. Da der µC sonst nichts zu tun hat, hab ich einfach ein Delay von 50ms in die Mainloop gesetzt, Als Hardware benutze ich eine Reflexlichtschranke und weißes bzw. schwarzes Klebband.

Ich hoffe, ich konnte dir ein paar Anregungen geben.

MfG Klebwax

[Ceos]

Eine Sache, die ich bei dem beschriebenen Verfahren in den Kommentaren gesehen habe, war wohl dass bei niedriger Drehzahl logischerweise auch die Spannung sinkt und du eventuell Pulse verpasst!

Ein kleines Problem dabei ist, daß der Timer ab und an mal überläuft

hatte ich auch zuerst vermutet, aber er verwendet in seinem Code ja Datentypen die auf den Timer passen also unsigned int 16 und wenn ich 2 uint16 subtrahiere macht der überlauf garnichts aus, die differenz ist immer gleich und immer positiv, der Vorteil von uint halt

[Klebwax]

hatte ich auch zuerst vermutet, aber er verwendet in seinem Code ja Datentypen die auf den Timer passen also unsigned int 16 und wenn ich 2 uint16 subtrahiere macht der überlauf garnichts aus, die differenz ist immer gleich und immer positiv, der Vorteil von uint halt

Du wirst sicher recht haben. Aber mir gefällt es grundsätzlich nicht, daß ein Programm nur mit Sideeffects funktioniert. Das mag in Assenbler noch angehen, in anderen Sprachen gibt es unsigned gar nicht. Ich versuche alles so zu halten, daß ein int zwar mindestens 16 Bit hat, der Code aber auch funktioniert, wenn es mal 64 sind. Mir sind noch die Problem beim Übergang von 16-Bit auf 32-Bit Code in Erinnerung. "unsigned" heißt bei mir eigentlich immer, es ist das Abbild eines HW-Registers, und da ist die Anzahl der benutzten Bits fest im Silizium. 10/12/14 Bit ADCs kann man direkt in ein int16_t einlesen und weiterrechnen, obwohl sie nie negativ werden. Nur bei Timern, wie hier, werden häufig alle Bits genutzt.

Das sind aber meine persönlichen Vorlieben. Ich war hier einfach zu faul, das Ganze beim Überlauf mal durch den Debugger laufen zu lassen und alle Grenzwerte auszutesten. Wenn bei tausend Touren mal eine Umdrehung nicht gemessen wird, merkt man das in der Anzeige nicht und es ist halt so im Code geblieben.

MfG Klebwax

[wkrug]

Soweit Ich den Code verstanden habe benutzt er ja den ICP Interrupt für die Drehzahlmessung.
Das sollte im Prinzip auch gut funktionieren und auch relativ unabhängig vom Auslesezeitpunkt sein.
Ich vermute hier eher einen Fehler auf der Hardwareseite.
Es kommen da evtl. unerwünschte Impulse durch.
Bei so Magnetzündungen hab Ich auch schon mal einen unidirektionalen Hallsensor verbaut.
Der liefert ein sehr gutes Rechtecksignal?!

Die Mittelung der Werte kann man auch über einen Ringpuffer machen.

Ein Zeiger erhält den Wert 0...4 bei jedem neuen Messwert inkrementierend.
Jeder Messwert wird dann in das Array geschrieben, an den Platz auf den der Zeiger zeigt.
Bei der Auswertung werden dann alle 5 Werte zusammengezählt und durch 5 geteilt.

Nimmt man für das Array 2^n Werte gehts auch mit ner Schiebeoperation dann noch schneller.

[Searcher]

Also echt. Klebwachs. Und alle anderen. Ihr habt mir ja eine Menge Input gegeben. Das will erst mal verarbeitet werden. Vielen Dank.

Werde zunächst kurz die wichtigsten Fakten durchgeben:

- Die Schaltung zur Abnahme des Zündimpulses vom Zündkabel ist im Eröffnungspost verlinkt.
- Überlauf bei der Differenzbildung von zwei aufeinanderfolgenden Meßwerten aus dem ICR ist gewollt und von Ceos schon gut erklärt. Dort liegt das Problem nicht.
- @wkrug: Mittelung mit Array hatte ich mit 8 Werten schon ausprobiert. War mir noch zu unruhig.
- Frequenzgenerator hatte ich dran. Sinusgenerator an den 1µF aus dem verlinkten Schaltbild und GND Anzeige ist von 1020Upm bis 17000Upm (17Hz bis 283Hz) stabil.

Ich tendiere jetzt auch schon ein wenig auf die Unzuverlässigkeit der Signalgewinnung für den µC.
Oszi zeigte aber auch keine 100% stabile Zündfrequenz von der Maschine was aber auch normal ist. Die angezeigte große Abweichung von der mittleren Frequenz irritiert mich halt.

Ich werde euren Input in Ruhe durchgehen und schauen, daß ich ein paar Meßreihen und aussagekräftige Ozillogramme aufzeichne und hier zeigen. Leider hat mein Oszi keinen großen Speicher, so daß es nicht einfach ist, seltene Ausreißer festzuhalten.

@Klebwachs: Für Deinen Post muß ich mir nochmal extra Zeit nehmen.

Gruß
Searcher

- - - Aktualisiert - - -

PS: Noch zum Programm:

Es gibt zwei ISR. Die Hauptschleife (do Loop) ist leer.

Die "get_icr" wird aufgerufen, wenn am ICP-Pin eine steigende Flanke erkannt wird.
Innerhalb der ISR wird das ICR Register, in den der aktuelle Timer1 durch die Flanke gesichert wurde, ausgelesen und die Differenz zum vorherigen ICR-Wert gebildet. Die Differenz ist die Zeit in µs zwischen zwei Zündimpulsen. Die Zeiten werden in der ISR in Accumul_difference noch aufaddiert. In Icp_events werden noch die Anzahl der Zündimpulse gezählt. Wenn nach Einschalten des Drehzahlmessers der alte ICR-Wert noch Null ist, ist die erste Drehzahlanzeige falsch.


In der update_display, die ich einfach an den Timer1 angehangen habe, aber nur etwa einmal pro Sekunde wirklich was tun soll. Deshalb das "If Tov_count = 15 then" Hier werden dann die in "get_icr" gesammelten Werte für die Anzeige aufbereitet und über RS232 mit Print zum PC.
Sind in Accumul_difference zB 990000µs zusammengekommen und in icp_events 45events werden 990000/45=22000µs als mittlere Zeit zwischen zwei Zündungen ausgerechnet. Entspricht einer Frequenz von 1/0,022s = 45 Hz. Das auf eine Minute in der Variablen Upmd (d für Double Word - 4 Byte unsigned Variable) gerechnet: 60000000/22000 entspricht 2727Upm.

Sind 1000000µs bei 100 events zusammengekommen. 1000000/100=10000µs mittlerer Zündabstand, 60000000/10000=6000Upm

[Searcher]

Hallo,
ich habe mal ein paar Messungen gemacht. Zunächst die verwendete Schaltung, die den Zündimpuls für den µC aufbereitet. (Mittlerweile fand ich im MC net weitere Kritiken dazu, die auch gar nicht gut aussehen).

Bild hier  

Abblockkondensatoren sind am 4093er und ATtiny2313 vorhanden. Versorgungsspannung ist sauber.

Das Programm wurde nur dahingehend verändert, daß man vom PC Terminal die Messungen untereinander geschrieben werden und wurden von dort kopiert. SW Hysterese testet auf >-1 statt auf >10, so das von einer Sekunde zur anderen jede Änderung geschrieben wird. Außerdem wird am Anfang einer Zeile eine Meßsequenznummer ausgegeben und am Ende einer Zeile steht die Anzahl der Zündimpulsabstände, die innerhalb einer Sekunde addiert wurden und durch die dann zur Mittelwerterzeugung geteilt wurde. Zum Start einer Meßreihe wurde die Versorgungsspannung für den stromlosen Drehzahlmesser eingeschaltet.

Hier die Meßwerte mit dem Sinusgenerator (alter analoger Pegelsender von Siemens, ein W2040).
Anhang 45Hz_Sinus_1Min_lang_60Updates.txt
Anhang 283Hz_Sinus_1Min_lang_60Updates.txt

Und Oszillogramme:
45Hz_Sinus_Pin8.png, Kanal 1 - Generatorsignal wie in Schaltung an C3, Kanal 2 - von Pin 8 des CD4093
Bild hier  

45Hz_Sinus_µC.png, Kanal 1 - Generatorsignal wie in Schaltung, Kanal 2 - rechte Seite von R4
Bild hier  

283Hz_Sinus_Pin8.png
Bild hier  

283Hz_Sinus_µC.png
Bild hier  


Hier Messungen an einer Motorsäge im Leerlauf, die vom Werk auf 2700Upm eingestellt ist. Dazu muß man sagen, daß je nach Temperatur die Leerlaufdrehzahl anders ist. Abweichungen davon sind also normal. Ich wüßte nur zu gerne in welchem Maße die Drehzahl zB im Sekundentakt abweicht. Im Oszi erkennt man deutlich Abweichungen von einem Zündungsabstand zum anderen. Der Zündimpuls wurde einmal einadrig mit Krokoklemme am Zündkabel abgenommen und an C2=220pF angeschlossen. Bei den beiden anderen Meßreihen wurde der Draht mit 3 Windungen um das Zündkabel gelegt und mit C2=220pF und mit C2=1nF gemessen. (Meßreihe mit Kroko an 1nF ist verschwunden )

Anhang Kroko_220pF.txt
Anhang 3Wdg_220pF.txt
Anhang 3Wdg_1nF.txt

Die Oszillogramme zeigen Kanal 1 an Pin 8 vom CD4093, Kanal 2 an rechter Seite von R4, also das Signal daß zum µC geht. Kanal 1 ict AC gekoppelt. +5V Gleichspannungsanteil dazu rechnen.

Kroko_220pF.png
Bild hier  

Kroko_1nF.png
Bild hier  

3Wdg_220pF.png
Bild hier  

3Wdg_1nF.png
Bild hier  

Und noch das Zündabnahmedrahtsignal Kanal 1 (Kein Gleichstromanteil) direkt vor C2 und Kanal 2 nach R4.

raw.png
Bild hier  

Alles erstmal ohne Kommentar, da selbst noch nicht genauer analysiert. Jedoch sind die Schwankungen geringer als bei meinen ersten Versuchen - warum auch immer? Subjektiv funktioniert es mit Wicklung um das Zündkabel besser..


Gruß
Searcher