EEPROM - ausgelesener Wert ist ungenau

[Moppi]

@basteluwe

wenn radio.getFrequency() nicht immer ein stabiles Ergebnis liefert, hättest Du auch so lange radio.getFrequency() aufrufen und den Wert vergleichen können, bis der stabil ist und erst dann speichern. Irgendwann muss der stabil sein. Jetzt machst Du es anders, da passiert in etwa dasselbe, indem Du alle 5 Sekunden den Wert liest und mit dem im EEPROM abgleichen lässt, der wird im EEPROM solange geändert, bis der sich nicht mehr ändert. Blöd ist dabei, dass Du unnötiger Weise ins EEPROM schreibst. Anders herum ist es eine konsequente Lösung. Wenn Du das andauernd so machst, speichert das Programm immer den letzten Sender, wann immer er verstellt wird. Aber nur solang bis die Schreibzugriffe dem EEPROM zu viel waren Das ist dann auch konsequent. Geplante Obsoleszenz.

Es gibt ja auch sowas wie Frequenzkorrektur, wenn der Sender abhaut, dass der sich durch Suchen den Sender wieder einfängt. So etwas war schon mal hier geschrieben, dass da noch eine Automatik im Spiel ist/sein könnte. - Spekulation.

MfG

[HaWe]

@moppi:
radio.getFrequency() funktioniert doch wie gewünscht, das Scannen vorher hat nicht funktioniert.
Daher meine Frage:

was macht dieser Scan-Befehl genau, wie lautet und funktioniert er, und warum liefert er falsche oder schwankende Ergebnisse?

[Moppi]

Wenn er einen Scan-Befehl schickt und ruft radio.getFrequency() auf, solange der Scan nicht beendet ist, wird es von radio.getFrequency() kein stabiles Ergebnis geben.

Gruß

[basteluwe]

aha, und was macht dieser Scan-Befehl genau, wie lautet und funktioniert er, und warum liefert er falsche oder schwankende Ergebnisse?

Der Befehl heisst radio.seekDown(); bzw. radio.seekUp();.
Was er genau macht und wie er funktioniert kann sicher der Programmierer der radio.h beantworten, ich in jedem Fall nicht. Die falschen Werte liefert nicht der Scan-Befehl sondern der radio.getFrequency() in zusammenhang mit dem Scan.
Ich denke, Moppi hat Recht. Vielleicht war der Scan noch nicht fertig, wenn schon getFrequency beantwortet wurde. Das könnte in der ersten Version den Fehler verursacht haben. Jetzt passiert das ja nicht mehr.
Der nackte Befehl get.Frequency liefert stabile Ergebnisse. Er wird ja in jeder Hauptschleife für die Anzeige im OLED sowieso abgefragt und die Anzeige steht stabil wie sonstwas!

Uwe

[HaWe]

Der Befehl heisst radio.seekDown(); bzw. radio.seekUp();.
Was er genau macht und wie er funktioniert kann sicher der Programmierer der radio.h beantworten, ich in jedem Fall nicht. Die falschen Werte liefert nicht der Scan-Befehl sondern der radio.getFrequency() in zusammenhang mit dem Scan.
Ich denke, Moppi hat Recht. Vielleicht war der Scan noch nicht fertig, wenn schon getFrequency beantwortet wurde. Das könnte in der ersten Version den Fehler verursacht haben. Jetzt passiert das ja nicht mehr.
Der nackte Befehl get.Frequency liefert stabile Ergebnisse. Er wird ja in jeder Hauptschleife für die Anzeige im OLED sowieso abgefragt und die Anzeige steht stabil wie sonstwas!

Uwe

also, jetzt mal logisch mitgedacht:
wenn der Befehl radio.getFrequency alleine korrekt funktioniert, dann wird er auch in Verbindung mit anderen Befehlen richtig funktionieren.
Also auch mit irgendwelchen dubiosen Scan-Befehlen.

Wenn also bei radio.getFrequency zusammen mit irgendwelchen dubiosen Scan-Befehlen Fehler auftreten, wird es nicht an radio.getFrequency liegen.
Sondern...? Na...?

Also wo wird dann wahrscheinlich oder möglicherweise irgendwas schief gelaufen sein?

[basteluwe]

@Moppi

wenn radio.getFrequency() nicht immer ein stabiles Ergebnis liefert, hättest Du auch so lange radio.getFrequency() aufrufen und den Wert vergleichen können, bis der stabil ist und erst dann speichern. Irgendwann muss der stabil sein. Jetzt machst Du es anders, da passiert in etwa dasselbe, indem Du alle 5 Sekunden den Wert liest und mit dem im EEPROM abgleichen lässt, der wird im EEPROM solange geändert, bis der sich nicht mehr ändert. Blöd ist dabei, dass Du unnötiger Weise ins EEPROM schreibst. Anders herum ist es eine konsequente Lösung. Wenn Du das andauernd so machst, speichert das Programm immer den letzten Sender, wann immer er verstellt wird. Aber nur solang bis die Schreibzugriffe dem EEPROM zu viel waren Das ist dann auch konsequent. Geplante Obsoleszenz...

Das hat mir dann doch keine Ruhe gelassen, also hab ich eine Zählvariable eingebaut, die im Terminal anzeigt, wann und wie oft in den EPROM geschrieben wird.


Das Bild zeigt das Ergebnis von 30 Betriebsminuten, in denen ich fünf mal die Scan-Funktion aufgerufen habe. Da wird also tatsächlich nur einmal je angefordertem Frequenzwechsel in den EEPROM geschrieben.
Genau genommen könnte ich die Zeitschleife von 5 Sekunden auch auf eine halbe Minute oder mehr vergrössern. Alles was ich erreichen will, ist ja nur der Neustart mit der gleichen Frequenz, wie beim Ausschalten. Solange ich nicht ausschalte, bevor die Schleife seit dem letzten Scan einmal durch ist, ist alles OK. Das würde sämtliche Scanbefehle dazwischen ignorieren und Schreibvorgänge im EPROM sparen. Wiederholtes Scannen innerhalb der Zeitspanne triggert ja kein neues Schreiben in den EPROM. Die Dauer der Schleife ist dann Ermessensfrage.
Perfekt wäre nur einmaliges Schreiben direkt beim Ausschalten. Das ginge aber wohl nur durch softwaremäßiges Ein- und Ausschalten.

[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?