Wer verwendet RFM69?

[Andreas (Gast)]

Hallo,

ich versuche mit dem RFM69HW einen Garagentor Sender nachzubauen.
Gesendet wird mit OOK. Mit dem (abgeänderten) Code von Felix 
funktioniert es soweit. Allerdings scheint der RFM69 immer ein einzelnes 
bit '1' vor meinen Daten zu senden, was ich mir nicht erklären kann!

Geändert wurde der Code (alles im Anhang):
- Unlimited length Packet (d.h. fixed length = 0)
- sync byte 0x49  ==> |0100|1001|, Keine Preambel.
- Max array size 60
- PA1 output

Empfangen wurde mittels SDR und ausgewertet mit baudline ==> siehe 
Anhang.

Gesendet werden sollte eigentlich
   |01001001|01010001|00101010|.....|00000000|
Empfangen wurde aber:
  1|01001001|01010001|00101010|.....|00000000|

Probiert habe ich auch zuerst Tx-on, dann Fifo füllen, jedoch mit 
gleichem Ergebnis.
Hat jemand schon ähnliches beobachtet?

[Johannes S. (Gast)]

Eine direkte Antwort habe ich nicht, ich habe mit dem RFM69 aber schon 
FS20 OOK gesendet/empfangen. Dazu habe ich den continous mode und den 
DATA Pin über DIO2 benutzt.

[Andreas S. (andy7683)]

Ich habe hier ein total seltsames Phänomen.

Mein RFM69 funktioniert nur ohne GND.
Ja... genau wegen diesem Grinse hatte ich lange überlegt ob ich das 
überhaupt posten soll.

Ich bin sogar soweit gegangen jeden der beiden GND-Pins auf je einen 
Jumper zu legen um zu test ob es nur an einem liegt.

Fehlanzeige! Das Modul funktioniert nur dann, wenn ich beide Jumper 
entferne.
Komischerweise funktioniert es wirklich. Es sendet und empfängt wie eine 
eins :-)

Und ja, ich habe bereits mehrere Module ausprobiert.

Hatte schon mal jemand ein derartiges "Problem" ?

Kann sich jemand einen Reim drauf bilden ?

[Klaus I. (klauspi)]

Andreas S. schrieb:
> Ich habe hier ein total seltsames Phänomen.
>
> Mein RFM69 funktioniert nur ohne GND.
> Ja... genau wegen diesem Grinse hatte ich lange überlegt ob ich das
> überhaupt posten soll.

Zu Recht :oD
Irgendetwas ist hier sehr kurios, zeig mal ein paar aussagekräftige 
Photos und Schaltpläne von Deinen Aufbauten.

Dir geht es hier aber nicht um die Beschaltung vom Reset des RFM69CW, 
oder?

[Andreas S. (andy7683)]

Nachdem ich mein 0.96" Display ans Laufen bekommen habe, habe ich mich 
heute mal wieder um das RFM96HW-Modul gekümmert.

Es hat sich herausgestellt, dass das Problem irgendetwas mit der 
Spannungsversorgung zu tun hat.

Wenn ich als Spannungsversorgung ein Labornetzteil verwende, dann 
funktioniert alles super.

Wenn ich jedoch eine 5V Powerbank verwende, dann bleibt das Controller 
stehen, sobald ich versuche in ein Register des RFM zu beschreiben.

Entferne ich die Jumper 2 und 3, dann startet auch der Controller ab und 
zu ordnungsgemäß und ich kann die geschrieben Register des RFM auch 
wieder zurücklesen.

Also wie gesagt: Alles recht komisch.

Die Schaltung habe ich zur Zeit auf einem Steckbrett aufgebaut.

Was zu Henker kann das sein ?

Ich habe auch mal ein kleines Video des Ganzen auf Youtube hochgeladen:
https://youtu.be/91jJatoTPy8

[Andreas S. (andy7683)]

So,
ich konnte das Problem weiter eingrenzen.

Die Kalibrierung des RC Oszilators funktioniert nicht.

Wenn ich das Register 0x0A mit 0x80 beschreibe, dann bekomme ich nur 
0x00 als Antwort zurück, wenn ich das Register auslese.

Sobald ich aber die GND-Jumper entferne, bekomme ich ein 0x40 zurück und 
alles läuft.

Kann sich jemand erklären warum das blöde Teil nicht anfängt zu 
schwingen ?

[Johannes S. (Gast)]

Was ist denn mit dem Reset am RFM? Der Jumper sollte offen sein.
Dieses GND Problem ist auch komisch, ich habe die hier auch in Betrieb 
und so angeschlossen wie es soll. Da solltest du nochmal den Steckbrett 
Aufbau kontrollieren. Oder ein Foto posten.

[Andreas S. (andy7683)]

Nachdem ich nun die Kalibrierung des RC-Oszilators und den 
anschließenden Wechsel in den Standby-Modus raus genommen habe, bekomme 
ich die geschrieben Register angezeigt.

Resultat:
ist GND angeschlossen steht da nur Müll drin.

Klemmt man GND ab sind die Register geschrieben wie gewünscht.

Echt komisch und wirklich nicht zu erklären.

Falls das Modul kaputt wäre, würde doch gar nix mehr aus den Registern 
rauskommen bzw. rein gehen oder ???

Kann mir mal jemand einen Beispiel von einem Testaufbau zukommen lassen 
?
Ich zweifel so langsam an mir.

Werde morgen mal ein neues Modul testen...

[Johannes S. (Gast)]

Kannst du selber etwas auf der verwackelten unscharfen Aufnahme 
erkennen?
Also mir fehlt da als erstes die +3,3 V links oben.

[umpfgr (Gast)]

So ein paar Gedanken dazu:
1) fehlende Abblock Kondis beim uC und beim Level-Shifter
2) Brown-Out-Detection beim uC gesetzt?
3) durch den 10uF beim 3.3V Regler startet der RFM möglicherweise später 
als der RFM ==> ggf. etwa 50ms im uC Code warten, dann erst den RFM 
schreiben/lesen.

