RFM69CW, wer kann helfen?

[Bruno M. (brumay)]

Hallo,

ich versuche seit geraumer Zeit eine Kommunikation zwischen zwei 
RFM69CW, bzw. auch RFM69 und RFM12 hinzubekommen. Leider keinerlei 
Empfang. Zwei RFM12 sind kein Problem!
Ich meine zwar, daß alle Register die ich auslese richtig sind, aber 
irgend etwas ist ja offensichtlich falsch. Wer hat Erfahrung und kann 
raten?

[Peter (Gast)]

Ja, schon mal erfolgreich gemacht. Aber lang her.

Wichtig ist wohl, beim RFM69 das Whitening und CRC auszuschalten.

Des weiteren muss der RFM12 eine korrekte Preamble schicken, sonst 
springt der RX beim RFM69 nicht an.

Zeig mal Code und Initialisierung...

[Bruno M. (brumay)]

Danke für die Antwort!

Der Code ist in asm, deswegen habe ich ihn nicht angehängt, weil ich 
damit offensichtlich abschreckend wirke.

Ich habe mal den Registerstatus angehängt, wie ich ihn nach der 
Initialisierung auslesen kann.

[Peter S. (peter_su)]

Hmmm, da sind noch zu viel Unbekannte.
- feste Paketlänge?
- Interrupt oder Polling?
- RSSI-Schwelle?

...und ja: auch mich schreckt das Lesen von langem ASM-Code ab.

Welche Status-Register sind im "Status.txt" (Ich vermute die vom RFM69)

Beim RFM69 würde ich setzen:
Register 0x2E = 0x88 // REG_SYNCCONFIG = RF_SYNC_ON | RF_SYNC_SIZE_2
Register 0x2F = 0x2D // REG_SYNCVALUE1 = 0x2D
Register 0x30 = 0xD4 // REG_SYNCVALUE2 = networkID
Register 0x37 = 0x80 // REG_PACKETCONFIG1 = RF_PACKET1_FORMAT_VARIABLE
Register 0x3D = 0x12 // REG_PACKETCONFIG2 = 
RF_PACKET2_RXRESTARTDELAY_2BITS | RF_PACKET2_AUTORXRESTART_ON

Ansonsten hatte ich mir geholfen, in dem ich beim RFM69 auf 
Continuous-RX gestellt hatte und
den Empfangs-FIFO dauerhaft ausgeprinted habe.

Nützt Dir C++ - Code etwas?

[Bruno M. (brumay)]

Anliegend die Daten noch als hex, falls es so übersichtlicher sein 
sollte.

[Bruno M. (brumay)]

Peter S. schrieb:
> Welche Status-Register sind im "Status.txt" (Ich vermute die vom RFM69)

richtig vermutet.

> Nützt Dir C++ - Code etwas?

Ich kann einigermaßen nachvollziehen was passiert, aber selbst schreiben 
kann ich nicht.

Ich habe z.B. den Code von Felix Pflaum, den ich zum probieren nutzen 
könnte, aber wenn ich das richtig sehe ist das zwar eine main für den 
Empfang, aber nichts zum senden.

[Bruno M. (brumay)]

Peter S. schrieb:
> Beim RFM69 würde ich setzen:
> Register 0x2E = 0x88 // REG_SYNCCONFIG = RF_SYNC_ON | RF_SYNC_SIZE_2

Im Vergleich zu meinen Werten ist mir aufgefallen, daß bei mir in 0x2E = 
0x00 steht. Das kann ja auch nicht funktionieren. Das werde ich gleich 
mal ändern!

[Bruno M. (brumay)]

Doch noch eine Nachfrage:

0x88 = 0b10001000

bit 7   = 1 = Sync on
bit 6   = 0 = FIFO filling condition: if SyncAddress interrupt occurs
bit 5-3 = 001 = Sice of Sync word: 1 byte ??
bit 2-0 = 000

[Peter S. (peter_su)]

RFM69:
#define RF_SYNC_SIZE_1            0x00
#define RF_SYNC_SIZE_2            0x08
#define RF_SYNC_SIZE_3            0x10
#define RF_SYNC_SIZE_4            0x18
#define RF_SYNC_SIZE_5            0x20
#define RF_SYNC_SIZE_6            0x28
#define RF_SYNC_SIZE_7            0x30
#define RF_SYNC_SIZE_8            0x38

