Moin, ich habe hier zwei RFM12B-Transceiver die im 868Mhz Bereich funken. Beide sind an je einen Atmega8L angeschlossen die mit dem internen 4Mhz Takt betrieben werden. Die Module liegen ca. 20-30cm voneinander entfernt und haben keine Antennen. Als Software verwende ich eine Abgewandelte Version aus der PDF-Datei "RFM12B and AVR — quick start" (zenburn.net/~goroux/rfm12b/rfm12b_and_avr-%20quick_start.pdf). Geändert habe ich unteranderem die Stromversorgung der Module. Sie werden von einem Pin des µC versorgt, den ich einige ms nach Programmstart auf high schalte. Zudem habe ich den Code auf 1Mhz-Hardware-SPI umgestellt. Die Ansteuerung der beiden Module scheint auch zu funktionieren, da beide wie gewünscht am CLK-Pin einen Takt von 1,665 Mhz haben. Das eine Modul sendet im 1Sekunden Takt jeweils die Synchronisationszeichen + 1Byte Daten, was ebenfalls zu funktionieren scheint, da die angeschlossene LED dementsprechend blinkt. Allerdings kommt beim anscheinend nix richtiges an. Sobald ich am Empfänger aktiviere, das auf die Synchronisationszeichen getriggert wird passiert nix mehr. Wenn ich es aber deaktiviere, so das alles was empfangen wird, im FIFO landet. Kann ich sehen, dass jedes mal, wenn die LED am Sender blinkt (also was gesendet wurde) am Empfänger ein oder mehrere 0-en empfangen werden. Könnte sich irgendjemand meinen Code mal anschauen, woran das liegen könnte? Ich habe meine Software bereits mit sämtlichen anderen Codeschnipseln vergleichen und kann nix falsches endecken. Oder hat zufällig jemand eine Routine zum senden oder empfangen parat, die er mit mit einem rfm12b-868Mhz Modul an einem 4Mhz Atmega8 betreibt? Damit ich wenigstens schon mal eine Fehlerquelle ausschließen kann. mfg philipp
Philipp wrote: > Sie werden von > einem Pin des µC versorgt, den ich einige ms nach Programmstart auf high > schalte. Ich vermute mal, du meinst damit, daß du per high am Pin eine Treiberstufe (z.B. Transistor) schaltest, welches das RFM12 betreibt. Denn falls du das RFM12 Modul direkt vom Pin speisen solltest, kann ich dir nur davon abraten. Beim Senden wird laut Datenblatt ein Strom von bis zu 25mA gezogen, was bei den meisten Controllern nur im low Zustand, aber nicht im High Zustand geliefert werden kann. Dadurch kann beim Senden die Betriebsspannung des RFM12 einbrechen, was zu Problemen führen kann. Du solltest auch deinen Schaltplan online stellen um mögliche Fehlerquellen in der Beschaltung zu finden. Ciao, Rainer
Hallo, der AVR kann den Strom prinzipiell schon liefern, allerdings starten meine RFM02-Module nur 100% zuverlässig, wenn recht dicht am Modul ein Elko mit ca. 10µF sitzt. Da hätte ich dann aber Bedenken wegen des Ladestroms. Es gibt allerdings aus meiner Sicht kaum einen Gruns, die RFM-Nodule so zu schalten. Wenn die komplett schlafen ziehen die um 0,5µA... Gruß aus Berlin Michael
Schaltung kann ich leider nicht liefern, da die Module einfach per Kabel in an den jeweiligen Dev-Board angeschlossen sind. Die Kommunikation sollte aber in Ordnung sein, da wie bereits erwähnt der eingestellte Takt am Clk-Pin der Module raus kommt. Doch, ich hatte beide Module direkt von dem µC-Pin mit Strom versorgen lassen, da sie, wenn direkt an die Stromversorgung mit angeschlossen, nur ab und zu liefen, bzw. Befehle annahmen. Hab sie jetzt wieder direkt an der Stromversorgung und so dicht wie möglich nen Kondensator mit rein (hatte allerdings nur 470µF zur Hand). Verändert hat sich nur, dass mein empfänger wieder nicht richtig auf die Befehle reagiert (CLK-Takt bleibt bei 1Mhz). Hätte sonst noch jemand ne Idee.
Ich habe in der Zwischenzeit die Software aus diesem Thread: www.mikrocontroller.net/topic/120759 ausprobiert. Es tritt der selbe Effekt auf, das nur 0en empfangen werden. Es muss also irgendwo ein Hardwareproblem sein. Allerdings ergibt dies kein Sinn, da ich das Statusregister der Module ohne Probleme auslesen kann => die Kommunikation funktioniert also. Schwankungen in der Stromversorgung konnte ich auch nicht feststellen, sowei mir das mit meinem Messgerät möglich war (Messgerät zeigte sowohl bei Wechselspannung wie auch bei Frequenzmessung 0 an). Oder kann es sein, das bei einem der Module ein Teil defekt ist?
Auch wenn die Module nur per Kabel verbunden sind gibt es einen Schaltplan. Also fix zeichnen.
Angehängte Dateien:
-
rfm12btest.png
13 KB
So, ich hab den Schaltplan jetzt mehr oder weniger schnell zusammen gepfuscht. Ich hoffe, ihr könnte damit was anfangen. Bevor die Frage aufkommt, wo denn der ISP-Anschluss ist: Beide Controller werden übers UART programmiert. Der an dem die LED dran ist, dient mir als Sender. Kabellängen von den Controllern zu den Funkmodulen betragen ca. 7cm (+/- 1cm). Hat jetzt noch jemand nen Tipp, was ich versuchen könnte?
Hab nen Fehler im Schaltplan gemacht. Die LED beim unteren Controller hängt an PB0. PB2 (SS) ist mit nix verbunden.
Ich glaub ich gebs auf. Ich hab jetzt direkt an die Module zwischen VCC und GND jeweils einen 10µF Elko gelötet und mir die Daten die zum Modul hin gehen mit meinem tollen 08/15-Soundkarten-Oszilloskop angesehen. Da laufen die Bits so durch wie sie sollen. Jetzt bleibt eigentlich wirklich nur noch ein Defekt in einem der Module übrig.... :(
Benutzt du nIRQ oder SDO zum Prüfen auf neue Daten bzw ob neue Daten gesendet werden können? Ich habe vor ein paar Monaten ein Projekt gehabt, in welchem ich erstmalig mit den RFM12 Modulen zwei Schaltungen "vernetzen" musste. Bei meinen ersten Experimenten hat sich rausgestellt, daß nIRQ (bei mir) nicht wirklich funktioniert. Deshalb bin ich auf eine Prüfung von SDO=1 umgestiegen, womit es dann auch sehr gut funktioniert. Da ich einen engen zeitlichen Rahmen hatte, konnte ich mir damals das Problem mit nIRQ leider auch nicht näher anschauen. Ich habe noch zwei kleine Programme, welche ich anfangs zum Testen der Hardware/Software benutzte. Eines hat dauernd 0x2DD4 (Synchronisationsmuster) gesendet. Das zweite Programm hat nach dem Synchronisieren die nachfolgenden 0x2DD4 als ASCII auf der RS232 Schnittstelle ausgegeben. Diese Programme haben sehr zuverlässig funktioniert. Die Programme und Hardware sind zwar für einen P89LPC935 (8051er) Controller ausgelegt, aber eventuell hilft dir der C Code doch etwas weiter. Denn bis auf die Spezialregister für das SPI ist der Code auch auf andere Controller übertragbar. Da man leider nur eine Datei an den Beitrag anhängen kann, habe ich meine beiden Programme auf meinen Server gelegt: http://quakeman.homelinux.net/files/Test_RFM12_RX1.c.txt http://quakeman.homelinux.net/files/Test_RFM12_TX1.c.txt Ciao, Rainer
Vielen Dank für den Quellcode. Werde mir den mal genauer ansehen. In der Zwischenzeit habe ich rausgefunden, dass auf am dem Mikrocontroller, welcher als Empfänger dient, beim übertragen eines Bytes an das Funkmodul die Taktleitung nur ein mal von Low auf High und zurück geht und nicht wie's eigentlich sein sollte 8 mal. So langsam wird das ganze merkwürdig....
So, ich hab den Code von Fox Mulder mit meinem verglichen und entsprechend angepasst. Zusätzlich habe ich nen anderen µC ausprobiert, um sicher zu sein, das es nicht an dem liegt. Funktionieren tut es aber dennoch nicht. Nach der Initialisierung ist der SDO Pin low, der nIRQ Pin auch low und im Statusregister steht 0x0000. Die Initalisierung scheint jedoch funktioniert zu haben, da am CLK Pin der Module 1,6Mhz ausgegeben werden. Nun hab ich noch mal mitgelesen, was die Module während der Initialisierung ausgeben: EINGABE -- AUSGABE 0x80E7 -- 0x0000 1000000011100111--0000000000000000 0x82C8 1000001011001000--0000000000000000 0xA74E -- 0x8008 1010011101001110--1000000000001000 0xC647 1100011001000111--0000000000000000 0x94A4 1001010010100100--0000000000000000 0xC2AC 1100001010101100--0000000000000000 0xCA81 1100101010000001--0000000000000000 0xC493 1100010010010011--0000000000000000 0x9827 1001100000100111--0000000000000000 0xE000 1110000000000000--0000000000000000 0xC800 1100100000000000--0000000000000000 0xC040 1100000001000000--0000000000000000 0x0000 0000000000000000--0000000000000000 Es kann doch nicht sein, das alle 4 Module, die ich hier habe defekt sind, oder? Könnte vielleicht einer von euch mal, wenn er grade nix zu tun hat, die Intialisierung eines seiner Module protokollieren?
Hallo, ich bin derzeit ebenfalls mit dem RFM12B beschäftigt, kämpfe aber mit anderen Themen. Zu Deinem Problem : Es gibt im Datenblatt des RFM12B ein einfaches Beispiel für einen Sender und einen Empfänger, jeweils in C geschrieben. Da heißt es : Initialisierung Sender RFXX_WRT_CMD(0x80E7);//EL,EF,868band,12.0pF RFXX_WRT_CMD(0x8239);//!er,!ebb,ET,ES,EX,!eb,!ew,DC RFXX_WRT_CMD(0xA640);//434MHz RFXX_WRT_CMD(0xC647);//4.8kbps RFXX_WRT_CMD(0x94A0);//VDI,FAST,134kHz,0dBm,-103dBm RFXX_WRT_CMD(0xC2AC);//AL,!ml,DIG,DQD4 RFXX_WRT_CMD(0xCA81);//FIFO8,SYNC,!ff,DR RFXX_WRT_CMD(0xCED4);//SYNC=2DD4; RFXX_WRT_CMD(0xC483);//@PWR,NO RSTRIC,!st,!fi,OE,EN RFXX_WRT_CMD(0x9850);//!mp,90kHz,MAX OUT RFXX_WRT_CMD(0xCC77);//OB1,OB0, LPX,!ddy,DDIT,BW0 RFXX_WRT_CMD(0xE000);//NOT USE RFXX_WRT_CMD(0xC800);//NOT USE RFXX_WRT_CMD(0xC040);//1.66MHz,2.2V Initialisierung Empfänger RFXX_WRT_CMD(0x80E7);//EL,EF,868band,12.0pF RFXX_WRT_CMD(0x8299);//!et,!ebb,ET,ES,EX,!eb,!ew,DC RFXX_WRT_CMD(0xA640);//434MHz RFXX_WRT_CMD(0xC647);//4.8kbps RFXX_WRT_CMD(0x94A0);//VDI,FAST,134kHz,0dBm,-103dBm RFXX_WRT_CMD(0xC2AC);//AL,!ml,DIG,DQD4 RFXX_WRT_CMD(0xCA81);//FIFO8,SYNC,!ff,DR RFXX_WRT_CMD(0xCED4);//SYNC=2DD4; RFXX_WRT_CMD(0xC483);//@PWR,NO RSTRIC,!st,!fi,OE,EN RFXX_WRT_CMD(0x9850);//!mp,90kHz,MAX OUT RFXX_WRT_CMD(0xCC77);//OB1,OB0, LPX,!ddy,DDIT,BW0 RFXX_WRT_CMD(0xE000);//NOT USE RFXX_WRT_CMD(0xC800);//NOT USE RFXX_WRT_CMD(0xC040);//1.66MHz,2.2V Unterschiedlich ist nur das Register 0x82XX. Dein Code zeigt 0x82C8, was in der Tat richtig zu sein scheint. Nach dem Initialisieren des Moduls als Receiver muss der IRQ-Pin auf HIGH gehen. Wenn er das nicht tut, ist vielleicht der Pin des µC als Ausgang und auf Masse geschaltet. Ein Pullup jedenfalls ist nicht erforderlich.
Hallo, das mit dem IRQ kann ich zumindest beim RFM12 nicht bestätigen, meine (reine) Empfangsroutine läuft auf 2 RFM12 komplett transparent nur im IRQ von nIRQ ohne Probleme. Hatte ich hier schonmal reingestellt: Beitrag "RFM12 Interrupt gesteuert" Gruß aus Berlin Michael
Der IRQ-Pin geht auf High, wenn ich das Modul nur als Sender konfiguriere. Den hab ich momentan auch nirgendswo angeschlossen. Dennoch steht im Statusregister, egal ob Sender oder Empfänger immer nur 0x0000, was eigentlich nicht sein darf. Verbindung zum µC ist aber in Ordnung.
Ich hab jetzt rausgefunden, woran es lag!! :) Die Module mögen es anscheinend nicht, wenn ihr Chip-Select Pin dauerhaft mit GND verbunden ist. Lasse ich den Pin vom Microkontroller steuern, dann funktioniert es (fast) einwandfrei. Es werden nun zwar immer zwei Zeichen gesendet anstatt einem, aber das scheint an meiner Senderoutine zu liegen.. Danke für all die Ratschläge und Tipps!!
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.