[Andreas S. (andy7683)]

So langsam wird es echt hoffnungslos...

Folgendes habe ich getestet:
-"alter" RFM69-HW; ATMega8A und alles auf 3.3V
-"alter" RFM69-HW; ATMega328P und alles auf 3.3V
-"neuer" RFM69-HW; ATMega328P und alles auf 3.3V

Somit habe ich ein Problem des µC ausgeschlossen.
Durch rausschmeißen der Logik-Buffer und die Versorgung mit 
ausschließlich 3.3V können nun auch an dieser Stelle keine Fehler 
auftreten.

Ich habe die Schaltung sowohl mit als auch ohne Kondensator am Reset 
getestet.

Anbei ein paar Bilder vom Steckbrett, die Bildschirmausgabe mit und ohne 
GND.
Meinen Code habe ich auch angehängt.

Schon mal vorab Danke für eure hilfe.

Bin schon am überlegen ob ich ohne GND initialisiere und dann später die 
GND dazuschalte. Ist aber total hässlich und es muss ja einen Grund 
haben warum der Sch... nicht funktioniert.

[Johannes S. (Gast)]

Da bleibt noch die Software. Und wie hoch ist der SPI Takt? Ist der 
vielleicht zu hoch?

ok, Code ist angehängt, hatte ich auf dem Smartphone übersehen. SPI init 
sieht für mich auch ok aus.

Hast du mal die GND pads gegen die Nachbarn auf Kurzschluss gemessen? Im 
gesteckten Zustand, nicht das das Steckbrett eine Macke hat?

[Andreas S. (andy7683)]

Es ist kein direkter Durchgang zu messen.

Komisch ist auch, dass der RFM sporadisch startet. Wenn ich das Netzteil 
ein und Aus schalte, dann ist ca. jeder 10 Vorgang erfolgreich.

[Andreas S. (andy7683)]

Ich habe den Fehler nicht gefunden.

Da der Controller sporadisch startet, habe ich den Startvorgang mit 
einem Watchdog versehen. Nachdem der RFM69 initialiert wurde, wird der 
Watchdog wieder deaktiviert.

Echt keine tolle Lösung, aber es funktioniert.

[Johannes S. (Gast)]

Ich war da fauler und habe die lowpowerlabs Lib benutzt: 
https://github.com/LowPowerLab/RFM69/blob/master/RFM69.cpp
Da wird im init erst das syncvalue register gesetzt und mit Timeout 
rückgelesen. Das ist da sicher auch nicht ohne Grund drin, obwohl ich 
sowas auch nicht im DB gefunden habe.
In deinem Code wird das Init 5 mal ausgeführt, war das so beabsichtigt 
oder sollte nur das Delay 5 mal 50 ms betragen?

[Katatafisch (Gast)]

Ich grüble derzeit über eine Realisierungsmöglichkeit eines 
Sensornetzwerks auf Funkbasis. Funk, weil ein Sensor durch 2 
Stahlbetondecken durch funken muss und per Batterie versorgt werden 
muss.

Das RFM69CW scheint da ein günstiger Kandidat zu sein.
Würde jemand mit Erfahrungen mit dem Modul mir von der Idee abraten? :-)

Johannes S. schrieb:
> Ich war da fauler und habe die lowpowerlabs Lib benutzt:
> https://github.com/LowPowerLab/RFM69/blob/master/RFM69.cpp

Er hier hat die Lib übrigens in C konvertiert:
https://github.com/cristi85/RFM69

[Johannes S. (Gast)]

Die RFM69 funktionieren einfach und gut, auch wenn Andy in den Postings 
hier vor Probleme damit hat(te). Ich habe ein paar Nodes die seit ein 
paar Wochen im Test laufen. Davon auch einer mit PIR Sensor im 
Batteriebetrieb, im Schlafmodus zieht der RFM ja weniger als 1 µA. Durch 
den grossen Fifo sind die auch angenehmer zu programmieren als die 
RFM12. Ich habe die 868 MHz und hier wenig Störsender in der Umgebung, 
eventuell ein Funksender von Nachbars Garagentor. Ich glaube das bekomme 
ich auch auf wenn ich das mitprotokoliere :-) Sicherheit bleibt da 
vielleicht ein Nachteil, das Tor von deinem Raptorengehege solltest du 
nicht damit steuern. Da ist zwar Verschlüsselung AES-128 drin, aber die 
lässt sich vermutlich knacken wenn die Pakete geloggt werden. Ich habe 
jedenfalls auch gelegentlich Mülldaten mit geringer Feldstärke 
empfangen, es sieht so aus als ob trotzdem Daten geliefert werden auch 
wenn der Schlüssel nicht passt.
Die C-Implementierung wäre ein Rückschritt für mich weil ich eine mbed 
Portierung verwende und mbed ist eine C++ lib. Der lowpowerlabs Code von 
Felix Rusu ist aber weit verbreitet und es gibt viele Portierungen, auch 
auf meinem RasPi als Gateway läuft der auf der RFM Seite.

[Katatafisch (Gast)]

@Johannes: Danke für die Erfahrungswerte und die Infos.

Dann werde ich demnächst mal zwei, drei Module bestellen und testen.

Die C-Portierung ist in soweit für mich relevant, da ich noch einige 
ATtiny 861 Controller hier liegen habe, welche ich für die Nodes 
einsetzen möchte.

Als Basis stelle ich mir auch als langfristige Lösung einen Raspberry Pi 
vor.

Die Verschlüsselungen sind ja fast alle knackbar. Es kommt immer auf die 
Rechenleistung an, welche dem Angreifer zur Verfügung steht.
So war vor paar Jahren AES-128 mal sicherer als Heute.
Natürlich wird auch manchmal einfach ein Sicherheitsloch gefunden, wie 
beim CSS zum Beispiel.

[Conny G. (conny_g)]

Katatafisch schrieb:
> Dann werde ich demnächst mal zwei, drei Module bestellen und testen.
>
> Als Basis stelle ich mir auch als langfristige Lösung einen Raspberry Pi
> vor.