Das Sync-Word beim RFM12 ist per default (2 Bytes):
0x2D (fest)
   und
0xD4 (einstellbar)

So muss beim RFM69 "RF_SYNC_SIZE_2" = 0x08 gesetzt sein.

[Bruno M. (brumay)]

Peter S. schrieb:
> So muss beim RFM69 "RF_SYNC_SIZE_2" = 0x08 gesetzt sein.

Danke für den Hinweis, hatte ich natürlich auch schon mal gelesen, aber 
wieder vergessen.

Ich habe 0x2E jetzt auf 0x88 geändert, aber leider trotzdem kein Erfolg. 
So einfach war es dann wohl doch nicht.

[Peter S. (peter_su)]

Meine Init-Werte...
- ohne Frequenz
- ohne Baudrate
- mit Interruptbetrieb
- mit Whitening (ggf. rausnehmen: RF_PACKET1_DCFREE_WHITENING)
- mit CRC (ggf. rausnehmen: RF_PACKET1_CRC_ON)

/* 0x01 */ { REG_OPMODE, RF_OPMODE_SEQUENCER_ON | RF_OPMODE_LISTEN_OFF | RF_OPMODE_STANDBY },
/* 0x02 */ { REG_DATAMODUL, RF_DATAMODUL_DATAMODE_PACKET | RF_DATAMODUL_MODULATIONTYPE_FSK | RF_DATAMODUL_MODULATIONSHAPING_00 }, // no shaping
/* 0x05 */ { REG_FDEVMSB, RF_FDEVMSB_90000}, // default: 5KHz, (FDEV + BitRate / 2 <= 500KHz)
/* 0x06 */ { REG_FDEVLSB, RF_FDEVLSB_90000},
/* 0x19 */ { REG_RXBW, RF_RXBW_DCCFREQ_010 | RF_RXBW_MANT_16 | RF_RXBW_EXP_2 }, // (BitRate < 2 * RxBw)
/* 0x25 */ { REG_DIOMAPPING1, RF_DIOMAPPING1_DIO0_01 }, // DIO0 is the only IRQ we're using
/* 0x26 */ { REG_DIOMAPPING2, RF_DIOMAPPING2_CLKOUT_OFF }, // DIO5 ClkOut disable for power saving
/* 0x28 */ { REG_IRQFLAGS2, RF_IRQFLAGS2_FIFOOVERRUN }, // writing to this bit ensures that the FIFO & status flags are reset
/* 0x29 */ { REG_RSSITHRESH, 170 }, // must be set to dBm = (-Sensitivity / 2), default is 0xE4 = 228 so -114dBm <-------- ACHTUNG, zuviel dBm verursachen ziemlich fehlerhaften Empfang
/* 0x2E */ { REG_SYNCCONFIG, RF_SYNC_ON | RF_SYNC_FIFOFILL_AUTO | RF_SYNC_SIZE_2 | RF_SYNC_TOL_0 },
/* 0x2F */ { REG_SYNCVALUE1, 0x2D },      // attempt to make this compatible with sync1 byte of RFM12B lib
/* 0x30 */ { REG_SYNCVALUE2, networkID }, // NETWORK ID
/* 0x37 */ { REG_PACKETCONFIG1, RF_PACKET1_FORMAT_VARIABLE | RF_PACKET1_DCFREE_WHITENING | RF_PACKET1_CRC_ON | RF_PACKET1_CRCAUTOCLEAR_ON | RF_PACKET1_ADRSFILTERING_OFF },
/* 0x38 */ { REG_PAYLOADLENGTH, 66 }, // in variable length mode: the max frame size, not used in TX
/* 0x3C */ { REG_FIFOTHRESH, RF_FIFOTHRESH_TXSTART_FIFONOTEMPTY | RF_FIFOTHRESH_VALUE }, // TX on FIFO not empty
/* 0x3D */ { REG_PACKETCONFIG2, RF_PACKET2_RXRESTARTDELAY_2BITS | RF_PACKET2_AUTORXRESTART_ON | RF_PACKET2_AES_OFF }, // RXRESTARTDELAY must match transmitter PA ramp-down time (bitrate dependent)
/* 0x6F */ { REG_TESTDAGC, RF_DAGC_IMPROVED_LOWBETA0 }, // run DAGC continuously in RX mode for Fading Margin Improvement, recommended default for AfcLowBetaOn=0

