Forum: Mikrocontroller und Digitale Elektronik Aktuellen Messwert mit Vorgängerwert vergleichen


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Michael F. (michael_f268)


Lesenswert?

Hallo zusammen,

ich sitze leider im Moment komplett auf dem Schlauch bzgl. einer 
wahrscheinlich ziemlich trivialen Sache.
Ich bekomme aus einen Sensor jede Sekunde einen Messwert. Den aktuellen 
Messwert will ich aber nur ausgeben, wenn sich der aktuelle Messwert vom 
letzten Messwert nicht mehr als 10% unterscheidet.
Für jeden Messwert zählt sich ein Zähler hoch.
Wenn ich nun eine feste Anzahl von Messwerten analysieren will, ist's ja 
einfach, da speichere ich einfach die Werte in Array und vergleich dannn 
z.Bsp. Messwert_old [2] mit Messwert[3].
Aber in meiner Anwendung will ja konkret nur den letzen Messwert mit dem 
Aktuellen vergleichen, dessen Zähler sich kontinuierlich nach oben 
zählt.

Der aktuelle Messwert überschreibt ja immer den alten Messwert, also wie 
kann ich konkret in einer Messung den aktuellen Messwert speichern, der 
dann in der nächsten Iteration der alte Messwert sein wird.

Sorry, ich komm da gerade nicht drauf, vielleich kann mir jmd. einen Tip 
geben.

Danke schon ma und Grüße

von Sebastian R. (sebastian_r569)


Lesenswert?

1
float Messwert_Neu
2
float Messwert_Alt
3
4
Schleife:
5
  Messwert_Alt = Messwert_Neu
6
  
7
  Messwert_Neu = machEineMessung()
8
  
9
  Wenn <10% Abweichung zwischen Messwert_Alt und Messwert_Neu:
10
    print(Messwert_Neu)

Braucht kein Array, du musst dir nur den Wert merken, bevor du einen 
neuen Messwert einholst.

: Bearbeitet durch User
von Michael F. (michael_f268)


Lesenswert?

Ah Super, vielen Dank! Ist ja ganz einfach :-)

von Katrin I. (Gast)


Lesenswert?

Mit der Methode kann es dir passieren, dass du gar keinen ausgeben 
wirst.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Michael F. schrieb:
> Den aktuellen Messwert will ich aber nur ausgeben, wenn sich der
> aktuelle Messwert vom letzten Messwert nicht mehr als 10% unterscheidet.
Es soll also laufend was ausgegeben werden, wenn die Werte gleich sind? 
Wofür braucht man sowas?

> vielleich kann mir jmd. einen Tip geben.
Ein µC ist ein zutiefst binäres Ding. Deshalb fällt es ihm unheimlich 
leicht, mit 2er-Potenzen zu rechnen. Das sind 1, 2, 4, 8, 16, usw. aber 
auch 1/2, 1/4, 1/8 usw.

Mit dem richtigen Rechenansatz fällt es ihm also recht leicht, 12,5% 
Abweichung (=1/8) auszurechnen. Er braucht aber einiges an Aufwand, wenn 
er 10% ausrechnen muss.

: Bearbeitet durch Moderator
von Mi N. (msx)


Lesenswert?

Lothar M. schrieb:
> Mit dem richtigen Rechenansatz fällt es ihm also recht leicht, 12,5%
> Abweichung (=1/8) auszurechnen. Er braucht aber einiges an Aufwand, wenn
> er 10% ausrechnen muss.