Ich habe das genau so gemacht und bin sehr zufrieden mit dem RFM69. 
Vorher mit dem RFM12 hatte ich sehr mit der Reichweite zu kämpfen und 
musste mir für die Basisstation eine Biquad-Antenne machen, die die 
Clients im Garten erreicht.
Mit dem RFM69 alles gegessen, mit der Standard-Stabantenne eine 
Reichweite von wenigstens 150m draussen, durch die Hausmauer/Fenster.
Ein "Client" zickt, aber ich denke das liegt daran, dass das das eine 
Art Funksteckdose ist und das Netzteil 3cm daneben zu sehr stört.

Habe mir für den Raspberry Pi ein Atmega328 + RFM69 "Hat" gemacht, 
kommunizieren seriell mit einem simplen Text-Protokoll. Sh. Foto.
(Ja, der Micromatch ist etwas angekokelt, da habe ich beim 
Heissluft-Reflow des Prototypen zuviel Gas gegeben.)
Ein Platz für einen 433 Mhz-Sender ist auch drauf, zum Ansteuern von 433 
Mhz Funksteckdosen.
Der Hat läuft seit 1 Jahr problemlos, hatte vorher eine entsprechende 
Breadboard-Schaltung mit RFM12, lief auch schon 1-2 Jahre problemlos 
(abgesehen von den Reichweiten-Problemen).

Auf dem Raspberry Pi läuft dann ein simpler Python-basierter Webserver, 
der HTTP-Befehle entgegennimmt und dann über das RFM rausfunkt oder über 
Apple Homekit etwas arrangiert, was auch immer.
Und es läuft eine NodeJS basierte Homekit-Bridge, die alle Geräte per 
Apple iOS verfügbar macht.
Das ist es:
https://github.com/KhaosT/HAP-NodeJS

Über die serielle Schnittstelle werden auch eingehende Funknachrichten 
angenommen, also was die Clients zurücksenden.
Und dann z.B. in eine Web-IoT-DB geschrieben für Temperaturverläufe etc.
Das RFM-Protokoll habe ich in ein redundantes Protokoll eingepackt, dass 
Prüfsummen mitsendet und Pakete bis zu 5x wiederholt, wenn kein ACK der 
Gegenstelle kommt. Kann zwar das RFM69 auch (zumindest die Prüfsumme), 
aber ich hatte das ja vom RFM12 eh schon.

Dafür braucht es einen Quadcore Raspi, NodeJS braucht viel Ressourcen.
Sonst braucht die Antwort auch mal ein paar Sekunden.

[Tsmeey (Gast)]

Hallo zusammen,

ein sehr interessanter Thread!
Auch wenn, das Thema inzwischen ausläuft, möchte ich noch eine Frage in 
die Runde werfen:

Ich würde gern die Funktion SYNC_WORD (Register 2E) in Verbindung mit 
LISTEN (0D)verwenden. (Ich verwende keine 12er nun 69Wer)
Zunächst versuche ich ein Sync_Word_Match hinzubekommen. Das 
funktioniert nicht.
Lasse ich bei PayloadReady am DIO0 einen INT auslösen und gehe in die 
RX-Routine, funktioniert das. Senden und Empfangen funktioniert also 
grundsätzlich, wenn Daten vorhanden sind.

Ich beschreibe die Register:
RegSyncConfig (2E) mit C8:
SyncOn,
FifoFillCond, weil ich KEIN SyncAddress, sondern nur SyncWord verwende,
SyncSize 0bxx001xxx (000 -> Byte 1, 001 -> Byte 2)

Byte 1 Soll Gruppe sein also z.B. 100, Byte 2 soll ID sein also z.B. 5. 
RegSyncValue1 wäre somit 100 und RegSyncValue2 dann 5.
Beide Werte werden sowohl in Sender wie auch in Empfänger geschrieben.

Die (auf fixe Payloadlänge (RegPacketConfig (37)) eingestellte) 
RegPayloadLen (38) beträgt 5 Byte und beinhaltet nur die eigentlichen 
Daten, kein SyncWord, keine Länge, kein CRC.

RegDioMapping (25) setze ich auf 80 -> DIO0 = SyncAddress.

Ich denke, es sollte so ablaufen:
Sender: 01010101 -> 100 , 5 , Payload....
Empfänger : 0101010 -> 100, 5 -> SyncMatch -> lade FIFO -> löse INT am 
DIO0 aus.

Habe ich ein Register vergessen? Einen falschen Gedanken?
Es scheint kein SyncWord erkannt zu werden. Im Thread wird 2D D4 
verwendet, aber scheinbar nicht ausgewertet. Die Beiden Bytes sind eher 
zufällig ?

Hat jemand eine schicke Idee oder ein brauchbaren Verweis auf die Doku ?

Gruss
Christian

[Felix P. (fixxl)]

Hallo Christian,

Tsmeey schrieb:
> Im Thread wird 2D D4
> verwendet, aber scheinbar nicht ausgewertet. Die Beiden Bytes sind eher
> zufällig ?
Die beiden Bytes 0x2D und 0xD4 stammen aus RFM12-Zeiten, da waren sie 
als Sync-Word fest vorgegeben und nicht frei konfigurierbar. Da ich 
beide Module in einem Netzwerk verwende, musste ich also die RFM69 auch 
auf diese Werte einstellen.

Und natürlich werte ich die beiden Bytes aus: Indem das Bit 
FifoFillCondition  im Register 0x2E auf 0 gesetzt wird, werden Daten 
ignoriert, wenn nach der Präambel nicht das korrekte Sync-Word erkannt 
wird. Dass der Interrupt SyncAddress-Interrupt heißt, ist 
missverständlich, vielleicht liegt hier auch dein Problem. 
Möglicherweise wird mit FifoFillCondition=1 einfach nie ein 
Sync-Interrupt ausgelöst.

[Steffen H. (Firma: www.shotech.de) (mc_sho)]

