EEPROM - ausgelesener Wert ist ungenau

[Moppi]

Vernünftig ist das. Man muss wissen, was man tut.
Theor. könnte man den Spannungsausfall feststellen und Schaltung bauen, die den Betrieb sicherstellt, bis der Wert geschrieben wäre. Also ca. eine Sekunde(?). Wen der nur einmal pro Frequenzwechsel reinschreibt, ist ja alles gut. Man hätte annehmen können, dass der das pro Scan mehrere Male macht.

MfG

[HaWe]

naja, also ehrlich: wenn man gerade die Frequenz frisch gewechselt hat, kann man auch 5 sec warten, bevor man den Stöpsel zieht...

so wie es aussieht, lag dann ja der Fehler also weder an radio.getFrequency() noch an korrumpierten EEPROM Daten, oder?

[Moppi]

Hatte basteluwe nicht irgendwo geschrieben, dass der Wert, den er von der Funktion liest, nicht der Frequenz entspricht, die eingestellt war? Dass muss man dann zu dem Zeitpunkt mal so annehmen, dass das stimmt. Aber wie sich herausstellt, ist es wohl so nicht gewesen. Der Wert wird nicht gestimmt haben, nachdem er ihn aus dem EEPROM gelesen hat, zum Erneuten Einstellen der Frequenz.

Meine Glaskugel sagt: Irgendwo muss der Fehler bei der ungewollten Umrechnung in irgendwas passiert sein.

Das Problem lag wohl hier:


1. EEPROM.put(0, frequency); // neue Frequenz in EEPROM speichern
2. EEPROM.get(0, frequency);


EEPORM.put() wird wohl dann bei dem Wert 10625 nur 129 (die unteren 8 Bit) speichern, wenn die Funktion nur byteweise ins EEPROM schreibt. Damit ist die Frequenz futsch. Kann auch möglich sein dass die put-Funktion zwei Byte ins EEPROM schreibt, nämlich High und Low-Byte, aber nur ein Byte zurückgelesen wird, gäbe auch nichts genaues. Und falls das Folgebyte im EEPROM, an Position #1, für andere Zwecke gebraucht wird, würde das direkt mit überschrieben, falls zwei Byte ab Position #0 geschrieben werden.
Durch den Umweg mit Frequenz/10 minus 825, den basteluwe hinzugefügt hat, funktioniert es dann, er übergibt put() nur noch ein Byte und da ist die Frequenz dann drin. Vorher war sie ja in zwei Byte drin.

Da es basteluwe ja selbst nicht nachvollziehen kann, können wir das Phänomen nicht ergründen.

Ist auch egal, weil es für ihn keine Rolle mehr spielt. Und letzten Endes sind die verschiedenen Vermutungen auch vorher schon im Thread mal hier und da geäußert worden.

Manchmal führen die einfachsten Fehler zu den merkwürdigsten Problemen, in denen man zeitweise sogar glaubt, eine Regel zu erkennen - hinterher kann man dann nicht sagen, warum Fehler verschwunden sind.
Das menschliche Gehirn trügt auch oft, durch Vereinfachen oder Ersetzen fehlender Informationen. Da muss man keine mathematische Formel mit Herleitung haben, sondern nur die Größe das einzugestehen.


MfG

[HaWe]

Nein, es kann NICHT an einzelnen Bytes iiegen, die verloren gehen, denn dadurch wäre der Fehler von 8820 zu 8800 nicht erklärbar!
Denn dann müsste entweder nur der MSB- oder nur der LSB-Wert zurückkommen, also in jedem Fall <=255, was aber nicht der Fall ist.
Auch ist das EEPROM nie "ungenau", wie es noch im Titel heißt und so auf der 1. Seite hier viele vermutet Datenkorruption haben.
EEPORM.put andererseits kann ohne weiteres auch ints schreiben, nicht nur bytes.

basteluwe:
ich fände es wirklich interessant, wenn du den Fehler eingrenzen könntest, nachdem du ja gezeigt hast, dass radio.getFrequency richtig funktioniert.
Was machen also die Scan-Befehle oder sonstige weitere Befehle unmittelbar davor und unmittelbar danach?

[Moppi]

Also ist das die Möglichtkeit! DOCH kann es NUR an einzelnen Bytes oder Bits liegen, die CPU verarbeitet nichts anderes.

So, gut jetzt

MfG

[HaWe]

Also ist das die Möglichtkeit! DOCH kann es NUR an einzelnen Bytes oder Bits liegen, die CPU verarbeitet nichts anderes.

So, gut jetzt

MfG

