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

Bee Observer BOB Entwicklung
, ,
99

Stimmt, habe auch schon überlegt, ob irgend eine Kommunikation ihn wach hält. Aber warum nur den FiPY und nicht den WiPy.

In der Doku zum FiPy habe ich auch gelesen, das man den RX und Tx Jumper auf dem Expansionsboard entfernen soll , da das Modem diese ebenfalls nutzt und der depp Sleep dadurch verhindert werden kann.
Aber welche meinen sie P0 & P1 oder wie im Pinout angegeben P15 & P17-P20

Muß glaube ich Mal alles mit Sim durchtesten.

Telefonieren können wir gerne mal, schick dir gleich mal ne PN

100

Tests mit oder ohne Sensoren

Vermutlich doch, weil es einfach das LTE Modem ist ;].

Zwischenbericht » Weitere Abschaltungen

Bis später!

101

Wie schon gesagt, benutze das Board schon seit 2-3 Wochen nicht mehr.
Mache alles nur noch über USB>TTL an P0 und P1 allerdings hatte ich ihn ab und an beim testen nicht mit abgezogen. Auch habe ich die Eingangs- Spannung nicht berücksichtigt das sie nicht zu niedrig werden sollte. SIM hatte ich auch nur Recht kurz drin dort also auch nicht die anderen Störfaktoren berücksichtigt worden.
Werde den FiPy heute Abend Mal kompl
nackig machen und nur an VCC > 4,20V mit Sim betreiben und ein paar der

1 Like
102

Neuigkeiten

image
image.png846×572 37.4 KB

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

105

Disclaimer: Bitte alle diese Abbildungen und Werte mit “a grain of salt” nehmen, da ich zwar den Spannungsteiler auf die passenden Werte fürs Expansion Board konfiguriert habe, da allerdings noch das Board von @clemens dazwischenhängt, das ja noch einen eigenen Spannungsteiler mitbringt.

Vermutlich Gewiß clipped daher daher der Spannungswert im vollgeladenen Zustand .

Die Erkennbarkeit der Fortschritte wird dadurch hoffentlich nicht allzu stark eingetrübt.

Why does this always happen to me…? ;]

1 Like
107

Ihr habt bis bis jetzt, entgegen aller Widersprüchlichen Meldungen in den div anderen Foren, einen tollen Job gemacht.
Der FiPy fährt jetzt auch problemlos in den Deep Sleep. (auf 3 x FiPy ohne SIM getestet).
Die Stromaufnahme im Deep Sleep ist dort erstaunlicherweise vergleichbar mit dem was wir beim WiPy schon gesehen haben.
= 320μA

  • 170μA für die 6 DS1820
  • 98 μA HX711
  • 29 μA BME280
  • 23 μA FiPY 3.0

somit ist Software-seitig (bis auf kleine Laufzeit-Optimierungen) maximal Mögliche erreicht.
Interessant wird es natürlich wieder, wenn wir das Modem im FiPy für einige Übertragungsvarianten (LTE) wieder in zeitweisen Betrieb nehmen müssen.

Getestet habe Ich mit der folgenden Config:
Testbedingungen:

  • Datalogger master 0.5.1 Latest commit [8bfda9c]
  • FiPy ohne Sim Karte
  • Logging über Usb via TTL Adapter
  • Firmware FiPy 1.20.0.rc11
  • Modem Firmware = Auslieferungszustand
  • Clemens Solar Board V0.0.14 mit und ohne Solarregler
  • Bosche H40
  • Hx711 (ohne Pullup)
  • 6X DS18b20
  • 1x BME280
  • WLAN an und verbunden
  • Beidseitige Datenübertragung zu Hiveeyes und BOB
  • Eingangsspannung 5V-3V
    IMG_20190627_065132_0
    IMG_20190627_065132_0.jpg1536×2048 961 KB

    Echt eine tolle Arbeit die Ihr und vor allem @Andreas bisher geleistet haben.
    Ich persönlich habe noch nie eine Software so schnell reifen gesehen!!!
1 Like
108

Wär traumhaft, wenn du rausfinden könntest, wie viel Datenübertragungen er in den 40,5 Std geschafft hat, dann könnten wir die Laufzeiten für längere Schlafpausen errechen. Auch für spätere vergleiche, der Softwareversionen ist es sicher hoch interesssant, wie viel mAh eine einzelne Übertragung “kostet”.

109

Du hast doch noch die Vorversion, die grüne Platine, die ist ohne Spannungsteiler fürs battery monitoring??