mein Design mit dem RFM69CW-868 Modul habe ich jetzt auch soweit fertig 
und im Test laufen. Derzeit im Keller, Wohnung und Balkon ohne Probleme.
Derzeit sind die Module nur für 868MHz vorgesehen. Ein neues Design mit 
315MHz bis 915MHz ist in Produktion. Die Leiterplatte wird dann aber um 
6,2mm länger da die Anbindung der Multibandantenne mehr Platz benötigt. 
Die derzeitigen Module mit Cortex-M0+ , RFM69CW, Current-Monitor und 
Antenne sind nur 31mm x 26,26mm. Die Multibandmodule sind dann 37,2mm x 
26,6mm.

Das jetzige RF-Sensor Design mit BME280 ( Bild: SPIRIT_Sensor_BME280 ) 
läuft noch mit dem Spirit1 Modul von ST. Nach dem jetzigen Test werde 
ich die aber auf die RFM69CW umstellen.

Die Software habe ich von https://github.com/cristi85/RFM69 genommen. 
Leider waren da noch einige Fehler enthalten, aber jetzt funktioniert 
das soweit und ich habe die Software auf den Cortex-M0+ angepasst.

Aktuell schreibe ich an dem Bootloader, mit dem dann ein Update über 
Funk möglich ist, oder halt über RS232-TTL. Die Erkennung erfolgt 
automatisch.

Die Software werde ich freigeben sobald alles funktioniert. Da ich mit 
dem IAR Compiler arbeite, suche ich noch jemand, der mir das auf den GCC 
anpasst. Module würde ich zur Verfügung stellen.

[Abdul K. (ehydra)]

Respekt, schöne Fotos, schönes Platinenlayout. Wenn deine Software 
genauso aussieht, biste ein echtes Vorbild!

[Tsmeey (Gast)]

Hallo Felix,

danke für die Antwort.
In der Tat bin ich vielleicht einem Gedankenfehler unterlegen.

In den Dox stand, dass sich SyncWordMatch UND SyncAddressMatch das 
Interrupt-Flag SyncAddress teilen.
Ich bin daher davon ausgegangen, dass SyncWordMatch ein Interrupt 
auslösen muss.
Da aber OHNE SyncWordMatch gar kein PayLoadReady erfolgen kann, lässt 
sich auch einfach der PayloadReady-Interrupt am DIO0 nutzen ;)
DAS Problem ist somit zwar umgangen, aber gelöst :)



Nun hänge ich aber am Listen-Modus fest. :/

Ich schalte den RFM69 in ListenModus:
1) STDBY
2) ListenMode | STDBY

Zu Testzwecken habe ich das Zeitfester für RX im RegListen1 bereits im 
mS-Bereich. (~40mS RX, ~100ms Idle) Gesendet werden jede Sekunde 5 Byte.

Trotzdem kommt nicht ein Packet an.
Crieria ist nur RssiTreshold. Rssi-Schwelle wird auch sicher 
überschritten. (mit RegRssiValue ausgewertet)

Ich gehe davon aus, dass zwischen den Idles im RX-Modus dann das gesamte 
Packet eingelesen wird und im FIFO steht.
Ich breche daher den ListenModus in 2 Schritten ab.
1) Abort & STDBY
2) STDBY
(Auch mit RX statt STDBY probiert)

Aber bereits zuvor sollte ein Interrupt wegen PayloadReady ausgelöst 
werden, oder nicht ?
Aber es löst kein Interrupt aus.

Meine möglichen Erklärungen:
1) In der RX-Phase wird das Paket nicht erkannt, obwohl RSSITheshold 
erreicht
2) In der RX-Phase wird das Paket nicht eingelesen, ein zweiter Step mit 
Paket lesen muss folgen
3) Der FIFO wird aus irgendeinem Grund geleert bevor ich die Daten lesen 
kann.

Trotz dieser möglichen Erklärungen erhalte ich auf keinem von mir 
versuchten Lösungsweg einen PayloadReady Interrupt.

Ich fürchte, dass Problem liegt ganz woanders. Hast Du dafür noch ein 
Tip?

[Felix P. (fixxl)]

Ohne deinen Code zu sehen, ist die Diagnose schwierig, zumal ich mit dem 
ListenMode bisher keine praktische Erfahrung habe. Wenn ich dich richtig 
verstehe, funktioniert der PayloadReady-Interrupt, wenn du dauerhaft im 
Rx-Modus bist, so dass der Fehler definitiv irgendwo im Bereich "Listen 
Mode" zu suchen ist?

[Sascha W. (sascha-w)]

Hallo Felix,

zum Listenmode

innerhalb der 40ms (bei Dir) muss Präambel, Syncword und evl. Adresse 
erkannt werden.
Da der Sender ja nicht weiß wann der Empfänger gerade Bereit ist, musst 
du beim Sender das Paket entsprechend oft, möglichst ohne Pause, 
wiederholen. Auch sollte das erste Paket möglichst kurz sein. Die aktive 
Zeit des Empfängers muss immer mindestens so lang sein wie das Paket das 
erkannt werden soll + 2x Präambel + Syncword + (Adresse) und noch etwas 
Reserve.

Sascha

[Tsmeey (Gast)]

Tach Felix,

sorry, bei mir hat es etwas gedauert. Und ja, Du hast mich richtig 
interpretiert.

Ich könnte Dir jetzt 400 Zeilen Code schicken, aber ich glaube, dass 
hilft jetzt auch nicht wirklich?!
Ich sehe aber ein, dass ein von Dir in die Glaskugel schauen auch nicht 
hilft ;)

Der Vorschlag von Sascha, einfach, wie effektiv, scheint mir zunächst 
interessant. Einfach mal den Empfänger richtig zutexten um zu sehen, ob 
der Bursche denn auch hinhört ;)

@Sascha: aber ich verstehe das doch richtig, dass der Empfänger in der 
"Wachphase" das ganze Packet einliest und in den FIFO schreibt, nicht?
Und nicht, dass in der Wachphase nur der Sync erkannt wird und ich 
aktiv, das Datenpaket durch ein Umstellen auf von Listen auf RX nochmals 
einlesen und deshalb absichtlich mehrfach senden muss?

