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
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...
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.
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.
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.
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.
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
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
voidrfm_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
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.
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.
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
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