Konstanten von hier:
https://github.com/LowPowerLab/RFM69/blob/master/RFM69registers.h

[Peter S. (peter_su)]

Bruno M. schrieb:
> So einfach war es dann wohl doch nicht.

falls es tröstet: ich habe mehrere Wochen damit zugebracht, RFM12 und 
RFM69 kompatibel zu bekommen.

Dafür hab ich aber die CRC-Generierung und das Whitening in Software für 
den RFM12 geschrieben. Der RFM69 kann ja beides in Hardware.

[Bruno M. (brumay)]

Peter S. schrieb:
> alls es tröstet: ich habe mehrere Wochen damit zugebracht, RFM12 und
> RFM69 kompatibel zu bekommen.

Mir würde es ja schon reichen, wenn zwei RFM69 miteinander sprechen 
würden. Das kann doch eigentlich nicht so schwierig sein, wenn man die 
gleiche Initialisierung benutzt.

[Bruno M. (brumay)]

Peter S. schrieb:
> Register 0x3D = 0x12 // REG_PACKETCONFIG2 =
> RF_PACKET2_RXRESTARTDELAY_2BITS | RF_PACKET2_AUTORXRESTART_ON

wodurch ergeben sich die 2 bits delay?

[Andreas Z. (andreas_z15)]

Hast du schon mal auf der Seite von JeeLabs nachgesehen. Da gibt es eine 
Lib für Arduino die mit RFM12 und RFM69 funktioniert. Ich habe es bei 
mir implementiert und es funktioniert. Allerding gibt es Probleme mit 
dem ACK zwischen verschiedenen Modulen.

Andreas

[Peter S. (peter_su)]

Laut Datenblatt:

After PayloadReady occurred, defines the delay between FIFO empty and the start of a new RSSI phase for next packet. Must match the transmitter’s PA ramp-down time.

Ich denke, das ist die minimale Zeit zwischen Ende eines Paketes und dem 
Start eines Folgepaketes. Ist aber sicher nicht kriegsentscheidend und 
muss sicher nicht genau zum Sender passen).

Empfängst Du per Polling oder Interrupt?

Und bedenke, der RFM69 hat einen Sequencer drin, der den Ablauf zwischen 
RX/TX und Standby handhabt.

Nach dem Umschalten muss man warten:

void RFM69::setMode(uint8_t newMode)
{
  switch (newMode) {
    case RF69_MODE_TX:
      writeReg(REG_OPMODE, (readReg(REG_OPMODE) & 0xE3) | RF_OPMODE_TRANSMITTER);
      break;
    case RF69_MODE_RX:
      writeReg(REG_OPMODE, (readReg(REG_OPMODE) & 0xE3) | RF_OPMODE_RECEIVER);
      break;
    case RF69_MODE_SYNTH:
      writeReg(REG_OPMODE, (readReg(REG_OPMODE) & 0xE3) | RF_OPMODE_SYNTHESIZER);
      break;
    case RF69_MODE_STANDBY:
      writeReg(REG_OPMODE, (readReg(REG_OPMODE) & 0xE3) | RF_OPMODE_STANDBY);
      break;
    case RF69_MODE_SLEEP:
      writeReg(REG_OPMODE, (readReg(REG_OPMODE) & 0xE3) | RF_OPMODE_SLEEP);
      break;
    default:
      return;
  }

  int max_tries = 20000;
  while (((readReg(REG_IRQFLAGS1) & RF_IRQFLAGS1_MODEREADY) == 0x00) && (max_tries-- > 0)); // wait for ModeReady
}

[Bruno M. (brumay)]

Peter S. schrieb:
> Empfängst Du per Polling oder Interrupt?

Z.Zt. überwache ich das PayloadReady Bit (Bit 2 von RegIrqFlag2 0x28).

Ich habe aber auch schon versucht den FIFO ständig auszulesen.

Den Sender habe ich so eingestellt, daß er laufend (mit kurzen Pausen) 
sendet.

