Hallo Mikrocontroller Forum, ich habe vor kurzem einen eigenen LoRa Sender für mein Smarthome gebaut: Atmega328p Chip mit BME280 als Sensor und RFM98W zum versenden der Daten über LoRa. Das funktioniert Prima: Ich lese den Sensor aus, falls sich die Werte geändert haben, sende ich diese über LoRa und gehe dann für 4 Minuten schlafen mit Hilfe der Rocketscream Library (LowPower.powerDown(SLEEP_8S, ADC_OFF, BOD_OFF);). Nach meiner Messung verbraucht der Atmega im Sleep Mode 9 Microampere. Da ich nur einen Multimeter zur Verfügung habe, kann ich den Peak während der LoRa Aktivität nur bedingt messen, mein Multimeter zeigt ca. 20-30 mA an. Auch wenn ich die Sendeleistung sehr gering halte (4 dBm) und via Software den Strom auf 45 mA limitiere, fehlen noch Welten zu der u.g. Laufzeit. Wenn ich jetzt großzügig Rechne, komme ich mit 2xAAA Batterien auf ein Jahr: 1 sec. 30 mA, 239 sec. 9 uA --> 0,13 mAh. Bei 1000 mAh sollte es 320 Tage halten. Leider sind die Eneloops nach 30 Tagen Leer. Ich habe via Software die Spannung gemessen und hier ist der schnelle Abfall deutlich zu sehen (BatteryVoltage.png) (https://provideyourown.com/2012/secret-arduino-voltmeter-measure-battery-voltage/) Habt ihr eine Idee, warum ich um mind. Faktor 10x danebenliege? Den Schaltplan habe ich Beigefügt (LoraWiring.png). Vielen Dank schon mal!
Angehängte Dateien:
-
BatteryVoltage.png
14 KB -
LoraWiring.png
69 KB
Gregor W. schrieb: > Leider sind die Eneloops nach 30 Tagen Leer. Hohe Selbstentladung wegen früherer schlechter Behandlung?
Vorab zu deinem "Schaltplan": AGND und AVCC müssen auch angeschlossen werden. Wenn du den ADC nicht verwendest, direkt mit GND und VCC verbinden. Dann die Frage: 9µA gemessen incl. BME und RFM-Modul, oder nur der AVR alleine?
Also an den Akkus kann das nicht liegen. Ich habe es sowohl mit neuen AAA wie auch mit AA Eneloops probiert und sogar mit AA Alkaline. Ich hoffe dass die 9 uA für die gesamte Schaltung gilt. In dem oben angehängten Bild habe ich auch die Messstellen (Amperemeter) eingefügt. Interessant ich wusste gar nicht dass AGND und AVCC verbunden werden müssen. Funktionieren tut es trotzdem. Kann dies eine "positive" Entwicklung auf den Stromverbrauch haben?
Wird der RFM auch für die ganze Pausenzeit schlafen gelegt? SLEEP_8S sind keine 4 Minuten, da wird relativ hochfrequent wieder alles geweckt, evtl. der RFM wieder konfiguriert. Das wären alle 8 s noch ordentliche Strompeaks. Wenn dabei nach 8 s der RFM nicht in den standby geschickt wird und empfängt, dann läuft der auch mit einigen mA. Besser wäre wirklich die 4 min. zu schlafen, dafür sind aber neuere AVR besser geeignet, sagen die AVR Experten welcher einer ich nicht bin.
Interessant, daran habe ich gar nicht gedacht. Wie gesagt, mit einem Multimeter kann ich die sehr kurzen Peaks gar nicht sehen. Der Sleep läuft in einer Schleife, da wird codemäßig nichts anderes ausgeführt: for (int i=0; i<SLEEPTIME; i++) LowPower.powerDown(SLEEP_8S, ADC_OFF, BOD_OFF); Ich würde mich ungern von dem Atmega328p trennen, die sind unschlagbar günstig und ich hab schon 'n Dutzend. Außerdem würde das Aufwecken nur Mikrosekunden dauern. Reicht es um so eine Laufzeitverkürzung hinzubekommen?
Gregor W. schrieb: > Reicht es um so eine Laufzeitverkürzung > hinzubekommen? Nein. 1Ah/24/30 => ~1mA sind gesucht. Die Lösung wird wohl in dem hoch geheimen Code stecken.. Wenn du die Akkus durch große, niederohmige Kondensatoren ersetzt, kannst du anhand der Kondenstorspannung auf den realen Strom/Ladungsmenge schließen..
Der Code ist nicht geheim (siehe Anhang). Aber ich gehe eher von einem HW Fehler, bzw. Messfehler aus, denn irgendwo muss ja der Strom verschwinden, sonst hätte ich nicht das Problem. Zu den Kondensatoren: Da bin ich elektrotechnisch nicht so gut bewandert, aber ich weiß ja, dass irgendwo der Strom verschwindet. Ich könnte damit zwar den realen Strom messen, aber warum weiß ich dann ja auch nicht.
Gregor W. schrieb:
// carrier frequency: 444.0 MHz
443,59375 - 444,96875 MHz Funkanwendungen der BOS
Der Gilb schrieb: > Gregor W. schrieb: > > // carrier frequency: 444.0 MHz > > 443,59375 - 444,96875 MHz Funkanwendungen der BOS Danke, werde ich ändern.
wie lange blockiert lora.transmit(), wartet das evtl. auf ein acknowledge? Zur Kontrolle könnte man vorher eine LED ein und danach wieder ausschalten. Um zu sehen, ob das hängt. Oder ein serial Print wenn der Status nicht ok ist.
Johannes S. schrieb: > wie lange blockiert lora.transmit(), wartet das evtl. auf ein > acknowledge? Zur Kontrolle könnte man vorher eine LED ein und danach > wieder ausschalten. Um zu sehen, ob das hängt. Oder ein serial Print > wenn der Status nicht ok ist. Ich habe testweise die Laufzeit der Loop (ohne sleep natürlich) gemessen: void loop() { startTime=millis(); //Sensor auslesen und verschicken, lora in sleep versetzen duration = millis()-startTime; for (unsigned long i=0; i<(seconds/8); i++) { LowPower.powerDown(SLEEP_8S, ADC_OFF, BOD_OFF); } } Diese ist zwischen 125 und 250 ms. Das bestätigt auch den kurzen Ausschlag von 20-30 mA am Multimeter wie im ersten Post genannt.
:
Bearbeitet durch User
Gregor W. schrieb: > Den Schaltplan habe ich Beigefügt (LoraWiring.png). Da bekommt man ja Augenkrebs und einen verkurbelten Nacken, wenn man den lesen will. Wenn du Probleme hast, den Sendepeak vernünftig zu messen, teste doch im Programm erstmal die einzelnen Phasen separat, d.h. nur Sleep und nur Aufwachen mit LoRa Aussendung. Mit einem Multimeter alleine wird es allerdings müßig sein, die Stromaufnahme sauber zu erfassen (allenfalls mit einem Drehspulinstrument und definierter, schneller Sendefolge).
@Wolfgang: Egal wie hoch der Sendepeak ist, so hoch kann er gar nicht sein, dass dieser meine Batterie auffrisst (~250 mA). Zudem die Spec des Chips folgende Werte auflistet: RFOP = +20 dBm, on PA_BOOST - 120 mA RFOP = +17 dBm, on PA_BOOST - 87 mA RFOP = +13 dBm, on RFO_LF/HF pin - 29 mA RFOP = + 7 dBm, on RFO_LF/HF pin - 20 mA Danke für eure Hilfe. So wie es scheint, ist mir nicht irgendein grober Schnitzer unterlaufen, sondern der Teufel steckt irgendwo im Detail. Ich versuche als nächstes den RFM nicht direkt an VCC zu legen sondern an einen Pin, den ich LOW halte und nur fürs Senden auf HIGH setze. Aber für weitere (Test) Vorschläge bin ich natürlich offen!
Gregor W. schrieb: > Nach meiner Messung verbraucht der Atmega im Sleep Mode 9 Microampere. Wie viel µA verbraucht denn die gesamte Schaltung wenn sie schläft?
Funkie schrieb: > Gregor W. schrieb: >> Nach meiner Messung verbraucht der Atmega im Sleep Mode 9 Microampere. > > Wie viel µA verbraucht denn die gesamte Schaltung wenn sie schläft? Das war von mir unglücklich formuliert: Nach meiner Messung verbraucht der Atmega mit BME und LoRa im Sleep Mode 9 Microampere.
ich würde wie schon vorgeschlagen vor und nach dem Senden eine Meldung ausgeben und das über lange Zeit in eine Datei loggen. Wenn das Programm über kurze Zeit funktioniert, dann heisst es noch nicht, das es auch über längere Zeit alles richtig macht. Am I2C sind im Schaltplan keine Widerstände drin, hat das Modul die PullUp aktiviert? Das I2C könnte sich auch verhaken und den µC längere Zeit wach halten. Die Empfangsseite könnte auch Aussetzer der Pakete zählen. Ist das ein Grafana Plot im ersten Posting? Werden da Werte aufgefüllt wenn keine empfangen wurden?
Εrnst B. schrieb: > Vorab zu deinem "Schaltplan": AGND und AVCC müssen auch angeschlossen > werden. Wenn du den ADC nicht verwendest, direkt mit GND und VCC > verbinden. Zeig mir bitte mal den AGND Anschluss.
Ok, ich werde die Pakete auf der Sendeseite Nummerieren und an der Empfangsseite auswerten, guter Punkt. Vielleicht ist es eine heiße Spur, denn: Ich logge in der Datenbank den Timestamp mit, also sollte alle 240 sec (+-15 sec) etwas empfangen werden. Von 1498 Einträgen sehe ich dass 72 den doppelten Timestamp haben (480 sec +-15 sec.). Also sieht es eher nach "verlorenen" LoRa Paket aus. Von den Empfangenen Sensordaten sind jedoch alle stimmig, also es sind reale Werte ohne Ausreißer. "Das I2C könnte sich auch verhaken und den µC längere Zeit wach halten." wie würde ich das mitbekommen? Ich müßte die Zeit vor dem Auslesen des BME und danach messen, oder?
Jörn P. schrieb: > Εrnst B. schrieb: >> Vorab zu deinem "Schaltplan": AGND und AVCC müssen auch angeschlossen >> werden. Wenn du den ADC nicht verwendest, direkt mit GND und VCC >> verbinden. > > Zeig mir bitte mal den AGND Anschluss. Der ist nicht verbunden.
Gregor W. schrieb: > wie würde ich das mitbekommen? Ich müßte die Zeit vor > dem Auslesen des BME und danach messen, oder? um den Übeltäter zu finden wäre das sinnvoll. Bei einem LPC812 hatte ich das Problem das der im deep power down auch die internen PullUp abschaltet und die floatenden SPI Leitungen am RFM zu höherem Strom (ein paar mA) geführt hatten. Das liess sich auch mit dem Multimeter messen. Aber soweit ich weiss behält der Mega328 die PullUp im power down? Oder ist es doch anders? Zum AVR Tiefschlaf gibt es hier auch zwei Artikel im Wiki: https://www.mikrocontroller.net/articles/Ultra_low_power https://www.mikrocontroller.net/articles/Sleep_Mode
Johannes S. schrieb: > Aber soweit ich weiss behält der Mega328 die > PullUp im power down? Oder ist es doch anders? Das ist auch mein Wissensstand. Dann messe ich mal die BME Auslesedauer. Johannes S. schrieb: > Am I2C sind im Schaltplan keine Widerstände drin, hat das Modul die > PullUp aktiviert? Diese Module haben bereits interne Pullups.
Also ich starte jetzt einen Test mit Sendeintervall 60 sec. OHNE TWI Interface, d.h. ich lese den BME gar nicht aus, sonder sende Fake-Random Werte. Ich melde mich dann nach ein Paar Tagen mit den Resultaten!
Angehängte Dateien:
-
OhneBme.png
35 KB
Hmmm, also leider hat das auch nichts gebracht. Der Spannungsabfall nach vier Tagen beträgt 0.2V (2.25 V auf 2.04 V). Falls ihr noch andere Ideen habt, her damit. Ich bin mit meinem Latein am ende.
schwierig. Dann müsste man einen 2. Logger bauen der die Stromaufnahme mitprotokolliert, irgendwann müsste der µC ja zu lange zu viel ziehen. Oder das Messgerät lange im Auge behalten. Sind die Eneloops in Ordnung? Und auch keine Fälschungen? Du kannst die mit einem R mit 50 - 100 mA belasten und deinen Logger dranhängen um die Kapazität zu messen. AAA Eneloops haben doch eher 750 mA statt 1000 mA, nicht das das irgendwelche überalterte Standard NiMH sind. Frisch geladen sollten die mit >2,8 V starten, deine Diagramme gehen bei 2,4 V los. Stimmt die µC Messung mit dem Multimeter überein?
Johannes S. schrieb: > Sind die Eneloops in Ordnung? Die sind neu. Aber wie weiter oben erwähnt, die "Entladekurve" ist auch bei Alkaline ähnlich. Johannes S. schrieb: > Frisch > geladen sollten die mit >2,8 V starten Sicher? Das sind AAA nicht AA. D.h. die Spannung ist 1,2V pro Zelle. Johannes S. schrieb: > Dann müsste man einen 2. Logger bauen der die Stromaufnahme > mitprotokolliert, irgendwann müsste der µC ja zu lange zu viel ziehen. Ja, so scheint es mir auch :( Hab 'n INA219 bestellt. Ich halte euch auf den laufenden.
Gregor W. schrieb: > Sicher? Das sind AAA nicht AA. D.h. die Spannung ist 1,2V pro Zelle. die Größe spielt keine Rolle, beides sind NiMH. Ganz voll und bei der geringen Last oder im Leerlauf müssten die 1,4 V anzeigen. https://docs.rs-online.com/d9ae/0900766b812ff4cc.pdf
Angehängte Dateien:
-
ina219.png
42 KB -
VCC_INA.png
28 KB
Ich habe eine Messschaltung mit einem Arduino Nano und INA219 laufen lassen. Angeschlossen habe ich INA nach Anleitung (https://www.14core.com/wiring-the-i2c-ina219-zero-drift-bidirectional-currentpower-monitor-with-mcu/) Zusätzlich ist der Arduino Nano mit USB mit meinem PC verbunden, damit ich über den seriellen Output die Messdaten loggen kann. Ich messe 100x in der Sekunde, erstelle einen Sekundendurchschnitt und speichere den max. Wert und gebe diese aus. Nach 3 Tagen (oder 284576 Messungen) sehe ich nichts auffälliges, im Anhang repräsentativ eine Stunde: Idle ca. 0 mA, beim Versenden ~6 mA pro Sekunde (ina219.png), der max. Wert liegt bei 28 mA , macht im Durchschnitt 0,16 mAh. ABER: Nach dem Anschließen des INA, sinkt meine Spannung nicht mehr und bleibt seit Tagen bei 1.9V, siehe VCC_INA.png. Habe ich jetzt bei der INA Schaltung was falsch gemacht und der Strom wird über USB gezogen, oder verbraucht meine Schaltung mit INA unerklärlicherweise endlich so wenig wie ich es erwartet habe?
Nur wenn sensorValuesChanged triggert, sendest und schläfst du. Ansonsten geht es nonstop über bme.read(). Sollte das Kerlchen nicht immer schlafen?
Du hast recht, da ist die eine Klammer falsch. Da habe ich wohl 'n copy paste Fehler. Es muss natürlich:
1 | //send the packet
|
2 | int loraState=lora.transmit(outBuffer, 6); |
3 | if (loraState == 0) |
4 | {
|
5 | Serial.println("the packet was successfully transmitted"); |
6 | }
|
7 | }//sensor values changed |
8 | //go to sleep
|
9 | lora.sleep(); |
10 | for (unsigned long i=0; i<(SLEEPTIME_SEC/8); i++) |
11 | {
|
12 | LowPower.powerDown(SLEEP_8S, ADC_OFF, BOD_OFF); |
13 | }
|
heißen.
Ich verwende derzeit vom Ina219 nur den Vin+ und Vin-, alle anderen Pins, Usb ist getrennt. Also besteht die Schaltung aus meinem lora node, Batterie und Ina219. Seit einer Woche bleibt die Spannung konstant, also frage ich mich was im Ina219 meinen Stromverbrauch gefixt hat?! Shunt, Dioden?
Thread beobachten
Seitenaufteilung abschaltenBitte 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.