Druckbare Version
Eeventuell entstehen die Schwankungen auch durch schwankende / fehlerhafte Teilerfaktoren?!
Probier mal pro sekunde nur 8 aufeinanderfolgende Messwerte aufzuaddieren und das Ergebnis duch 8 zu teilen.
Das funzt dann runter bis 500 U/min.
Wenn die Anzeige dadurch stabiler wird hab ich vermutlich mit meiner Annahme recht.
Ich glaub, so etwas hab ich schon gemacht und verworfen. Bevor ich die Säge wieder anschmeiße und Meßreihen dazu aufnehme :-) :meintest Du es so? ...Zitat:
Zitat von wkrug
In einem Ringpuffer mit 8 Plätzen ( Middle( 8 ) ) werden 8 aufeinanderfolgende ICP Meßwerte, also der Abstand von einer Zündung zur anderen reihum abgespeichert.
Ist nach etwa einer Sekunde ein Update der Anzeige dran, wird der Mittelwert der letzten 8 Meßwerte gebildet und angezeigt. Siehe Code.
Code:$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_o As Word
Dim Tov_count As Byte
Dim Middle(8) As Word
Dim Ar_idx As Byte
Dim Idx As Byte
Dim Diff As Dword
Dim Icp_alive As Byte
Dim Disp_upd As Byte
Dim Icp_events As Word
Print "Drehzahlmessung"
Tccr1b = Bits(cs11 , Ices1) 'prescaler = 8, input capture event on rising edge
On Timer1 Update_display
Enable Timer1
On Icp1 Get_icr
Enable Icp1
Enable Interrupts
Do
Loop
Get_icr: 'called by an ICP event
Incr Icp_events
Icr_new = Icr1 'save ICR register
Icr_difference = Icr_new - Icr_old
Icr_old = Icr_new
If Idx < 8 Then Incr Idx Else Idx = 1 'value into 8 elements ring buffer
Middle(idx) = Icr_difference 'value into 8 elements ring buffer
Icp_alive = 1
Return
Update_display:
Incr Tov_count
If Tov_count >= 15 Then 'display update in about 1s interval
Incr Disp_upd 'sequence number for display update
For Ar_idx = 1 To 8
Diff = Middle(ar_idx) + Diff 'add last 8 values before display upd
Next
Upmd = 480000000 / Diff 'calculate rpm 60.000.000/(diff/8)
Upm_o = Upmd
If Icp_alive = 0 Then Upm_o = 0
'Remark Print " " ; Chr(13) ; Upm_o ; Chr(13);
Print Disp_upd ; ": " ; Upm_o ; " " ; Icp_events
Tov_count = 0
Diff = 0
Icp_alive = 0
Icp_events = 0
End If
If Disp_upd = 60 Then Disp_upd = 0
Return
Genau so hatte Ich das gemeint.Zitat:
In einem Ringpuffer mit 8 Plätzen ( Middle( 8 ) ) werden 8 aufeinanderfolgende ICP Meßwerte, also der Abstand von einer Zündung zur anderen reihum abgespeichert.
Ist nach etwa einer Sekunde ein Update der Anzeige dran, wird der Mittelwert der letzten 8 Meßwerte gebildet und angezeigt. Siehe Code.
Aber wenn Du das schon probiert hast und es nichts gebracht hat...
Ich dachte, das Du z.B. 40 Messwerte aufaddiert hast, dann aber durch z.B.41 geteilt hast, weil evtl. schon wieder ein neuer Zündimpuls gekommen ist, der aber noch nicht verrechnet war - bzw. Umgekehrt.
Das hätte dann die Drehzahlsprünge erklären können.
Wenn es tatsächlich an der Abnahme des Zündsignals liegt ( auch wenn Ich mir das an Hand der Oszillogramme nicht vorstellen kann ) könntest Du trotzdem noch mal über die Abnahme über einen Magnetfeldsensor ( z.B. TLE4905 ) direkt am Magneten der Schwungscheibe nachdenken.
Wenn man da gut ran kommt.
Oder aber Du versuchst mal eine Induktive Abnahme ( Mehrere Wicklungen über das Zündkabel - Ein Anschluss auf Masse, der andere an den Eingang Deiner Schaltung.
Das funktioniert dann wie ein Trafo. Der Stromfluss im Zündkabel bewirkt einen Spannungsstoß in der Wicklung.
Sollte nicht passieren, da ja alles im Interrupt stattfindet und die Daten konsistent sein sollten. Kleine Ungenauigkeiten passieren beim Dividieren, da dort gerundet wird. Grob bleiben die Rundungsfehler aber unter 10 Upm.Zitat:
Zitat von wkrug
Ich werde da auch noch experimentieren. Wenn ich da was zusammenbringe, werd ich nochmal Meßreihen hier zeigen. Auch noch die mit dem 8er Ringpuffer. Ich versuche die lauten und qualmigen Versuche schnell hintereinander zu machen. Vollgas hab ich noch nicht probiert, da ich dann auch noch Abwehrmaßnahmen gegen das Kettenöl treffen muß. das von der laufenden Kette verspritzt wird. :-) (Könnte man abbauen, würde aber dann ohne Last die Messung verfälschen)Zitat:
Wenn es tatsächlich an der Abnahme des Zündsignals liegt ...
Gruß
Searcher
Ich habe jetzt erst noch mit der kapazitiven einadrigen Zündimpulsabnahme experimentiert. Eine einadrige, 1,5m lange, ca. 0,75mm² dicke Kupferlitze ist mit zwei Windungen um das Zündkabel einer Husqvarna 445 Motorsäge gelegt. Das andere Ende zur gestern geposteten Schaltung. C2 ist jedoch 1nF und R2 = 110kOhm.
Bild hier
Kanal 1 des Oszis ist wieder an Pin 8 des CD4093B angeschlossen. Die Impulse erreichen für mich klar die Schaltschwellen des der Schmitttriggereingänge ds CD4093. Kanal zeigen die Pulse die generiert werden und die der µC zur Verarbeitung bekommt. Bei längeren Beobachtungen des Oszis konnte ich keine Ausfälle oder Mehrfachimpulse auf Kanal 2 erkennen. Wenn auch die Impulsabnahme nicht ideal erscheint und vielleicht bei der nächsten Maschine nicht mehr sauber funktioniert, möchte ich damit erstmal weitermachen.
Die "unruhige" Anzeige ist immer noch da. Sie kann meines Erachtens nur vom unruhigen Lauf des Zweitakters herrühren. Ich habe dazu 2 Meßreihen über je eine Minute (60 Anzeigen) gemacht und in Excelgraphiken dargestellt. Programme (jeweils ohne SW-Hysterese) weiter oben im thread zu finden.
1. Upm errechnet mit ICR Differenzwerten über eine Anzeigeperiode. (Mittelwert über die 60 Werte= 2681Upm)
Bild hier
2. Upm errechnet mit den letzten 8 Differenzwerten vor der Anzeige. (Mittelwert über die 60 Werte= 2694Upm)
Bild hier
Ich möchte jetzt weiter versuchen, die Anzeige per Programm zu "smoothen". Werd mir Deinen Beitag, Klebwax, mal intensiver zu Gemüte führen. Vielleicht einen riesengroßen Ringpuffer - aber der Tiny2313 hat so wenig SRAM. Oder innerhalb einer Anzeigeperiode 8 verdeckte Mittelwerte bilden und die im Ringpuffer über eine Anzeigenperiode mitführen. Daraus dann den Anzeigewert mitteln. Die Reaktion wird dann zäher. Aber alles zusammen geht wohl nicht :-) , scheitert an dem Zweitakter.
Gruß
Searcher
Guten Morgen Searcher,
dein Oszilloskopbild habe ich mal vergrößert und ausgedruckt und mit dem Lineal gemessen.
Anhang 34204
Hier ist eindeutig zu erkennen, dass die Messwerte erheblich schwanken.
Da Du anscheinend wenig RAM zur Verfügung hast, wäre ein Softwarefilter (Tiefpass) angebracht.
Ich hab mal in mühsamer Kleinarbeit einen Tiefpass geschrieben, der ohne Floats auskommt
und auch keinen Puffer benötigt, da er in Echtzeit (Samplegenau) funktioniert.
Der Code ist absolut trivial, aber entspricht exakt einem RC-Tiefpass und lässt sich sehr einfach anpassen.
Zunächst mal einige Erläuterungen dazu:
Das Entscheidende ist die Abtastrate (Samplerate) also wieviele Messwerte kommen pro Sekunde
und die Centerfrequenz (Fc) des Filters.
Beispiel bei mir:
Mein ADU liefert 1000 Messwerte pro Sekunde, das ist also die Abtastrate
Die Centerfrequenz (Fc) ist die Frequenz an dem die Amplitude um 3 Dezibel fällt wenn man eine
Sinusschwingung durch den Filter schickt.
Um sich unnötige (komplizierte) Berechnungen zu ersparen, kann mein Controller eh nicht
habe ich "vorab" einen Faktor benannt mit "D" berechnet.
Dieser Wert wird nur einmal (extern, Taschenrechner) berechnet und abgelegt.
Da ich keine floats habe, wird der Wert vorher noch mit 65536 multipliziert
So kann ich auch Nachkommastellen berücksichtigen
Ich habe den Code inzwischen in Pascal und C implementiert, aber ich denke das sollte kein Problem sein
ihn nach (sieht aus wie Basic ?) zu konvertieren.
Die Funktion ist für 32 Bit Integer ausgelegt
In Basic musst Du vermutlich den Typ long nehmen für 32 Bit
Dreh und Angelpunkt ist die Vorabberechnung bzw. der Wert von "D"
D:=1-exp(-(2*pi*Fc) / Samplerate);
Hier kannst Du aber auch ganz experimentell Werte probieren und schauen wie es sich verhält.
Die "C" Variante
Die "Pascal" Variante:Code:/*---------------------------------------------------------------------------*/
/* Siro's Spezialfunktion für einen Softwarefilter Tiefpass */
/* simuliert exakt ein ganz normales R/C Glied */
/* D:=1-exp(-(2*pi*Fc) / Samplerate); */
/* Fc ist die Centerfrequenz, der -3dB Punkt */
/* dann den Wert noch mit 65536 multiplizieren, wegen Integer Berechnungen < 0 */
/* Bezogen auf eine Abtastrate von 1000 Hz (1KHz) ergeben sich folgende Werte */
/* D = 21 ==> Fc = 0.05 Hz */
/* D = 41 ==> Fc = 0.1 Hz */
/* D = 206 ==> Fc = 0.5 Hz */
/* D = 410 ==> Fc = 1 Hz */
/* D = 818 ==> Fc = 2 Hz */
/* D = 2026 ==> Fc = 5 Hz */
/* D = 3991 ==> Fc = 10 Hz */
/* D = 7739 ==> Fc = 20 Hz */
/* D = 17668 ==> Fc = 50 Hz */
/* D = 30573 ==> Fc = 100 Hz */
/* D = 46884 ==> Fc = 200 Hz */
/* D = 62704 ==> Fc = 500 Hz */
S32 flowFilter(S32 value)
{ const S32 d = 206; // LowPassFilter Fc=0.5 Hz at 1000 Hz Samplerate
static S32 n = 0;
static S32 rest = 0;
S32 xx;
value = value - n;
xx = value * d;
rest = (xx+rest) % 65536; // % ist MOD Modulo (Divisionsrest) in "C"
xx = (xx+rest) / 65536;
n = n + xx;
return n;
}
/*---------------------------------------------------------------------------*/
Der Aufruf erfolgt mitCode:{------------------------------------------------------------------------------}
// !!!!! die mit const deklarierten Variablen
// müssen "statisch lokal" sein oder "global"
// sie müssen also erhalten bleiben nach dem Verlassen der Funktion
// in Pascal kann man das mit Const erzwingen.
Function FilterTP(value:Integer):Integer; // Tiefpass
const d : Integer = 206; // LowPassFilter Fc=0.5 Hz at 1000 Hz Samplerate
const n : Integer = 0;
const rest : Integer = 0;
var xx : Integer = 0;
begin
value:= value - n;
xx := value * d; // d ist ja schon mit 65536 multipliziert
rest := (xx + rest) MOD 65536; // wir muessen jetzt durch 65536 teilen
xx := (xx + rest) DIV 65536; // und den jeweiligen rest uns merken
n := n + xx;
result:=n;
end;
{------------------------------------------------------------------------------}
Messwert:=FilterTP(Messwert); // durch den Filter jagen
Ausgabe(Messwert); // hier dann anzeigen
Du kannst einfach mit dem Wert für "D" herum experimentieren,
je kleiner der Wert wird, umso ruhiger wird auch deine Anzeige, aber auch träger.
PS.: Die Variablen innerhalb der Funktion solltest Du vermutlich "GLOBAL" definieren, ich hab nicht gefunden dass Basic statische lokale Variablen kann...
Einfach mal den D Wert irgendwie setzen und vor deiner Anzeige des Messwertes diesen durch den Filter schicken.
Siro
Hier mal ein Beispiel was er aus meinem verrauschten Signal macht: die grüne Kurve ist die gefilterte mit obigen Code.
Anhang 34205
Hier habe ich den D-Wert vergößert: es wird etwas unruhiger, aber dafür schnellere Reaktionszeit
Anhang 34206
Tach Siro,
Wenn ich meine, ohne mehr RAM geht es nicht, würde ich auch einen größeren µC nehmen. Ein bißchen betrachte ich es auch als Sport mit dem kleinen zurecht zu kommen. Deine Idee mit dem Tiefpaß hört sich gut an. Versuch ich auch mal umzusetzen und eventuel Dein Programm für mich umzuschreiben. Filter hab ich noch nicht gemacht. Danke!Zitat:
Zitat von Siro
Gruß
Searcher
Doch, sicher. Einen Buffer mit Messwerten füllen und daraus den Mittelwert bilden, ist ein Filter. Ich hatte in meinem vorigen Beitrag schon ein einfaches Tiefpassfilter angedeutet. Ich will das hier noch mal etwas ausführlicher beschreiben.Zitat:
Zitat von Searcher
Damit das folgende besser verständlich ist, erläutere ich hier mal die von mir verwendeten Begriffe. Erstens der Messwert. Dieses ist das ungefilterte Ergebnis einer Messung: ein ADC-Wert (Spannung), der Temperaturwert aus einem digitalen Sensor, die Messwerte aus einem Accelerometer oder Gyrosensor oder, wie hier, die Zeit aus einem Input Capture. Und zweitens der Anzeigewert. Dies ist der Wert nach dem Filter und hat die selbe Einheit und Skalierung wie der Messwert. Der Messwert wird regelmäßig ermittelt, hier im Capture-Interrupthandler. Es könnte genausogut ein ADC im Timerinterrupt sein.
Die allgemeine Formel für einen Tiefpass ist: (neuer) Anzeigewert = k * (alter) Anzeigewert + (1 - k) * Messwert
k ist ein Koeffizient zwischen 0 und 1. Da einmal mit k und einmal mit 1-k multipliziert wird, bleibt die Skalierung von Messwert und Anzeigewert gleich. Der neue Anzeigewert ist also ein gewichtetes Mittel aus dem alten Anzeigewert und dem aktuellen Messwert.
Zur Abschätzung, was diese Formel bewirkt, kann man mal Extremwerte für k wählen: für k = 0 erhält man immer den aktuellen Messwert, das Filter hat keine Wirkung. Für k = 1 erhält man den Anzeigewert und der bleibt konstant. Zusammen mit der Frequenz, mit der die Messungen erfolgen, gibt k die Grenzfrequenz des Filters. Siro hat das dargestellt und ausgerechnet, ich kneife mir typisch die Rechnung und probiere einfach.
Wie kann man die Rechnung eines solchen Filters für einen µC leicht gestalten? Nun man verwendet Intergermathematik. Damit kann man k im Bereich 0 - 1 aber nicht darstellen. Wenn ich die Formel aber so schreibe : (k * Anzeigewert + (k - 1) * Messwert) / 1, kann man diesen Bruch so erweitern, daß sich sowohl das erweiterte k als auch (erweitert) 1 - k als Integer darstellen lassen. Wenn ich dann auch noch mit einer Potenz von 2 erweitere, wird aus dem Teilen ein Rightshift. Ein besonders einfacher Fall egibt sich für k = 0,5: (Anzeigewert + Messwert)/2. Ähnlich einfach ist auch k = 0,75: (3 * Anzeigewert + Messwert) / 4. Wobei man für µC, die keine HW-Multiplikation haben auch (Anzeigewert + Anzeigewert + Anzeigewert + Messwert) / 4 schreiben kann. Wie man hier auch erkennen kann, tragen bei k = 0,75 die alten Messwerte stärker zum Ergebnis bei als der neue Wert. Die Grenzfrequenz liegt also tiefer.
Da bei diesem Filter alle alten Messwerte (hier Anzeigewert genannt) zum neuen Wert beitragen, nennt man diese Filter IIR (Infinite Impulse Response). Infinite daher, weil jeder Messwert "für immer" mit im Anzeigewert steckt, jedoch entsprechend gering gewichtet. Wenn man im Gegensatz dazu auf einem Buffer rechnet, nennt man das ein FIR (Finite Impulse Response) Filter. Dabei kann der Buffer gleitend oder hintereinander gefüllt werden. Die Filtertypen haben unterschiedliche Eigenschaften. Ich zeig mal ein Bild, das ich aus dem Mikrocontroller.net Forum habe. Da hat Yalu X, der von digitaler Signalverarbeitung viel mehr Ahnung als ich hat, den Frequenzgang der beiden Filter mal geplottet.
Anhang 34208
In der roten Kurve erkennt man den klassischen Tiefpass, das IIR Filter. Den gleitenden Mittelwert (grüne Kurve) benutzt man gerne, um feste Störfrequenzen wie 50Hz auszublenden. Man dimensioniert es dann mit Bufferlänge und Samplingrate so, daß z.B. das erste Minimum auf diese 50Hz fällt und diese Störsignal nur sehr gering zum Ergebnis beiträgt. Da ein solcher Fall hier nicht vorliegt, sind die aufwändigere Rechnung und der größere Speicher für ein FIR nicht nötig.
Mit der Anzeige der Messwerte hat das nichts zu tun. Wenn die serielle Ausgabe kürzer ist, als die Zeit zwischen zwei Capture-Interrupts, wie du berechnet hast, kann die Ausgabe aus dem Capture-Interrupt selbst erfolgen. Das vermeidet jeglichen Konflikt. Da der Mensch nicht mehr als ca. 5 Werte pro Sekunde wirklich erfassen kann, muß man die Anzeige nicht bei jedem Interrupt updaten.
MfG Klebwax
P.S. irgendwie ist das Bild nicht angekommen, versuche es nochmal
Da die Impulsaufnahme anscheinend gut funktioniert geht es nun an die Auswertung.
Tiefpassfilterung hast Du ja im Prinzip schon gemacht.
Ich würde die Refreshrate auf 3 neue Anzeigen / Sekunde ändern bzw. umschaltbar machen.
Das gibt dann noch eine "lesbare" Anzeige und ist trotzdem "schnell".
Ich bin hier bestimmt nicht der große Mathematiker vor dem Herrn, aber für solche Aufgaben wird immer wieder gerne mal das Kalman Filter empfohlen.
Ich hab mich da früher schon mal reingelesen, konnte es aber nicht anwenden, da ich die Varianz der Messwerte nicht bestimmen konnte.
https://www.cbcity.de/das-kalman-fil...rklaert-teil-1
https://www.cbcity.de/das-kalman-fil...rklaert-teil-2
https://www.cbcity.de/das-extended-k...nfach-erklaert
Das ist bei Dir durch deine Messreihen anders.
Eventuell kann Dir jemand, der in Mathe besser drauf ist, mal gucken ob das hier funktionieren würde?!
Ich meine auch, anhand Deiner Messreihen, das dein Verfahren innerhalb einer festen Messperiode die Impulse zu verarbeiten zu der genauesten Messung führen wird.
Allerdings ist dadurch die Anzahl der Messwerte variabel und wird zu höheren Drehzahlen hin weniger.
Ich hab das früher mal so gelöst, das Ich ab einer bestimmten Drehzahl auf die Impulszählung mit fester Torzeit umgeschaltet habe.
Denn wenn die Pin Change Werte zu klein werden steigen die Rundungsfehler massiv an und eine Torzeitmessung bringt dann genauere Ergebnisse.
So hab's Ich gemacht:
Im ersten Moment werden dabei die Impulse pro fester Zeiteinheit ermittelt.
Sind die zu gering wird auf Impulsdauermessung ( das Verfahren, das Du jetzt benutzt ) umgeschaltet.
Bei mir war das Nötig, weil Ich an mehrblättrigen Propellern mit Drehzahlen bis 20000 U/min messen wollte und Ich deshalb stellenweise 4 Impulse pro Umdrehung bekommen habe.
Da kam dann der Pinchange Interrupt nicht mehr mit, außerdem waren da ja noch die Rundungsfehler!
Uff, ich hoffte, der Kelch wird an mir vorbeigehen :-) Ich wollte doch nur die Zweitakter einstellen :-) :-)Zitat:
Zitat von wkrug
Für den Drehzahlmesser möchte ich jetzt erst wieder klein weiter machen und mal sehen wie die Grafik mit der von Klebwax erwähnten Methode aussieht. Die, die zwei Meßwerte addiert und durch zwei teilt und dann zum Ergebnis den nächsten Meßwert addiert und wieder durch zwei teilt usw.
Das ist für mich überschaubar ;) und danach geht es weiter ...
Zu allererst muß aber ein Simulator her, also ein Impulsgeber, der anstelle der CD4093 Schaltung mit angehängter Motorsäge die Rechteckimpulse zum ICP Eingang gibt. Dazu sollte ein ATmega88, der hier tatenlos rumschlummert, in der Lage sein.
Kostet mich sonst zuviel Sprit, verpestet unnötig die Luft und immer Gehörschutz aufsetzen ist auch noch lästig.
Gruß
Searcher