Announcement: there is an English version of this forum on 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#Reset_ausl.C3.B6sen 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
...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.
>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
>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.
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:
1 | int sleeptime __attribute__ ((section (".noinit"))); |
2 | int main(void) |
3 | {
|
4 | unsigned char mcucsr; |
5 | |
6 | mcucsr = MCUCSR; |
7 | MCUCSR = 0; |
8 | |
9 | if(mcucsr & (1<<WDRF)) // wenn der Wachhund zugebissen hat |
10 | sleeptime++; |
11 | else // bei allen anderen reset sources |
12 | {
|
13 | sleeptime=0; |
14 | }
|
15 | wdt_enable(WDTO_2S); |
16 | |
17 | ... // andere Deklarationen, Inits etc. |
18 | |
19 | if(sleeptime == 4) // es sind 8s vergangen |
20 | {
|
21 | do_something(); |
22 | }
|
23 | set_sleep_mode(SLEEP_MODE_PWR_DOWN); |
24 | sleep_mode(); |
25 | }
|
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
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
@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
Angehängte Dateien:
-
voltage.png
7,4 KB
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.
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).
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 ;)
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 :-(
>http://www.fortunecity.com/referercheck/denial.jpg kriege ich als
Antwort ;)
dito, aber mit 'Speichern als...' kann man das Textfile laden.
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.
@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?
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.
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?
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.
Angehängte Dateien:
-
X10.png
45 KB
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!
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.
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.
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
Abend, ich versuche mein rfm112 ins "Standby" zu schicken leider geht der nur schlafen wenn ich irgendetwas nachsende. Irgend eine Ahnung warum? Ablauf:
1 | rf12_trans(0x8201); |
2 | rf12_trans(0x...); //Ohne geht nicht. |
thx
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.
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?
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
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.
1 | rfm12_send_cmd(0x0000); // Status read |
2 | |
3 | rfm12_send_cmd(0xC080); // CLK-Frequenz / Batterie-Level |
4 | rfm12_send_cmd(0x80D7); // FIFO ein, 433MHZ-Band, C = 12pF |
5 | rfm12_send_cmd(0xC2AB); // Clock Recovery Auto, Filter digital, DQD-Thresold 3 |
6 | rfm12_send_cmd(0xCA81); // FIFO-Level 8 Bit, Sync Pattern ein, High senity Reset aus |
7 | rfm12_send_cmd(0xE000); // WakeUp aus |
8 | rfm12_send_cmd(0xC800); // Low Duty Cycle aus |
9 | rfm12_send_cmd(0xC4F3); // AFC immer, +7,5 / -10kHz, Add Freq-Offset zur PLL, Berechne Freq. Offset aus AFC |
10 | rfm12_send_cmd(0xA620); // Frequenz 433,92MHz // Status read |
11 | rfm12_send_cmd(0x948C); // VDI Output, VDI Fast, Bandbreite 200kHz, LBA-Gain -6dB, RSSI-Thresold -79dB |
12 | rfm12_send_cmd(0xC610); // Baudrate 19200 |
13 | rfm12_send_cmd(0x8281); // Empfänger ein, Clock Out aus |
14 | rfm12_send_cmd(0xCA81); // set FIFO mode |
15 | 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
Angehängte Dateien:
-
rfm12.png
3,7 KB
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
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?
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?
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...
1 | #include <avr/io.h> |
2 | #include <avr/interrupt.h> |
3 | #include <stdlib.h> |
4 | #include <inttypes.h> |
5 | #include "global.h" |
6 | #include "rf12.h" |
7 | #include <stdint.h> |
8 | #include <string.h> |
9 | |
10 | #define F_CPU 16000000UL |
11 | #include <util/delay.h> |
12 | |
13 | #define F_PWM 100 // PWM-Frequenz in Hz |
14 | #define PWM_STEPS 256 // PWM-Schritte pro Zyklus(1..256) |
15 | #define PWM_PORT PORTD // Port für PWM |
16 | #define PWM_DDR DDRD // Datenrichtungsregister für PWM |
17 | |
18 | #define T_PWM (F_CPU/(F_PWM*PWM_STEPS)) // Systemtakte pro PWM-Takt |
19 | |
20 | #if (T_PWM<(93+5)) |
21 | #error T_PWM zu klein, F_CPU muss vergrösst werden oder F_PWM oder PWM_STEPS verkleinert werden |
22 | #endif |
23 | |
24 | // globale Variablen |
25 | |
26 | volatile uint8_t pwm_setting[8]; // Einstellungen für die einzelnen PWM-Kanäle |
27 | |
28 | // Timer 1 Output COMPARE A Interrupt |
29 | |
30 | ISR( TIMER1_COMPA_vect ) |
31 | {
|
32 | static uint8_t pwm_cnt=0; |
33 | uint8_t tmp=0; |
34 | |
35 | OCR1A += (uint16_t)T_PWM; |
36 | |
37 | if (pwm_setting[0] > pwm_cnt) tmp |= (1<<0); |
38 | if (pwm_setting[1] > pwm_cnt) tmp |= (1<<1); |
39 | if (pwm_setting[2] > pwm_cnt) tmp |= (1<<2); |
40 | if (pwm_setting[3] > pwm_cnt) tmp |= (1<<3); |
41 | if (pwm_setting[4] > pwm_cnt) tmp |= (1<<4); |
42 | if (pwm_setting[5] > pwm_cnt) tmp |= (1<<5); |
43 | if (pwm_setting[6] > pwm_cnt) tmp |= (1<<6); |
44 | if (pwm_setting[7] > pwm_cnt) tmp |= (1<<7); |
45 | PWM_PORT = tmp; // PWMs aktualisieren |
46 | |
47 | if (pwm_cnt==(uint8_t)(PWM_STEPS-1)) |
48 | pwm_cnt=0; |
49 | else |
50 | pwm_cnt++; |
51 | } |
52 | |
53 | |
54 | int main(void) {
|
55 | |
56 | // PWM einstellen |
57 | |
58 | PWM_DDR = 0xFF; // Port als Ausgang |
59 | |
60 | //Timer 1 OCRA1, als variablem Timer nutzen |
61 | |
62 | TIMSK |= (1<<OCIE1A); //compare mode |
63 | TIFR |= (1<<OCF1A); //reset flags |
64 | TCCR1B = 1; //Timer läuft mit vollem Systemtakt |
65 | sei(); //Interrupts gloabl einschalten |
66 | |
67 | |
68 | rf12_init(); // ein paar Register setzen (z.B. CLK auf 10MHz) |
69 | rf12_setfreq(RF12FREQ(868.92)); // Sende/Empfangsfrequenz auf 433,92MHz einstellen |
70 | rf12_setbandwidth(4, 1, 4); // 200kHz Bandbreite, -6dB Verstärkung, DRSSI threshold: -79dBm |
71 | rf12_setbaud(19200); // 19200 baud |
72 | rf12_setpower(0, 6); // 1mW Ausgangangsleistung, 120kHz Frequenzshift |
73 | |
74 | |
75 | uint8_t pegel = 0; |
76 | unsigned char test[1]; |
77 | |
78 | while (1) |
79 | {
|
80 | rf12_rxdata(test,1); |
81 | pwm_setting[5] = test[0]; |
82 | pwm_setting[6] = test[0]; |
83 | } |
84 | |
85 | } |
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:
1 | |
2 | |
3 | rf12_trans(0x82C8); // RX on |
4 | rf12_trans(0xCA81); // set FIFO mode |
5 | rf12_trans(0xCAF3); // enable FIFO (mit änderung für 868 Modul Normal CA83 |
6 | while (1) |
7 | {
|
8 | //rf12_rxdata(test,1); |
9 | pwm_setting[5] = test[0]; |
10 | pwm_setting[6] = test[0]; |
11 | } |
also einfach den RX on und waren... aber nix... nIRQ ist einfach immer high... hat da wer ne idee?
Hallo, ist eigentlich noch eine Sammelbestellung mit den 443MHz Modulen am laufen? Hätte Interesse an 2-3 Teilen. Grüße
Die Speisung der RFM12 Module darf nicht zu langsam ansteigen, sonst gibt es Probleme (also vorsichtig mit zu grossen Cs).
Glückwunsch für´s Leichenschänden! Der Thread ist 8 Jahre alt und knapp 5 Jahre nicht verändert worden.
Trotzdem gerade was gelernt. Lasst Leichen Leichen und Threads Threads sein. RFM12 ist nach wie vor aktuell.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.