Deep sleep funktioniert in aktueller 2020/09 hiveeyes Terkin-Software nicht

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?

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 funktionier, wir waren doch schon bei 50 uA (sogar mit dem stromhunrigen FiPy!) im deep sleep, da muss sich mit weiteren code-Modifikationen seit damals wieder ein bug eingeschlichen haben, @didilamken! Oder ein komisches Verhalten im Zusammenhang mit dem LoPy statt des FiPys, ich dachte ich hätten den LoPy aber auch schon mal gemessen und bin auf um die 20 uA gekommen. Also irgendeine software regression seit dem Zeitpunkt wo es funktioniert hat!!

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