[Sascha W. (sascha-w)]

Tsmeey schrieb:
> Tach Felix,
>
> @Sascha: aber ich verstehe das doch richtig, dass der Empfänger in der
> "Wachphase" das ganze Packet einliest und in den FIFO schreibt, nicht?
> Und nicht, dass in der Wachphase nur der Sync erkannt wird und ich
> aktiv, das Datenpaket durch ein Umstellen auf von Listen auf RX nochmals
> einlesen und deshalb absichtlich mehrfach senden muss?

Also beim RFM69 kann man ja einstellen was den Listenmode beendet <rssi> 
oder <rssi & sync>. M.M. nach sollte er das Paket nach dem erkennen der 
Abbruchbedingung auch einlesen. Lässt sich natürlich schlecht 
feststellen ober er dann doch erst das nächste Paket in den Puffer 
einliest. Auf jeden Fall braucht man zum Empfang des Pakets den 
Listendmode nicht beenden, hab ich bei mir schon so verwendet. Beim 
RFM22 war das im Datenblatt irgendwie genauer beschrieben.
Aber es ändert trotzdem nichts daran das der Sender mindestens so lange 
senden muss das die Empfangspause überbrückt wird. Es sei denn du 
könntest Empfänger und Sender so genau syncronisieren das der Sender auf 
die ms genau weiß wann der Empfänger bereit ist.

Sascha

[Christian D. (christian_d347)]

Moin Sascha,

das mit rssi & sync hatte ich gelesen, trotzdem danke für den Hinweis.

Wenn Du Dir sicher bist, dass ich den Listen-Mode nicht beenden muss, 
ist das schon mal ein guter Hinweis.

Denn in der Beschreibung unter RegListen1  Bits 2-1  ListenEnd ist das 
nach meiner Auffassung ziemlich widersprüchlich beschrieben. "Listen 
mode stops and must be disabled..."

Kannst Du Dich entsinnen welchen Mode Du eingestellt hast? Mir erscheint 
ja 10 (... stays in Rx mode... resumes in idle state..." sinnig, wenn 
ich nur periodisch Daten "einsammeln" will.

Ich werde das am WE mal austesten...

tsmeey -> christian

[Christian D. (christian_d347)]

Sascha W. schrieb:
> Also beim RFM69 kann man ja einstellen was den Listenmode beendet <rssi>
> oder <rssi & sync>

Wobei ich hier allerdings der Meinung bin, dass Listen nicht beendet, 
sondern nur unterbrochen wird.

Wobei das insgesamt schon merkwürdig ist:
Wenn ich ein Idle und ein Rx Zeitfester habe, dann kann ListenCriteria 
vmtl. sowieso nur im Rx-Zeitfenster wirksam sein.
Das wiederum wäre dann aber das "normale" Verhalten im Rx-Modus und es 
erscheint mir fraglich, warum dann extra dieses Kriterieum angegeben 
werden muss ;)

Fragen über Fragen :)

[Sascha W. (sascha-w)]

Christian D. schrieb:
> Moin Sascha,
>
> das mit rssi & sync hatte ich gelesen, trotzdem danke für den Hinweis.
>
> Wenn Du Dir sicher bist, dass ich den Listen-Mode nicht beenden muss,
> ist das schon mal ein guter Hinweis.
also für den Empfang musst du nicht ausschalten, da ich in meiner 
Anwendung jedoch immer eine Bestätigung sende beende ich den Listendmode 
sowieso nach dem Empfang von Hand.

> Denn in der Beschreibung unter RegListen1  Bits 2-1  ListenEnd ist das
> nach meiner Auffassung ziemlich widersprüchlich beschrieben. "Listen
> mode stops and must be disabled..."
>
> Kannst Du Dich entsinnen welchen Mode Du eingestellt hast? Mir erscheint
> ja 10 (... stays in Rx mode... resumes in idle state..." sinnig, wenn
> ich nur periodisch Daten "einsammeln" will.

ich verwende bei mir RSSI&SYNC als Kriterium und 01 als Ende.
Im Mode:
00 geht das Teil nach erkennen der Bedingung auf Dauer RX, wenn kein 
gültiges Paket erkannt wird legt sich's nicht wieder schlafen und man 
merkt davon nichts
01 weckt auf, und wenn kein gültiges Paket erkannt wird kommt ein 
Timeout Interrupt. Ich hab mir Timeout und PayloadRDY auf einen Pin 
gelegt. Bei Timeout beende ich Listend lösche den FiFo und schalte den 
Listenmode wieder ein.
10 sollte auch gehen man muss den FiFo nur schnell genug auslesen, da 
die Daten beim nächsten Paketbeginn gelöscht werden.

> Wobei ich hier allerdings der Meinung bin, dass Listen nicht beendet,
> sondern nur unterbrochen wird.
ja, wenn du eine andere Betriebsart willst musst du immer erst den 
Listenabort machen - sonst macht das Teil gar merkwürdiges.

> Wobei das insgesamt schon merkwürdig ist:
> Wenn ich ein Idle und ein Rx Zeitfester habe, dann kann ListenCriteria
> vmtl. sowieso nur im Rx-Zeitfenster wirksam sein.
genau - in der IDLE-Zeit ist der Empfänger aus, sonst könnte man ja 
keinen Strom sparen

> Das wiederum wäre dann aber das "normale" Verhalten im Rx-Modus und es
> erscheint mir fraglich, warum dann extra dieses Kriterieum angegeben
> werden muss ;)
das macht schon Sinn, er schaut ob in der RX-Phase ausreichend 
Signalpegel vorhanden ist und evl. ob ein Sync gelingt. Trifft die 
Bedingung zu geht er nicht wieder in den IDLE und kann das Paket 
komplett empfangen.

Sascha

[Matthias T. (matthias_199)]

Hallo,

ich benutze auch das Modul und es funktioniert,
bin aber etwas von der Reichweite und Sendeleistung eintäuscht.

