Hallo,
wie dem Betreff bereits zu entnehmen ist, bekomme ich die Funkmodule
RFM01/RFM02 einfach nicht zum laufen. Ich hoffe, dass mir hier jemand
weiterhelfen kann. Die Datenblätter für das RFM01 und RFM02 scheinen
inzwischen OK zu sein (Wenn auch viele Informationen leider fehlen...).
Ich habe bislang zumindest keine großen Fehler gefunden und sie stimmen
auch mit den Datennblättern vom RF01 und RF02 überein. Ich habe
versucht, den Code anhand der Datenblätter und mit dem scheinbar nach
wie vor fehlerhaften Pollin-Code zu erstellen.
Über die UART-Schnittstelle schickte mir der Mikrocontroller am RFM01
nur 0en, das aber immerhin nur, solange auch der Sender (RFM02)
eingeschaltet war. Ich habe nun versucht, mit einer Abfrage des FFIT
statusbits im Code für das RFM01 den Fall, dass der Interrupt nicht von
einem vollen FIFO ausgelöst wird, abzufangen und nun bekomme ich über
die UART gar keine Ausgabe mehr.
Ich habe auch den Code von Benedikt ausprobiert, welcher ebenfalls in
der Abfrage, ob etwas Empfangen wird ("1 an SDO"), hängen bleibt.
Die Belegung der PINS vom RFM01, RFM02 und von den Mikrocontrollern
steht in meinem Quellcode ganz oben als Kommentar. Als Mikrocontroller
verwende ich jeweils einen mit 8MHz getakteten ATMEGA8. Bei den beiden
Modulen handelt es sich laut Aufdruck um rev. 5.
Inzwischen habe ich glaube ich sämtliche Beitrage zu dem Thema hier im
Forum rauf und runter gelesen.
Wäre super, wenn sich jemand, der mehr Erfahrung mit den Modulen hat,
mal meinen angehängten Quellcode anschauen könnte. Vielleicht ist es ja
nur mal wieder ein ganz dämlicher Fehler...
Gruß Tobias
Hallo Tobias,
kenne die RFM01/02 nicht.
Ich bin jedenfalls mit dem RFM12 in einen ganz dämlichen Fehler
gelaufen: ich hatte überlesen, dass das Modul 100ms zur Initialisierung
benötigt und man erst nach dieser Zeit SPI-Commands schicken kann. Das
hat mich einen ganzen Abend beschäftigt, weil das Modul sich sehr
seltsam verhielt, mal ging es, mal nicht - bis mir dann endlich dieser
Satz im Datenblatt auffiel und dann war alles gut.
Vielen Dank erstmal für die schnelle Antwort!
Das mit den Zeiten hatte ich zuerst auch überlesen, habe hier allerdings
nochmals genauer im Datenblatt nachgelesen, nachdem ich hier in mehreren
Beiträgen davon gelesen habe. Beim RFM02 sollten 50ms reichen und beim
RFM01 150ms. Ich warte bei beiden vorsichtsheitshalber 200ms das sollte
also denke ich nicht das Problem sein.
Gruß Tobias
Also einen saudämlichen Fehler habe ich inzwischen behoben (Die
Initialisierung der Ports war/ist im ersten Code natürlich völliger
Blödsinn).
Ich gebe mir inzwischen auch den Inhalt der Statusbits über die Uart aus
und werte über diese jetzt auch aus, ob der Interrupt durch ein
vollständiges Empfangenes Byte ausgelöst wurde. Das ganze funktioniert
soweit jetzt, allerdings empfange ich anstatt dem gesendeten 0xAFFE
(fast durchgängig) nur 0xFFFF.
Hat vielleicht jemand eine Idee, an was das noch liegen könnte?
PS: Der aktuelle Code ist diesem Beitrag angehängt
Gruß Tobias
Ich habe beste Erfahrungen damit gemacht, den Fifo jedesmal nach dem
Empfang neu zu initialisieren. Also Fifo Reset (0xCE84) und dann Fifo
Restart(0xCE87) machen.
Ich kann dir gerne mal Code posten, allerdings ist meiner für 868Mhz und
in Assembler.
Ich habe das gerade mal ausprobiert mit dem Fifo Reset und Restart. Das
wäre bei mir dann nach der Zeile "buf = receiveByte();". Dann empfange
ich jedoch gar nichts mehr.
Wenn du mir deinen Code posten könntest das wäre nett. Ich kann zwar
kein Assembler für AVR Mikrocontroller aber für diverse andere,
vielleicht fang ich ja etwas damit an :-)
Heute ist mein neues Oszilloskop gekommen und ich habe jetzt mal am
Sender gemessen, was denn überhaupt vom µC an das RFM02 übertragen wird.
Hier scheint alles in Ordnung zu sein (frequenz von nIRQ = 4,8kHz und
auch die Daten, welche der µC hierbei zurücksendet entsprechen der
Präambel, Synchronisationswort und dem zu übertragenden 0xAFFE). Daraus
schließe ich, dass das Initialisieren des RFM02 funktioniert und ich
würde den Fehler nun eher beim Empfänger suchen.
Lässt sich am RFM01 vielleicht irgendwo direkt Messen, was für Daten es
empfängt (Ich meine ich hätte hier in einem Beitrag etwas in die
Richtung gelesen, finde es gerade aber nicht mehr)
Gruß Tobias
Ich habe gerade so festgestellt, dass bereits das leichte Berühren eines
Kabels am Steckbrett beim RFM01 komplett andere Empfangsergebnisse
liefert. Ich werde mir wohl erst einmal 2 Platinen für die Module ätzen,
nicht dass es nachher nur am Steckbrett liegt...
Gruß Tobias
Hallo Tobias,
ich habe schon öfter gelesen, dass die Steckbretter durchaus
problematisch sein können, weil sie sehr viel Metallmasse enthalten um
die Steckkontakte zu realisieren - z.B. haben sie wohl recht hohe
Kapazität im vgl. zu einer normalen Platine.
Das könnte die Antennenverhältnisse eines RF-Moduls schon
durcheinander bringen.
Bei mir setze ich allerdings die RFM12 bisher nur auf Steckbrettern ein
und habe einfach ein 8cm Prototypenboard-Kabelchen senkrecht als Antenne
eingesteckt und die Module funktionieren wunderbar auf eine Entfernung
von ca. 5m innerhalb der Wohnung. Reichweite habe ich noch nicht genauer
ausgetestet, bei ab 7/8m war's mal wechselhaft kann ich mich an einen
Versuch erinnern. Wir haben aber auch recht dicke Ziegelwände im Haus -
da reicht selbst das WLan gerade noch in den Nebenraum.
Ich würde also meinen, dass nicht das Steckboard sein sollte, wenn die
Module eher nah beeinander sind, auf einem Tisch beim Entwickeln
sozusagen.
Danke für den Hinweis. Also der Abstand wir es wohl kaum sein der
beträgt ca 15 cm. Das RFM02 scheint wie oben geschrieben auch zu
funktionieren.
Mein Steckbrett ist allerdings nicht gerade das beste und ich hatte hier
schon hin und wieder Probleme mit den Kontakten. Da ich für die Module
wenn sie denn dann irgendwann hoffentlich mal laufen sollten sowieso
Platinen brauchen ziehe ich das entwerfen, ätzen und bestücken der
Platinen jetzt einfach mal vor.
Gruß Tobias
Ich konnte es einfach nicht lassen und habe gerade nochmal etwas an den
Kabeln gewackelt und habe jetzt doch tatsächlich das gesendete Wort
empfangen. Es scheint also tatsächlich an den Kabelen/dem Steckbrett zu
liegen. Ich werde auf jeden Fall nochmals berichten, wenn meine Platinen
fertig sind. Das kann aber etwas dauern .-)
Gruß Tobias
Bei mir hat es sich auch bewährt, direkt an Vcc auf dem Platinchen einen
SMD Elko gegen Masse zu schalten. Die Empfindlichkeit des Empfängers
steigt auch enorm an, wenn man ihn über eine gut abgedrosselte
Betriebsspannung versorgt und nicht direkt aus der Vcc des
Mikrocontrollers.
Anbei der Code für den Receiver. Dieser Code läuft auf einem Arduino und
sendet über die serielle Konsole das Statusbyte, wenn das RFM01 was
empfangen hat. Die empfangenen Bytes werden in den Buffer ab DMXSTART
eingelesen, mit einer kleinen Prüfsumme.
Wie bereits erwähnt, ist für 868 MHz, die gewählte Bitrate der
Funkstrecke ist hier 4800, seriell werden 19200 Baud benutzt.
Hallo Matthias,
Danke für den Quellcode.
Das RFM01 sollte seine Spannung von einem 7805 beziehen und das RFM02
von einem LF33CV. Ich hatte eigentlich vor, diese direkt dort
anzuschließen und wie auch bei den Mikrocontrollern an VCC kleine
Keramikkondensatoren (100nF und zusätzlich noch wie im Datenblatt 220pF)
anzubringen. Die Mikrocontroller hängen dann natürlich jeweils am
gleichen Spannungsregler. Ist wirklich ein "großer" Elko an VCC
notwendig? Normal reicht das doch einer für so eine kleine Platine in
der nähe des Spannungsreglers!?
Wenn ich dich richtig verstehe, wäre es sogar sinnvoll, das RFM01/RFM02
direkt aus einem Pin des Mikrocontrollers mit Spannung zu versorgen!?
Das wollte ich eigentlich nicht, da ich viele Pins brauche. Wenn das
jedoch die Sende-/Empfangsqualität aus irgendwelchen Gründen erhöhen
sollte wäre es mir den einen Pin wert :-)
Gruß Tobias
Tobias L. schrieb:> Wenn ich dich richtig verstehe, wäre es sogar sinnvoll, das RFM01/RFM02> direkt aus einem Pin des Mikrocontrollers mit Spannung zu versorgen!?
Oh nein, da hast du etwas falsch verstanden. Im Gegenteil, je weniger
der RFM (vor allem der Empfänger) von den Störungen des MC abkriegt,
desto besser. Der SMD Elko, den ich hier benutze, ist nicht grösser als
4u7 - 15u. Wichtig ist eine Drossel (100uH - 470uH) in der
Betriebsspannung für das Modul. Damit filterst du etwaige Störungen auf
der Betriebsspannung von MC oder anderen Oszillatoren weg, bevor sie das
Modul erreichen.
Ich habe mit diesen Massnahmen und Schnurlostelefon Antennen schon
locker 200-300m überbrückt. Ohne die Entstörungsmassnahmen am Empfänger
warens nur 40-50m, also ein deutlicher Gewinn.
Die Antennen waren in diesem Fall ausserhalb des Metallgehäuses (LED
Beamer, der seine Vcc wirklich verseucht) und das RFM Modul war ein
wenig vom MC abgesetzt.
Achso, im Quellcode sind noch Pins des Moduls wie VIN usw. an den MC
angeschlossen. Das ist lediglich für Versuchszwecke. Allerdings muss an
VIN ein Pullup von ca. 10k, das wird aber in den Hope Datenblättern
irgendwo erwähnt.
Ok. Dass hier sogar eine Drossel notwenig ist hätte ich nicht gedacht.
Werde das bei meinem Schaltplan/Layout noch einbauen. Das scheint sich
ja richtig zu lohnen bei dem Reichweitengewinn.
Welchen Pin meinst du genau mit VIN (bei mir ist kein Pin so
bezeichnet). Meinst du vielleicht VDI? Ich habe bislang lediglich einen
Pullup an Data/nFFS, die restlichen nichtbenötigten Pins hängen in der
Luft.
Gruß Tobias
Aber so wie ich das lese ist es bei Verwendung des
Synchroniserungswortes nicht notwendig. So wie ich das lese würde er den
Fifo dann sogar füllen, wenn kein Synchronisationswort erkannt wurde.
Das ist ja in meinem Betriebsmodus nicht erwüscht. Da müsste doch eher
ein Pulldown Widerstand hin oder habe ich hier einen Denkfehler?
Gruß Tobias
Tobias L. schrieb:> Aber so wie ich das lese ist es bei Verwendung des> Synchroniserungswortes nicht notwendig. So wie ich das lese würde er den> Fifo dann sogar füllen, wenn kein Synchronisationswort erkannt wurde.> Das ist ja in meinem Betriebsmodus nicht erwüscht. Da müsste doch eher> ein Pulldown Widerstand hin oder habe ich hier einen Denkfehler?>> Gruß Tobias
Hehehe, jetzt muss ich mich doch noch mal durch den Code wühlen - ist
schon ein bisschen her. Ja, du hast natürlich recht, Pullup an nFFS, und
VDI kriegt in meinem Code einen Pullup vom AVR spendiert, muss aber
vermutlich nicht sein. Ich wollte mir in der Software die Option auf
direktes FSK offenhalten, mit dem Synchronwort ist das alles nicht
nötig, lediglich der Pullup an FFIT sollte dran sein.
Das Pollin Programm hatte bei mir auch den Nachteil, das ISP nicht mehr
ging, wenn das Modul angeschlossen war, deswegen bei mir auch eine
andere Pinbelegung.
Hallo,
ich bin inzwischen dazu gekommen, meine Platinen zu bestücken und in
Betrieb zu nehmen. Mal davon abgesehen, dass die letzten beiden Bit der
von mir übertragenen 2 Byte eine extrem hohe Bitfehlerhäufigkeit
aufweisen funktioniert die Übertragung damit nun. Dem muss ich bei
Gelegenheit mal noch voll auf den Grund gehen.
Vielen Dank an dieser Stelle nochmal an alle, die mir hier
weitergeholfen haben.
Gruß Tobias
