So, die (wieder) Einrichtung der Terkin Sandbox war erfolgreich und es konnte schon etwas weitergehen. Auch wenn ich noch mit dem Upload meiner Änderungen auf den Lopy kämpfe.
Ich habe bis jetzt versucht den Aufruf für den Pytrack Deepsleep per py.go_to_sleep() an verschiedenen Stellen einzufügen. Scheinbar gibt es dazu aber ein Problem mit dem I2C Bus über den der Lopy mit dem Pytrack kommuniziert. Der Pytrack nutzt dafür die Pins scl=P21 und sda=P22. Das Ergebnis ist jetzt immer ein I2C bus error:
Das hier habe ich bisher benutzt:
# Pytrack deepsleep
# Initialize the hardware driver.
try:
from terkin.lib.pytrack import Pytrack
py = Pytrack()
except Exception as ex:
log.exc(ex, 'Pytrack hardware driver failed')
raise
py.setup_sleep(int(interval * 1000))
log.info('Pytrack entering deepsleep for {} seconds'.format(interval))
py.go_to_sleep()
Die Funktion zum power_on/off und die Registrierung für den I2C in Terkin habe ich noch nicht durchschaut um ehrlich zu sein. Ich dachte auch schon, dass es eine Rolle spielen könnte, ob ich in der settings.py den zweiten I2C Busscan an- oder ausschalte. Das hat aber auch keine Veränderung gebracht.
das ist schonmal ordentlich, dass Du so weit gekommen bist – exzellent! Ich freue mich sehr, dass Du Dich hier eingearbeitet hast und @tonke vielleicht auch – ihm ist es zu verdanken, dass wir den Pytrack bereits etwas erschlossen haben, v.a. um das GPS Modul auszulesen.
Vom Fleck weg kann ich jetzt aus der Ferne zwar nicht sagen, was hier genau schief geht. Allerdings habe ich mitbekommen, dass Pycom am Support für den Pytrack weitergearbeitet hat und auch den entsprechenden Software-Support in Form der pycoproc.py weiterentwickelt hat. Momentan wird per “make download-requirements-ratrack” an dieser Stelle noch eine ältere Variante angezogen:
Die aktuellen Implementierungen finden sich bei [1,2], weitere Details dazu kenne ich aber auch nicht. Vielleicht helfen Dir für entsprechende archäologische Arbeiten Dinge wie [3], [4] oder Inhalte im Pycom Forum via Pycom Forum » Search for “pytrack” weiter.
Soweit ich es mitbekommen habe, gibt es mittlerweile mindestens zwei Hardware-Revisionen (Pytrack 1.0 vs. 2.0) und manchmal kann auch ein Firmware-Upgrade weiterhelfen. Dafür will ich jedoch keine Verantwortung übernehmen, möglicherweise hat dies bei früheren Varianten zu einem “device bricking” geführt – vielleicht lag es aber auch nur am Kabel.
@tonke hatte den Pytrack im Rahmen seines Ratrack Vorhabens damals folgendermaßen in den Einstellungen registriert. Es fällt auf, dass dort "enabled": False steht. Vielleicht hilft auch das weiter?
Bei der Erschließung des Pytrack ging es uns damals also primär um die Nutzung der L76GNSS und LIS2HH12 Module als Sensoren. Also würde ich sagen, lass Dich davon nicht ablenken, wenn es Dir nun um die Erschließung des Deepsleep-Modus geht. Ergo registriere den I2C Bus auf P22/P21 lieber nicht per Terkin-Konfiguration, sonst kommt da u.U. irgendetwas in die Quere.
Sobald die Basisfunktionalität steht, können wir immer noch (später) schauen, wie die Integration optimiert werden kann.
Ansonsten kann ich u.U. dazu raten, die Erschließung des Deepsleep-Modus des Pytrack erst einmal komplett ohne Terkin anzugehen und stattdessen ein ganz einfaches MicroPython-Programm zu verwenden, das nur (die passende aktuellste) pycoproc.py verwendet. So sparst Du Dir erstmal jeglichen Overhead den Du mit Terkin hast und kannst Dir hernach (hoffentlich!) sicher sein, dass die Hardware mit der richtigen Software auf jeden Fall erstmal das tut, was Du Dir wünschst.
Danach können wir dann gemeinsam weiterschauen, was u.U. im Kontext von Terkin schiefgeht.
Das habe ich bereits gemacht, da klappt das alles mit dem Minimal Example von Pycom zum Sleep des Pytrack. Damit lässt sich der Pytrack wie beschrieben ansteuern und schlafen legen. Die Firmware des Pytrack habe ich auch noch mal zur Sicherheit geupdated (war aber schon aktuell).
Tatsächlich habe ich mir sowas auch schon gedacht und das in den settings auf False gesetzt.
Ich versuchs mal weiter heute Abend. Noch mal Danke für die Hilfe bis hier hin
VG,
Jan
Im Gegensatz dazu wird bei Terkin ja bisher noch der folgende Treiber verwendet, vielleicht ist dieser nicht mehr mit der aktuellen Hardware [1] kompatibel?
Möglicherweise liegt es an Unterschieden in diesem Bereich?
Jep, ich habe mir die aktuelle pycoproc_1.py geladen.
Ich habe einen Pytrack 1.0, daher auch die pycoproc_1.py
Was schon funktioniert hat in Terkin ist das Auslesen den Firmwareversion des Pytrack mit py.read_fw_version() ganz am Anfang beim Start des Datenloggers. Also noch bevor die Buses angegangen werden. Meine Vermutung ist gerade, dass der Pytrack ebenfalls versucht als I2C Master zu fungieren nachdem das schon der SensorManager versucht.
All right. Vielleicht ist die von Terkin verwendete Version pycoproc.py trotzdem zu alt? Es gab ja schließlich auch ein Firmware-Upgrade für die 1.0er Variante? Versuche doch einmal, die aktuelle pycoproc_1.py manuell als pycoproc.py ins ./dist-packages Verzeichnis zu legen.
Ich verstehe jetzt zwar nicht 100%ig, was Du genau meinst, würde jedoch empfehlen, in Deinem Fall die Registrierung des Pytrack komplett aus der Terkin-Konfiguration herauszunehmen. Sobald P22/P21 dort als regulärer I2C-Bus eingetragen ist, wird ja durch den SensorManager bereits ein I2C Objekt initialisiert. Vielleicht kommt das dann in die Quere, wenn es pycoproc.py abermals versucht.
Hm, also ich bin mir sicher, dass ich bei mir die aktuelle von Pycom eingebunden habe. Beim Crosscompile wird bei mir auch von Terkin aus gar keine pycoproc.mpy erzeugt/geladen. Ich habe die erstmal per Hand in /lib/terkin/lib/ abgelegt und importiere die auch von diesem Pfad. In dist-packages ist auch keine pycoproc vorhanden.
Achso, ich meinte, wer von den beiden (Pytrack Lopy) als Master definiert ist. Ich gehe bisher davon aus, dass der Lopy dabei der Master ist und den Pytrack als Slave anspricht. Aus der Terkin Registrierung habe ich das komplett rausgenommen, aber leider noch keinen Erfolg mit dem Deepsleep des Pytrack gehabt. Ich habe erstmal alle Sensoren deaktiviert und alle Busse ebenfalls. Dabei bin ich dann noch darüber gestolpert, dass der HX711 ja auch auf den Pins P21/22 liegt. Spätestens beim Deaktivieren des HX711 sollte das ja aber kein Problem mehr sein. Das hat nur teilweise Erfolg gebracht.
Zusätzlich habe ich die Bus-Nummer in der pycoproc wahlweise auf 1 oder sogar 2 gestellt. Hier ein Auszug aus der pycoproc.py:
Ich habe damit zwar keinen I2C Bus Error mehr, aber entweder stürzt der Lopy ab oder es gibt ein paar Fehlermeldungen/Restart:
Zwei weitere Erkenntnisse:
Der Deepsleep des Pytrack schaltet die Stromversorgung für den Lopy ab. Der Deepsleep vom Pytrack ist also endgültig und nicht wie vorher gedacht zusätzlich zum Deepsleep des Lopy. Der Stromverbrauch im Deepsleep durch den Pytrack beträgt ca. 17 uA (gemessen).
Der Deepsleep des Pytrack lässt sich in Terkin aktivieren, wenn dies vor TerkinDatalogger.read_sensors() erfolgt (datalogger.py). Erfolgt der Aufruf py.go_to_sleep() erst danach, so kommt zum Absturz des Lopy. Dabei scheint es egal zu sein, ob die Sensoren oder Busse aktiviert oder deaktiviert sind.
Zumindest habe ich das Problem schon ein wenig weiter eingegrenzt.
Ah, all right. Danke für die Klarstellung. Ja, das ergibt Sinn, weil die pycoproc.py glaub ich erst per make install-ratrack eingebracht wird - das ist eine Variante spezifisch zu Gerät- und Hardwarezenario. Ein ähnliches make target werden wir dann für Dein Szenario auch einführen.
Ja so ist es. Sorry, ich dachte das war Dir klar. Aber – genauso klar und absolut verständlch – man muss sich natürlich erst in das Ökosystem ein wenig einarbeiten, damit man versteht, welche Funktionalität wie genau vorgesehen ist und wie man am besten jeweils damit umgeht. Bei uns war es – gerade am Anfang – auch ein wenig holprig.
Das ist das Grandiose an dieser Variante [1]. Da kommt der “soft”-deepsleep des *Py-Moduls selber niemals in ähnliche Größenordnungen.
Dazu habe ich eine Idee: Hast Du in der Terkin-Konfiguration "deepsleep": True gesetzt? Falls das nämlich so ist, fährt Terkin nach dem Auslesen der Sensoren erst die Sensordomäne runter, damit diese im “soft”-deepsleep Modus möglichst wenig Strom verbraucht. In Deinem Fall wäre das nicht gewünscht, weil wir in Deinem Szenario “hard”-deepsleep anpeilen.
Deine Logmeldungen “Turning off...” sowie “Shutting down...” weisen in der Tat darauf hin, dass hier erst die Sensordomäne stillgelegt wird. u.U. geht es deswegen in die Hose.
Oh! Ich bin mir nicht sicher, ob das gutgehen kann.
Davon würde ich jetzt so pauschal nicht ausgehen. @weef oder @roh können dazu bestimmt etwas berichten.
Konkret auf Dein aktuelles Szenario bezogen (und aus Deinen Berichten und Log-Auszügen gefolgert [2]), ist es – selbst wenn es grundsätzlich ginge – bestimmt problematisch, wenn – vermutlich – kurz vorher der HX711 power-mäßig deaktiviert wird (und der auf den gleichen Pins liegt), weil der SensorManager Dir damit kurz vor dem Kommunikationsversuch per Bus-Objekt, auf dem der HX711 registriert ist, die Füße unter dem Boden wegzieht. Also: Am besten (erstmal) in der Terkin-Konfiguration keinerlei Sleep-Modi konfigurieren.
Das ist bestimmt keine schlechte Idee, um die Domänen (Terkin-Sensormanager vs. “Standalone”-Pycoproc) erst einmal unabhängig voneinander zu halten. Sobald die Tests damit erfolgreich sind, können wir uns in der Folge um eine “ordentliche” Integration kümmern.
Teile diese zukünftig gerne in ASCII statt mit Screenshots, falls möglich. Dann lässt sich besser damit arbeiten und z.B. auch Textinhalte daraus zitieren etc. pepe. Danke! ↩︎
Oh und ich sehe gerade, dass es noch eine Konfigurationseinstellung “power_toggle_sensors” gibt.
Beide sind per default auf “True”, d.h. sie sollten in Deinem Szenario (erst einmal) explizit auf False gesetzt werden [1]. Bitte stelle es also bei Dir einstweilen folgendermaßen ein:
Ich habe gerade erst gesehen, dass die Einstellung “power_toggle_sensors” leider nirgends in einer example.settings.py-Datei dokumentiert ist. Das tut mir leid, das ist natürlich ein großer faux pas von Terkin. Ich hole gleich nach, das auch in die Beispielkonfigurationen einzubringen. ↩︎
Hey Andreas, danke noch mal für deine Unterstützung bis hier! Gestern (Nacht) habe ich das Problem mit dem Pytrack Deepsleep offensichtlich gelöst und dir Ursache für das komische Verhalten gefunden! In datalogger.py macht TerkinDatalogger.read_sensors() nach dem Auslesen des HX711 folgendes:
Das läuft dann letztendlich in der hx711.py hierauf hinaus:
Dabei sind die letzten zwei Zeilen wohl die Ursache, dass P21 und P22 nicht mehr als Bus zu gebrauchen sind nach diesem dauerhaften “power down”. Das killt einfach diese Pins für die serielle Kommunikation.
Meine Lösung war jetzt, dass ich die Funktion sensor.power_off() in der datalogger.py auskommentiert habe. Damit läuft jetzt der Deepsleep über den Pytrack und entzieht dem Lopy die Stromversorgung. Ich kann auch alle anderen Funktionen wie power_toggle_buses oder power_toggle_sensors aktiviert lassen.
Das Ganze lassen ist jetzt erstmal bei mir zu Hause etwas laufen und beobachte. Bisher scheint aber alles wie gewohnt zu funktionieren.
Super dass Du diese Stelle finden und das Problem lösen konntest. Hier fehlt wohl eine Prüfung auf power_toggle_sensors == True?
Bzw. - wenn ichs mir recht überlege - sollte self.pSCK.hold(True) wohl besser in der Busdomäne untergebracht werden, so dass es an power_toggle_buses == True hängt.
Ich habe den Timer Interrupt des Pytrack mit der gleichen Variable interval konfiguriert wie auch der normale Terkin Deepsleep es macht. Mein Testcode sieht so aus:
log.info(‘Pytrack entering deepsleep for {} seconds’.format(interval))
'# Pytrack Test
py = Pytrack()
py.setup_sleep(int(interval))
log.info(‘Bye bye…’)
py.go_to_sleep()
Das Letzte was in der REPL dann zu sehen ist ist die Zeile Pytrack entering deepsleep for {} seconds. Der Satz Bye bye... kommt schon nicht mehr in der Ausgabe an, keine Ahnung warum das nicht mehr ausgegeben wird bevor der Pytrack die USB-Verbindung aufgibt.
Das Ganze Läuft schon 24 Std. bisher ohne Probleme.
Eigentlich sollte das nur die Uhr für den Sleep einstellen. In den Examples von Pycom folgt dann immer noch py.go_to_sleep(). Naja, nicht ganz so wichtig im Moment.
Hier noch mal eine kurze Rückmeldung zum ersten Feldversuch mit dem Deepsleep des Pytrack mit der BOB V5a Platine. Mit einem 4400 mAh Akku läuft mein Setup mit Lora und einem Sendeintervall von 20 Min. jetzt bereits seit 16 Tagen stabil. Rechnerisch sollten noch weiter 5-6 Tage sicher drin sein denke ich. Das war also bis jetzt ein guter Erfolg für die Laufzeit meines Setups.
Der nächste Schritt wäre nun, das Ganze mit einem Solarmodul zu betreiben. Vom Gefühl her sollte das zumindest im Sommer “wartungsfrei” sein.
