EEPROM - ausgelesener Wert ist ungenau

[HaWe]

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.

danke, aber das erklärt IMO die Abrundung bei 8820 zu 8800 nicht ausreichend (CMIIW).

Daher würden mich auch andere damalige aufgetretene "Fehler" interessieren, und auch der komplette Rechenweg.

[Moppi]

Aber so, wie es ausschaut, gab es kein anderes Problem. Ich denke, das wars.

@basteluwe weiß mehr, ist sein Projekt.

Gruß

[HaWe]

Aber so, wie es ausschaut, gab es kein anderes Problem. Ich denke, das wars.
@basteluwe weiß mehr, ist sein Projekt.
Gruß

Das kanns nicht gewesen sein, siehe 8820 -> 8800.
genau deswegen bat ich ja um weitere Informationen von basteluwe.

[basteluwe]

Oh Ha! Hier ging ja noch richtig die Post ab!
Danke für eure ganzen Beiträge. Ich gebe mal ein Update, um vielleicht etwas Licht in's Dunkel zu bringen.

Das Problem ist tatsächlich für mich gelöst! Der im Post #14 von mir gezeigte Code funktioniert einwandfrei unter den bei mir gegebenen Bedingungen:

Die wichtigste Änderung im neuen Code zum ursprünglichen ist der Punkt an dem ich radio.getFrequency() aufrufe. Ursprünglich habe ich das jedes Mal nach einem Scan-Befehl getan. Zum Debuggen hatte ich dann im Terminal die zurück gemeldete Frequenz anzeigen lassen. Die stimmte sehr oft nicht mit der aktuell wiedergegebenen überein. Pausen vor und nach dem Befehl änderten nichts an der Abweichung.
Schließlich habe ich getFrequency einfach in die Hauptschleife gebaut und über "millis" nur alle 5 Sekunden aufgerufen. Zusätzlich habe ich EEPROM.update entdeckt, das nur bei Änderungen einen neuen Wert in den EPROM schreibt. Mit diesen Änderungen läuft der Code seit Gestern ohne jedes Problem.
Ich habe aber nach wie vor keine Ahnung warum die Abfrage im ursprünglichen Code teilweise falsche Ergebnisse lieferte, aber egal: Problem solved!

Ich sollte noch was zu den Bedingungen sagen, die zu der verwendeten Umrechnung geführt haben:

Sämtliche Sender in unserer Ecke liegen im 100KHz Raster, der frequency-Wert endet also hier IMMER auf 0, niemals auf 5.
Bei einem Frequenzbereich 87,00 - 108,00 MHz ergaben sich also 210 mögliche frequency-Werte.
Um von den richtigen Werten (8700 bis 10800) auf byte-Format zu kommen, das EEPROM.put und EEPROM.get verlangt, habe ich die Formel storeFreq=(frequency/10)-825 "erfunden". Damit liegen die Speicherwerte zwischen 45 (87,0 MHz) und 255 (108,0 MHz).

Mir ist klar, das das nur für meine spezielle Anwendung geht und nicht sehr elegant ist. Es erfüllt aber meinen Zweck, ich bin halt kein Profi-Coder.

Ich bin wirklich dankbar für Eure Hilfe, das ist schon ein Spitzen-Forum hier!

Uwe

- - - Aktualisiert - - -

Immerhin scheint es aber jetzt ja auf magische Weise nicht mehr relevant zu sein, daher würde mich schon interessieren, wie was vorher berechnet, gespeichert und zurückgerechnet wurde, als der Fehler beim Zurücklesen/rechnen des Speicherwertes noch auftrat.

Sorry, die Frage hatte ich überlesen.
Im ursprünglichen Code gab es keine Umrechnung! Ich hatte get und put für den EEPROM verwendet, weil ich meine, dass die integer handeln können. Also habe ich den Wert aus getFrequency direkt in den EPROM gespeichert.
Im neuen Code verwende ich für den EEPROM update, das leider nur byte akzeptiert. Daher jetzt die Umrechnung storeFreq = (frequency/10)-825;

Uwe

[HaWe]

Ursprünglich habe ich das jedes Mal nach einem Scan-Befehl getan.

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

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

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