Elektronische Zündung auf Arduino-Basis

[Emil1957]

Nachdem die ersten Hardware-Test zufriedenstellend gelaufen sind, hab ich mich nochmal um die Software gekümmert. Diverse kleinere Verbesserungen eingebaut, Ergebnis: Nichts funktionierte mehr (die Situation hat wahrscheinlich jeder Programmierer schon mal erlebt). Nachdem ich zwei Abende lang den Code durchforstet hatte (die Debug-Fähigkeiten des Arduino sind "recht bescheiden"), war die Ursache gefunden: Ein "=" zu wenig (in C ist halt "if ( usCoilDelayTime = 0 )" was anderes als "if ( usCoilDelayTime == 0 )" ).

Hier eine kurze Auflistung der Änderungen:

-Verbessertes Handling der Spulen-Ladezeit bei hohen Umdrehungszahlen (Ladezeit wird autom.reduziert, damit der gesamte Zündvorgang in die Zeit zwischen den beiden Signalen des Hall-Sensors passt)

-Verbessertes Handling bei sehr geringen Drehzahlen (z.B. beim Anlassen per Kickstarter)

-Berücksichtigung der Zeit (ca. 40 µs), die die für die jeweilige Berechnung des Zündzeitpunktes benötigt wird (diese muss für ein korrektes Ergebnis von der Warte- bzw. Ladezeit abgezogen werden).

Für die Tests hab ich dann noch einen einfachen Signalgenerator für einen Arduino Uno geschrieben, der das Signal simuliert, das normalerweise vom Hall-Sensor auf der Nockenwelle geliefert wird. Früher hab ich das über ein PC-Programm gemacht. Dessen Signal wurde dann über den PC-Kopfhörerausgang und einen kleinen Verstärker auf den Arduino Pro Mini geleitet. Das waren mir aber zuviele Zwischenschritte, die jetzige Lösung mit dem Arduino Uno als "Nockenwellen-Simulator" ist viel direkter. Hier ein Bild der Testumgebung (links: Arduino Uno, rechts oben: Platine mit Arduino Pro Mini). Die drei Leitungen (schwarz, rot, grün) gehen zum Line-In-Eingang des PC, von dort zum Oszilloskop-Programm.

Versuchaufbau.jpg

Hier mal zwei Beispiele (180°-Twin, d.h. asymetrisches Zündverhalten), grün ist das Signal von der Nockenwelle, rot das vom Arduino berechnete Signal, das auf die Zündpule gegeben wird (steigende Flanke: Spule wird geladen, abfallende Flanke: Spule zündet).

Beispiel 1: RPM=4000

Twin180_4000RPM.jpg

Beispiel 2: RPM=9000

Twin180_9000RPM.jpg

Deutlich wird das "Wandern" der der roten Kurve nach links (wegen größerer Frühzündung) und die Reduzierung der Ladezeit ("Plateau" der roten Kurve), die notwendig ist, weil sonst die Zündung nicht innerhalb des Zeitfensters erfolgen würde.

Die nächsten Tage werde ich mal einige Tests mit einer Signalaufnahme an der Kurbelwelle machen. Ein Forumsmitglied (goob) hat mich nämlich darauf hingewiesen, dass u.U. nur eine Konstante im Programm geändert werden muss, um es auch für eine solche Konstellation nutzen zu können.

[Emil1957]

Hab heute wie angekündigt mal einige Test mit einer simulierten Signalaufnahme an der Kurbelwelle anstelle der Nockenwelle gemacht.Dabei ist folgendes zu berückisichtigen:

-Da die Kubelwelle sich ja doppelt so schnell dreht wie die Nockenwelle bekommt man bei gleicher Geometrie der Steuerscheibe auch doppelt soviele Signale vom Hallsensor geliefert (einmal am UT zu Beginn des Verdichtungstaktes, einmal beim UT zu Beginn des Auspufftaktes). Es gibt (zumindest bei der verwendeten Technik) keine Möglichkeit, diese zu unterscheiden. Einzige Lösung ist eine Zündung sowohl im Verdichtungstakt als auch im Auspufftakt ("wasted spark"). Das ist aber nichts besonderes, bei den meisten 4-Zylinder-Maschinen (die nur 2 Zündspulen haben) ist das genau so.

