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?
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?
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.txthttp://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!!
