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?
Gast
#5047052
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...
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.
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?
Anliegend die Daten noch als hex, falls es so übersichtlicher sein sollte.
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.
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!
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
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.
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.
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)
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
Konstanten von hier: https://github.com/LowPowerLab/RFM69/blob/master/RFM69registers.h
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.
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.
Peter S. schrieb: > Register 0x3D = 0x12 // REG_PACKETCONFIG2 = > RF_PACKET2_RXRESTARTDELAY_2BITS | RF_PACKET2_AUTORXRESTART_ON wodurch ergeben sich die 2 bits delay?
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
Laut Datenblatt:
1 | |
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:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
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!
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:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
... Ansonsten schon mal den TX-Teil getestet? (sieht man an der Stromaufnahme oder mit einem SDR)
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!
Hallo Bruno, anbei mal ASM-Code der bei mir auf mehreren RFM69CW läuft. (nur RFM69 <-> RFM69) Sascha
Hallo Sascha, herzlichen Dank!! Danach habe ich schon lange gesucht. Aber heute habe ich erstmal genug!
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?
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"
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.
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!
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).
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.
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
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!!!
Ich habe mir jetzt das Register 0x28 nach PayloadReady angesehen: 0x28=01100100 Also ist auch hier das Bit 5 gesetzt! Was bedeutet das?
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.
Freut mich, jetzt hast Du Dir Dein Wochenend-Bier verdient ;o)
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.
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
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.
Gast
#5251758
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
Gast
#5256202
Hallo, danke. Problem gelöst. VG Walter
Gast
#5256210
Toll, Danke für den Hinweis.
Walter L. schrieb: > Hallo, > danke. Problem gelöst. > VG Walter Was war das Problem?
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.