-Durch die doppelte Frequenz wird auch das Zeitfenster, in dem ein Zündvorgang abläuft, halbiert. Insbesondere bei Gegenläufer-Twins (Zündabstand 180°) wird das zum Problem, da muss schon bei moderaten Drehzahlen die Spulen-Ladezeit reduziert werden (wie bei dem Beipiel im vorherigen Beitrag, da aber erst bei 9000 RPM). Für Gegenläufer-Twins ist die Signalaufnahme an der Kurbelwelle also m.E. nicht geeignet, bei den "echten" 360°-Twins (aber auch beim Boxermotoren) ist das Zeitfenster aber größer, da geht es.

Die Änderungen im Programm-Code waren zum Glück minimal, nur die Prozeduren zum Laden und Feuern der Spulen mussten etwas angepasst werden. Da sie nun vom jeweiligen Motortyp abhängen, habe ich sie in die jeweilige "modellspezifische" Datei ausgelagert, d.h. das Hauptprogramm ist nun unabhängig vom Motortyp.

Hier erst mal zur Kontrolle der Verlauf für einen 360°-Twin bei Signalaufnahme an der Nockenwelle (4000 RPM):

Twin360_4000RPM_cam.jpg

Und hier das Ergebnis bei einer Signalaufnahme an der Kurbelwelle:

Twin360_4000RPM_crank.jpg

Bei gleicher Umdrehungszahl ist die Frequenz des Eingangssignals (grüne Kurve = simuliertes Signal vom Hallsensor) doppelt so hoch wie vorher, das vom Zündsystem berechnete Signal ist aber gleich, d.h. an den Zündzeitpunkten hat sich nichts geändert. Zu erwähnen ist aber, dass nun (an den abfallenden Flanken der roten Kurven) in beiden Zylindern gezündet wird (bei Signalaufnahme an der Nockenwelle jeweils nur in einem).

Im nächsten Schritt wird der simulierte Hallsensor durch einen echten ersetzt. Die Steuerscheibe wird dann wie bei vorherigen Versuchen durch eine Bohrmaschine angetrieben.

[GalosGarage]

klasse....

weisst du schon, welchen hallsensor du verwenden willst?

[Emil1957]

http://www.hallsensors.de/CYHME1AV.pdf

Ich kann die Tage auch mal eine "Kurbelwellen-Simulation" für Deine Ducati machen.

[GalosGarage]

och, wenne grad nix anderes vor hast.....

[Emil1957]

Hab mich jetzt mal geistig mit dem Ducati-Motor beschäftig. Für einen wie mich, der sich bisher nur mit simplen Twins beschäftigt hat, was das schon eine gewisse Herausforderung . Die Zündverhältnisse haben sich mir erst mal nicht so einfach erschlossenen wie bei einem Twin, wo entweder beide Zylinder gleichzeitig im UT stehen oder der eine am OT, der andere am UT steht. Aber schließlich habe ich es dann doch begriffen.

Hier mal das Ergebnis der Simulation mit 6000 RPM (Signalaufnahme an der Nockenwelle) :

Ducati_6000RPM_cam.jpg

Anders wie beim Twin ist nun der 1. Zylinder nicht am OT, wenn der Hallsensor das Signal für den UT des 2. Zylinders liefert (abfallende Flanke der grünen Kurve), sondern schon vorher (gestrichelte rote Linie). Aus der Zeitdifferenz zwischen dem Zündzeitpunkt (abfallende Flanke der roten Kurve) und der OT-Position ergibt sich ein Frühzündungswinkel von ca. 30°, was gut mit den Angaben, die mir Gallo mal geliefert hat übereinstimmt. Das Programm rechnet also auch hier richtig .

Und hier das gleiche für 8000 RPM (Signalaufnahme wieder an der Nockenwelle) :

Ducati_8000RPM_cam.jpg

