Stromsparmaßnahmen für die MicroPython-Firmware im Batteriebetrieb

Andreas · July 1, 2019, 5:43pm

Danke @clemens. Das liest sich vielversprechend, wenn die Werte stimmen. <Pöbel>Darf ich nach der Qualität der Meßgeräte fragen? :P</Pöbel>

Vor allem interessiert mich aber Deine settings.py und konkret solche Details, ob im Vergleich zwischen Eurer beiden Messungen signifikante Unterschiede an den Software-Einstellungen zu erkennen sind. Einige Dinge hatte ich halt pro forma eingebaut und nie erwartet, dass das ernsthaft etwas bringt. Wenn sich nun aber herausstellt, dass sowohl die Abschaltung von UART0 als auch Logging und das LED taming usw. usf. in Kombination doch noch etwas ausmacht, dann sollten wir das verbriefen.

Hört sich gut an.

Im Zweifelsfall nein. Vielen Dank für die Aufmerksamkeit, wir nehmen das mit für die nächsten Stunden am Code.

clemens · July 1, 2019, 9:11pm

@MKO vielleicht könntest du mit der aktuellen firmware nochmal nachmessen, traue meinen Werten nicht ganz bzw. wäre gut, wenn sie jemand zweites bestätigt bevor wir hier zeitintensive Optimierungen nachschieben.

Du hast gar kein Messgerät, oder? Voltcraft VC175

Messbereich A/DC min. 0.1 µA

hier meine settings.py

"""Datalogger configuration"""

# General settings.
main = {

    # Measurement interval in seconds.
    # TODO: Please note this is not the _real thing_ yet at it will just use
    #       this value to apply to ``time.sleep()`` after each duty cycle.
    'interval': 40.0,

    # Whether to use deep sleep between measurement cycles.
    'deepsleep': True,

    # Configure logging.
    'logging': {

        # Enable or disable logging completely.
        'enabled': True,

        # Log configuration settings at system startup.
        'configuration': True,
    },

    # Configure Watchdog.
    'watchdog': {

        # Enable or disable Watchdog completely.
        'enabled': False,

        # Watchdog timeout in milliseconds.
        'timeout': 20000,
    },

    # Configure RGB-LED.
    'rgb_led': {
        'heartbeat': False,
    },

}

# Interface settings.
interfaces = {
    'uart0': {
        'terminal': True,
    }
}

# Networking configuration.
networking = {
    'wifi': {
        # WiFi stations to connect to in STA mode.
        'stations': [

            # Variant 1: Use DHCP.

            # Variant 1a: Straight forward.
            {'ssid': 'your-ssid', 'password': 'your-pw'},

            # Variant 1b: Configure timeout (default: 15 seconds).
            # Configure this to decrease or increase the maximum time in
            # seconds to wait for the connection to succeed.
            #{'ssid': 'FooBar', 'password': 'SECRET', 'timeout': 5.0},

            # Variant 2: Using static IP address.
            #{
            #    'ssid': 'FooBar',
            #    'password': 'SECRET',
            #    # Use static network configuration (ip, subnet_mask, gateway, DNS_server).
            #    'ifconfig': ('192.168.42.42', '255.255.255.0', '192.168.42.1', '192.168.42.1'),
            #},
        ],
    },
}

# Telemetry configuration.
telemetry = {
    'targets': [

        # Hiveeyes telemetry: JSON over MQTT
        {
            # Enable/disable this telemetry target.
            'enabled': True,

            # Define telemetry endpoint and address information.
            'endpoint': 'mqtt://swarm.hiveeyes.org',
            'topology': 'mqttkit',
            'address': {
                "realm": "hiveeyes",
                "network": "testdrive",
                "gateway": "area-005",
                "node": "fipy-cg-01",
            },
        },

        # Beep telemetry: JSON over HTTP
        {
            # Enable/disable this telemetry target.
            'enabled': True,

            # Define telemetry endpoint and address information.
            'endpoint': 'https://bee-observer.org/api/sensors',
            'topology': 'beep-bob',
            'data': {
                'key': 'my-key',
            },
        },

    ],
}