Mache ich etwas Grob Falsch ?

mein RssiThreshold ist -100dbm, Sendeleistung ist 5dbm.

Als Antenne benutze ich eine Ader aus einem Stromkabel auf lambda/4 also 
rund 8,6 cm

und die Module sind nebeneinander (20 cm) und ich hab folgende Rssi 
Werte.(Bild)

Die Reichweite würde ich auf rund 3 meter schätzen.

würde "richtige" Antennen besser funktionieren mit einem Sma Anschluss,

Die sollten ja um einiges besser auf die 50 Ohm abgestimmt sein als mein 
draht Stummel.

Gibt es beim Anschluss Design was zu beachten.
Habe jetzt nur ein so kurz wie mögliche Feedline gewählt, wo dann die 
Antenne aufgelötet wurde,

kann ich später mal Fotos machen.

MFG
Matthias

MFG Matze

[Felix P. (fixxl)]

Der zweite, oft nicht beachtete Teil einer lambda/4-Antenne ist das 
notwendige Gegengewicht, eine ausreichend (idealerweise "unendlich") 
große Massefläche. Von daher wäre eine "richtige" Antenne mit 
SMA-Anschluss, welche meist als Sperrtopfantenne ausgeführt ist und 
keine zusätzliche Massefläche benötigt, auf jeden Fall anzuraten.

[Matthias T. (matthias_199)]

Ja genau da liegt das Problem.

das wird auf einem Roboter montiert, da sieht das mit so ner 
Sperrtopfantenne echt mieß aus.
Auf meiner Platine habe ich den Fehler schon eingesehen das die 
Massefläche wohl einfach nicht groß genug ist....

Also wenigstens ein 2 Layer bord und ein Layer sozusagen nur masse wäre 
doch das mindeste was ich optimieren könnte sehe ich das richtig ?

oder vielleicht ein ein Metallgehäuse für die Platine das auch auf Masse 
hängt?

und vielleicht so eine Antenne ?

http://de.rs-online.com/web/p/telemetrieantennen/7934363/

MFG Matze

[Matthias T. (matthias_199)]

Kleine nachfrage dazu,

ich habe mal den 300kbps modus aus Interesse probiert.

Hier nimmt der dbm Wert drastisch ab, ist das normal so ?
Das Modul generiert doch quasi das gleiche Feld mit gleicher 
Feldstärke...

MFG
Matze

[Fabian F. (fabian_f55)]

Ich Versuche grad eine RFM69 Lib für ARM umzubauen. Hat jemand einen 
sicher Funktionierenden Stand von dieser Lib, den man als Startpunt 
verwenden kann?
Am Anfang des Posts gab es mal eine Lib, aber seitdem gab es ja offenbar 
viel Diskussionsbedarf....

[mh (Gast)]

Hallo zusammen,
ich versuche gerade eine Verbindung zwischen zwei RFM69-Funkmodulen 
aufzubauen. Ein STM32 ist TX und ein zweiter RX.
Wenn das eine Modul permanent im RX-Modus ist, funktioniert alles 
wunderbar.
Doch wenn ich nach dem Empfang eines Pakets in den Standby-Modus schalte 
und dann kurz darauf wieder in den RX-Modus, bricht die Verbindung nach 
ein paar empfangenen Paketen ab. Nach einem Reset des µC geht es wieder 
für ein paar Pakete.
Ich bin um jeden Hinweis dankbar, da ich jetzt schon den ganzen Tag nach 
dem Fehler suche...

Hier die Init-Routine RX-on und die IRQ-Routine für den externen 
Interrupt (diese löst aauf positive Flanke von DIO0 aus; in main 
passiert nichts):

void rfm_init(void)
{
  rfm_communication_enable = 0;

  spi_init();
  ext_irq_init();


  rfm_send_spi_cmd(0x0200,1);  // FSK, Packet mode, no shaping


  uint8_t bw;
  uint16_t fdev;

  switch (RFM_BITRATE/19200L)
  {
  case 0:
  case 1:
    bw = 0x03; // 62.5 kHz
    fdev = (45000LL * 524288LL + RFM_FXOSC / 2) / RFM_FXOSC;
    break;
  case 2:
  case 3:
    bw = 0x02; // 125 kHz
    fdev = (90000LL * 524288LL + RFM_FXOSC / 2) / RFM_FXOSC;
    break;
  default:
    bw = 0x09; // 200 kHz
    fdev = (120000LL * 524288LL + RFM_FXOSC / 2) / RFM_FXOSC;
    break;
  }

  // Frequency Deviation
  rfm_send_spi_cmd(0x0500 | (fdev >> 8), 1);
  rfm_send_spi_cmd(0x0600 | (fdev & 0xFF), 1);

  // Data Rate
  rfm_send_spi_cmd(0x0300 | RFM_BITRATE_MSB, 1);
  rfm_send_spi_cmd(0x0400 | RFM_BITRATE_LSB, 1);

  // Receiver Bandwidth
  rfm_send_spi_cmd(0x1940 | bw, 1);

  if (bw) bw--;

  // AFC
  rfm_send_spi_cmd(0x1A40 | bw, 1);


  rfm_send_spi_cmd(0x131B, 1); // OCP enabled, 100mA

  // DIO-Mapping
  rfm_send_spi_cmd(0x2500, 1); // Clkout, FifoFull, FifoNotEmpty, FifoLevel, PacketSent/CrcOk
  rfm_send_spi_cmd(0x2607, 1); // Clock-Out off

  // Carrier frequency
  rfm_send_spi_cmd(0x0700 | RFM_FRF_MSB, 1);
  rfm_send_spi_cmd(0x0800 | RFM_FRF_MID, 1);
  rfm_send_spi_cmd(0x0900 | RFM_FRF_LSB, 1);

  // Packet config
  rfm_send_spi_cmd(0x3790, 1); // Variable length, No DC-free encoding/decoding, CRC-Check, No Address filter
  rfm_send_spi_cmd(0x3800 + RFM_MAX_PAYLOAD_LENGTH, 1); // Max. Payload-Length
  rfm_send_spi_cmd(0x3C80, 1); // Tx-Start-Condition: FIFO not empty
  rfm_send_spi_cmd(0x3DA0, 1); // Packet-Config2

  // Preamble length 4 bytes
  rfm_send_spi_cmd(0x2C00, 1);
  rfm_send_spi_cmd(0x2D04, 1);

  // Sync-Mode
  rfm_send_spi_cmd(0x2E88, 1); // set FIFO mode
  rfm_send_spi_cmd(0x2F2D, 1); // sync word MSB to 0x2D
  rfm_send_spi_cmd(0x30D4, 1); // sync word LSB to 0xD4

  // Receiver config
  rfm_send_spi_cmd(0x1800, 1); // LNA: 50 Ohm Input Impedance, Automatic Gain Control
  rfm_send_spi_cmd(0x582D, 1); // High sensitivity mode
  rfm_send_spi_cmd(0x6F30, 1); // Improved DAGC
  rfm_send_spi_cmd(0x29C4, 1); // RSSI mind. -98 dBm
  rfm_send_spi_cmd(0x1E2D, 1); // AFC auto on and clear
  rfm_send_spi_cmd(0x2A00, 1); // No Timeout after Rx-Start if no RSSI-Interrupt occurs
  rfm_send_spi_cmd(0x2B28, 1); // Timeout after RSSI-Interrupt if no Payload-Ready-Interrupt occurs

  rfm_send_spi_cmd(0x1180 | (RFM_OUTPUTPOWER & 0x1F), 1); // Set Output Power

  rfm_send_spi_cmd(0x0A80, 1); // Start RC-Oscillator

  do
  {
    rfm_send_spi_cmd(0x0A00, 0); // Wait for RC-Oscillator
  }
  while (!(spi_rx_data & (1 << 6)));


  rfm_send_spi_cmd(0x0104, 1);
  do
  {
    rfm_send_spi_cmd(0x27FF, 0);
  }
  while (!(spi_rx_data & (1 << 7)));

}