Auch hier zeigt die gestrichelte rote Linie wieder die OT-Postion des 1. Zylinders an. Wenn man sich nun vorstellt, dass das Signal an der Kurbelwelle aufgenommen wird (also doppelte Signalfrequenz), liegt der OT bei unter 4 ms. Es bleiben somit für das Laden der Spule und für die Frühzündung weniger als 2 ms. Das reicht vermutl. nicht, um einen brauchbaren Zündfunken zu erzeugen. Somit ist m.E. die Signalaufnahme an der Kurbelwelle bei einem 90° V-Motor (ebenso wie beim 180°-Twin) nicht geeignet.

[brummbaehr]

Ich habe bei der Güllepumpe (NEC-Zündung) mal Messungen gemacht.
Die Picups sitzen an der KW. Es sind aber 2, einer je Zylinder.
Im Leerlauf etwa 8ms ladezeit. Bei voller Vorzündung ca. 3000UPM ca. 4ms.

Bei 10.000 UPM braucht die KW ca. 6ms pro U.
2-3ms braucht die Zündspule um sich zu entladen.
Also hat man 3-4ms Zeit zum aufladen.
Ob das nun ein V2, ein Twin, ein 4Zylinder ist, spielt doch kein Rolle.

[Emil1957]

Die Picups sitzen an der KW. Es sind aber 2, einer je Zylinder.

Danke für den Hinweis, da liegt wohl der Hase im Pfeffer. Die Gülle hat somit 2 Messysteme, jede mit ihrer eigenen "Zeitzone", die unabhängig voneinander agieren können. Das ist bei meinem System anders, da ja derzeit nur ein Hallsensor verwendet wird. Das bedeutet, dass der erste Zylinder komplett "abgearbeitet" sein muss, bevor das Signal vom zweiten kommt. Bei asymetrischer Zündfolge gibt also immer das kleinere Zeit- (oder Winkel-)Fenster die maximale Ladezeit der Spulen vor.
Im Prinzip könnte man das System auch um einen zweiten Hallsensor (der dem zweiten Pickup in der Gülle entspricht) ergänzen. Allerdings ist der verwendete Hallsensor mit ca. 25 € das teuerste Teil des ganzen Systems. Alternativ könnte man auch einfachere Hallsensoren nehmen, die nur einen Bruchteil kosten. Dann wird allerdings die Fertigung der Steuerscheibe aufwändiger, da man dann ja mit "fliegenden Magneten" arbeiten muss. Irgendwann ist es dann kein low cost System mehr.
Ich werd das aber mal im Kopf behalten, vieleicht werde ich das in das Konzept für die SMD-Version der Platine übernehmen (wenn ich denn mal dazu komme, das anzugehen). Auf Seiten der Software dürften die Änderungen gar nicht so groß sein.

[brummbaehr]

Hmm... so ganz verstehe ich das Problem wohl nicht.
Man muss doch "nur" die Drehzahl und die Position der KW kennen, und kann dann den Zündzeitpunkt und die Ladezeit der Zündspulen für die nächste KW Umdrehung berechnen. Dazu reicht doch EIN Hallsensor, oder?

[Emil1957]

Für die Umdrehungszahl reicht die Information aus. Gleichzeitig ist das Signal des Hallsensors aber auch der "Nullpiunkt" der Zeitmessung für den jeweiligen Zündvorgang (Ladezeit der Spule + Zeit für Vorzündung), wofür ab einer gewissen Umdrehungszahl die Zeit nicht ausreicht. Ich habe aber schon die Ursache im Blick: Es ist meine Fixierung auf den UT als Nullpunkt. Wenn man den weiter nach vorne versetzt, gewinnt man Zeit. In den Abbildungen würde das einer Verschiebung der grünen Kurve nach links entsprechen. Dazu muss einfach die Steuerscheibe anders justiert werden (dass sie vor dem UT am Hallsensor ankommt). Im Programmcode muss ich dazu möglicherweise nur eine Konstante (derzeit 180=Winkel zwischen Hallsensor-Signal und OT) auf einen größeren Wert setzen. Werde ich heute abend gleich mal ausprobieren.