110

Wow!!

Bei den DS18B20 kann was nicht stimmen, laut Datenblatt (Seite 2) brauchen die maximal 1000 nA, also 1 µA! … oder wir haben uns irgendwelchen China-Schrott reingezogen.

1 Like
111

Das bezieht sich auf den einzelnen Ds18b20 denke mal da spielt der 4,7K Widerstand sicher auch eine recht große Rolle und evtl sind auch unter der Kappe noch zusätzliche Halbleiter wie Dioden oder so verbaut. ich kann aber gerne mal ohne den 4,7K messen.
die 170µA finde ich aber gar nicht so Dramatisch.

beim aktuellen verbrauch von 320μA im deep sleep kann der FiPy 260 Tage schlafen bis der Akku leer ist.
Wenn ich jetzt ganz Grobe, (ohne @Andreas Werte zu kennen)
mit 1600 Übertragungen (ca.40/h) im Kopf überschlage und mit Stündlicher
Übertragung umrechne, sollten wir etwa bei etwa 50 Tage bei 320μA landen. Bei 100μA Deep Sleep währen wir etwa bei ca. 60Tage.

Übertragen wir häufiger wird auch der Unterschied kleiner.
2/h ca 29Tage zu 32 Tage
4/h ca 15,5 Tage zu 16,3 Tage
10/h ca 6,5 Tage zu 6,6 Tage

hoffe mal ich habe so halbwegs richtig gerechnet.

115

Exzellent! Vielen Dank für die Berichterstattung.

Das deute ich ebenfalls als gutes Zeichen. Das heißt wir haben es mit der aktuell verwendeten Software- und Hardwarekonfiguration geschafft, die noch nicht benötigte (Modem-)Peripherie so abzuschalten, dass sie nicht beim Energiebudget aufträgt. Wunderbar.

Ja. Ein wenig mehr könnte noch gehen. Gerade vom Freezing der Python-Quellen verspreche ich mir noch ein wenig Optimierung zur Laufzeit.

Robustheit geht aber vor [1] und derzeit sind wir schließlich noch recht aktiv in der Entwicklung. Daher haben solche Dinge noch keine so hohe Priorität bzw. wir denken derzeit noch nicht aktiv ans Freezing – schließlich haben wir endlich Sommer. Gebt gern Bescheid, wenn Euch daran gelegen ist, solche Aspekte früher als geplant zu verbessern.

Vielen herzlichen Dank für Deine Tests, Michael!

  1. Um die Robustheit sind wir derzeit weiterhin vor allem froh. Dass das Teil einigermaßen stabil zu rennen scheint, erzählte man sich neulich schon beim Späti. Dass es nun auch bei @clemens, @MKO und anderswo passabel klappt, ist vielversprechend. Den Dank will ich vor allem an @einsiedlerkrebs weitergeben, der nicht nur bei der Grundsteinlegung für den MicroPython-Datenlogger ordentlich mit angepackt hat sondern weiterhin mit Rat und Tat auf Hard- und Softwareebene zur Seite steht. Vielen Dank aber auch an alle, die durch die folgenden gemeinsamen Diskussionen zu einem guten Gelingen beigetragen haben und nicht zuletzt an @caro, @Diren, @vinz und @didilamken von Hiverize, die dies durch die Bee Observer Workshops überhaupt erst ermöglicht haben. ↩︎

116

Hmmm, ich habe gerade diese Werte:

Gesamt 50 μA

DS18B20 5 μA
Wägezelle ohne HX711 < 0,1 μA [edit] die Wägezelle scheint komplett abgeschaltet zu sein, HX711 alleine habe ich nicht gemessen!
BME280 38 μA

2 Likes
117

Schon sehr schön!

Der Wert aber für den BME280 ist noch zu hoch: das ist eine Größenordnung mehr, als der im ‘normal mode’ bei 1Hz (f. Luftdruck, Temperatur und Feuchte) hat - jedenfalls ein Bosch-Orginal laut Datenblatt ! ;) Dort sind das 3,6 µA.

Den BME280 will man im ‘forced mode’ betreiben (Punkt 3.3.3. im Datenblatt), da mißt er nur auf Anforderung und geht selbsttätig in den sleep danach - da braucht er nur noch 0,1 µA.

Ohne im code selbst geschaut zu haben: fliegt Ihr den BME280 im forced mode?

118

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.

119

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

120

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.

121

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

123

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

126

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.

127

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.