Peter S. schrieb:
> Nach dem Umschalten muss man warten:

Ich schalte z.Zt. nicht um!

[Peter S. (peter_su)]

Bruno M. schrieb:
> Z.Zt. überwache ich das PayloadReady Bit (Bit 2 von RegIrqFlag2 0x28).
Genauso - korrekt.

...

Schreibe gelegentlich:

writeReg(REG_PACKETCONFIG2, (readReg(REG_PACKETCONFIG2) & 0xFB) | 
RF_PACKET2_RXRESTART);

Das startet den RX-Fifo neu.

Mein RX-Init sieht so aus:

void RFM69::rx_enable()
{
  setMode(RF69_MODE_STANDBY);
  if (readReg(REG_IRQFLAGS2) & RF_IRQFLAGS2_PAYLOADREADY)
    writeReg(REG_PACKETCONFIG2, (readReg(REG_PACKETCONFIG2) & 0xFB) | RF_PACKET2_RXRESTART); // avoid RX deadlocks
  writeReg(REG_DIOMAPPING1, RF_DIOMAPPING1_DIO0_01); // set DIO0 to "PAYLOADREADY" in receive mode
  setMode(RF69_MODE_RX);
}

...

Ansonsten schon mal den TX-Teil getestet? (sieht man an der 
Stromaufnahme oder mit einem SDR)

[Bruno M. (brumay)]

Hurra, ich kann einen kleinen Erfolg melden. Ich empfange zumindest das 
erste Packet. Anschließend zwar Müll, aber ich habe zumindest den 
Beweis, daß sie sich verstehen!

[Sascha W. (sascha-w)]

Hallo Bruno,

anbei mal ASM-Code der bei mir auf mehreren RFM69CW läuft.
(nur RFM69 <-> RFM69)

Sascha

[Bruno M. (brumay)]

Hallo Sascha,

herzlichen Dank!! Danach habe ich schon lange gesucht.

Aber heute habe ich erstmal genug!

[Bruno M. (brumay)]

Hallo Sascha,

nochmals herzlichen Dank für deinen Code. Ich habe mich in der 
Zwischenzeit intensiv damit beschäftigt und auch einiges dazugelernt. 
Leider habe ich aber noch immer keinen Empfang, obwohl ich nur 
geringfügige Änderungen vorgenommen habe.

Folgende Anpassungen habe ich im Wesentlichen vorgenommen:

- kein Interrupt, sondern Dauerschleife bei TX und warten auf 
PayloadReady Flag bei RX.

- Software SPI statt USI

- rfm_txon vor dem Füllen des Fifo. Nach langer Suche mußte ich diese 
Änderung vornehmen, da sonst kein TXReady und kein PacketSent!

Tx funktioniert jetzt anscheinend normal, aber ich bekomme keinen 
Empfang. Am Modul kann es eigentlich nicht liegen, da beide Module als 
Sender normal funktionieren.

Hast du eventuell noch einen Tip?

[Klaus I. (klauspi)]

Wie hast Du den Reset am RFM69CW beschaltet? Bei mir funktioniert ein 
Pulldown-Widerstand (SMD 0805) direkt auf Modul gelötet am besten. 
Floaten lassen oder Pullup haben langfristig immer unreproduzierbare 
Störungen bewirkt. Mit Pulldown funktioniert mein Aussensender seit 1,5 
Jahren ohne Probleme.

Hier habe ich mal eine funktionierende Konfiguration für 433 MHz 
gepostet:
Beitrag "Re: RFM69 - Beispiel für Initialisierung gesucht"

Nutzt Du das Hersteller-Tool für die Erstellung der Konfiguration?
Beitrag "Re: RFM69 - Beispiel für Initialisierung gesucht"

[Bruno M. (brumay)]

Klaus I. schrieb:
> Hier habe ich mal eine funktionierende Konfiguration für 433 MHz
> gepostet:
> Beitrag "Re: RFM69 - Beispiel für Initialisierung gesucht"

Das hatte ich mir schon vor längerer Zeit runtergeladen, aber irgendwo 
drehe ich mich im Kreis. Außerdem arbeite ich mit 868 MHz.

Mit dem Pulldown will ich aber mal versuchen.