# Sensor configuration.
sensors = {
    'system': {

        # Adjust voltage divider resistor values matching the board.
        #
        # See also
        # - https://forum.pycom.io/topic/3776/adc-use-to-measure-battery-level-vin-level
        # - https://github.com/hiveeyes/hiveeyes-micropython-firmware/issues/5
        # - https://community.hiveeyes.org/t/batterieuberwachung-voltage-divider-und-attenuation-fur-microypthon-firmware/2128
        #
        # As a reference (all readings using 6dB attenuation unless otherwise noted):
        #
        # - Pycom Expansion board v3.0: 115 kÎ© / 56 kÎ©
        # - Pycom Expansion board v3.1: 1 MÎ© / 1 MÎ©
        # - Pycom Expansion board v3.2: 1 MÎ© / 1 MÎ©
        # - BOB-HAT-V5: 1 MÎ© / 470 kÎ© or 220 kÎ©
        # - BOB-SHIELD: 10 MÎ© / 2 MÎ©
        # - Air Quality monitor: 100kÎ© / 47 kÎ©, measured with 2.5dB attenuation

        # These settings are matching the resistor values of the Pycom Expansion Board 3.1 and 3.2.
        'vcc': {

            'pin': 'P16',

            # Main resistor value (R1).
            'resistor_r1': 10,

            # Resistor between input pin and ground (R2).
            'resistor_r2': 2,
        },

        # Settings for button events, e.g. through touch pads.
        'buttons': {
            'enabled': False,
        },
    },
    'registry': {
        'hx711': {
            'address': 0x00,
            'pin_dout': 'P22',
            'pin_pdsck': 'P21',
            'scale': -22479.0,
            'offset': 32423.0,
        },
        'ds18x20': {
            'bus': 'onewire:0',
        },
        'bme280': {
            'bus': 'i2c:0',
            'address': 0x77,
        },
    },
    'busses': [
        {
            "family": "i2c",
            "number": 0,
            "enabled": True,
            "pin_sda": "P9",
            "pin_scl": "P10",
        },
        {
            "family": "onewire",
            "number": 0,
            "enabled": True,
            "pin_data": "P11",
        },
    ]
}

# Map sensor field names to telemetry field names.
# Right now, please adapt this according to your sensor configuration by
# looking at the console output of the line
# `[terkin.datalogger] INFO: Sensor data`. Thanks!
#
# Remark:
# This will be replaced by runtime configuration through
# HTTP API and captive portal.
sensor_telemetry_map = {
    "_version": "1.0.0",
    "temperature.0x77.i2c:0": "t",
    "humidity.0x77.i2c:0": "h",
    "pressure.0x77.i2c:0": "p",
    "weight.0": "weight",
    "temperature.28ff641d8fd18ab0.onewire:0": "t_i_1",
    "temperature.28ff641d8fd4d5d5.onewire:0": "t_i_2",
    "temperature.28ff641d8fd833ac.onewire:0": "t_i_3",
    "temperature.28ff641d8fd8778b.onewire:0": "t_i_4",
    "temperature.28ff641d8fd922ab.onewire:0": "t_i_5",
    "system.temperature": "t_i_6",
}

Vielleicht könntest du noch 2 Sätze zu UART0 schreiben, war mir in der Konfig nicht klar was das macht.

LEDs brauchen bei dauer-an pi-x-daumen 20 mA und mehr, klar bringt es was die auszuschalten!

Kombinierte Effekte würde ich nicht erwarten, eher additive.

Andreas · July 1, 2019, 9:43pm

Nicht was den Namen verdient. Meine Frage nach Deinem war auch eher rhetorisch ;].

Danke. Hier war meine Frage vermutlich auch eher Quatsch, weil die Dinge, die den Deepsleep betreffen, nicht unbedingt in der Konfiguration selbst zu finden sind.

Das macht Sinn wenn man Logging ohnehin aus hat und daran glaubt, dass ein entsprechendes uart.deinit() schon zum Start des Datenloggers Strom oder andere sinnvolle Dinge sparen kann oder man es ganz einfach für andere Dinge benötigt als die Terminalkonsole, siehe terkin-datalogger/terkin/device.py at 0.5.1 · hiveeyes/terkin-datalogger · GitHub im Code.

Momentan ist das Blinkmuster “Zweimal kurz grün beim Anfahren.”. Sag gern Bescheid, wenn wir da noch weiter gehen sollen (ganz aus? / nur einmal kurz blinken? / kürzer blinken?).

Vermutlich meinte ich das so. So ein paar µ halt noch.

Andreas · July 11, 2019, 9:57am

Anbei ein Beitrag aus dem Pycom-Forum, der ebenfalls hierher passen könnte.

Lopy4 uses lots of mA when voltage is getting low | Pycom user forum

clemens · July 11, 2019, 6:16pm

Können wir das noch angehen? 38 µA vs. 0,1 µA würde sich schon lohnen!

Andreas · July 11, 2019, 7:44pm

Den BME280 will man im ‘forced mode’ betreiben

Das ist irgendwie zu Prio 2 bei [Backlog] Terkin-Datenlogger für BOB - #2 by Andreas gerutscht.

clemens · July 14, 2019, 8:41pm