Ist Dir Dein Komentar nicht peinlich?
Nachher soll man nicht einmal Dezimalzahlen anzeigen sondern nur eine 
Kette aus LEDs?
Als Benutzer soll es einem völlig egal sein, wie der µC das Ergebnis 
erreicht, solange Rechenzeit und Speicher ausreichend sind. Und für 
solche trivialen Aufgaben ist das heutzutage immer der Fall, außer man 
konstruiert sich - wie hier öfter zu verfolgen ist - nicht lösbare 
Umstände. Und das nur aus Wichtigtuerei.
:-(

Beitrag #7648973 wurde vom Autor gelöscht.
von Klar P. (Gast)


Lesenswert?

> Lothar M. schrieb:
>> Mit dem richtigen Rechenansatz fällt es ihm also recht leicht, 12,5%
>> Abweichung (=1/8) auszurechnen. Er braucht aber einiges an Aufwand, wenn
>> er 10% ausrechnen muss.
>
> Ist Dir Dein Komentar nicht peinlich?
> Als Benutzer soll es einem völlig egal sein, wie der µC das Ergebnis
> erreicht, solange Rechenzeit und Speicher ausreichend sind. Und für
> solche trivialen Aufgaben ist das heutzutage immer der Fall,

Scherzkeks, auch heute sind noch 8bit µC zu programmieren, die kein 
Fliesskomma können. Und natürlich ist für einen selbst erklärten 
Anfänger wie dem TO einfachre einen Shift zu programmieren (">>") als 
ein korrekte
Division durch 10.0. Zumal dafür der Sensorwert erstmal in eine korrekte 
(normalisierte) float zu konvertieren ist.

von Rolf (rolf22)


Lesenswert?

Lothar M. schrieb:
> Mit dem richtigen Rechenansatz fällt es ihm also recht leicht, 12,5%
> Abweichung (=1/8) auszurechnen. Er braucht aber einiges an Aufwand, wenn
> er 10% ausrechnen muss.

Aua. Du hast das Buch "Wie funktioniert eigentlich ein Computer?" 
gelesen", aber das war es dann auch schon.

Diese Rechenaufgabe war schon vor 50+ Jahren für den 4-Bit-µP Intel 4004 
ein Klacks, sowohl von der Programmlänge als auch von der Laufzeit.

Zum Thema "richtiger Rechenansatz und Aufwand": Man muss bei dieser 
Aufgabenstellung gar nicht 10 % ausrechnen. Man multipliziert die 
Abweichung mit 10 und vergleicht anschließend. Das ist weniger Aufwand 
und der Rundungsfehler fällt weg.
Und nebenbei: Wenn man tatsächlich unnötigerweise in Assembler 
programmieren würde und der uralte µP keinen Multiplikationsbefehl 
hätte, dann würde man die Multiplikation mit 10 so abkürzen: y = 2*x   y 
= y + 4*y. Das kostet nur eine Addition mehr als das Berechnen von 1/8.

von Klar P. (Gast)


Lesenswert?

> Aua. Du hast das Buch "Wie funktioniert eigentlich ein Computer?"
> gelesen", aber das war es dann auch schon.

Warum reagieren manche Enkel beleidigt, wenn Opa ihnen einen Trick 
zeigt, der ihn vor Stalingrad überleben ließ??

von Rolf (rolf22)


Lesenswert?

Klar P. schrieb:
> Und natürlich ist für einen selbst erklärten Anfänger wie dem TO einfachre
> einen Shift zu programmieren (">>") als ein korrekte
> Division durch 10.0.

Lies nochmal. Der TO hat gar nicht nach der Berechnung von 10 % gefragt, 
und der erste Antworter hat dafür auch keine Lösung geliefert.

von Mi N. (msx)


Lesenswert?

Klar P. schrieb:
> Scherzkeks, auch heute sind noch 8bit µC zu programmieren, die kein
> Fliesskomma können. Und natürlich ist für einen selbst erklärten
> Anfänger wie dem TO einfachre einen Shift zu programmieren (">>") als
> ein korrekte
> Division durch 10.0. Zumal dafür der Sensorwert erstmal in eine korrekte
> (normalisierte) float zu konvertieren ist.

Der TO hat das mit 'float' schon begriffen. Ihn jetzt mit Bananen auf 
einen Baum zu locken, sollten die Opas ruhig lassen.

von Rolf (rolf22)


Lesenswert?

Sebastian R. schrieb:
> float Messwert_Neu
> float Messwert_Alt

Ohne Initialisierung mit Werten, die niemals als Messwerte vorkommen 
können, ist das einfach falsch.

von Steve van de Grens (roehrmond)


Lesenswert?

Klar P. schrieb:
> Warum reagieren manche Enkel beleidigt, wenn Opa ihnen einen Trick
> zeigt, der ihn vor Stalingrad überleben ließ??

Weil sie sich nicht vorstellen können, dass diese Tricks für ihre Leben 
jemals relevant werden könnten.

Ich hätte bis vor kurzem auch nicht gedacht, dass ich mir Gedanken über 
Alternativen zu Klopapier machen musste. Dass es mal weder Nudel noch 
Mehr zu kaufen geben würde. Dass ich aus Sorge vor Stromausfall Wasser 
und Kerzen bevorraten würde. Das Krieg für mich relevant würde. ...

Wer als junger Mensch in guten Zeiten aufwächst, hat keine Ahnung, was 
danach kommen kann. Und er will das auch nicht von Opa hören.

Lieber schaut man sich Videos von "genialen" Tricks mit gefakten 
Erfolgen auf Youtube an, die machen gute Laune.

von Klar P. (Gast)


Lesenswert?

>> Division durch 10.0.
>
> Lies nochmal. Der TO hat gar nicht nach der Berechnung von 10 % gefragt,
Doch, hat er.

>> wenn sich der aktuelle Messwert vom letzten Messwert nicht mehr als 10%
>> unterscheidet.

von Sebastian R. (sebastian_r569)


Lesenswert?

Rolf schrieb:
> Sebastian R. schrieb:
>> float Messwert_Neu
>> float Messwert_Alt
>
> Ohne Initialisierung mit Werten, die niemals als Messwerte vorkommen
> können, ist das einfach falsch.

Pseudocode.
Dass das keine fertige oder 100% funktionierende Lösung ist, sollte 
eigentlich klar sein, oder?

von Rolf (rolf22)


Lesenswert?

Klar P. schrieb:
>> Lies nochmal. Der TO hat gar nicht nach der Berechnung von 10 % gefragt,
> Doch, hat er.

Gruß nach Schiefturmstadt.

von Klaus H. (hildek)


Lesenswert?

Ich sehe das Problem u.U. dabei, dass z.B. eine entsprechend langsame 
aber kontinuierliche Änderung des Wertes nie zu einer neuen Anzeige 
führt.
Das kann natürlich so gewollt sein - Details zum Problem wurde nicht 
genannt.
Wenn nicht, dann nimmt man einen Ringbuffer, der in gewissen zeitlichen 
Abständen mit neuen Werten gefüllt wird und der neue Wert wird mit dem 
ältesten verglichen.

von Mi N. (msx)


Lesenswert?

Klaus H. schrieb:
> Ich sehe das Problem u.U. dabei, dass z.B. eine entsprechend langsame
> aber kontinuierliche Änderung des Wertes nie zu einer neuen Anzeige
> führt.

"messwert_alt" darf erst dann angepaßt werden, wenn er auch angezeigt 
wurde. Dann würde das passen.
Welchen Sinn da haben soll? Vielleicht sollen nur die 'wahren' Werte 
angezeigt werden.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Klaus H. schrieb:
> Ich sehe das Problem u.U. dabei, dass z.B. eine entsprechend langsame
> aber kontinuierliche Änderung des Wertes nie zu einer neuen Anzeige
> führt.
Es wird bei entsprechend schneller Wandlung sogar immer etwas 
ausgegeben. Nur, wenn der Unterschied mal zufälligerweise größer als 10% 
ist, wird einmal nichts ausgegeben. Mir erscheint diese Forderung des TO 
seltsam, deshalb hatte ich nachgefragt, wofür man sowas braucht.

Rolf schrieb:
> Aua. Du hast das Buch "Wie funktioniert eigentlich ein Computer?"
> gelesen", aber das war es dann auch schon.
Hach.

> Diese Rechenaufgabe war schon vor 50+ Jahren für den 4-Bit-µP Intel 4004
> ein Klacks, sowohl von der Programmlänge als auch von der Laufzeit.
Aber sie war auch auf dem 4004 mit einer Zweierpotenz schneller als mit 
einer Zehnerpotenz.

> Wenn man tatsächlich unnötigerweise in Assembler programmieren würde
Ja, tatsächlich: der Compiler "programmiert" in Assembler. Ob das nötig 
ist, kann nur ein Compilerbauer abschätzen. Und eine Multiplikation mit 
8 geht bei geeignetem Variablentyp schneller als ein mit 10.

Mi N. schrieb:
> solange Rechenzeit und Speicher ausreichend sind.
Du kennst den Rest der Aufgabe nicht. Und hier schlagen laufend Leute 
auf, die auf dem AVR alles Float rechnen und dann jammern, der wäre zu 
langsam oder das Programm würde seltsame Dinge machen.

Oder andersrum: wenn ich von vorn herein "binär" denke und programmiere, 
dann spare ich mir hinterher die Fehlersuche, die durch 
"Rechenzeitverplemperung" nötig ist.

: Bearbeitet durch Moderator
von Mi N. (msx)


Lesenswert?

Lothar M. schrieb:
> Mi N. schrieb:
>> solange Rechenzeit und Speicher ausreichend sind.
> Du kennst den Rest der Aufgabe nicht. Und hier schlagen laufend Leute
> auf, die auf dem AVR alles Float rechnen und dann jammern, der wäre zu
> langsam oder das Programm würde seltsame Dinge machen.

Den Rest der Aufgabe kennst auch Du nicht und mir fallen immer die Leute 
auf, die antiquarische Vorbehalte gegen 'float' äußern. Man kann die 
Sache ja auch Intergerebene bequem mit Faktor 10 verarbeiten.

> Oder andersrum: wenn ich von vorn herein "binär" denke und programmiere,
> dann spare ich mir hinterher die Fehlersuche, die durch
> "Rechenzeitverplemperung" nötig ist.

Das ist doch albern!

von Klaus H. (hildek)


Lesenswert?

Lothar M. schrieb:
> Es wird bei entsprechend schneller Wandlung sogar immer etwas
> ausgegeben. Nur, wenn der Unterschied mal zufälligerweise größer als 10%
> ist, wird einmal nichts ausgegeben.

Ja, du hast recht - meine Lesekompetenz :-(.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Mi N. schrieb:
> Das ist doch albern!
Kam doch letzthin wieder einer der Praktikanten zu mir und sagte: "Der 
µC ist zu langsam, der schafft die Rechnung in den nötigen 100µs nicht!"

Ich habe ihm dann in etwa das selbe gesagt wie du und ihm geholfen, die 
Berechnung in diesen 100µs locker zu schaffen. Und ja, wir haben dazu 
auch den vom Compiler erzeugten Assembler angeschaut.

> mir fallen immer die Leute auf, die antiquarische Vorbehalte gegen
> 'float' äußern.
Mir fallen immer wieder Leute auf, die ihr Unwissen mit Rechenleistung 
erschlagen.

Am 32-Bit Float stört mich übrigens am meisten, dass er nur 6 
signifikante Stellen hat. Deshalb nehme ich im Zweifelsfall (und vor 
allem, wenn ich die Dynamik eines Float nicht brauche) lieber einen 
32-Bit Integer.

: Bearbeitet durch Moderator
von Bernd N. (_bn_)


Angehängte Dateien:

Lesenswert?

Mi N. schrieb:
> Welchen Sinn da haben soll? Vielleicht sollen nur die 'wahren' Werte
> angezeigt werden.

Lothar M. schrieb:
> Mir erscheint diese Forderung des TO
> seltsam, deshalb hatte ich nachgefragt, wofür man sowas braucht.

Man kann solche Strategien z.B. zur Messwertberuhigung verwenden. Ab 
einem gewissen Delta folgt die Anzeige schnell, innerhalb eines Delta 
folgt die Anzeige in 1 mV Schritten. Ich habe mal ein altes Beispiel von 
mir angehangen. Vielleicht hilft es ja zum Verständnis. Den Rest sollte 
der TO beisteuern.

von Manfred P. (pruckelfred)


Lesenswert?

Steve van de Grens schrieb:
> Ich hätte bis vor kurzem auch nicht gedacht, dass ich mir Gedanken über
> Alternativen zu Klopapier machen musste. Dass es mal weder Nudel noch
> Mehr zu kaufen geben würde.

Klopapier ist hier schon immer bevorratet. Als geiziger Mensch achte ich 
auf Preise und lagere haltbare Artikel großzügig ein. Was Elektronikkram 
angeht, gehe ich auch großzügig vor - lieber 50 Dioden als die 
benötigten drei kaufen, wenn der Preis passt und Aussicht auf weitere 
Anwendungen besteht.

Mi N. schrieb:
> "messwert_alt" darf erst dann angepaßt werden, wenn er auch angezeigt
> wurde. Dann würde das passen.

Das ist halt die Kunst des Entwicklers, solche Dinge zu bedenken. Wenn 
nicht gleich, bemerkt man das im Testlauf und biegt es gerade.

> Welchen Sinn da haben soll? Vielleicht sollen nur die 'wahren' Werte
> angezeigt werden.

Meine Lötstation macht um 20 Messungen pro Sekunde, da aktualisiere ich 
die Isttemperatur nur, wenn sie min. 3K vom letzen Wert abweicht. 
Schreibe ich jeden Meßwert ins Display, wird das zur Flackerdisco und 
stiehlt mir auch Zeit, die ich lieber der Regelschleife überlasse.

Lothar M. schrieb:
> Es wird bei entsprechend schneller Wandlung sogar immer etwas
> ausgegeben. Nur, wenn der Unterschied mal zufälligerweise größer als 10%
> ist, wird einmal nichts ausgegeben. Mir erscheint diese Forderung des TO
> seltsam, deshalb hatte ich nachgefragt, wofür man sowas braucht.

Da das keinen Sinn macht, habe wohl die meisten von uns interpretiert, 
dass er es anderherum meint: Wert nur ausgeben, wenn größer 10% 
Änderung.

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
Noch kein Account? Hier anmelden.