void rfm_rx_on(void)
{
  rfm_send_spi_cmd(0x0110, 1);  // rx on
  do
  {
    rfm_send_spi_cmd(0x27FF, 0);
  }
  while (!(spi_rx_data & (1 << 7)));
}





void EXTI9_5_IRQHandler(void)
{
  EXTI->PR |= EXTI_PR_PR7;
  GPIOA->ODR ^= GPIO_ODR_ODR_5;



  rfm_send_spi_cmd(0x0000, 0);
  rfm_send_spi_cmd(0x0000, 0);
  rfm_send_spi_cmd(0x0000, 0);
  rfm_send_spi_cmd(0x0000, 0);
  rfm_send_spi_cmd(0x2810, 1);

  rfm_send_spi_cmd(0x0104, 1);
  do
  {
    rfm_send_spi_cmd(0x27FF, 0);
  }
  while (!(spi_rx_data & (1 << 7)));

  //for(volatile uint32_t i=0; i<10000; i++);
  rfm_send_spi_cmd(0x3DFF, 0);
  rfm_send_spi_cmd(spi_rx_data | 0x3D04, 1);
  rfm_send_spi_cmd(0x0110, 1);  // rx on
}

[mh (Gast)]

Es liegt scheinbar an der AFC...
Wenn ich AfcAutoOn nicht setze, dann funktioniert es.
Hatte jemand damit auch schonmal Probleme??

[mh (Gast)]

Update:
Hab das mit dem TimeOut weiter oben leider übersehen. Wenn ich bei einem 
TimeOut den RX neu starte, dann geht alles, auch mit AfcAutoOn...

[John (Gast)]

hallo,

ich probiere auch gerade mit den beiden modulen herum, ich sende aber
meine daten über den fsk-pin - also senden ist übertrieben, ich weiß
noch nicht, ob was raus kommt .. ist über sdi eine adere variante, oder
geht fsk gar nicht?

mfg

[Fabian F. (fabian_f55)]

Keine Ahnung. Ich Habs über SDI Angesteuert. Ging problemlos.

[Wolle G. (wolleg)]

Conny G. schrieb:
> Mit dem RFM69 alles gegessen, mit der Standard-Stabantenne eine
> Reichweite von wenigstens 150m draussen, durch die Hausmauer/Fenster.

Wenn alles so gut funktioniert, da kann man annehmen, dass Du dafür ein 
funktionierendes Programm hast.

Ich hatte versucht, das Beispiel https://github.com/LowPowerLab/RFM69 zu 
verwenden.
Leider ist das alles so umfangreich, dass ich gar keinen Anfang finde.

Deshalb hier meine Frage, ob jemand ein "einfaches" und funktionierendes 
Programmbeispiel "übrig" hat, welches ich als Grundlage verwenden 
könnte.
Mein Ziel ist zunächst die Übertragung von 8x 16Bit Temperaturmesswerte 
im Abstand von ca. 10s über eine Entfernung von ca. 80m. (o.ä.)
vorhanden: RFM69HW 868MHz;
Dank im Voraus.

[Conny G. (conny_g)]

Wolle G. schrieb:
> Conny G. schrieb:
>> Mit dem RFM69 alles gegessen, mit der Standard-Stabantenne eine
>> Reichweite von wenigstens 150m draussen, durch die Hausmauer/Fenster.
>
> Wenn alles so gut funktioniert, da kann man annehmen, dass Du dafür ein
> funktionierendes Programm hast.
>
> Ich hatte versucht, das Beispiel https://github.com/LowPowerLab/RFM69 zu
> verwenden.
> Leider ist das alles so umfangreich, dass ich gar keinen Anfang finde.
>
> Deshalb hier meine Frage, ob jemand ein "einfaches" und funktionierendes
> Programmbeispiel "übrig" hat, welches ich als Grundlage verwenden
> könnte.
> Mein Ziel ist zunächst die Übertragung von 8x 16Bit Temperaturmesswerte
> im Abstand von ca. 10s über eine Entfernung von ca. 80m. (o.ä.)
> vorhanden: RFM69HW 868MHz;
> Dank im Voraus.

