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.

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.

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.

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 :-(

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

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 :(

@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).

@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

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

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?

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

@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

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

>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.

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.

>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.

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 :-).

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

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.

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.

>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.

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

wieviel Strom zieht dein Modul denn momentan im Standby?

>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?

>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.

@ 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

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

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

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

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

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

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

@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

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.

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

Klaus G. wrote:
> http://members.fortunecity.com/montrough/common/x10.rf.txt

http://www.fortunecity.com/referercheck/denial.jpg kriege ich als
Antwort ;)

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

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?

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.

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
***************************************************
*/

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.

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.

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
*/

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

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.

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

Vermutlich hast du zuviel auskommentiert:
Setz mal die Baudrate des Moduls.

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.

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?

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

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

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

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

Wie schnell läuft dein AVR?

Der AVR läuft mit 8 MHz.

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...

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

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

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.

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 ...

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?

falscher Thread?
zu schwierige Frage?
zu altes Funkmodul?
liest es keiner?

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

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?

Hallo,

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

Grüße