EEPROM - ausgelesener Wert ist ungenau

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