nein, das musst du erklären: wie soll es an nur 1 einzelnen verlorenen Byte beim Lesen oder Schreiben im EEPROM liegen, wenn die ursprüngliche Version auf glatte 100er abrundet, z.B. von 8820 auf 8800 ??
Ich habe gereits gezeigt, dass das nicht an einem komplett verloren gegangenen LSB und erst recht nicht an einem verlorenen MSB liegen kann, siehe hier, bereits auf der 1. Seite: https://www.roboternetz.de/community...l=1#post647127
Und auch nicht irgendwie an radio.getFrequency, denn das funktioniert ja IMMER, wie bereits gezeigt.
Und reine (statistische) Datenkorruption muss hingegen eine Gaussche, statistische Fehlerverteilung vom ursprünglichen Wert sowohl nach oben als auch nach unten gleichermaßen führen, was der OP auch nicht bestätigen konnte.
Oder wie erklärst du das Runden auf glatte 100er mit deinen verlorenen LSB oder MSB?!

also nochmal

basteluwe:
ich fände es wirklich interessant, wenn du den Fehler eingrenzen könntest, nachdem du ja gezeigt hast, dass radio.getFrequency richtig funktioniert.
Was machen also die Scan-Befehle oder sonstige weitere Befehle unmittelbar davor und unmittelbar danach?

EDIT:
und nochmal ergänzt, hatte ich auch schon öfter erbeten:
wie sahen andere Beispiele damals aus, wo es zu Abweichungen kam? (10 Beispiele mindestens).
Vielleicht waren es ja nicht immer Abrundungen, wie es sich bislang anhörte - oder doch?

[Moppi]

Schau mal an den Anfang des Threads, da hatte er den Code doch reingestellt.

Gruß

[HaWe]

ich verstehe nicht die einzenen Funktionen, was die genau mit welcher Konsequenz machen oder machen sollen,
und auch nicht den komplexen Code im Zusammenspiel.

Auch radio.getFrequency verstehe ich in seiner Funktionsweise nicht, ich sehe nur, dass es aus logischen Gründen nicht daran liegen kann, ebensowenig an komplett verloren gegangenen Bytes.

Daher aber auch neben allem anderen: man muss die genauen Fehler mal aufgelistet sehen, um sie analysieren zu können.

[basteluwe]

OK, ich versuch es mal aus meiner Sicht als interessierter Laie:

Die Befehle radio.seekDown(), radio.seekUp() und radio.getFrequency funktionieren jeder für sich ohne jedes Problem! Das ist Fakt!
Es ist die falsche Verwendung/Kombination, die Probleme macht.

Beim Schreiben des ursprünglichen Codes war ich von der Annahme ausgegangen, das das Radio die erhaltenen I2C Befehle der Reihenfolge nach abarbeitet und den zweiten Befehl erst nachdem der erste fertig ist, also den get.Frequency erst nachdem seek.Up/Down fertig ist. So ist es aber nicht!

 if(!digitalRead(button_3) ) {               // wenn Taster 3 gedrückt, abwärts scannen   
   while(!digitalRead(button_3) )             // warten auf Taster loslassen == HIGH
      {delay(10);}
      radio.seekDown();
      delay(100);
      frequency = (radio.getFrequency());     // neue Frequenz aus RDA5807M auslesen
      delay(100);
      EEPROM.put(0, frequency);               // neue Frequenz in EEPROM speichern
      delay(100);
      }

Im Code seht ihr, dass ich nach seek... jeweils nur 100 millis gewartet hatte, bis ich die neue Frequenz abgefragt habe. Es braucht aber durchaus länger, bis er eine neue Frequenz eingestellt hat! Das kann schon eine Sekunde oder länger dauern. Wie gesagt, dachte ich, er würde warten mit dem Senden der neuen Frequenz, bis er mit seek... fertig ist. Ganz offensichtlich tut er das nicht, sondern beantwortet getFrequency sobald er gefragt wird, unabhängig ob seek... schon fertig ist oder nicht! Daher passiert es, das ein zu frühes getFrequency sozusagen ein "Zwischenergebnis" anzeigt, nicht die endgültig neue Frequenz.

Um das zu beweisen, habe ich in den ursprünglichen (fehlerhaften) Code eine zweite Abfrage erst nach 1000 millis eingefügt.
Hier das Ergebnis im Terminal:

Das Zwischenergebnis ist nach 100 millis gemessen, das Endergebnis nach 1000. Bei sechs Abfragen sind zwei Fehlergebnisse dabei.
Für mich ist damit das Problem gelöst. Es war kein Problem in irgendeinem Befehl oder Library, sondern einfach nur dumm programmiert! Man muss dem Radio genügend Zeit geben, die neue Frequenz einzustellen, bevor man sie abfragt. So einfach ist das.

Gruß Uwe

[oberallgeier]

.. Man muss dem Radio genügend Zeit geben, die neue Frequenz einzustellen, bevor man sie abfragt. So einfach ist das ..

So ein Problem ist im Betrieb von chemisch-physikalischen Laboren bekannt beim Abwägen von Mengen. Dort beschreibt man es mit "Wägen bis zur Gewichtskonstanz". Daher könnte es eine sichere Abfragemethode geben: abfragen1, kurz warten, abfragen 2 - wenn a1==a2 dann (zur Sicherheit vielleicht noch mal) ist der WErt ok, wenn a1 != a2 dann nochmal warten, nochmal abfragen und vergleichen a2 mit a3 usf. Bis zur "Wertekonstanz".