RFM69 aka SX1231: Listen Mode

[Sven P. (Gast)]

Hallo,

ich versuche den Transceiver von Semtech in Betrieb zu nehmen. An und 
für sich funktioniert das (wider Erwarten, mangels RF-Erfahrung) auf 
Anhieb ziemlich gut, nur dieser ListenMode macht mir Probleme.

Und zwar kann man den Chip damit ja so konfigurieren, dass er im 
Schlafmodus läuft und periodisch aufwacht und eine Weile nach RF sucht, 
um dann wieder schlafen zu gehen.
Ich habe ihn nun so eingestellt, dass es je eine Sekunde läuft und eine 
Sekunde schläft.

Was mir nun als erstes auffällt: Laut Datenblatt soll der Chip die 
Nachtruhe im Mode verbringen, also dem Modus, den man im RegOpMode 
einstellt. In der Wachphase läuft er natürlich sinnvollerweise im 
RxMode.
Wenn ich nun das RegOpMode polle, während der Chip seinem 
Tagesrhythmus nachgeht, dann stelle ich aber fest, dass er zwischen 
RxMode und SleepMode wechselt:

... 00 00 00 00 00 00 00 00 04 04 04 04 04 04 04 04 04 00 00 00 00 00 00 00 00 00 ...

(Einfach nur in einer Schleife das Register gepollt und 2 Bit nach 
rechts geschoben, damits leichter zu lesen ist; 04 ist Rx, 00 ist 
Sleep).

Das ist blöd, weil im SleepMode der Quarz abgeschaltet wird, und aus 
dem gewinne ich per ClkOut-Ausgang meinen Prozessortakt. Gut, testweise 
lasse ich den Prozessor nun mit internem RC laufen.
Bug im Chip oder Fehler im Datenblatt? Das Datenblatt spricht von 
"Idle"-Modus, den gibts aber nirgendwo. Eventuell meinen die damit ja 
den Sleep-Modus.


Dann habe ich den Ausgang Dio0 auf PayloadReady konfiguriert, um den 
Prozessor später aufzuwecken bzw. einen Interrupt auszulösen. Das 
/PayloadReady/-Signal kommt auch und der Interrupt startet. Im Interrupt 
lese ich dann das RegIrqFlags2 aus, in dem sich das dazugehörige 
/PayloadReady/-Bit befindet. Aus mir unverständlichen Gründen wird 
dieses Bit automatisch gelöscht:

for (;;) {
    uint8_t f = read(RegIrqFlags2);
    if (f & IrqFlags2_PayloadReady) {
        uint8_t b[16];
        for (int i = 0; i < 5; i++)
            b[i]=read(RegIrqFlags2);

        for (int i = 0; i < 5; i++)
            printf("flags %02X\n", b[i]);

        // Payload aus dem FIFO abholen...
    }
}

Ergibt mit einem Sender, der im Sekundentakt ein Paket schickt, im 
Sekundentakt folgendes:

flags 66
flags 60
flags 60
flags 60
flags 60

Die untere 0x06 enthält PayloadReady und CrcOk, d.h. die Übertragung 
funktioniert einwandfrei. Wohl gemerkt, die beiden Bits verschwinden von 
alleine, bevor die Payload aus dem FIFO gelesen wurde!
Das ist auch wieder ziemlich doof, denn wenn der Interrupt ausgelöst 
wird, könnte das Bit schon weg sein - warum auch immer.

Bis auf die Paketlänge und das SyncWord ist der Chip weitestgehend in 
den Standardeinstellungen aus dem Datenblatt konfiguriert.

Für Ideen wäre ich dankbar...

Danke und Grüße,
K

[Christian S. (roehrenvorheizer)]

"Periodically the receiver is woken up and listens for an RF signal. If 
a wanted signal is detected, the receiver is kept on and the data is 
demodulated."

Die Beschreibung im Dabla ist auch extrem dürftig.


Hast Du mal diese Einstellungen ausprobiert?
"Table 19 End of Listen Cycle Actions "

"RegAutoModes "  auf intermediate Standby umgestellt?

MfG

[Sven P. (Gast)]

Christian S. schrieb:
> "RegAutoModes "  auf intermediate Standby umgestellt?
Da verändert sich nichts, habs gerade ausprobiert.

Christian S. schrieb:
> "Table 19 End of Listen Cycle Actions "
Jo, da wirds noch beknackster :)
Das Problem entsteht, wenn ein kaputtes Paket empfangen wird. Der 
Empfang eines Paketes im ListenMode beginnt nämlich schon, wenn 
Präambel+Syncword (ListenCriteria = 1) erkannt wurden, d.h. das Paket 
kann immer noch Müll sein (CRC falsch oder Paket zu kurz 
beispielsweise). Trotzdem hat der Empfang aber begonnen und der Chip 
macht das, was als ListenEnd eingestellt wurde.

Es gibt da im drei Einstellugen, nämlich
- "00" um nach dem Empfang im Rx zu bleiben, egal ob das Paket gültig 
ist oder nicht.
- "10" um nach dem Empfang eines gültigen Paketes (also PayloadReady) 
oder nach einem kaputten Paket (Timeout) gleich wieder weiterzumachen 
mit dem ListenMode und
- "01", um nach Empfang eines Paketes oder nach Timeout den ListenMode 
zu beenden und  in Mode zu wechseln.


Für den Empfang ergibt das folgende Möglichkeiten:
- Paket ist in Ordnung -> PayloadReady kommt, löst Interrupt aus, FIFO 
wird abgeholt. Danach kann man den Chip in irgendeinen Modus versetzen, 
oder er geht automatisch wieder in den ListenMode.
- Paket ist kaputt -> PayloadReady kommt nicht, dafür schlägt das 
Timeout zu. Mit ListenEnd = "10" gehts dann im ListenMode weiter, mit 
den anderen Modes hängt das System, weil der Prozessor nichts mitkriegt.

Soweit ich das verstehe, gibt es halt keine sinnvoll nutzbare 
Interrupt-Leitung, um das Timeout zu erwischen und den ListenMode neu zu 
starten. Wirklich nutzbar bleibt also nur der /ListenEnd/-Modus "10", 
denn der macht einfach so lange weiter, bis wirklich PayloadReady 
kommt und ein gültiges Paket empfangen wurde.

Hoffentlich versteh ich was falsch :)

[Christian S. (roehrenvorheizer)]

Vor einiger Zeit, als ich mit dem Automode experimentieren wollte, bekam 
ich ähnliche Probleme mit der korrekten Abfrage der Flags. Der Zeitpunkt 
der Abfrage änderte oft deren Ergebnis. Automode habe ich dann nicht 
mehr benutzt wegen der umständlichen bis unmöglichen Handhabung der 
Ereignisse.

Aber diese Erkenntnis hilft Dir nicht weiter.

MfG

[Sven P. (Gast)]

Christian S. schrieb:
> Aber diese Erkenntnis hilft Dir nicht weiter.
Ne, aber zu derselben Erkenntnis bin ich auch schon gelangt...

Grüße