EEPROM - ausgelesener Wert ist ungenau

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

[HaWe]

@basteluwe:
ahaaa, danke, jetzt ist mir das Problem klar, und so lässt sich auch alles erklären mit den beobachteten Fehlern!

[Klebwax]

Statt zu warten, bis sich die Frequenz während des Sendersuchlaufs nicht mehr ändert, könnte man auch in das Datenblatt des Radiochips schauen. Dort sind die via I2C erreichbaren Register beschrieben. Man findet dort auch das Bit, das gesetzt werden muß, um einen Seek zu starten. Und man findet ebenfalls, daß es vom Chip zurück gesetzt wird, wenn ein Sender gefunden wurde. Man braucht also nur das passende Register (0x02) zu lesen und Bit 8 auszuwerten. Dann weiß man genau, daß der Empfänger auf einen Sender eingerastet ist. Ich denke mal, so haben sich die Erfinder des Chips das gedacht.

MfG Klebwax

[PICture]

Statt zu warten, bis sich die Frequenz während des Sendersuchlaufs nicht mehr ändert, könnte man auch in das Datenblatt des Radiochips schauen.

Genau ! Änliches habe ich schon im Beitrag #3 erwähnt.