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?
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.
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 ?
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?
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
:
Bearbeitet durch User
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 ?
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.
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...
Kannst du selber etwas auf der verwackelten unscharfen Aufnahme erkennen? Also mir fehlt da als erstes die +3,3 V links oben.
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.
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.
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?
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.
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.
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?
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
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.
@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.
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.
:
Bearbeitet durch User
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
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.
:
Bearbeitet durch User
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.
Respekt, schöne Fotos, schönes Platinenlayout. Wenn deine Software genauso aussieht, biste ein echtes Vorbild!
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?
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?
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
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?
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
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
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 :)
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
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
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.
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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
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....
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):
1 | void rfm_init(void) |
2 | {
|
3 | rfm_communication_enable = 0; |
4 | |
5 | spi_init(); |
6 | ext_irq_init(); |
7 | |
8 | |
9 | rfm_send_spi_cmd(0x0200,1); // FSK, Packet mode, no shaping |
10 | |
11 | |
12 | uint8_t bw; |
13 | uint16_t fdev; |
14 | |
15 | switch (RFM_BITRATE/19200L) |
16 | {
|
17 | case 0: |
18 | case 1: |
19 | bw = 0x03; // 62.5 kHz |
20 | fdev = (45000LL * 524288LL + RFM_FXOSC / 2) / RFM_FXOSC; |
21 | break; |
22 | case 2: |
23 | case 3: |
24 | bw = 0x02; // 125 kHz |
25 | fdev = (90000LL * 524288LL + RFM_FXOSC / 2) / RFM_FXOSC; |
26 | break; |
27 | default:
|
28 | bw = 0x09; // 200 kHz |
29 | fdev = (120000LL * 524288LL + RFM_FXOSC / 2) / RFM_FXOSC; |
30 | break; |
31 | }
|
32 | |
33 | // Frequency Deviation
|
34 | rfm_send_spi_cmd(0x0500 | (fdev >> 8), 1); |
35 | rfm_send_spi_cmd(0x0600 | (fdev & 0xFF), 1); |
36 | |
37 | // Data Rate
|
38 | rfm_send_spi_cmd(0x0300 | RFM_BITRATE_MSB, 1); |
39 | rfm_send_spi_cmd(0x0400 | RFM_BITRATE_LSB, 1); |
40 | |
41 | // Receiver Bandwidth
|
42 | rfm_send_spi_cmd(0x1940 | bw, 1); |
43 | |
44 | if (bw) bw--; |
45 | |
46 | // AFC
|
47 | rfm_send_spi_cmd(0x1A40 | bw, 1); |
48 | |
49 | |
50 | rfm_send_spi_cmd(0x131B, 1); // OCP enabled, 100mA |
51 | |
52 | // DIO-Mapping
|
53 | rfm_send_spi_cmd(0x2500, 1); // Clkout, FifoFull, FifoNotEmpty, FifoLevel, PacketSent/CrcOk |
54 | rfm_send_spi_cmd(0x2607, 1); // Clock-Out off |
55 | |
56 | // Carrier frequency
|
57 | rfm_send_spi_cmd(0x0700 | RFM_FRF_MSB, 1); |
58 | rfm_send_spi_cmd(0x0800 | RFM_FRF_MID, 1); |
59 | rfm_send_spi_cmd(0x0900 | RFM_FRF_LSB, 1); |
60 | |
61 | // Packet config
|
62 | rfm_send_spi_cmd(0x3790, 1); // Variable length, No DC-free encoding/decoding, CRC-Check, No Address filter |
63 | rfm_send_spi_cmd(0x3800 + RFM_MAX_PAYLOAD_LENGTH, 1); // Max. Payload-Length |
64 | rfm_send_spi_cmd(0x3C80, 1); // Tx-Start-Condition: FIFO not empty |
65 | rfm_send_spi_cmd(0x3DA0, 1); // Packet-Config2 |
66 | |
67 | // Preamble length 4 bytes
|
68 | rfm_send_spi_cmd(0x2C00, 1); |
69 | rfm_send_spi_cmd(0x2D04, 1); |
70 | |
71 | // Sync-Mode
|
72 | rfm_send_spi_cmd(0x2E88, 1); // set FIFO mode |
73 | rfm_send_spi_cmd(0x2F2D, 1); // sync word MSB to 0x2D |
74 | rfm_send_spi_cmd(0x30D4, 1); // sync word LSB to 0xD4 |
75 | |
76 | // Receiver config
|
77 | rfm_send_spi_cmd(0x1800, 1); // LNA: 50 Ohm Input Impedance, Automatic Gain Control |
78 | rfm_send_spi_cmd(0x582D, 1); // High sensitivity mode |
79 | rfm_send_spi_cmd(0x6F30, 1); // Improved DAGC |
80 | rfm_send_spi_cmd(0x29C4, 1); // RSSI mind. -98 dBm |
81 | rfm_send_spi_cmd(0x1E2D, 1); // AFC auto on and clear |
82 | rfm_send_spi_cmd(0x2A00, 1); // No Timeout after Rx-Start if no RSSI-Interrupt occurs |
83 | rfm_send_spi_cmd(0x2B28, 1); // Timeout after RSSI-Interrupt if no Payload-Ready-Interrupt occurs |
84 | |
85 | rfm_send_spi_cmd(0x1180 | (RFM_OUTPUTPOWER & 0x1F), 1); // Set Output Power |
86 | |
87 | rfm_send_spi_cmd(0x0A80, 1); // Start RC-Oscillator |
88 | |
89 | do
|
90 | {
|
91 | rfm_send_spi_cmd(0x0A00, 0); // Wait for RC-Oscillator |
92 | }
|
93 | while (!(spi_rx_data & (1 << 6))); |
94 | |
95 | |
96 | rfm_send_spi_cmd(0x0104, 1); |
97 | do
|
98 | {
|
99 | rfm_send_spi_cmd(0x27FF, 0); |
100 | }
|
101 | while (!(spi_rx_data & (1 << 7))); |
102 | |
103 | }
|
104 | |
105 | |
106 | |
107 | |
108 | |
109 | void rfm_rx_on(void) |
110 | {
|
111 | rfm_send_spi_cmd(0x0110, 1); // rx on |
112 | do
|
113 | {
|
114 | rfm_send_spi_cmd(0x27FF, 0); |
115 | }
|
116 | while (!(spi_rx_data & (1 << 7))); |
117 | }
|
118 | |
119 | |
120 | |
121 | |
122 | |
123 | void EXTI9_5_IRQHandler(void) |
124 | {
|
125 | EXTI->PR |= EXTI_PR_PR7; |
126 | GPIOA->ODR ^= GPIO_ODR_ODR_5; |
127 | |
128 | |
129 | |
130 | rfm_send_spi_cmd(0x0000, 0); |
131 | rfm_send_spi_cmd(0x0000, 0); |
132 | rfm_send_spi_cmd(0x0000, 0); |
133 | rfm_send_spi_cmd(0x0000, 0); |
134 | rfm_send_spi_cmd(0x2810, 1); |
135 | |
136 | rfm_send_spi_cmd(0x0104, 1); |
137 | do
|
138 | {
|
139 | rfm_send_spi_cmd(0x27FF, 0); |
140 | }
|
141 | while (!(spi_rx_data & (1 << 7))); |
142 | |
143 | //for(volatile uint32_t i=0; i<10000; i++);
|
144 | rfm_send_spi_cmd(0x3DFF, 0); |
145 | rfm_send_spi_cmd(spi_rx_data | 0x3D04, 1); |
146 | rfm_send_spi_cmd(0x0110, 1); // rx on |
147 | }
|
Es liegt scheinbar an der AFC... Wenn ich AfcAutoOn nicht setze, dann funktioniert es. Hatte jemand damit auch schonmal Probleme??
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...
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
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.
:
Bearbeitet durch User
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.
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.
:
Bearbeitet durch User
Christian S. schrieb: > Beitrag "RFM69HW - Arduino Uno" > > Hier die Fragmente: > > Beitrag "RFM69HW - Arduino Uno" > > Mfg Das ist aber auch C++ :-)
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
:
Bearbeitet durch User
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.
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
:
Bearbeitet durch User
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.