mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik RFM12: Erfahrungen


Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich denke mal, dass hier schon einige die RFM12 Module verwendet haben. 
Mich würde jetzt mal interessieren, wie die Erfahrungen mit diesen recht 
grünstigen Modulen sind.
Ich habe diese mittlerweile mehrfach im Dauerbetrieb laufen, und mir ist 
aufgefallen, dass sich ab und zu einige Module aufhängen. Irgendein 
Register verstellt sich anscheinend, so dass die Daten nicht mehr 
richtig übertragen werden. Zumindest wurde dieser Verdacht dadurch 
verstärkt, dass das Problem weg sind, seitdem ich periodisch alle paar 
Minuten die Einstellungen neu sende. Außerdem sind einige Module 
anfälliger als andere.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das passiert bei mir nur bei dem jeweils empfangenden Modul. Da ich mit 
Interrupten, Timern und Zählvariablen arbeite, kann ich feststellen, 
wenn ein Modul beim Empfang abkackt und es dann neu initialisieren. Es 
scheint mit dem FIFO und den damit korrespondierenden Einheiten im Chip 
zusammenzuhängen.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei mir passiert das dummerweise auch bei sendenden Modulen. Dank 
Listen-before-Talk empfange ich aber auch. Mittlerweile habe ich einen 
Timeout drin, der das Modul neu initialisiert, wenn 5 Minuten lang 
nichts empfangen wurde.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist stark applikationsabhängig, wie man da am besten verfährt und ob das 
Verhalten der Module stört. Ist natürlich ein lästiger Bug, den ich bis 
jetzt noch nicht annageln konnte :-(

Autor: Klaus G. (ktg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich benutze nicht das RFM12, sondern ein Pärchen RFM01/02 und kann daher 
nur darüber berichten.
Nach vielen eher ernüchternden Versuchen mit preiswerten Funkmodulen von 
Conrad und ELV (die Dinger fangen aufgrund ihrer Verstärkungsregelung 
jeden Dreck ein und man muß ewig Präambeln senden, damit sie sich wieder 
beruhigen) bin ich auf die hier reichlich diskutierten Module gestoßen, 
habe damit meine Versuche gemacht und muß sagen, daß ich (jetzt!) höchst 
zufrieden bin.
Wie an vielen Stellen im Forum erwähnt, ist es nicht trivial, dem 
Empfänger die Daten zu entlocken, die der Sender von sich gibt. Ich habe 
die Sache mit dem FIFO trotz der vielen Tips, die hier 
dankenswerterweise publiziert sind, recht schnell aufgegeben, da sich 
die Ergebnisse nicht reproduzieren ließen, d.h. mal ging es, mal nicht. 
Also habe ich die Betriebsart OOK gewählt, wie ich sie auch mit den o.a. 
Modulen ohnehin benutzen mußte, und siehe da, es läuft wie am 
Schnürchen. Wenn man einmal (beim Empfänger) die Verstärkung und die 
DRSSI-Schwelle (probieren!) eingestellt hat, geht es ab wie Schmitz' 
Katze. Kein Müll mehr, keine Präambel nötig, alles bestens. Ich bin auf 
eine Frequenz am unteren Ende des erlaubten Bereichs ausgewichen, so daß 
die Gefahr des Wetterstationengewitters kleiner ist, obwohl der 
Empfänger auch nicht gerade als schmalbandig zu bezeichen ist.
Ich muß natürlich erwähnen, daß meine Anwendung für den OOK-Betrieb 
geeignet ist, denn ich sende einfach einen Bitstream gemäß 
R5C-Kodierung, wie es auch IR-Fernbedienungen tun, d.h. mein Empfänger 
hatte ursprünglich einen IR-Sensor und natürlich die entsprechende 
Routine zum Dekodieren. Das Ganze habe ich nun auf Funk umgebaut und 
kodiere im Sender entsprechend; so mußte ich die Empfangsroutinen nicht 
neu schreiben, bis auf das Programmieren des Empfängers nach dem 
Einschalten.
Herzlichen Dank an alle hier im Forum, die mir mit ihren Beiträgen 
zumindest die Basics im Umgang mit den Modulen erleichtert haben.
Gruß, Klaus

Autor: Kai Franke (kai-) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich habe auch mal 2 Module (RFM12) mit Atmega8 aufgebaut und bin über 
die Leistung recht zufrieden, auch wenn es im Bereich Reichweite eben 
nie genug sein kann :P
Allerdings habe ich die Module bis jetzt auch nur zum Übertragen von 
einem Byte benutzt, also nichts langes, und am Empfänger eben abgefragt 
welches Byte ankam...
Was mir zum Verhängnis wurde war, dass die Empfangsverstärkung abnimmt 
falls die Spannung am Akku einbricht. Ich hatte am Empfänger nämlich 
über ein Relais eine Autohupe angeschlossen, die die Akkusspannung so 
weit in den Keller gezogen hat, dass das Modul den AUS Befehl nicht mehr 
empfangen hat :(

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@kai-
Weist du zufällig wie niedrig die Spannung war ?

Beim Senden habe ich die Module schon mit 2,5V betrieben, da hat sich 
nicht alltzuviel in der Amplitude geändert (warscheinlich deshalb weil 
der Sender eine Stromquelle ist, wenn ich das richtig gesehen habe).

Autor: Klaus G. (ktg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Kai:
Ich betreibe mein Set mit 3 Micro-Akkus (Atmega8L), was einen 
Spannungsbereich zwischen voll und leer von 3,85...2,7V umfasst 
(Lithium-Batterie mit 3,6V geht auch sehr gut) und habe keine Probleme 
damit insofern, als ich die Batteriespannung über einen Spannungsteiler 
mit 2x10K am Analogeingang zyklisch kontrolliere und die Verstärkung 
(nur Empfänger - der Sender bläst immer 'volles Rohr') entsprechend 
nachregele.
Problematisch ist bei Dir u.U. nicht die Höhe der Spannung an sich, 
sondern die Tatsache, daß die Spannung beim Losbrüllen der Hupe 
einbricht und den Empfänger sozusagen vollständig aus dem Tritt bringt. 
Über solche Effekte wurde hier gelegentlich schon berichtet.
Meine Empfehlung:
1. Stromversorgung von Hupe und Empfänger+MC separat halten. Ansteuerung 
des Relais dann über Optokoppler.
2. Funkmodul mit einem Keramikkond. 1µ direkt am Modul zwischen Vcc und 
GND stützen. Die hier schon mal erwähnte Pufferung mit Elkos im 
2-stelligen µ-Bereich bringt nicht viel, da die aufgrund ihres hohen 
Innenwiderstands bei hohen Frequenzen (sprich: steilen Flanken) viel zu 
lahm sind; sie sind allenfalls zusätzlich einzusetzen bei langen 
Batteriezuleitungen, aber der KerCo muß sein.
Ich habe jedenfalls mit dieser Maßnahme die Stabilität enorm steigern 
können.

Gruß, Klaus

Autor: Björn B. (elmo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Klaus,

du schreibst dass du deine Module mit Akkus betreibst. Das gleiche tue 
ich hier auch zwecks Aussentemperaturmessung mit 3.7V Li-Ion Akkus. Um 
möglichst wenig Energie zu verbrauchen benutze ich den WakeUp Timer vom 
RFM Modul. Ich aktiviere diesen und schicke danach das Modul und den 
mega8 schlafen. Über den nINT Pin vom Modul wird der mega8 dann nach 
etwa 30s wieder geweckt. Leider klappt dies nur meistens, in 
unvorhersehbaren Abständen scheint sich das Modul aufzuhängen. Das eine 
Modul, von zweien, läuft bei Zimmertemperatur ein paar Tage, das andere 
nur wenige Stunden. Ich schreibe deshalb Zimmertemperatur, weil sich 
beide Module grundsätzlich weghängen, wenns kalt wird (Gefrierschrank). 
Ohne den Sleep-Modus zu benutzen funktionierts allerdings tadellos.
Vielleicht weisst du, oder jemand anders der mitliest, einen Rat? Oder 
du könntest mir deinen Aufbau (Hard- und Software) etwas näher 
beschreiben?

Gruß
Björn

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was hältst Du davon, das Modul über einen Transistor vom ATMEGA 
versorgen zu lassen, den ATMEGA in den Sleep schicken und das Modul 
abschalten, per Watchdog alle paar Sekunden den ATMEGA kurz aufwachen zu 
lassen, alle paar Weckzyklen das Modul mit einzuschalten, zu 
initialisieren, eine Messung zu machen und die Werte zu übertragen und 
so weiter?

Autor: Kai Franke (kai-) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nochmal zu meinem Aufbau. Ich habe einen Bleiakku (12V/1,5Ah) für den 
Empfänger benutzt und über einen 7805 runtergeregelt. Die Hupe hing dann 
eben wieder direkt an dem Akku.
Sobald ich die Entfernung verringert hatte, hat der Empfänger auch 
wieder geschaltet, kann aber auch sein, dass das mit der kurzen 
Wartezeit zu tun hatte, sodass sich das Modul "erholen" konnte.
Ich war eben eher darum besorgt die Autohupe wieder aus zu bekommen, 
dass ich den Bleiakku noch verwenden kann. Der nächste Versuch bekommt 
auf jeden Fall eine eigene Stromversorgung und 1µF KerKos hab ich auch 
noch genug :P

@Björn: Wenn das mit dem Aufwachen funktionieren sollte, würde ich mich 
sehr dafür interessieren, weil ich noch eine Lösung für Batterien suche. 
Momentan zieht ein ATmega8 und das Modul glaube ich etwa 30mA, kann mich 
aber auch irren

Autor: Klaus G. (ktg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Björn:
Es ist offensichtlich so, daß, wie verschiedenen Beiträgen hier zu 
entnehmen ist, die RFMxx sehr kapriziös sind und durchaus ihre eigene 
Ansicht darüber haben, ob sie nun arbeiten oder streiken wollen. Die 
Module entsprechen, soweit ich das sehen kann, dem Referenzdesign von 
HopeRF. Da ich nicht glaube, daß der Fertigungsprozess der Module 
variant ist, vermute ich eher, daß die auf den Modulen verarbeiteten 
Chips u.U. nur 2. Wahl sind - traurig, aber möglich.
Ich halte deshalb den Vorschlag von travelrec für eine sehr gute Lösung.
Im Sleep-Modus 'PowerDown' braucht der Atmega nur max. 1µA. Den 
Transistor kann man sich sparen und den Sender direkt aus einem Portbit 
versorgen, weil der die max. 25mA des Senders locker geregelt bekommt, 
falls nicht noch weitere Stromfresser an dem Port hängen, weil, wenn ich 
mich recht erinnere, die Summe der Ströme eines Ports 200mA nicht 
überschreiten darf.
Dieses Verfahren geht allerdimgs nur solange gut, wie die Akkuspannung 
nicht unter 3V sinkt, denn man muß damit rechnen, daß am Port max. 0.8V 
abfallen, und der Sender braucht nun mal min. 2.2V lt. Datenblatt.
Akkus in kalter Umgebung sind eine Sache für sich. Ein LiPo-Akku 
verliert bei 0° 0.125V/Zelle, bei -20° bereits 0.3V, jedoch zählt dieser 
Akkutyp noch zu den robusten bei niedrigen Temperaturen. NiMH-Akkus 
sehen hier sehr schlecht aus (Digitalfotografen können im Winter ein 
Lied davon singen), und NiCd-Akkus sind demnächst nicht mehr zu 
bekommen.
Zu empfehlen ist daher für solche Temperaturen eine Lithium-Batterie(!) 
mit 3,6V (Omnicel oder TekCell bei z.B. Reichelt), die bis -55° 
spezifiziert ist. Die Baugröße AA hat eine Kapazität von 2400mAh. Dann 
ist auch das Problem der Selbsentladung gelöst, denn diese Biester 
halten 10 Jahre. Damit solltest Du Deine Schaltung ewig betreiben 
können, wenn nur hin und wieder etwas Strom gebraucht wird.
Was meinen Aufbau betrifft, so ist er trivial. Da ich weder 
außergewöhnliche Temperaturen bedenken, noch Strom sparen muß, benutze 
ich auch keinen Wecker. Es ist eine Fernbedienung mit drei Tasten, die 
bei Bedarf eingeschaltet und danach wieder ausgeschaltet wird. Da das 
Ganze in ein noch als handlich zu bezeichnendes Gehäuse passen soll, 
habe ich mich, auch wegen der ständigen Verfügbarkeit, für die 
Versorgung mit 3xAAA entschieden. Die aktuelle Spannung frage ich über 
einen 2x10K-Spannungsteiler an einem Analogeingang ab und signalisiere 
ihn über die Blinkfrequenz einer LED, damit dem Teil nicht im falschen 
Moment die Puste ausgeht.
Mir geht jetzt auch die Puste aus ;)
Gruß, Klaus

Autor: Björn B. (elmo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

@travelrec:
Die Idee finde ich gut. Ich werde es mal so ausprobieren. Bisher habe 
ich allerdings den Watchdog noch nie zum erwecken des uC benutzt. Würde 
dabei nicht auch ein Reset ausgeführt?

@Kai:
Ja ich komme mit meinem 3.6V Li-Ion Akku auf etwa 22mA permanenten 
Verbrauch. Das ist natürlich für Batteriebetrieb indiskutabel. Sobald 
ich eine schöne Lösung habe, wahrscheinlich mit travelrecs Methode, 
werde ich sie mal vorstellen.

@Klaus:
Ok das ohne Transistor wäre eine noch schönere Lösung. Mit dem 
kompletten Abschalten des Moduls wäre dann die Stabilität auch nur noch 
vom atmega, dem ich mehr vertraue, abhängig.
Mein erster Gedanke war bei dem Experiment mit dem Gefrierfach erstmal 
der Akku. Um das auszuschliessen habe ich auch die Akkuspannung messen 
und übertragen lassen (mit der internen Bandgap Referenz). Selbst bei 
-20°C lag der Akku noch gut über 3.6V. Das reicht für meine Tests 
erstmal.
Diese Lithium Batterien kannte ich noch garnicht, sehen aber sehr 
interessant aus. Sobald mein Aufbau stabil läuft und ich den 
Stromverbrauch hinreichend klein gemacht habe wäre das wohl die ideale 
Lösung!

Gruß
Björn

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Bisher habe
>ich allerdings den Watchdog noch nie zum erwecken des uC benutzt. Würde
>dabei nicht auch ein Reset ausgeführt?

Ja. Und? Ist ja nicht schlimm, wenn man´s weiß. Das SRAM behält (so man 
denn will) alle Daten und nur die I/Os werden initialisiert. 
Andererseits haben die neueren ATMEGAs und einige TINYs auch eine 
Watchdog-Interrupt-Funktion, die lediglich in den Interruptvektor 
springt, wenn der Controller geweckt werden soll.

Autor: Klaus G. (ktg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Travel Rec. wrote:
> Ja. Und? Ist ja nicht schlimm, wenn man´s weiß. Das SRAM behält (so man
> denn will) alle Daten und nur die I/Os werden initialisiert.
> Andererseits haben die neueren ATMEGAs und einige TINYs auch eine
> Watchdog-Interrupt-Funktion, die lediglich in den Interruptvektor
> springt, wenn der Controller geweckt werden soll.

Der Watchdog des Atmega8 löst in der Tat einen Reset aus, jedoch kann 
man im MCUCSR die Ursache des Reset nachschauen, d.h. im Falle Watchdog 
anders reagieren als bei einem Power-On-Reset.
Falls Du statische Laufzeitvariablen hast, wäre es zweckmäßig, zumindest 
die Unverzichtbaren vorm Zubettgehen ins EEPROM zu retten und nach einem 
Watchdog-Reset wieder hervorzuholen. Der SRAM bleibt zwar (zunächst) 
unverändert, aber falls Du in einer höheren Sprache (als Assembler) 
programmierst, werden von der automatisch dem eigentlichen (von Dir so 
gewollten) Programmstart vorangesetzten Präambel u.U. genau diese 
Variablen initialisiert. Ist ja auch richtig so, denn Du verläßt Dich ja 
darauf, daß eine als z.B. int willi=0; deklarierte Variable genau diesen 
Wert hat. Ob die Initialisierung unterbleibt, wenn man in der 
Deklaration keinen Wert zuweist, habe ich noch nicht probiert und mag 
auch vom verwendeten Compiler abhängig sein.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Falls Du statische Laufzeitvariablen hast, wäre es zweckmäßig, zumindest
>die Unverzichtbaren vorm Zubettgehen ins EEPROM zu retten und nach einem
>Watchdog-Reset wieder hervorzuholen.

Gute Idee, bei 7-sekündlichem Aufwecken ist das EEPROM in 8 Tagen im 
Eimer ;-). Vielleicht doch einen Controller mit Watchdog INT nehmen oder 
in Assembler proggen.

Autor: Klaus G. (ktg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Travel Rec. wrote:
>>Falls Du statische Laufzeitvariablen hast, wäre es zweckmäßig, zumindest
>>die Unverzichtbaren vorm Zubettgehen ins EEPROM zu retten und nach einem
>>Watchdog-Reset wieder hervorzuholen.
>
> Gute Idee, bei 7-sekündlichem Aufwecken ist das EEPROM in 8 Tagen im
> Eimer ;-). Vielleicht doch einen Controller mit Watchdog INT nehmen oder
> in Assembler proggen.

Hoppla! Das hatte ich nicht bedacht. Danke für den Hinweis. Wer lesen 
kann, ist eben klar im Vorteil :-).

Autor: Björn B. (elmo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Problem des zyklischen Aufwachens via WDT scheint nicht trivial zu 
sein ;-) Der Code, den ich bisher habe, existiert, wegen des Umfangs, 
nur in C. Den komplett in ASM zu portieren dürfte ein nicht 
unerheblicher Aufwand werden. Oder vielleicht bekommt man es mit einem 
Misch-Masch C,ASM hin? Bisher blieb auch die Suche nach schon existentem 
Code erfolglos. Wenn bloß der Wakeup Timer des Moduls zuverlässig 
funktionieren würde. Das scheint mir doch noch die einfachste Lösung zu 
sein. Da ich schon zwei Platinen angefertigt habe möchte ich die atmega8 
uC auch ungerne tauschen.

Klaus G. wrote:
> Ist ja auch richtig so, denn Du verläßt Dich ja
> darauf, daß eine als z.B. int willi=0; deklarierte Variable genau diesen
> Wert hat. Ob die Initialisierung unterbleibt, wenn man in der
> Deklaration keinen Wert zuweist, habe ich noch nicht probiert und mag
> auch vom verwendeten Compiler abhängig sein.

Soweit ich das der avr-libc FAQ entnehmen kann werden Variablen immer 
automatisch initilisiert. Int mit 0, Pointer mit NULL etc.

Gruß
Björn

Autor: Björn B. (elmo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ahaaa, zu voreilig geantwortet! Hiermit könnte es klappen:
http://www.roboternetz.de/wissen/index.php/Avr-gcc...
Sobald ich wieder zuhause bin und etwas Zeit habe werde ich es damit mal 
ausprobieren. Mal ausrechnen und messen wie weit ich den Stromverbrauch 
gedrückt bekomme wenn der Controller die vom Watchdog vorgegebenen 
maximalen 2s schläft und nur ganz kurz aufwacht.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Björn Biesenbach wrote:

> Soweit ich das der avr-libc FAQ entnehmen kann werden Variablen immer
> automatisch initilisiert.

...es sei denn, du packst sie in die .noinit section.

Du kannst aber auch die Initialisierungsfunktionen durch deine
eigenen ersetzen und dann die Initialisierung im Falle des
watchdog-Resets überspringen.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Das Problem des zyklischen Aufwachens via WDT scheint nicht trivial zu
>sein ;-) Der Code, den ich bisher habe, existiert, wegen des Umfangs,
>nur in C.

Doch ist es, zumindest in Assembler, da man da die volle Handhabe über 
den Controller hat. Die über das MCUC(S)R festgestellte Resetursache 
wird maskiert und dann entsprechend initialisiert oder ganz normal in 
die Main gesprungen. Nach dem Abarbeiten der gewünschten Funktionen wird 
alles sauber beendet, der Watchdog initialisiert und eingeschlafen. Viel 
mehr als 20 Zeilen zusätzlichen Code kostet das nicht.

Autor: Björn B. (elmo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

nach einigem Testen habe ich es nun mit dem Watchdog Reset hinbekommen. 
Leider ist der Stromverbrauch, bedingt durch den Watchdog, der mit 1MHz 
tickert und das zyklische, mindestens alle 2s, kurze aufwachen, 
wesentlich größer als vorher. Dafür stürzt das Modul nun nicht mehr ab! 
Zum Test habe ich dann nochmal die alte Methode mit dem Wakeuptimer vom 
RFM12 Modul reaktiviert. Siehe da, ein paar "Minusgrade" aus dem 
Gefrierfach kamen noch rüber, dann war wieder Schluss. Als ich dann den 
Interrupt Pin zum Aufwecken "per Hand" auf Masse gezogen habe, lief das 
Modul wieder weiter.
Es scheint eindeutig der WakeUpTimer zu sein der bei 
Temperaturschwankungen abstürzt. Hat schon irgendwer ähnliche 
Erfahrungen gemacht oder kann versuchen diesen Fehler bei sich zu 
reproduzieren? Vielleicht hat auch einfach meine Charge an RFM12 Modulen 
einen Weg. Sind welche aus der ersten oder zweiten Sammelbestellung.

Gruß
Björn

Autor: Kai Franke (kai-) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wieviel Strom zieht dein Modul denn momentan im Standby?

Autor: roboterheld (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...daß die auf den Modulen verarbeiteten
Chips u.U. nur 2. Wahl sind - traurig, aber möglich....


ist für leute gedacht die nach dem motto kaufen : geiz ist geil.

was wollt ihr von den billigprodukten verlangen. kauft euch welche für 
über 30 euro, dann seit ihr zufrieden.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>nach einigem Testen habe ich es nun mit dem Watchdog Reset hinbekommen.
>Leider ist der Stromverbrauch, bedingt durch den Watchdog, der mit 1MHz
>tickert und das zyklische, mindestens alle 2s, kurze aufwachen,
>wesentlich größer als vorher.

Der Watchdog läuft intern mit 128kHz, nicht mit 1Mhz. Der Controller 
kann dabei im absoluten Tiefschschlaf und ohne Takt sein und verbraucht 
dann so um die 40µA bei 5V. Das Modul schaltest Du vorher aus und beim 
Aufwachen nur dann an, wenn Du´s wirklich brauchst. Was hast Du denn an 
Strom gemessen?

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>was wollt ihr von den billigprodukten verlangen. kauft euch welche für
>über 30 euro, dann seit ihr zufrieden.

Das ist Unsinn. Einchip-Module kosten in der Heststellung nur einige 
Cent, warum soll man dann 30 Euronen für denselben Kram in grün löhnen? 
So schlecht sind die Teile auch gar nicht, wenn man von den paar Bugs 
absieht. Ich hatte mal Aurel-Teile und die haben mich auch 30 Euro 
gekostet und taugten nichts. Inzwischen habe ich die an die Wand 
geschmissen und durch die RFM12 ersetzt.

Autor: Björn B. (elmo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Travel Rec: Zitat Datenblatt: The Watchdog Timer is clocked from a 
separate On-chip Oscillator which runs at 1 MHz.
So mache ich es derzeit auch. Der Wachhund weckt den Controller alle 2s 
auf. Das ist leider die maximale Zeit die sich erreichen lässt. Dabei 
wird ein Zähler inkrementiert. Somit sendet das Modul nur alle X 
Sekunden, derzeit alle 60. Der Ruhestrom beträgt ca 100uA. Durch den 
Watchdog Reset kommt der Controller für ungefähr 72ms in den 
Wachzustand. Dass er so lange wach ist mag daran liegen dass ich in C 
programmiere. Hier zieht die Schaltung jedenfalls etwa 5mA. Ich habe das 
mal grob zusammengerechnet und komme auf einen Schnitt von um die 300uA 
ohne die RFM "uptime" mit reinzunehmen. Bei meinem 1000mAh Li-Ion Akku 
sind das dann grob 4 Monate.

Gruß
Björn

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ich hatte mal Aurel-Teile und die haben mich auch 30 Euro
>gekostet und taugten nichts.

Ich benutze Aurel-Teile. Und alles was ich dazu sagen
kann ist: Die RFM12 Teile taugen nichts.

Autor: Kai Franke (kai-) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wäre interessant zu wissen ob die Leute, die sich hier negativ den RFM12 
gegenüber äußern diese überhaupt schonmal ausprobiert hatten...
Ich bin von den Modulen nämlich sehr überzeugt.

@Björn: verstehe ich das richtig, dass dein Empfänger den Controller 
weckt und jede Minute ein "ich leb noch" sendet?
Gehe ich recht in der Annahme, dass das Modul während der ganzen Zeit 
empfangsbereit ist? Wenn ja, sind 300µA im Schnitt doch ein super 
Ergebnis!

Gruß
Kai

Autor: Björn B. (elmo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kai Franke wrote:
> @Björn: verstehe ich das richtig, dass dein Empfänger den Controller
> weckt und jede Minute ein "ich leb noch" sendet?
> Gehe ich recht in der Annahme, dass das Modul während der ganzen Zeit
> empfangsbereit ist? Wenn ja, sind 300µA im Schnitt doch ein super
> Ergebnis!

Hallo Kai. Nein leider nicht, das wäre zu schön ;-) Im moment wird der 
Controller von Watchdog zyklisch geweckt und schaltet das Modul bei 
bedarf an. Vorher hatte ich es dass das Modul den Controller über einen 
Interrupt geweckt hat. Das allerdings auch nur zyklisch, über den 
eingebauten "Wakeup Timer". Bei beiden Methoden schlafen also Controller 
und Modul und werden in zeitlichen Abständen geweckt.

Gruß
Björn

Autor: Kai Franke (kai-) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
hatte mir schon gedacht, dass das etwas utopisch wäre bei dem 
Stromverbrauch. Da ich aber sowieso einen Sender habe, der mehrfach 
sendet und auf Empfangsbestätigung wartet (danke, Benedikt) wäre das gar 
nicht mal so schlimm. Ich würde den Watchdog dann aber wahrscheinlich 
auf 0,5s stellen, dass mindestens ein Signal ankommt.
Wenn du den Code dafür hochladen würdest, wär das echt super!

Gruß
Kai

Autor: Björn B. (elmo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Kai,

im Grunde basiert mein Code zu 80% auf dem vom Benedikt (auch von mir, 
danke dafür!). Damit das mit dem Watchdog Reset klappt muss man aber nur 
wenig hinzufügen. Ich versuchs mal zusammenzufassen:
int sleeptime __attribute__ ((section (".noinit")));
int main(void)
{
  unsigned char mcucsr;

  mcucsr = MCUCSR;
  MCUCSR = 0;

  if(mcucsr & (1<<WDRF)) // wenn der Wachhund zugebissen hat
    sleeptime++;
  else // bei allen anderen reset sources
  {
    sleeptime=0;
  }
  wdt_enable(WDTO_2S);

  ... // andere Deklarationen, Inits etc.

  if(sleeptime == 4) // es sind 8s vergangen
  {
    do_something();
  }
  set_sleep_mode(SLEEP_MODE_PWR_DOWN);
  sleep_mode();
}
So sollte das funktionieren. Nachdem der Watchdog aktiviert wurde darf 
alles Folgende natürlich nicht zu lange dauern, da er sonst zu früh 
"zubeisst". Auch sind die 2s nicht besonders genau. Laut Datenblatt 
~2.1s - 2.2s.

Gruß
Björn

Autor: Kai Franke (kai-) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
super, danke
werd das bei Gelegenheit mal ausprobieren.
Ich werd ihn wohl alle 2 Sekunden aufwachen lassen, so ein bisschen 
Strom darf er schließlich verbrauchen :P

Autor: Avr Nix (avrnix) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In unseren Forum gab es mal das Problem das nicht mehr 
empfangen/gesendet wurde durch das verschieben der Frequenz.

http://comwebnet.weimars.net/forum/showthread.php?tid=34

Autor: Knickohr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,

ich muß noch was zu den Li-Batterien sagen, die Klaus weiter oben 
vorgestellt hat.

Die Batterien sind OK, wenn es sich um kleine Ströme (<5mA) handelt. 
Wird der Strom größer, dann sinkt die Spannung rapide ab und die 
Kapatität läßt stark nach. Das liegt an dem relativ hohen 
Innenwiderstand der Batterie. Und bei Kälte verstärkt sich das Problem. 
Bei Temperaturen unter 0° und Strömen über 5mA sind die Batterien nicht 
mehr zu gebrauchen.

Lösung ist ein Li-Ion Akku, besser ein Li-Po Akku. Diese Zellen haben 
einen niedrigeren Innenwiderstand, vor allem die Li-Po. Modellbauer 
nutzen diesen Typ Akku für ihre "Spielzeuge", die teilweise recht hohe 
Stöme ziehen.

OK, war etwas Off-Topic,
Thomas

Autor: Klaus G. (ktg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@knickohr:
Das stimmt, aber da das Teil lt. Datenblatt bei -30° immerhin noch 20mA 
bei 3V liefert, ist das für den von Björn vorgesehenen Zweck locker 
ausreichend.
LiPo-Akkus verwende ich auch im Modellbau; sie erfordern jedoch 
besondere Ladegeräte und sind wegen ihres in diesem Zusammenhang 
gebräuchlichen Aufbaus mit Vorsicht zu handhaben.
Zufällig stolperte ich gestern bei der Suche nach einem 
leistungsfähigeren Akku für mein Mobile über die Tatsache, daß auch dort 
mittlerweile nach LiIon die LiPo-Technik Einzug gehalten hat. Da diese 
Akkus stabil verpackt sind, ist das vielleicht eine Alternative. Ich 
weiß allerdings nicht, ob diese Dinger zum Laden ins Handy gesteckt 
werden müssen (die Ladeelektronik also im Gerät steckt, was ich glaube) 
oder ob das auch extern geht - ein Handyladegerät, falls nicht ohnehin 
vorhanden, kostet nicht viel. Den Weg werde ich gelegentlich 
untersuchen.
Gruß, Klaus

Autor: Christian Mock (rabbit)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
zum thema stromverbrauch: ich betreib hier seit einem 3/4 jahr einen 
sensor mit einem tiny45, einem SHT11 temperatur/feuchtesensor und einem 
simplen 868MHz-sendemodul (rf-solutions?) an 2xAA alkaline.

jedenfalls hab ich ursprünglich ausgerechnet, daß das ca. 9 monate 
aushalten wird, wie die grafik zeigt, hab ich mich aber grob verschätzt.

die chose legt sich mit dem watchdog timer des tiny45 schlafen (im 
watchdog-interrupt-modus, dh ohne daß ein reset ausgeführt wird), führt 
alle 64 sek. eine messung durch und sendet die ergebnisse (dabei wird 
das funkmodul über seinen enable-port eingeschaltet).

und jetzt warte ich auf das eintreffen meiner RFM12, um das ganze 
umzubauen, derzeit generier ich nämlich den zu sendenden seriellen 
datenstrom per bit-banging, der takt kommt vom internen R/C-oszillator 
des tiny45 und der empfänger tut sich entsprechend schwer, stabil zu 
synchronisieren.

Autor: JojoS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann man mit den RFM Modulen auch eine X10 Fernbedienung emulieren bzw. 
empfangen? Habe eine Medion X10 FB die auch auf 433Mhz sendet, aber der 
Empfang ist nicht besonders zuverlässig (häufiges prellen oder falsch 
interpretierte Codes).

Autor: Klaus G. (ktg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
JojoS wrote:
> Kann man mit den RFM Modulen auch eine X10 Fernbedienung emulieren bzw.
> empfangen? Habe eine Medion X10 FB die auch auf 433Mhz sendet, aber der
> Empfang ist nicht besonders zuverlässig (häufiges prellen oder falsch
> interpretierte Codes).

Im Prinzip ja - Dokumentation über das Protokoll hier 
http://members.fortunecity.com/montrough/common/x10.rf.txt

Ich würde zunächst mal versuchen festzustellen, wo die Schwachstelle 
liegt. Bei mir (ich hatte auch mal sowas von Pearl) war definitiv die 
durch meine Wetterstation verseuchte Umgebung die Ursache für das 
Eigenleben, das das Teil zuweilen zeigte.
Ich würde zunächst einen Empfänger mit einem MC zusammenstecken, um 
festzustellen, was der Sender überhaupt von sich gibt, d.h. einfach den 
empfangenen Bitstream analysieren. Da läßt sich schon sehen, ob die 
Daten verstümmelt ankommen oder ob sogar Sachen ankommen, obwohl der 
Sender nicht in Betrieb ist. Da der z.B. RFM02 (Du mußt ihn vermutlich 
im OOK-Mode betreiben, um was zu sehen) zum Glück keine AGC hat, sondern 
die Verstärkung sich gezielt einstellen lässt, ist eine Menge 
festzustellen und evtl. auch schon gewonnen, wenn sich durch eine 
geeignete Verstärkungseinstellung der "Lärm" ausblenden läßt. Danach 
mußt Du weitersehen, ob es reicht, den Empfänger zu ersetzen oder ob 
auch der Sender dran glauben muß. Im letzteren Falle kannst Du natürlich 
beidseitig auf den FSK-Mode gehen (dann ist das aber nicht mehr 
kompatibel zu anderen X10-Geräten, falls Du noch weitere betreibst).
Gruß, Klaus

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: JojoS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
danke für die Antwort, ich hatte in der zwischenzeit auch nochmal etwas 
weitergesucht. Das Problem können auch falsche Treiber sein oder das 
Interface zum DVBViewer den die FB steuern soll. Ich habe noch einen 
einfachen Logger gefunden bzw. kann die Events von der X10 DLL jetzt 
selber in einem .Net Programm auffangen.
Da ich auch ein paar RFM12 Module hier liegen habe ist es trotzdem 
interessant zu wissen ob es geht. Ich habe allerdings noch keine Angabe 
über die genaue Sendefrequenz der FB gefunden, ist das bei X10 über RF 
auch Standard? Auf der Seite der Taiwan Firma X10 habe ich noch ein paar 
Daten zum Protokoll gefunden, aber die sind da sehr versteckt zwischen 
der ganzen Werbung :-(

Autor: JojoS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>http://www.fortunecity.com/referercheck/denial.jpg kriege ich als
Antwort ;)

dito, aber mit 'Speichern als...' kann man das Textfile laden.

Autor: Klaus G. (ktg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Simon K. wrote:
> Klaus G. wrote:
>> http://members.fortunecity.com/montrough/common/x10.rf.txt
>
> http://www.fortunecity.com/referercheck/denial.jpg kriege ich als
> Antwort ;)

Komisch - bei mir geht das.
Versuch mal zuerst http://members.fortunecity.com/montrough/index2.html
Dann klick auf den Link Documents, dann auf X10 RF data formats

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klaus G. wrote:
> Komisch - bei mir geht das.
> Versuch mal zuerst http://members.fortunecity.com/montrough/index2.html
> Dann klick auf den Link Documents, dann auf X10 RF data formats

Jau, das geht.
Vermutlich verbietet fortunecity das direkte verlinken, sodass man nur 
über die Hauptseite dieser Homepage auf dessen Content zugreifen darf.

Wenn ich "Speichern Unter" wähle, krieg ich unlesbaren Mist. Oder ist 
das etwa eine umbenannte .pdf?

Autor: Klaus G. (ktg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
JojoS wrote:
> Ich habe allerdings noch keine Angabe über die genaue Sendefrequenz der FB > 
gefunden

vermutlich 433,92 MHz.
Im OOK-Mode ist der RFM so breitbandig, daß er auch noch was mitbekommt, 
wenn die Frequenz grob danebenliegt.

Autor: JojoS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Klaus:
ich habe am WE das RFM Modul angeschlossen und versuche die X10 Signale 
einzufangen. Ich habe ein analoges Oszi an den Daten und Data Valid 
Ausgang gehängt und mit der Initialisierung des RFM Moduls gespielt. 
Aber auch bei Schmalbandig und niedriegster Verstärkung kommt da jede 
Menge Aktion auf der Datenleitung. Ich konnte noch keine Daten 
aufzeichnen, muß mir noch ein Speicheroszi besorgen.
Du hattest die Module doch auch im OOK Mode betrieben, welche 
Einstellungen verwendest du?

Autor: Klaus G. (ktg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Daten liegen am Pin DATA des RFM01 an.
Wenn sich am Oszi überhaupt nichts ändert, gleichgültig, welche 
Einstellung Du vornimmst, solltest Du prüfen, ob die SPI-Schnittstelle 
richtig bedient wird, z.B. NSEL nur dann Low, wenn Du auch wirklich die 
Schnittstelle ansprichst.
Hier das Headerfile. Die Einstellungen sollten auch in dieser 
Reihenfolge vorgenommen werden.
Viel Glück, Klaus

/*
************************************************************************ 
***********************************
*** Configuration File generated automatically by Integration's Wireless 
Development Suite    ***
*** WDS2 GUI Version 2.2.2                    ***
*** Device: IA4320 rev:'F' or above                  ***
***                          ***
*** Crystal Value: 10 MHz                    ***
***                          ***
*** For further details please consult device datasheet available at 
<http://www.integration.com>;  ***
*** For technical support please attach this file and contact: 
***
*** wireless.support@integration.com 
<mailto:wireless.support@integration.com>        ***
************************************************************************ 
***********************************
*/


#define IA4320
#define UPCLKFREQUENCY      1000000


#define rx_CONFIGSET_CMD    0x893C
/*
  Configuration Setting Command

  Frequency Band:      433 MHz
  Crystal Oscillator:    Enabled
  Crystal Load Capacitance:  10.0 pF
  Baseband Bandwidth    67 kHz
*/

#define rx_FREQSET_CMD    0xA620
/*
  Frequency Setting Command

  Center Frequency    433,92 MHz
*/

#define rx_RECEIVERSET_CMD    0xC0C9
/*
  Receiver Setting Command

  VDI Signal:      Always
  LNA Gain Set:      max.
  RSSI Treshold:      -79 dBm
  Receiver Chain:      Enabled
*/

#define rx_WTC_CMD      0xE196
/*
  Wake Up Timer Command

  Time Period:       0,3 sec
*/

#define rx_LOWDUTYCCL_CMD    0xCC0E
/*
  Low Duty-Cycle Command

  Low Duty-Cycle:      10 %
*/

#define rx_LBD_CMD      0xC200
/*
  Low Battery Detector and Microcontroller Clock Divider Command

  Threshold Voltage:     2,2 V
  Clock Output Frequency:    1 MHz
*/

#define rx_AFC_CMD      0xC6F2
/*
  AFC Command

  Automatic Operation Mode:  Auto, keep Foffset
  Range Limit:      +3/-4 Fs
  Output:        Enabled
*/

#define rx_DATAFILTER_CMD    0xC463
/*
  Data Filter Command

  Clock Recovery Mode:    Fast
  Filter Type:      Digital LPF (OOK)
  DQD Parameter:       3
*/

#define rx_DATARATE_CMD    0xC8CC
/*
  Data Rate Command

  Data Rate:      0,56 kbps
*/

#define rx_FIFO_CMD      0xCE84
/*
  Output and FIFO Mode Command

  FIFO IT Level:       8
  FIFO Fill Start Condition:  Synchron pattern
*/


/*
************************************ End of header file 
***************************************************
*/

Autor: Klaus G. (ktg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag:
Du brauchst kein Speicheroszi. Hänge den Datenausgang über einen 
Spannungsteiler 10k:1k an den Line-Eingang der Soundkarte und schalte 
auf Aufnahme. Die .wav-Datei schaust Du Dir dann in Ruhe mit einem 
Wave-Editor an (ist oft bei der Soundkarte dabei).
Da die Soundkarte keinen DC-Eingang hat, wird sich der Eingang, wenn 
sich nichts tut, auf 0 einpendeln, aber wenn dann Signale kommen, kann 
man das sehr schön sehen. Auf diese Weise habe ich den RC5-Code einer 
IR-Fernbedienung analysiert - geht prima.

Autor: JojoS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
besten Dank für die Tipps und die Init Sequenz. Das mit der Soundkarte 
habe ich auch schon gelesen und werde das ausprobieren (habe sogar vor 
Jahren das org. Cooledit gekauft). Wir haben aber auch gute 
Speicheroszis nur das kriege ich erst am Wochenende.
Das SPI sollte schon klappen, den 10Mhz Clock bekomme ich nach der 
Initialisierung. Auch am Data Output ist Action, aber eben eher zuviel. 
Die 433,92 scheinen stark belegt zu sein, im Garten ist z.B. so ein 
Wettersensor, aber die sollten doch nur höchstens im Minutentakt senden?

Autor: Klaus G. (ktg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In dem Bereich steppt echt der Bär. Drahtlose Kopfhörer, Funkthermostate 
am Heizkörper usw.
Dreh mal die Verstärkung runter und die Schwelle rauf, also 
rx_RECEIVERSET_CMD = C0FF und/oder mach die Antenne ab. Dann sollte 
wenig bis nix mehr kommen. Kommt dann immer noch was, macht Dein MC 
zuviel "Lärm", evtl. wg. fliegender Verdrahtung des Versuchsaufbaus. 
Löte einen 100nF direkt auf dem Platinchen über die Versorgungsspannung. 
Das hilft in dem Fall enorm.

Autor: JojoS (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
so langsam empfange ich brauchbare Signale, die Idee mit der Soundkarte 
war wirklich gut. Wenn man den Filter auf analog stellt kommt übrigends 
am DATA-Ausgang auch ein analoges Signal raus und man mit der Soundkarte 
das Rauschen oder die Störungen auf der eingestellten Frequenz hören.
Für diese Versuche ist eine online Verstellung der Parameter sinnvoll, 
das kommt als nächstes. Und auch die Dekodierung von dem X10 sollte 
nicht so schwierig sein. Diese RFM Module sind wirklich schnuckelig!

Autor: wolfgang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hey,

Ich spiele auch schon ne Weile mit dem RFM12 herum und das 
initialisieren funktioniert. Am Anfang messe ich am CLK Pin 1MHZ danach 
meine eingestellten 2MHZ.

Danach öffne stetze ich das Power Config Restier auf 8238h und die 
Stromaufnahme steigt an. Nach dem Senden von 4 Bytes setzte ich das 
Power Config Reg. auf 8208h (TX off) geht der Strom aber nicht mehr 
runter er bleibt immer gleich.
Das versteh ich nicht normal müsste nach dem Senden der Strom wieder 
zurückgegen und während dem Senden hin und her schwanken oder?

Vielleicht kack das RFM einfach ab, denn während dem Senden hab ich am 
CLK Pin ein sehr verschwommenes Signal von rund 2.8Mhz.

Autor: Josef (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

irgendwie habe ich das Power-Management des RFM12 noch nicht verstanden. 
Für einen Remote-Sensor der mit Batterien betrieben wird, bin ich an 
minimalem Stromverbrauch interessiert.
In meiner Anwendung steuert ein ATmega48 den RFM12, liest alle 10 min. 
die Sensorwerte, schickt das Zeug an den Receiver und legt dann erst den 
RFM12 und dann sich selbst schlafen. Für den Wakeup nutze ich den 
Wakeup-Timer im RFM12. Der Stromverbrauch in der Sleep-Phase ist 
erfreulich gering (< 10 uA). Das klappt einige Zyklen ganz gut. 
Irgendwann geht der Stromverbrauch des RFM12 im Power-Down Mode nicht 
mehr in den Microampere-Bereich sondern bleibt bei etwa 2 mA. Ansonsten 
geht alles noch ganz normal. Erst ein Power-Up-Reset des RFM12 hilft 
dagegen.
Als Notlösung sende ich jetzt ein SW-Reset-Kommando (0xff00) an den 
RFM12 bevor ich das Modul in den Power-Down-Mode bringe. Das Kommando 
ist nur im "Integration"-Datenblatt beschrieben, glaube ich.
Toll ist die Lösung nicht, da der Reset-Zyklus einige 100 ms benötigt 
und damit die Gesamt-Energie-Bilanz verschlechtert wird.

Das Thema Reichweite wird ebenfalls immer wieder diskutiert: Wer nur 
eine Peer-to-Peer-Verbindung braucht, kann auf die AFC ganz verzichten. 
Damit hat der Empfänger bei niedrigen Pegeln die Chance ohne an der 
Frequenz herumzuregeln den Datenstrom zu synchronisieren. Voraussetzung 
ist allerdings eine einmalige Justierung der Frequenz in Sender und 
Empfänger. Die Quarzoszillatoren sind normalerweise stabil genug, das da 
nicht wegläuft.

Autor: Jojo S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich arbeite gerade an einem Tool mit dem ich die Parameter des RFM vom 
PC aus über Einstelldialoge vorgeben kann. Das klappt auch schon für 
einige Kommandos, ich habe jetzt aber eine Unstimmigkeit im Datenblatt 
von HopeRF, Datei rf12.pdf Seite 17, gefunden:
Das Datafilter Command sollte die Bits 3 und 5 gesetzt haben, aber in 
Beispielen oder dem Output von dem Integration 'WDS' Tool sind die Bits 
jeweils 0. Praktisch ist es auch so das bei gesetztem Bit3 der 
Analogfilter Mode eingeschaltet bleibt. Frage: gibt es da Errata oder 
'bessere' Datenblätter?

#define rx_DATAFILTER_CMD    0xC463
/*
  Data Filter Command

  Clock Recovery Mode:    Fast
  Filter Type:      Digital LPF (OOK)
  DQD Parameter:       3
*/

Autor: Gerd H. (anatec)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für alle die mal schnell testen wollen, ob der Sender überhaupt einen 
Mucks von sich gibt, ein 5min Projekt. Rechts an die RC Kombination 
kommt ein Digivolt drann. Die beiden Dioden sind BAT41, der R hat 39k, 
die C's haben 10nF und die "Antenne" ist 17cm lang. Alle Werte sind 
unkritisch. Ob Daten gesendet werden kann man nicht sehen, aber ob HF da 
ist schon :-)

http://www.ha-electronic.de/Images_1/RF-Indikator.jpg

MfG Gerd H

Autor: fantomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Abend,
ich versuche mein rfm112 ins "Standby" zu schicken leider geht der nur 
schlafen wenn ich irgendetwas nachsende. Irgend eine Ahnung warum?

Ablauf:
rf12_trans(0x8201);
rf12_trans(0x...); //Ohne geht nicht.

thx

Autor: Björn Biesenbach (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

bei mir funktioniert es ohne etwas hinerherzuschicken.

Gruß
Björn

Autor: fantomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hat wer schon Erfahrung mit OOK mode? Oder gibts es irgendwo Info wie 
man an die Signale auf 433 die herumspucken kommt? Würde gerne 
Funksteckdosen Signal einlesen.

Autor: OVIS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

Experimentiere zur Zeit mit einem RFM12 Funkmodul und einem ATmega8. Im 
Energie zu sparen möchte ich den ATmega in den Sleep Mode (Power Down) 
versetzen. Die Aktivierung soll über einen Interrupt INT0 erfolgen, 
dabei soll der Interrupt über den RFM12 Wakeup Timer ausgelöst werden.

Verwende folgende Konfiguration der Register:



rf12_trans(0xEA02);  // Wakup Timer initialisieren 2048 ms
rf12_trans(0xC800);  // disable low duty cycle

rf12_trans(0x8203);  // Wakeup Timer aktivieren, Clockoutput 
deaktivieren

Leider ist das nIrq signal immer low, scheinbar funktioniert der Timer 
mit meiner Konfiguration nicht.

Habt ihr vielleicht ein paar Tips oder auch Beispiele zum RFM12 Wakeup 
Timer?

Autor: Stefan Helmert (Firma: dm2sh) (stefan_helmert)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

hier schreiben ja einige, der Empfänger würde abstürzen. Auch wenn die 
Frage jetzt dumm klingt: Habt ihr den Empfänger immer wieder deaktiviert 
(mit dem Kommando zum FIFO deaktivieren) - nach einem Datenpaket?
Um es mal kurz zusammenzufassen: Die Synchronisation des Empfängers auf 
den Sender ist nur möglich, wenn der Empfänger "bereit" ist. Er lauscht 
ständig. Empfängt er das das Synch.-Wort, legt er los mit Empfangen, 
eine Synchronisation ist nicht mehr möglich. Nach einer Anzahl von 
Bytes, muss der Empfänger deaktiviert und gleich wieder reaktiviert 
werden, damit er vom Empfangsmodus in den Synchronisationsmodus 
wechselt, in dem er wieder auf das Sync.-Wort wartet. Macht man das 
nicht, so laufen Empfänger und Sender langsam auseinander und es kommt 
nur noch Käse an, d. h. ein gesendetes Byte ist nicht mehr gleich zum 
empfangen - es kommt zur Bitverschiebung.

Autor: Johannes P. (jop)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
Ich versuche gerade mit RFM12B-Modulen eine Funkverbindung aufzubauen. 
Ich arbeite mit AVR-Studio4 und steuere die Module über ein Atmega128 
an.
Die Befehle die ich schicke werden auch nachweislich verstanden, z.B. 
kann ich den Clocktakt ändern und mit dem Oszi nachmessen.

Folgendes Problem hab ich aber:
Wenn ich senden will müsste ja nachdem er den Inhalt des TX-Registers 
gesendet hat auf dem MISO-Kanal ein Signal kommen, dass er fertig ist 
und das nächste Datenpaket haben will. Dieses Signal kommt aber nie.

Ich habe meinen Code (der auf dem hier aus dem Forum basiert, danke) 
angehängt. Ich habe mal alles was nicht zwingend nötig ist 
auskommentiert sowie die Datenausgabe per LEDs rausgenommen.
Hat jemand eine Idee woran es liegen könnte? Ich habe drei Module da, 
aber es funktioniert mit keinem von denen.

Vielen Dank, JP

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vermutlich hast du zuviel auskommentiert:
Setz mal die Baudrate des Moduls.

Autor: Johannes P. (jop)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn ich alles einkommentiere geht es ja leider auch nicht, auch nicht 
mit der Orginalversion hier aus dem Forum.
Habe es natürlich aber gerade nochmal mit Baudrate setzen versucht 
(0xC610), was aber das Modul auch zu keinerlei Sendetätigkeit bewegen 
konnte.

Autor: Johannes P. (jop)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Könnte es auch an der Verkabelung liegen? Ich verwende ja eigentlich nur 
SPI und hab auch den nFFS-Pin auf High gezogen. Oder könnte es noch 
Verkabelungsprobleme geben, die nur beim senden und nicht bei anderen 
Befehlen auftreten?

Muss man denn eigentlich überhaupt irgendwelche Dinge wie z.B. die 
Übertragungsgeschwindigkeit einstellen bevor der Sender sendet? Es sind 
doch überall Power-On-Reset-Werte eingestellt, so dass es doch reichen 
müsste einfach die Sendekette anzuschalten und Daten zu übergeben. Falls 
das nicht der Fall ist: steht irgendwo was man mindestens einstellen 
muss?

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe da auch teilweise seltsame Erfahrungen mit RFM12 und RFM02 
gemacht.
Den RFM12 nutze ich zur Zeit nur als Empfänger, der ist recht friedlich, 
allerdings hatte ich den Effekt, daß das Ding manchmal nicht machte, was 
es sollte. Seit ich als erstes Kommando beim Init den Status auslese, 
starten sie immer... Ausreichend Wartezeit nach dem PowerOn ist auch 
nötig.
Beim RFM02 (Sender) half das ebenfalls, zusätzlich ein Elko 4,7µ...10µ 
über der Betriebsspannung, sonst wachen sie aus de, Sleep gern nicht 
wieder auf.
100n am Modul scheinen nutzlos, ist wohl sowieso einer auf dem Modul.

Meine Init des RFM12 als Empfänger.
  rfm12_send_cmd(0x0000);  // Status read

  rfm12_send_cmd(0xC080);  // CLK-Frequenz / Batterie-Level
  rfm12_send_cmd(0x80D7);  // FIFO ein, 433MHZ-Band, C = 12pF
  rfm12_send_cmd(0xC2AB);  // Clock Recovery Auto, Filter digital, DQD-Thresold 3
  rfm12_send_cmd(0xCA81);  // FIFO-Level 8 Bit, Sync Pattern ein, High senity Reset aus
  rfm12_send_cmd(0xE000);  // WakeUp aus
  rfm12_send_cmd(0xC800);  // Low Duty Cycle aus
  rfm12_send_cmd(0xC4F3);  // AFC immer, +7,5 / -10kHz, Add Freq-Offset zur PLL, Berechne Freq. Offset aus AFC
  rfm12_send_cmd(0xA620);  // Frequenz 433,92MHz  // Status read
  rfm12_send_cmd(0x948C);  // VDI Output, VDI Fast, Bandbreite 200kHz, LBA-Gain -6dB, RSSI-Thresold -79dB
  rfm12_send_cmd(0xC610);  // Baudrate 19200
  rfm12_send_cmd(0x8281);  // Empfänger ein, Clock Out aus
  rfm12_send_cmd(0xCA81);  // set FIFO mode
  rfm12_send_cmd(0xCA83);  // enable FIFO
Ich hoffe jetzt mal, meine Kommentare stimmen noch alle...

Hintergrund meiner Basteleien:
http://www.avr.roehres-home.de

Gruß aus Berlin
Michael

Autor: Harry S. (littlegonzo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Etwas Off-Topic, aber hallo Michael war eben auf deiner Seite und habe 
deinen Amiga Hintergrund gesehen, welche(n) haste denn?

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Erst A2000, dann A4000 mit PPC-Karte, Picasso4 mit Paloma, VLab-Motion, 
Toccata, Ariadne2 usw. usw.

Hat irgendwie alles neue Besitzer gefunden nachdem er nur noch 
rumstand...

Gruß aus Berlin
Michael

Autor: Johannes P. (jop)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe hier auch nochmal meinen Schaltplan angehängt, vielleicht 
könnte da jemand mal drauf schauen, ob da ein Fehler drin ist, den ich 
nicht sehe.

Nochmal die Frage: Sendet das Modul auch wenn man nichts weiter 
Konfiguriert, sondern nur die Bits el und et aktiviert?

Vielen Dank, JP

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie schnell läuft dein AVR?

Autor: Johannes P. (jop)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der AVR läuft mit 8 MHz.

Autor: Harry S. (littlegonzo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OT: Cool, ich hatte auch die Reihe kpl durch, angefangen mit dem A1000 
dann A2000 und zum Schluß einen A4000... am besten gefiel mir der A2000, 
den hatte ich auch aufgerüstet ohne Ende, ISDN-Karte, zig Platten damals 
glaub ich je max 150MB wenn überhaupt. Die Picasso hatte ich auch ;-)
Es lief eine Mailbox mit ca. 150 Usern drauf. Ach ja......

Sorry für OT aber die gute alte Zeit verleitet machmal...

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

@ Harry S. (littlegonzo):

bevor man uns hier erschlägt:
http://www.roehres-home.de/amiga_lebt

ich hab die alte Seite mal auf den Server geschoben...
Weiteres wohl besser per Mail.

Gruß aus Berlin
Michael

Autor: Johannes P. (jop)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat niemand eine Idee was schief laufen könnte bei mir?
(Code und Schaltplan siehe oben)

Autor: Johannes P. (jop)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Inzwischen habe ich nochmal die Stromversorgung durchgecheckt und 
sicherheitshalber noch 10µF direkt neben das Modul gelötet, falls beim 
einschalten die Spannung zu sehr einbricht. Allerdings verweigern die 
Module nach wie vor die Sendetätigkeit.
Über gute Ideen was man noch probieren könnte wäre ich sehr froh.

Autor: Johannes P. (jop)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falls es jemanden interessiert: der Fehler ist gefunden. Etwas schönes 
kleines, was trotzdem keiner der vielen Leute die es gelesen haben 
gesehen hat.
for(i=15;i>0;i--)
Damit lassen sich nunmal schwer 16-Bit-Befehle senden.

Was aber vielleicht interessanter ist für die Nachwelt:
Das Funkmodul versteht scheinbar auch Befehle wenn sie nach 15 Bit 
abgebrochen werden. Nachweislich das "Low Battery and Microcontroller 
Clock Divider Command".
Aber es geht eben nicht bei allen Befehlen ...

Autor: Johannes P. (jop)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab mal wieder eine Frage zum Funkmodul RFM12B.
Dazu eine Situationsbeschreibung:

Ich habe zwei Mikrocontroller die jeweils ein Funkmodul über SPI 
ansteuern. der Empfänger wartet nicht auf das Syncrone Pattern (weil es 
noch nicht kommt). Wenn der Sender nun aus ist, werden wild  1en und 0en 
durcheinander empfangen, etwa gleich viel (=Rauschen). Wenn der Sender 
angestellt wird ohne etwas zu empfangen werden NUR 0en empfangen. Bis 
dahin klingt es ja gut. Wenn der Sender aber nun etwas sendet, z.B. 
0101010101... , dann wird nur sehr selten mal eine 1 empfangen, so alle 
20 0en. Vollkommen unregelmäßig und ohne erkennbares Muster. Auch wenn 
ich nur 1en sende werden nur ganz wenige 1en empfangen. Wenn ich nur 0en 
sende werden keine 1en empfangen.

Ich habe mit der Empfängerbandbreite und der Senderbandbreite 
herumgespielt und alles scheint in Ordnung. Wenn ich den Sender nach 
oben verschiebe weden 1en als 0en empfangen und umgekehrt. Auch habe ich 
den Sender mal invertiert, wodurch der Empfänger nach Senderaktivierung 
NUR 1en empfangen hat und wenn ich etwas gesendet habe die gewohnt 
seltenen 0en. Also das Problem genau auch invertiert.
Es scheint so, als ob der Sender viel zu langsam sendet. Wenn ich 
allerding die Sendegeschwindigkeiten gegeneinander verschiebe empfange 
ich noch weniger bzw sehr schnell gar nichts mehr.

Hat irgendjemand eine Idee an was das liegen könnte oder was ich 
probieren könnte?

Autor: Johannes P. (jop)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
falscher Thread?
zu schwierige Frage?
zu altes Funkmodul?
liest es keiner?

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das sieht nach einem Problem in der HF-Technik aus. Vermutlich sind 
Sender und Empfänger zu weit frequenzmäßig von einander entfernt. Also 
kontrolliere, das die Registereinstellung Frequenz exakt übereinstimmt. 
Außerdem sollte das AFC aktiv sein, was den Empfänger auf die Frequenz 
des Senders ranholt. Geht aber nur bei geringer Ablage.
Wenn du die Möglichkeit dazu hast, dann messe über den Clockausgang des 
Moduls indirekt die Quarzfrequenz. Sollte bei beiden Modulen auf ca. 
1kHz gleich sein.


Gruß -
Abdul

Autor: Flo S. (agemta)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hey.. bei mir haben die funkmodule bis heute früh funktioniert. jetzt 
habe ich was ausprobiert und nun gehts nicht mehr. software technisch 
habe ich nichsts verändert. hardware habe ich alles überprüft. da ist 
auch nicht verändert.
ich nutze die software aus dem forum.
der µc hängt sich bei folgenden code auf:

void rf12_ready(void)
{  cbi(RF_PORT, CS);
  while (!(RF_PIN&(1<<SDO))); // wait until FIFO ready
}

wisst ihr woran das liegen kann und ie kann ich überprüfen, ob die 
funkmodule noch funktionieren. Vielleicht habe ich sie ja zerschossen?

Autor: Nova (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,
ich habe eigendlich guter erfahrung mit dem modul gemacht... (868MHz)

nur bekomme ich den nIRQ nicht zum lauffen der is immer high...
mit diesem Programm habe ich kein Problemm PWM geht RX im Pulling Mode 
geht auch...
#include <avr/io.h>
#include <avr/interrupt.h>
#include <stdlib.h>
#include <inttypes.h>
#include "global.h"
#include "rf12.h"      
#include <stdint.h>
#include <string.h>

#define F_CPU 16000000UL
#include <util/delay.h>

#define F_PWM 100                       // PWM-Frequenz in Hz
#define PWM_STEPS 256                   // PWM-Schritte pro Zyklus(1..256)
#define PWM_PORT PORTD                  // Port für PWM
#define PWM_DDR DDRD                    // Datenrichtungsregister für PWM
 
#define T_PWM (F_CPU/(F_PWM*PWM_STEPS)) // Systemtakte pro PWM-Takt
 
#if (T_PWM<(93+5))
    #error T_PWM zu klein, F_CPU muss vergrösst werden oder F_PWM oder PWM_STEPS verkleinert werden
#endif
 
// globale Variablen
 
volatile uint8_t pwm_setting[8];                    // Einstellungen für die einzelnen PWM-Kanäle
 
// Timer 1 Output COMPARE A Interrupt
 
ISR( TIMER1_COMPA_vect )  
{
    static uint8_t pwm_cnt=0;
    uint8_t tmp=0;
 
    OCR1A += (uint16_t)T_PWM;
        
    if (pwm_setting[0] > pwm_cnt) tmp |= (1<<0);
    if (pwm_setting[1] > pwm_cnt) tmp |= (1<<1);
    if (pwm_setting[2] > pwm_cnt) tmp |= (1<<2);
    if (pwm_setting[3] > pwm_cnt) tmp |= (1<<3);
    if (pwm_setting[4] > pwm_cnt) tmp |= (1<<4);
    if (pwm_setting[5] > pwm_cnt) tmp |= (1<<5);
    if (pwm_setting[6] > pwm_cnt) tmp |= (1<<6);
    if (pwm_setting[7] > pwm_cnt) tmp |= (1<<7);
    PWM_PORT = tmp;                         // PWMs aktualisieren
    
    if (pwm_cnt==(uint8_t)(PWM_STEPS-1))
        pwm_cnt=0;
    else
        pwm_cnt++;
}
 

int main(void) {
 
// PWM einstellen
    
  PWM_DDR = 0xFF;         // Port als Ausgang
    
//Timer 1 OCRA1, als variablem Timer nutzen
 
  TIMSK  |=  (1<<OCIE1A);        //compare mode
  TIFR  |=  (1<<OCF1A);          //reset flags
  TCCR1B   = 1;                     //Timer läuft mit vollem Systemtakt
  sei();                          //Interrupts gloabl einschalten


  rf12_init();          // ein paar Register setzen (z.B. CLK auf 10MHz)
  rf12_setfreq(RF12FREQ(868.92));  // Sende/Empfangsfrequenz auf 433,92MHz einstellen
  rf12_setbandwidth(4, 1, 4);    // 200kHz Bandbreite, -6dB Verstärkung, DRSSI threshold: -79dBm 
  rf12_setbaud(19200);      // 19200 baud
  rf12_setpower(0, 6);      // 1mW Ausgangangsleistung, 120kHz Frequenzshift

  
  uint8_t pegel = 0;
  unsigned char test[1];

  while (1)
  {  
    rf12_rxdata(test,1);
    pwm_setting[5] = test[0];
    pwm_setting[6] = test[0];          
  }

}

was muss ich den ändern damit der nIRQ reagirt?
erste idee war RX einschalten aber daten nicht abhollen ...dann müsste 
er ja mekern... so war mein gedanke

nur die änderung:
 

  rf12_trans(0x82C8);      // RX on
  rf12_trans(0xCA81);      // set FIFO mode
  rf12_trans(0xCAF3);      // enable FIFO (mit änderung für 868 Modul Normal CA83
  while (1)
  {  
    //rf12_rxdata(test,1);
    pwm_setting[5] = test[0];
    pwm_setting[6] = test[0];          
  }

also einfach den RX on und waren... aber nix... nIRQ ist einfach immer 
high...

hat da wer ne idee?

Autor: Simon N. (jahusi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ist eigentlich noch eine Sammelbestellung mit den 443MHz Modulen am 
laufen?
Hätte Interesse an 2-3 Teilen.

Grüße

Autor: Roland Plüss (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Speisung der RFM12 Module darf nicht zu langsam ansteigen, sonst 
gibt es Probleme (also vorsichtig mit zu grossen Cs).

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Glückwunsch für´s Leichenschänden! Der Thread ist 8 Jahre alt und knapp 
5 Jahre nicht verändert worden.

Autor: Magermilch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Trotzdem gerade was gelernt.
Lasst Leichen Leichen und Threads Threads sein. RFM12 ist nach wie vor 
aktuell.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.