Deep sleep funktioniert im aktuellen Terkin-Datalogger 0.10.0 nicht (2020/09)

Ich wollte gerade für @Werner den Verbrauch eines LoPys im deep sleep mit der aktuellen Terkin-Software messen. Dabei zeigte mein CurrentRanger 1,5 mA an, viel zu viel für den deep sleep!

Mein settings.py sollte passen, hier ein Auszug:

    # Measurement intervals in seconds.
    'interval': {

        # Apply this interval if device is in field mode.
        'field': 90.0,

        # Apply this interval if device is in maintenance mode.
        # https://community.hiveeyes.org/t/wartungsmodus-fur-den-terkin-datenlogger/2274
        'maintenance': 15.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. 60000
        'timeout': 60000,
    },

    [...]

}

# Control the services offered by the device.
services = {
    'api': {
        'modeserver': {
            'enabled': False,
        },
        'http': {
            'enabled': False,
        },
    },
}

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

# Networking configuration.
networking = {
    'wifi': {

        # Enable/disable WiFi completely.
        'enabled': False,

Was ich zuerst versucht hatte, den watchdog zu enablen / disablen, ebenfalls das logging kompletti zu disabablen, ebenfalls uart0, brachte alles nichts.

Dann habe ich zum Multimeter gegriffen und die Spannung am Ausgang des HX711 gemessen, die ist bei 2,irgendwas auch im deep sleep, d.h. die Abschaltung hier scheint nicht zu funktionieren!

# Whether to power toggle the 1-Wire, I2C or SPI buses.
'power_toggle_buses': True,

ist gesetzt, falls das nötig ist! Muss ich den light sleep noch explizit disablen? Könnte es daran liegen?? Den hatte ich bisher gar nicht in der settings.py? Noch andere Ideen?

1 Like

Ob der light sleep aktiviert ist siehst du daran, das er nur ein paar Sec zum Messen wach ist. Wenn Deep sleep aktiv ist zieht er über 10 -20sec. (wegen Bootvorgang) den vollen Strom.
Lightsleep ist auf alle Fälle für hohe und mittlere Messfrequenz bei niedrigem Stromverbrauch sehr gut.

Irgendwas war aber mit light sleep noch nicht ganz in Ordnung. Glaube hatte was mit reconnect oder dem Aufwachgrund (zurücksetzen IRQ) zu tun.
Deep sleep hat dort ja keine Probleme da er ja jedes Mal neu verbindet bzw startet. .

Selbst im light sleep müsste er aber den HX711 in den Sleepmodus versetzen.

In hiverize/FiPy habe ich folgendes ausprobiert:

Es geht hier nur um die terkin-Software. Habe jetzt auch lightsleep mit false in die settings eingetragen, brachte nix, geht nicht, echt Mist!

Es gibt da feine Unterschiede zwischen Micropython und PyComMicropython, die ich noch nicht verstanden habe. ich habe untersucht:

  1. time.sleep(sec) Der FiPy tut nichts, aber er verbraucht genau so viel Strom wie vorher
  2. machine.sleep(msec): Der FiPy tut nichts, aber hinterher geht das WLAN nicht mehr
  3. machine.sleep(msec, resume_wifi_ble=True): führt zu Exception ( Absturz )
  4. machine.lightsleep(msec): führt zu Exception ( Absturz )
  5. machine.deepsleep(msec): funktioniert, aber der FiPy bootet neu ( 20 sec) ,Stromverbrauch nicht so niedrig wie erhofft.
    Andere Methoden hab ich in der Doku nicht gefunden. Deshalb meine Platine BOB-Strom-V2

Hat eine ältere Terkin-Version weniger mA verbraucht?

1 Like

Das Ganze hat ja schon mal funktioniert, wir waren doch schon bei 50 uA (sogar mit dem stromhungrigen FiPy!) im deep sleep, da muss sich mit weiteren Code-Modifikationen seit damals wieder ein Bug eingeschlichen haben, @didilamken! Oder es handelt sich um ein komisches Verhalten im Zusammenhang mit dem LoPy statt des FiPys, ich dachte wir hätten den LoPy aber auch schon mal gemessen und sind auf um die 20 uA gekommen. Also irgendeine Software Regression seit dem Zeitpunkt wo es funktioniert hat!!

1 Like

Mit git-bisect könnte man es vermutlich recht schnell ausfindig machen. Ich habe leider keine Messgeräte zur Verfügung.

1 Like

Schon Mal geschaut, ob es vielleicht an der Pycom Firmware liegt? BOB und Terkin Firmware liefen beide. Entweder wurden da die gleichen Bugs eingebaut oder in der Pycom Firmware hat sich was geändert.

Ich fürchte, da können wir den Fehler nicht finden.
Ich habe aber in den letzten 1 1/2 Jahren verschiedene Pycom-Firmware von 1.18.x bis 1.20.y mit PyBytes am Laufen gehabt. deepsleep habe ich erst in diesem Sommer getestet, da lief es nicht gut.
Man müsste wieder alte PyCom-Firmware aufspielen und testen - keine gute Idee.
es geht um das statement : machine.deepsleep(sec * 1000)

Habe es mit der firmware von Andreas getestet, ggf. eine andere als damals, aber die von Andreas, nicht die originäre bzw. aktuelle von Pycom. Genauer: LoPy4-1.20.2.rc6-0.10.2-vanilla-squirrel-nosmartconfig.tar.gz

Hi Clemens,

vielen Dank für Deinen Bericht. Wir müssten das Pony mal wieder striegeln und neu satteln. Pycom hat schließlich auch weitergearbeitet und das Firmware Release 1.20.2 ist mittlerweile endlich final, siehe Pycom MicroPython: Probleme mit der Uhrzeit seit Firmware-Upgrade auf 1.20.2.r2 (behoben in 1.20.2.r4) sowie Pycom Firmware Release 1.20.2.

Viele Grüße,
Andreas.

P.S.: Allerdings wäre es schön, wenn Pycom noch jenen von @robert-hh entdeckten Bug [1] beheben würde, den er per [2] u.U. bereits gefixt hatte.


  1. LFS: Core dumps on heavy file operations · Issue #518 · pycom/pycom-micropython-sigfox · GitHub ↩︎

  2. mperror.c: Move noticing of the next heartbeat transition by robert-hh · Pull Request #525 · pycom/pycom-micropython-sigfox · GitHub ↩︎

Hi @clemens,

vielen Dank, ich habe gerade mal Deep sleep does not work · Issue #88 · hiveeyes/terkin-datalogger · GitHub dazu angelegt.

Es wäre interessant zu wissen, welche Version Du damals auf dem Gerät hattest, als Du Deine Messungen veranstaltet hattest, bei denen die Werte im deepsleep noch besser waren. Können wir das rückwirkend herausfinden?

Viele Grüße,
Andreas.

Ne, kann ich leider nicht mehr nachvollziehen. Ich vermute es war der damals bei github aktuelle code.