Hallo, ich versuche aktuell meinen Aufbau bestehend aus Atmega 328 und RFM69CW batteriefähig zu machen. Leider scheitere ich aktuell mit der Implementierung des Listen Mode beim RFM69. Hat diesbezüglich jemand von euch schon Erfahrung gesammelt? Wenn ich das Datenblatt richtig verstanden habe, können mit den zwei Registern ListenCoefRx und ListenCoefIdle die Zeiten zwischen Schlafmodus und Rx Modus bestimmt werden. Ich setze das Funkmodul mit angehängtem Code in den Listen Modus. Im Rx Modus benötigt er ungefähr 20 mA. Nach der Bespielung mit der Listen Funktion, sinkt die Stromaufnahme auf ca. 4mA ab. Leider empfangt das Funkmodul dann auch keine Pakete mehr. Habt ihr eine Idee an was das liegen könnte? Ich wäre für eure Hilfe sehr dankbar. Habe die Hauptinitialisierung und die Initialisierung hier angehängt. Schöne Grüße Hannes // Routine RFM69CW Listen Mode RFM69_spi(0x0AFF | 0x8000); // RSSI Timeout höchster Wert RFM69_spi(0x0D52 | 0x8000); // Listen Rx und Idle 64 µs; Signal über RSSI Threshold; RFM69_spi(0x0E60 | 0x8000); // 96 * 64 = 3780 µs Sleep RFM69_spi(0x0F05 | 0x8000); // 8 * 64 = 320 µs Listen RFM69_spi(0x0144 | 0x8000); //Standby mode + Listen Mode setzen
Hallo Hannes, ja habe ich schon erfolgreich eingesetzt. Um ein Paket zu empfangen muss dieses vom Sender natürlich für die Sleepzeit + Paketdauer kontinuierlich wiederholt werden. Die Empfangsdauer habe ich auf ca. 1.5 fache Länge der Paketdauer eingestellt, da die mindestlänge der Preambel auch noch mit dazugehört und der Empfang ja auch gerade mittend in einer Übertragung aktiviert werden kann. Um möglichst kurz aufzuwecken sollte das Initiale Paket auch möglichst kurz sein (ein Nutzbyte). Wichtig noch - Listenmodus nicht vergessen zu deaktivieren. Da hab ich am Anfang lang gesucht da immer nach dem aufspielen der Software auf den AVR selbst das setzen der ganzen Register den Modus nicht beendet und dann natürlich kein normaler Betrieb möglich ist. Also am besten beim Init auch 1x Listenabort setzen. Sascha
Danke für deine Antwort. Den Listen-Mode zu deaktivieren war ein guter Tipp - hab ich gleich ins Init übernommen. Leider bekomme ich den RFM damit auch nicht aufgeweckt. Ich habe versuchsweise den Sender umprogrammiert, dass dieser ein Paket mit 10 Bytes Nutzdaten alle 20ms aussendet. Mit dieser Konfiguration müsste die RSSI Schwelle doch überschritten werden, sodass der RFM in den RX Modus wechselt und zumindest ein Paket empfangt. Ich stelle mir vor, den Empfänger zuerst aufzuwecken (RFM geht in RX Mode) und anschließend die Nutzdaten zu senden. Daraufhin würde der Empfänger wieder in den Listen Modus zurückversetzt werden. Was mich noch etwas stutzig macht, ist die Einstellung im Register: RFM69_spi(0x0F08 | 0x8000); // 8 * 64 = 320 µs Listen Wenn ich den Wert erhöhe auf zum Beispiel 12*64µs = 768µs steigt der Stromverbrauch sofort wieder auf 20mA an. Ich habe das Gefühl, dass in der Initialisierung noch ein Denkfehler steckt. Freue mich sehr über weitere Ideen.
Mit welcher Bitrate arbeitest du? Werd' morgen mal meinen Code rauskramen. Leider ist das Datenblatt in dem Bereich nicht wirklich ausführlich. Sascha
Hallo,
ich würde für Experimente immer AES ausschalten, da es nur in Vielfachen
von 16ern funktioniert.
> RFM69_spi(0x3D03 | 0x8000); // No Wait time defined; AES on
mfG
Sascha W. schrieb: > Mit welcher Bitrate arbeitest du? Ich hab aktuell 19200 Baud eingestellt. > Werd' morgen mal meinen Code rauskramen. Leider ist das Datenblatt in > dem Bereich nicht wirklich ausführlich. Das wär wirklich sehr nett - vielleicht kann man ja das ein oder andere nachvollziehen/abgucken :)
Hallo Hannes, also ich verwende als ListenCriteria RSSI+SYNC läuft bei mir mit 12000Bd, macht 667µs pro Byte. Ich wecke mit einem Byte Nutzdaten macht bei mir 3 Byte Preambel 2 Syncword 1 Byte Länge 1 Byte Nutzdaten 2 Byte CRC =9 Byte -> *667s == 6ms Packetlänge Der Empfänger ist 100ms wach und schläft 2.1s, zum wecken wiederhole ich das Packet ohne nenneswerte Zwischenpause 229x (Dauer damit ca. 2.2s). Wie weit ich mit der RX-Zeit runtergehen kann bis es nicht mehr funktioniert habe ich glaube ich nicht weiter getestet. Mit den 100ms lässt er sich in ca. 95% der Fälle erfolgreich wecken. Hast du mal die Zeiten aus Abschnitt 4.2.3 (Receiver Startup Time) aus dem DB entsprechend deiner Konfig zusammengerechnet? Am besten erst mal mit großer Zeit anfangen und dann immer weiter runtergehen. Sascha
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.