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
Habs doch noch im Datenblatt entdeckt. Ist VDI. Hab ich wohl mal wieder überlesen. Danke nochmal für den Hinweis. 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
Thread beobachten
Seitenaufteilung abschaltenBitte 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.