Wir sind gerade dabei das Energiebudget für den Betrieb mit Solarzellen zu berechnen. Dazu wäre es vorteilhaft wenn wir den BME280 in einen Modus mit möglichst wenig Stromaufnahme im deep sleep bekommen bzw. die von @weef im Datenblatt gefundenen Optionen auch in MicroPython hingekommen.

Andreas · July 14, 2019, 8:58pm

Steht jetzt hier bei Prio 2. Vermutlich ist es ~~kein~~ wieder ein kleines Hexenwerk? Traust Du Dich ran, @clemens?

clemens · July 25, 2019, 10:36am

Bump! ;-) @MKO könntest du mit aktueller Firmware nochmal nachmessen, würde helfen. Mein Multimeter hatte einen Unfall und liefert seit gestern komische Werte.

MKO · July 25, 2019, 1:55pm

So auf die schnelle, zwischen Tür und Angel hab ich Mal mein aktuelles Setup gemessen.

2xBME 280
2xHX711
0x ds18b20.

Im Deep Sleep = 32uA

Andreas · July 25, 2019, 3:34pm

Vielen Dank fürs Nachmessen!

… und das, obwohl wir den bei [Backlog] Terkin-Datenlogger für BOB - #2 by Andreas sowie Versuchsaufbau "Autonome Zelle" #1 & #2: Solar-Feinstaub-Wetter-Vergleichsding erwähnten “forced mode” für die BME280 noch nicht aktiv implementiert haben?

Andreas · July 25, 2019, 9:55pm

2 posts were merged into an existing topic: Kontinuierliche Verbesserungen des Terkin-Datenloggers (600er)

clemens · July 29, 2019, 12:47pm

Mein Testsystem braucht gerade 73 µA, hmmmm??

MKO · July 29, 2019, 5:50pm

Ich hab diesmal ja andere BME280 mit nur ausgeführten I²C Bus verwendet. Vielleicht liegt es auch daran.
Werde die beiden heute Nacht Mal beide Durchmessen. Hast Du @clemens auch ds1820 mit dran?

clemens · July 29, 2019, 7:24pm

Ja, 5 Stück.

Andreas · July 30, 2019, 9:17pm

9 posts were merged into an existing topic: BME280 optimaler mit MicroPython ansteuern

Andreas · July 30, 2019, 8:49pm

Neuigkeiten

– amo-fipy-testbench-power – 39h runtime on batteries

MKO · July 30, 2019, 10:49pm

Wär jetzt interessant zu wissen, wie viele Sendezyklen er jetzt im vergleich zu 0.5.1 geschafft hat. soweit ich mitgekommen bin hast du ja die Wachzeit versucht zu verkürzen.

Aber 1,5 Std. weniger als 0.5.1? Ist aber trotzdem echt schwer einzuschätzen, ob da nicht noch andere Faktoren mitgespielt haben. Optimierung Wartezeiten der DS1820? evtl auch Verschleiß der AKKUS, da sie ja immer bis an die Maximalgrenze gefahren werden? Das Expansionsboard? usw.

Andreas · July 30, 2019, 10:58pm

Ich wollte es einfach nur mal wieder laufen lassen. Ja, wir hatten ursprünglich gehofft, dass die ahead-of-time Bytecode-Kompilierung hier Zeitersparnis bringt – v.a. um die Turnaround-Zeit zu optimieren.

Joa, eben. Ist ja nun aber auch nicht so weit auseinander. Vielleicht war es das letzte Mal der andere Akku oder der Watchdog braucht nun auch ein wenig mehr Strom oder irgendwas. Auf jeden Fall ist der durchlaufene Code nicht weniger geworden und die ahead-of-time Kompilierung hat erstmal leider auch nicht die gewünschten Verbesserungen gebracht, die sich ja auch positiv aufs Strombudget hätten auswirken können.

IngoP · August 21, 2019, 11:17am

Ich habe vorgestern auch mal die Stromaufnahme nachgemessen…
Beim SETUP selber habe ich nicht Mikro sondern Milliampere … Die Last beim Senden kenne ich noch nicht, messe ich demnächst aber auch noch…

Ich habe von Diren gehört, dass über ein Intervall beim Senden von 10sec. nachgedacht wird, Während dieser 10sec. ist dann aber doch der µC mit DS18B20 Abfragen antriggen und aufnehmen beschäftigt… Dann kann ich doch nicht in den DeepSleep …. oder ist das die “Nachtabsenkung” ?

Kann man ggf. für die Intervallzyklen DAY und NIGHT ggf. auch Parameter auf der CONFIG Seite mit aufnehmen ? So muss man nicht wieder neu flashen …
Und bei der späteren Datenanalyse denke ich wird ohnehin auf Viertelstunden / Stunden oder gar Tagesscheiben verdichtet ?