[Klaus I. (klauspi)]

Benutzt Du auch die Software des Chip-Herstellers?

Aber halt die Ohren steif, ist halt immer schwierig rauszufinden warum 
es jetzt nicht klappt wenn man kein laufendes System hat und auf Sender 
UND Empfänger-Seite gleichzeitig rumtüftelt. Viel Erfolg!

[Conny G. (conny_g)]

Peter S. schrieb:
> Bruno M. schrieb:
>> So einfach war es dann wohl doch nicht.
>
> falls es tröstet: ich habe mehrere Wochen damit zugebracht, RFM12 und
> RFM69 kompatibel zu bekommen.
>
> Dafür hab ich aber die CRC-Generierung und das Whitening in Software für
> den RFM12 geschrieben. Der RFM69 kann ja beides in Hardware.

Das ging mir auch so, dass ich einige Tage über mehrere Wochen damit 
zubrachte die beiden zum Reden zu bringen. Gerade die CRC-Geschichte war 
eine der Hürden. Und dann habe ich noch ein Wrapper-Protokoll für 
Paketwiederholung drüber und das bekam ich nicht so einfach kompatibel 
für beide Libs darunter. Und habe dann beschlossen ich werfe alle RFM12 
raus, die RFM69 haben sowieso sehr viel bessere Reichweite (150m vs. 
50m, jeweils durch eine Außenwand).
Habe dann eine SMD-Adapterplatine für die RFM69CW gemacht, die auf 
"Beinchen" auf dem ehemaligen Platz der RFM12 sitzt und die 
5V-3.3V-Übersetzung macht (Low Drop Spannungsregler, Spannungsteiler). 
Ziemliches Gefummel die auf die Pads der RFM12 aufzulöten, aber konnte 
damit 3 alte Schaltungen umrüsten und vermeiden alle diese Schaltungen 
neu zu machen (paar Stunden Adapterplatine vs. paar Tage ganz neue 
Platinen entwickeln).

[Bruno M. (brumay)]

Das Problem mit rfm_txon ist gelöst! Ich hatte das CS nicht wieder auf 
high gesetzt. Das hat aber nichts daran geändert, dass ich keinen 
Empfang habe.

[Sascha W. (sascha-w)]

Bruno M. schrieb:
> Das Problem mit rfm_txon ist gelöst! Ich hatte das CS nicht wieder auf
> high gesetzt. Das hat aber nichts daran geändert, dass ich keinen
> Empfang habe.
lass doch am Empfänger mal die Statusbits dauernd ausgeben, bis 
Payload-Rdy passiert ja zuvor noch einiges, evl. lässt sich damit 
erkennen wo es klemmt.
Hast du an den Modulen eine Antenne dran? Hatte bei mir schon beim 
probieren ohne Antenne das Problem das das Teil nicht auf Empfang geht 
wenn es offenbar keinen sinnvollen RSSI im Ruhezustand bestimmen kann.

Sascha

[Bruno M. (brumay)]

Sascha W. schrieb:
> lass doch am Empfänger mal die Statusbits dauernd ausgeben, bis
> Payload-Rdy passiert ja zuvor noch einiges, evl. lässt sich damit
> erkennen wo es klemmt.

Danke, daß du nochmals reinschaust!

Die Statusbits habe ich mehrfach kontrolliert. Ich kann daraus aber 
leider keine Erkenntnisse ableiten.

0x27=11011001
0x28=01100100 ?? was bedeutet FIFO strictly exceeds FifiThreshold
0x27=00010000
0x28=00000000
0x27=11011000
0x28=00000000
0x27=11011000
0x28=00000000 usw.

> Hast du an den Modulen eine Antenne dran?

Ja, Antenne ist dran. Die Schaltung funktioniert auch mit einem RFM12.

Während ich das schreibe, habe ich weiter getestet und dabei 
festgestellt, daß ich doch etwas empfange. Bei jedem Signal des Senders 
geht PayloadReady tatsächlich hoch und auch die LED leuchtet auf. Es 
wird allerdings nichts über UART ausgegeben. Warum das so ist weiß ich 
noch nicht.

Damit bin ich aber schon einen großen Schritt weiter!!!

[Bruno M. (brumay)]

