Hallo Leute, Ich bin auf der Suche nach ein paar Algo's zur Mittelwertberechnung. Zur Zeit berechne ich meinen gleitenden Mittelwert mit der Std Methode. (x Werte sammeln, Addieren und durch x teilen) Das klappte bis jetzt ganz gut. Nun muss ich Spannungen, Ströme und Gesamtleistungen überwachen mit einer max Abweichung von +/- 2,5%. Ich habe hier zur Zeit die Platine offen auf dem Tisch liegen und die letzten Tage den Code Programmiert und alles war gut. Jetzt ist mein Kollege wieder aus dem Urlaub zurück und sein alter Lötkolben produziert SUPER TOLLE Spikes die meinen Mittelwert zu stark ansteigen lassen. Da ich eine Zeitvorgabe habe, für das Abschalten des Gerätes(Sicherheit), kann ich meine 'Messreihe' nicht erweitern. (max 16 Messungen in der Zeit möglich, wenn der Lötkolben ca. 4 Spikes (Vollausschlag, 3x mehr als Nutzsignal) in meine Messreihe einschleust, geht mein Gerät aus!) PS: Die Verhältnisse sind aus dem Gedächtnis, bestimmt etwas Übertrieben Ich bin nun auf der Suche nach, wie soll ich es sagen, 'Toleranteren' Verfahren zur Mittelwert Berechnung und wie man die 'Güte' des Algorithmus bestimmt. Ich hab jetzt bei der Recherche den 'Median' ein Rangordnungsfilter gefunden. Der gibt mir jetzt keinen berechneten Mittelwert, sondern eine echten gemittelte Wert der x Werte, aber wie gut oder schlecht ist das!?! Die Möglichkeit hier echte Werte zur Verfügung zu haben gefällt mir sehr, aber wie gesagt ich kanns leider nicht beurteilen. Ich würde dann hier auf die echten Werte die Abschaltung realisieren und für den Kunden aus diesen Werten einen std Mittelwert bilden. Oder mache ich mir zu viele Sorgen und sollte einfach nur einen Bandfilter nutzen? Die sehr geringe Toleranz der zu überwachenden Werte macht mir sorgen. Ich weiß das das Gerät im eingebauten Zustand viel besser abgeschirmt ist und dort solche Störung nicht auftauchen. Es bleibt halt so ein komisches Bauchgefühl. Für Tips und Anregungen wäre ich sehr Dankbar. Median: (Quelle Wiki) Messwerte 1, 2, 4, 4, 4, 5, 15; Der Median (auch der Ober- und der Untermedian) ist der Wert an der mittleren Stelle, also 4. Wenn im Beispiel durch einen Fehler eine 4 durch 46 ersetzt wurde, ändert sich der Median wenig oder überhaupt nicht, 1, 2, 4, 4, 5, 15, 46. Das arithmetische Mittel hingegen springt von 5 auf 11.
Stephan schrieb: > Jetzt ist mein Kollege wieder aus dem Urlaub zurück > und sein alter Lötkolben produziert SUPER TOLLE Spikes die meinen > Mittelwert zu stark ansteigen lassen. Da fallen mir zwei Sachen ein. Zum ersten musst du klären, warum deine Schaltung seinen Lötkolben su gut 'empfängt', da scheint also mit der Sensorik oder dem Aufbau irgendetwas nicht in Ordnung zu sein, und das wird dir in der Praxis noch einige Probleme bereiten, wenn du dich nicht drum kümmerst. Gotseidank ist der Kollege also gekommen und hat den Lötkolben angeschaltet. Zum Zweiten ist mir das Problem nur insofern klar, als das du richtige Ausreisser erkennen und eliminieren willst, bevor du Mittelwerte bildest? Falls das so ist, suche mal nach 'Artefakt Erkennung', ein bei medizinischen Geräten übliches und wichtiges Verfahren, denn es soll nicht jedesmal ein Alarm eines Gerätes ausgelöst werden, wenn der Patient hustet oder sich umdreht. Zuerst musst du aber die Hardware von vorneherein störsicherer machen.
Stephan schrieb: > Zur Zeit berechne ich meinen gleitenden Mittelwert mit der Std Methode. > (x Werte sammeln, Addieren und durch x teilen) > Das klappte bis jetzt ganz gut. Und was ist daran das Gleitende? Wenn du zuerst n Werte sammelst, addierst und durch Anzahl teilst,und dann eben diesen Vorgang wiederholst, dann ist das KEIN gleitender Mittelwert, sondern lediglich das Herabsetzen der Samplingrate. Für einen gleitenden MW brauchst du einen Puffer, wo die gewesenen Samples gespeichert werden - und bei jedem neuen Sample fällt der letzte aus dem Puffer heraus und versammelt sich mit seinen Vorgängern im Nirwana. Und den gleitenden MW errechnest du über die in deinem Puffer befindlichen Werte - und zwar jedes Mal, wenn ein neuer Wert hereinrauscht. Also nix mit "x Werte sammeln". Wenn du ne 2er Potenz als Puffergröße nimmst, dann gibt es dafür ne sehr effiziente Art, den gleitenden MW zu berechnen: die untersten n Bits deines Ereigniszählers als Index im Puffer verwenden und zunächst den dortigen Wert von der gespeicherten Summe abziehen, dann den neuen Wert dorththin schreiben und zur Summe addieren. Easy und schnell. W.S.
Hi Matthias, Die Steuerung ist schon ein paar Jahre alt und da wird auch leider nichts mehr an der Hardware geändert. Das Netzteil ist erneuert worden, wo bei die Grenzen der Überwachung halt angepasst werden sollen. (vorher +/- 7,5% auf +/- 2,5%) Ich bin der 3. Programmierer an dem Gerät seit seiner Erstellung und muß auf das zurück greifen was ich hier habe. Die Steuerung ist soweit, im eingebauten Zustand IO, keine Spikes!!! 'Burst- und Surge-Tests' hat das Ding im Winter (vor Weihnachten) mit dem neuen Netzteil bestanden. >wird dir in der Praxis noch einige Probleme bereiten Das ist halt das Bauchgefühl was ich habe, oder was falsches gegessen... >richtige Ausreisser erkennen und eliminieren willst, bevor du Mittelwerte >bildest? Das habe ich mir dabei gedacht, ich will die Messung entschärfen. Kollege meinte: schmeiß den größten und kleinsten Wert weg und berechne daraus den Wert, aber bei mehren, gleichen Störungen hilft das nichts. Da wäre ein Hochpass besser.(und Tiefpass) Die Kollegen sagen es passt schon und ich soll mir keinen Kopf machen, mmmhhhmm. 'Artefakt Erkennung' Ich hab auf der Schnelle nichts gefunden, werde mich heute Abend bzw. morgen noch mal dran setzen. Danke.
W.S. >Wenn du ne 2er Potenz als Puffergröße nimmst, dann gibt es dafür ne sehr >effiziente Art, den gleitenden MW zu berechnen: die untersten n Bits >deines Ereigniszählers als Index im Puffer verwenden und zunächst den >dortigen Wert von der gespeicherten Summe abziehen, dann den neuen Wert >dorththin schreiben und zur Summe addieren. Easy und schnell. Ja genau so wirds ja gemacht. Sorry wollte da nichts verschweigen.
Ich wuerde den exponentiellen Mittelwert vorschlagen, denn er benoetigt die kleinsten Resourcen : http://www.ibrtses.com/embedded/exponential.html
Bastler schrieb: > Ich wuerde den exponentiellen Mittelwert vorschlagen, Hilft leider nicht bei einem einzigen Ausreisser, der ja dann doch wieder in den Mittelwert eingeht. Wie wäre es mit folgender Strategie: Du hast bereits den gleitenden Mittelwert, den du über eine weitere Mittelung laufen lassen kannst. Um diese herum bildest du ein Fenster, bei dem völlig aus dem Ruder laufende Werte schon im Fifo gekillt werden und nicht in die gleitende Mittelwertbildung mehr eingehen. Es ist leider schon lange her, aber bei unserem Hirndruckmessgerät war es m.W. so ähnlich gelöst, um Huster aus dem Messergebnis herauszuhalten. Leider habe ich den Quellcode damals (Dual-Z80 mit Hardware Multiplier) nie gesehen.
Matthias Sch. > Um diese herum bildest du ein Fenster, bei dem völlig aus dem Ruder > laufende Werte schon im Fifo gekillt werden und nicht in die gleitende > Mittelwertbildung mehr eingehen. Ja das hab ich auch schon überlegt, ich wollte aber vor der Mittelwertbildung den Messwert begrenzen. Das heißt das der Wert nur um x% schwanken kann, alles darüber oder darunter wird auf Aktueller-Mittel-Wert +x% begrenzt (bzw Aktueller-Mittel-Wert -x%) Nur wie 'gut' wird dann noch der Mittelwert?
Stephan schrieb: > Nur wie 'gut' wird dann noch der Mittelwert? Was spricht denn dagegen, sich dass mal mit einem Tool wie z.B. Excel oder LibreCalc anzusehen, idealerweise mit den tatsächlich gemessenen Daten? Die Bilder zeigen eine exponentielle Glättung, einmal mit alpha=0.1 und einmal mit alpha=0.5. In diesem Beispiel sieht man schön, wie der Glättungsfaktor den "Nachhall" von Sprüngen und Spikes beeinflusst. -> http://de.wikipedia.org/wiki/Exponentielle_Gl%C3%A4ttung Grüße, ein anderer Stephan.
:
Bearbeitet durch User
Hey anderer Stephan, Danke für die Bilder. Das zu testen sollte ich mich wieder zwingen. Bin leider einmal so auf die Nase damit gefallen, deshalb beruflich davon weg. (echt teuer gewesen)
Evtl. hat die Fachrichtung Statistik da einiges Parat, wenn es darum geht Ausreißer zu erkennen/ignorieren. Fang mal an bei "Deviance" oder "Standardabweichung". Das geht noch gut mit mc Bordmitteln ohne übermässige Arithmetik. Weitergehend: Zeitreihen und/oder lineares Modell bilden, Abweichung der Beobachtungen von den Prognosen um so Ausreisser zu erkennen. Der gleitende Durchschnitt ist nur ein sehr einfacher Spezialfall der zur Verfügung stehenden Methoden. Andere Möglichkeiten sind Polynome oder höherwertige Funktionen drüberlegen und dann wieder die Abweichler einzukassieren. Tuning mit einem einstellbaren Maß an erlaubter Abweichung. Gruß Mike
Wenn der Aufbau schon so lausig ist, dass ein Loetkolben Spikes produziert, Sind Messungen in unbekannter Umgebung voelliges Wuerfeln. Verbessere das Design, und spar dir solche Ansaetze.
Bastler schrieb: > Wenn der Aufbau schon so lausig ist, dass ein Loetkolben Spikes > produziert, Sind Messungen in unbekannter Umgebung voelliges Wuerfeln. > Verbessere das Design, und spar dir solche Ansaetze. Ich habe bei einer Messung des Stromes am Netz das selbe Problem. Auch bei mir hat sich das Problem per Software nicht lösen lassen. Ich messe mit einem über den Leiter geschobenen Ringkern, danach Verstärkung und Spitzenwertgleichrichter mit Opamp. Dabei werden leider die Spikes viek besser übertragen als der 50Hz Strom. Ich bin jetzt mit Tiefpass am Testen! Der müsste sehr steilflankig werden! Momentan habe ich auf den Ringkernen Kurzschlusswicklungen drauf, das entschärft das Problem ein bisschen :-) Gruss Chregu
Bei solchen Problemen sollte man das Layout anschauen. Metallgehaeuse ?
Das der Aufbau nicht optimal ist weiß ich auch, aber wenn ich mir die 19 Zoll-Schränke bei mir an den Platz hole und das Gerät einbaue, kann ich keine Eingangswerte mehr simulieren (Hilfsspannungen, Hilfs IOs, Stromsenken usw). Auch die Möglichkeit des Debugens mit einem JTAG ist dann nicht mehr gegeben!!! Mir geht es jetzt erst mal darum, was für Algo's gibs für die Mittelwertbildung und wie kann ich steile Störimpulse quasi aus der Mittelwertrechnung raus halten bzw nicht so stark auswirken lassen. Ich werde, so wie Stephan M. vorgeschlagen hat, mir die org. ADC Werte raus holen und dann in Excel testen. Diese Werte werden aus einem eingebauten Gerät mit alten Wella-Lötkolben daneben sein. PS: Der Lötkolben ist eigentlich auch nicht in der Entwicklung erlaubt. Keine Ahnung wie der wieder bei uns gelandet ist. Eigentlich sollte die Produktion den bekommen, wenn es im Radio bei denen Knackt macht das nichts.
Ausreisser bekommt man mit dem Median gut weg. Je größer die Anzahl der Elemente umso mehr näheren sich die Ergebnisse von Median und Mittelwert an. Bei einer Anwendung hatte ich bei N=256 keinen nennenswerten Unterschied festgestellt. Kommt aber natürlich darauf an wie extrem die Ausreisser sind. Bei nur 16 Werten sieht das aber schon anders aus. Den Median bekommst du ganz einfach indem du deine 16 Samples kopierst, sortierst und dann das 8. oder 9. Element verwendest. Oder den Mittelwert des 8. und 9. ;).
Danke Stefan. Du hast das Beispiel von Wiki gesehen? >Messwerte 1, 2, 4, 4, 4, 5, 15; Siehe 1. Post >Da ist der Unterschied von Median und Mittelwert doch ganz schön groß!?! >Das arithmetische Mittel hingegen springt von 5 auf 11. Die 256 Elemente sortierst du aber nicht im Int von ADC oder? Ich werde mir mal am Montag die Rechnungen in Excel rein hauen und sehen was raus kommt. Danke an alle.
Dumme Frage: Jeweils den neuesten Wert hinzuaddieren und das Ergebnis durch Zwei teilen? Man könnte natürlich auch dreimal den alten Wert nehmen, den neuen hizuaddieren und dann durch vier teilen ...
:
Bearbeitet durch User
Frank Esselbach schrieb: > Jeweils den neuesten Wert hinzuaddieren und das Ergebnis durch Zwei > teilen? Und das soll genau welche Besserung bei Ausreißern in den Daten bringen. Damit versaust du die Daten endgültig.
Stephan schrieb: > Du hast das Beispiel von Wiki gesehen? >>Messwerte 1, 2, 4, 4, 4, 5, 15; Siehe 1. Post >>Da ist der Unterschied von Median und Mittelwert doch ganz schön groß!?! >>Das arithmetische Mittel hingegen springt von 5 auf 11. > > Die 256 Elemente sortierst du aber nicht im Int von ADC oder? In dem Beispiel sind es ja sogar nur sieben Werte. Da gehen Mittelwert und Median mitunter deutlich auseinander. Für 256 Werte ist die Verarbeitung in Blöcken ungeschickt sofern man nicht Rechenleistung im Überfluss hat. Ich verteile die Werte auf zwei Heaps. Der eine liefert das größte Element, der andere das kleinste. Die Anzahl der Elemente pro Heap ist gleich. Dazu müssen immer wieder Elemente von einem Heap auf den anderen geschoben werden. Das sortierte Einfügen benötigt damit für jeden neuen Wert O(log N) Schritte. Für 16 Elemente lohnt sich der Aufwand aber nicht. Es dürfte sogar eher langsamer sein als ein Array direkt zu sortieren. Für N>100 kann man darüber nachdenken. Ich hatte mir auch überlegt Median und Mittelwert zu kombinieren: Erst den Median der z.B. letzten 15 Werten nur um Ausreisser auszufiltern und dann den Tiefpass zur Glättung dahinter. Den Ansatz habe ich aber nicht weiter verfolgt.
Stephan schrieb: > PS: Der Lötkolben ist eigentlich auch nicht in der Entwicklung erlaubt. > Keine Ahnung wie der wieder bei uns gelandet ist. Eigentlich sollte die > Produktion den bekommen, wenn es im Radio bei denen Knackt macht das > nichts. Nicht mogeln! Das ist schon ganz gut so, das dir das jetzt passiert und nicht erst, wenn sich eure R&D auf die 19" Sächelchen verlässt. Du solltest auf jeden Fall mal mit der Hauselektrik auf die Suche gehen und die Ursache finden. Das wird nicht das letztemal sein, das der Schrank 'ne Störung vom Abschalten einer Induktivität bekommt.
Eine weitgehend identische Aufgabe hatte ich vor langer Zeit (+/-1990) auch mal. Die damaligen Anforderungen waren so hoch das ich sie weder mit "klassischen" Filtern noch mit simplen Tricks bewältigen konnte. Erst eine Fuzzylösung führte zu einer stabilen, (groß)serientauglichen Lösung. "Keep it simple" bringts halt nicht immer ... Diese benötigte jedoch bei 16Hz Abtastfrequenz und 16 betrachteten Samples erhebliche Rechenleistung des damals mit 2MHz getakteten 68HC11; von den 62.5 zur Verfügung stehenden Millisekunden von Sample zu Sample war er ca. 20ms nur damit beschäftigt. @TE: Wenn in Deiner Applikation genug Rechenleistung zur Verfügung steht UND Du Interesse hast Dich mit einem komplexeren Algorithmus zu beschäftigen dann tauche ich gerne mal in mein Kellerarchiv ab und schaue ob ich da noch etwas dazu finde.
Ralf D. schrieb: > einem komplexeren Algorithmus zu beschäftigen dann tauche ich gerne mal > in mein Kellerarchiv ab und schaue ob ich da noch etwas dazu finde. Ich hab zwar das Problem gerade nicht, aber ich finde es trotzdem interessant. Wenn du in dein Archiv tauchen würdest, fände ich das nett :)
Bitte 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.