Ich habe auch diese Library als Basis verwendet, die ist ganz gut 
gemacht.
Da sind auch Beispiele dabei (Verzeichnis Examples), da müsstest Dir nur 
die einfachsten raussuchen und die runterstrippen auf das, was Du 
brauchst.

[Wolle G. (wolleg)]

Conny G. schrieb:
> Ich habe auch diese Library als Basis verwendet, die ist ganz gut
> gemacht.

Es ist schön, dass Du dich meldest und ich hoffe, dass ich jetzt weiter 
komme.
Zwischenzeitlich hatte ich ein eigenes Thema 
(Beitrag "Programmbeispiel für RFM69 gesucht") aufgemacht und dort 
meine Frage wiederholt.
Mein Problem besteht u. a. auch darin, dass ich von Programmierung nur 
wenig Ahnung habe.
Deshalb zunächst einige Fragen:
a) in welcher Programmiersprache sind die Beispiele geschrieben?
b) für welche µC sind sie geschrieben?
c) wie könnte man ein Beispiel in "C" umschreiben?

Wenn ich in "C" programmiere, dann beginnt das Programm  mit der 
Funktion:
 int main (void)
{
  Funktion 1 ();
  Funktion 2 ();
  usw.
}
Da ich nichts Derartiges in den Beispielen gefunden habe, finde ich 
zunächst keinen Anfang.
Vielleicht gibt es doch noch ein einfaches Beispiel, welches ich 
verwenden könnte.
Als µC möchte ich MSP430Fxxx einsetzen.

[Christian S. (roehrenvorheizer)]

Beitrag "RFM69HW - Arduino Uno"

Hier die Fragmente:

Beitrag "RFM69HW - Arduino Uno"

Mfg

[Conny G. (conny_g)]

Christian S. schrieb:
> Beitrag "RFM69HW - Arduino Uno"
>
> Hier die Fragmente:
>
> Beitrag "RFM69HW - Arduino Uno"
>
> Mfg

Das ist aber auch C++ :-)

[Christian S. (roehrenvorheizer)]

Was ich in "Fragmente"  abgeliefert habe, ist AVR-GCC. Das sollte 
genügen, um Unsicherheiten, die beim Lesen und Verstehen des Dablas 
entstanden sind, auszuräumen. Aber das Dabla des RFM69 ist bereits recht 
umfangreich und für Anfänger eigentlich zu kompliziert.

Mit Arduino habe ich nichts zu tun.

mfg

[Wolle G. (wolleg)]

Christian S. schrieb:
> Aber das Dabla des RFM69 ist bereits recht umfangreich und für Anfänger
> eigentlich zu kompliziert.
Ursprünglich hatte ich deshalb schon fast aufgegeben.

Jetzt möchte ich noch einmal stufenweise anfangen.
Ich hatte gedacht, ich fange mit "Füllen des FIFO" an.
Aus „Fragmente“ entnehme ich die Funktion
void RFM69_TxPacket(void)
{
BurstWrite(0x00, (char *)RFM69Data2, 16); // Füllen des Fifo mit Daten 
zum Senden
}

Könnte man das mal ausführlicher darstellen und könnte man mein 
„SPI_Config_CMD_16Bit“ evtl. für „BurstWrite“ verwendet werden? (in 
abgewandelter Form, um bytweise zu übertragen)

Um ein Register zu beschreiben verwende ich z.B
SPI_Config_CMD_16Bit(0x117F| 0x8000); //Register 0x16, Sendeleistung 
(80mA) mit der unter „SPI 16BIT_8BIT.c“ stehenden Funktion.

Hoffentlich habe ich verständlich genug ausgedrückt und es findet sich 
jemand, um mir zu helfen.

[Christian S. (roehrenvorheizer)]

Hallo,

"void RFM69_TxPacket(void)
{
BurstWrite(0x00, (char *)RFM69Data2, 16); // Füllen des Fifo mit Daten
zum Senden"

RFM69Data2 ist ein Array aus Zahlen oder Zeichen, die im Burst-modus 
möglichst schnell ins Fifo geschrieben werden sollen. Deswegen hier 
Zeiger auf das character-array. Es sollen 16 Zeichen daraus gelesen und 
ins Fifo geschrieben werden.

" und könnte man mein
„SPI_Config_CMD_16Bit“ evtl. für „BurstWrite“ verwendet werden"

Nein nicht ganz. Das Burst-write muß ja die Registadresse angeben und 
danach soundsoviele Bytes verschicken, wie vorgegeben. Das Fifo läßt 
sich allerdings nacheinander durch einzelne Byte-Zugriffe füllen oder 
eben schlauer mittels burst-Zugriff.
"BURST access: the address byte is followed by several data bytes. The 
address is automatically incremented internallybetween each data byte. 
This mode is available for both read and write accesses. The NSS pin 
goes low at the beginning of the frame and stay low between each byte. 
It goes high only after the last byte transfer"

"um bytweise zu übertragen"

Wenn nur ein einziges Byte übertragen werden soll, muß trotzdem ein 
ganzes Paket gesendet werden.
Bisher realisiert habe ich nur "5.5.2.1.  Fixed Length Packet Format" 
oder "5.5.2.2.  Variable  Length  Packet  Format".

https://cdn.sparkfun.com/datasheets/Wireless/General/RFM69HCW-V1.1.pdf

Die Angfängerübung wäre nun, das Fifo zu füllen, bis die entsprechenden 
Flags auftauchen. Diese müssen natürlich abgefragt werden. TxReady 
PacketSent, FifoLevel, FifoNotEmpty,  im Sender, RxReady, PayloadReady, 
CrcOk, FifoNotEmpty im Empfänger beispielsweise.

Entweder schaltet man bei genügend gefülltem Fifo auf Senden um oder 
überläßt dies der Automatik, die bei richtiger Konfiguration abhängig 
von der Einstellung Fifo-Level das Senden auslöst.

mfG