Ich habe mir jetzt das Register 0x28 nach PayloadReady angesehen:

0x28=01100100

Also ist auch hier das Bit 5 gesetzt! Was bedeutet das?

[Bruno M. (brumay)]

Ich muß feststellen, das war eine schwierige Geburt, aber jetzt 
funktioniert es!!!
Allen die mitgeholfen haben, herzlichen Dank, insbesondere an Sascha.

Die Ausgabe in UART ging nicht, da ich als Empfangsroutine das 
Codesegment RFM_RX_IRQ: von Sascha (wie alles andere auch, natürlich 
leicht modifiziert!) übernommen habe. Das kann aber vom Grundsatz her 
nicht funktionieren, da beim Auslesen des FIFO nicht bei jedem Byte CS 
low und high gesetzt werden darf. Genau das passiert aber mit 
RFM_SEND_CMD.
Für alle die es eventuell interessiert anliegend der letzte Code.

[Klaus I. (klauspi)]

Freut mich, jetzt hast Du Dir Dein Wochenend-Bier verdient ;o)

[Bruno M. (brumay)]

Ich schiebe doch noch eine Frage hinterher.

Hat jemand Erfahrung mit höheren Baudraten beim RFM69? Ich hatte beim 
RFM12 immer mit 19200 gearbeitet, aber das funktioniert mit dem 69 
nicht. Oder muß man dann noch etwas anderes einstellen?

Die von Sascha verwendeten 12000 sind OK.

[Sascha W. (sascha-w)]

Hallo,

mit der Bitrate hab ich auch schon rumgespielt das gestaltet sich recht 
schwierig. An die Bitrate scheinen noch ein paar andere Register 
(Bandbreite) angepasst werden müssen.
Für das RFM22 gibt's von SiLabs ne Konfigurations-Excel-Datei mit der 
man die Registerwerte berechnen kann - da steig ich aber auch nicht ganz 
durch. Sollte evl. auch für das '69 verfügbar sein.

Sascha

[Bruno M. (brumay)]

Klaus I. schrieb:
> Nutzt Du das Hersteller-Tool für die Erstellung der Konfiguration?
> Beitrag "Re: RFM69 - Beispiel für Initialisierung gesucht"

Ich habe mir dieses Tool mal angesehen. Das sieht tatsächlich brauchbar 
aus.
Mal sehen, wie weit ich damit komme.

[Walter L. (charly2)]

Hallo,
vorweg: Seit Jahren benutze ich erfolgreich den RFM12B mit dem 
TMS320F280xx.
Wegen der Reichweite möchte ich den RFM69CW einsetzen.
Zuerst habe ich versucht, zwei RFM69CW zu verbinden (Sender - 
Empfänger). Negativ.
Danach habe ich den Sender-RFM69 auf die Frequenz, BAUT-Rate, Anzahl der 
Präambel-Bytes, Sync.-Bytes (x02D,x0D4) und Nutzdatenlänge eines im 10 
Sek.-Takt funktionierenden RFM12B-Empfänger gesetzt, in der Annahme, der 
RFM12B-Empfänger müsste jetzt den Checksummenfehler melden, da die 
Checksumme nicht stimmt, oder zu mindestens den Empfang irgendwelcher 
Daten. Der RFM69CW sendete im Sek.-Takt.
Keine Funktion.
Als Softwareunterstützung habe ich
Beitrag "Wer verwendet RFM69?"
und
Beitrag "RFM69 - Beispiel für Initialisierung gesucht"
von maggggus genutzt.

Mit der Software sind die Register auslesbar.
Der 32MHZ-Takt ist auch vorhanden.

Mittlerweile habe ich den Verdacht, dass diese CHINA-Ware im 
HF-Ausgansbereich einen Defekt hat oder falsch bestückt ist.

Wäre jemand bereit, dies bei sich in ein einem funktionieren System zu 
testen?
Weiter Konditionen über PN?
VG Walter

[Walter L. (charly2)]

Hallo,
danke. Problem gelöst.
VG Walter

[Fragen (Gast)]

Toll,

Danke für den Hinweis.

[Conny G. (conny_g)]

Walter L. schrieb:
> Hallo,
> danke. Problem gelöst.
> VG Walter

Was war das Problem?