Ich nehme an, dass ihr eine 1nce-Karte nutzt? Die Telekom bietet jetzt auch LTE-M an und 1nce ist Partner der Telekom.
Wie lange dauert denn in etwa ein erneuter Aufbau zum CAT M1-Netz mit dem FiPy nach einem Verbindungsabbruch? Woran liegen denn momentan die häufigen Reconnects? Die Sache mit dem durchgehenden Neustarten hört sich etwas problematisch an.
Danke für den Testbericht!
Hi Citrus, willkommen bei hiveeyes! Ja, wir verwenden für die ersten Gehversuche eine 1nce-SIM, die sich über den FiPy mit dem eingebauten Sequanz-Modem per LTE-M verbindet.
Das sind alles Stationen wo etwas schief gehen kann:
Die selbstgebaute FiPy-Firmware verwenden wir mit WLAN oder LoRa in diversen anderen settings, wo sie stabil läuft, diese wird das Problem alleine nicht sein. Die Sequanz-Firmware ist auf dem letzten Stand den PyCom anbietet, keine Ahnung wie gut / schlecht die ist. Statt der FiPy-Software / BOB-Hiverize haben wir auch schon den Hiveeyes Terkin-Datalogger verwendet, allerdings mit LTE NB1 und hatten ähnliche Probleme, d.h. Verbindungen, die nach einigen Stunden abbrachen.
In der aktuellen Software-Version gibt es noch kein automatisches re-connect, d.h. wir verbinden uns initial mit LTE CAT M1 und schauen im Testsetting dann wie lange das läuft. Physikalischer Empfang sollte ok sein und sich während des Test in städtischer Umgebung nicht geändert haben. Auch der Server über den wir die Datenpakete empfangen läuft störungsfrei. Da der Abbruch nicht z.B. nach exakt 24 Stunden erfolgt, oder immer zur gleichen Zeit, gehe ich erst mal nicht von einer Zwangstrennung aus, sondern von Problemen auf “unserer” Seite. Ob’s die Firmware (ESP oder Modem) oder die Software ist kann ich nicht sagen. @cedric.cfk wird bei unserer Software einen check einbauen, ob die connection noch da ist und falls nicht einen reconnect initiieren. Damit sollte es für unsere Anwendung ok sein, wenn man allerdings eine stabilere Verbindung für andere Anwendungen benötig, die länger hält, müsste man noch weitere debugging-Arbeit reinstecken.
Vielen Dank für die nette Begrüßung, @clemens!
Danke für den ausführlichen Bericht! Das hilft mir schonmal sehr weiter, falls bei mir irgendwo der Schuh mit der Datenübertragung drücken sollte, wenn ich meinen GPy mit der 1nce-Karte nutze. Ich wollte persönlich meine Messdaten jede Minute versenden. Mal schauen, ob es bei mir Probleme gibt.
In der aktuellen Software-Version gibt es noch kein automatisches re-connect, d.h. wir verbinden uns initial mit LTE CAT M1 und schauen im Testsetting dann wie lange das läuft
Okay, verstehe! Ich war schon besorgt, dass es Probleme bei softwareseitigen, erneuten Verbindungsversuchen gibt, weil das 1nce-Netz nicht mitspielt.
Der Vorschlag mit einem softwareseitigen Verbindungscheck ist eine gute Idee. Wäre da nicht lte.isattached() sinnvoll (kennt ihr sicherlich schon): LTE
Dürfte ich fragen, welches Band ihr nutzt? Ich scanne gerade mit dem GPy wild durch die Landschaft. Laut der Telekom gibt es bei mir LTE-M-Konnektivität, aber ich spüre es gerade nicht so mit dem GPy. Ich versuche mich seit 20 Minuten mit dem LTE-M-Netz über lte.attach(apn="iot.1nce.net") zu verbinden, aber es klappt leider nicht und ich sehe nur +CSQ: 99,99.
Ich überlege gerade meine Firmware zu downgraden, da ich meinen GPy nach Dezember 2019 erworben habe. Dieses Modul verfügt über neue Firmware, die man noch gar nicht auf der offiziellen Seite von Pycom runterladen kann (Kurios). Bei euch geht es ja mit der älteren Firmware und dem FiPy. Prinzipiell sollte es ja dann auch mit dem GPy funktionieren.
Meine jetzige Firmwareversion lautet LR5.1.1.0-47510.
Beim LTE-M geben wir gar kein band an(lte.attach()). Bei LTE NB1 hingegen schon da benutzen wir ebenfalls “iot.1nce.net”.
Bei der Firmware muss man gucken welche geht. Damit hatte ich auch schon Probleme.
Meine Firmwareversion, mit der es gehen sollte, ist die: 1.20.2.rc6-0.10.1-vanilla-squirrel
Und dann natürlich auch die modem Firmware auf den LTE-M betrieb anpassen.
Bei LTE CAT NBIot verwenden wir vermutlich Band 8, siehe Erschließung von LTE Cat M1 und NB1 mit dem Pycom FiPy - #35 by Andreas , dort gibt es auch ein paar code snippets zum debugging.
Einen neueren GPy, vor ein paar Wochen geliefert, habe ich auch hier aber noch nicht ausgepackt, wenn ich dir beim debuggen helfen kann, sag gerne Bescheid.
Hatte eigentlich gehofft, dass mit der von PyCom angekündigten re-callibration der neueren Geräte einiges was Richtung Stromverbrauch und Reichweite angeht besser wird, scheint aber nicht so zu sein wenn ich das von dir verlinkte posting so lese! :-(
Vielen Dank @cedric.cfk und @clemens ! Die Unterstützung freut mich sehr. Ich werde meine Gehversuche in diesem Beitrag morgen nochmal zusammenfassen, die ich bis jetzt mit einem erworbenen GPy nach Dezember 2019 unternommen habe, um eine Konnektivität zum LTE CAT M1-Netz herzustellen.
Edit 1:
Momentan liest es sich auf der offiziellen Homepage von 1nce so, dass das Band 8 speziell für NB-IoT gedacht ist [1. Verbindungsaufbau IoT/M2M]:
Aktuell unterstützt 1NCE den Funkstandard NB-IoT nur über das Netzwerk der Telekom Deutschland. Die Telekom Deutschland nutzt das LTE-Band 8 für die NB-IoT-Kommunikation.
@clemens und @cedric.cfk Ich kann mit großer Freude verkünden, dass ich gerade eben CAT-M1-Konnektivität via 1nce-SIM von meinem Heim aus mit einem re-kalibrierten GPy (erworben nach Dezember 2019) herstellen konnte. 
Anstatt lte.attach(apn="iot.1nce.net") habe ich heute morgen lte.attach() verwendet und es hat sofort geklappt. Ich habe es danach nochmal mit lte.attach(apn="iot.1nce.net") getestet und es hat ebenfalls sofort geklappt. Ich weiß nicht, ob es an meinem alten Standort lag, aber ich werde die Konnektivität nochmal am selben Standort testen. Laut der Telekom-Map dürfte es dort aber nicht am fehlenden LTE-M-Netz liegen. Persönlich fände ich es schon sehr bescheiden, wenn es einfach irgendwann mal klappt und die erste Einbuchung einfach katastrophal lange dauert. Insgesamt habe ich gestern 3 Stunden lang versucht mich am alten Standort einzubuchen und es hat einfach nicht funktioniert.
SYSTEM FSM
==========
+--------------------------+--------------------+
| FSM | STATE |
+--------------------------+--------------------+
| RRC TOP FSM |CAMPED |
| RRC SEARCH FSM |CAMPED |
| RRC ACTIVE FSM |IDLE |
| PMM PLMN FSM |NORM_CAMPED |
| EMM MAIN FSM |REGISTERED |
| EMM AUTH FSM |KASME_DEFINED |
| EMM CONN FSM |EMM_IDLE |
| EMM TAU FSM |NULL |
| EMM TEST FSM |NULL |
| ESM BEARER FSM |BEARER_ACTIVE |
| SMS MT FSM |IDLE |
| SMS MO FSM |IDLE |
| HP MAIN FSM |IDLE |
| HP USIM FSM |READY |
| HP SMS MO FSM |IDLE |
| HP SMS MT FSM |IDLE |
| HP CAT FSM |IDLE |
+--------------------------+--------------------+
OK
print(lte.send_at_cmd("AT+CSQ"))
+CSQ: 10,99
OK
Kommen wir zu den Firmware-Versionen:
import os
os.uname()
(sysname='GPy', nodename='GPy', release='1.20.2.r3', version='v1.11-d945d33ee on 2020-03-08', machine='GPy with ESP32', pybytes='1.3.1')
print(lte.send_at_cmd('AT!="showver"'))
SYSTEM VERSION
==============
FIRMWARE VERSION
Bootloader0 : 5.1.1.0 [39529]
Bootloader1* : 5.1.1.0 [47510]
Bootloader2 : NA
NV Info : 1.1,0,0
Software : 5.1.1.0 [47510] by robot-soft at 2020-01-24 08:44:21
UE : 5.0.0.0d
COMPONENTS
ZSP0 : 1.0.99-13616
ZSP1 : 1.0.99-12376
OK
Und hier nochmal alles fix zusammengefasst mit der Bibliothek sqnsupgrade:
import sqnsupgrade
sqnsupgrade.info()
<<< Welcome to the SQN3330 firmware updater [1.2.6] >>>
>>> GPy with firmware version 1.20.2.r3
Your modem is in application mode. Here is the current version:
UE5.0.0.0d
LR5.1.1.0-47510
Edit 1:
Der GPy wurde bei mouser bestellt. Eventuell ist das irgendwo interessant.
Hallo, ich wollte mich mal wieder zu Wort melden. Ich habe jetzt den GPy 10 Tage lang getestet. Die Firmwareversion meines GPy’s ist in diesem Beitrag niedergeschrieben: FiPy mit LTE CAT M1 nutzen. Meine Erfahrungen sind leider sehr ernüchternd. :(
Mein eigentliches Messsystem besteht aus einem Arduino und verschiedenen Sensoren. Ich sende einen Measurement-String über eine serielle Schnittstelle an den GPy (RX-Pin, TX-Pin). Ich setze auch 2 weitere Pins am GPy über den Arduino auf High oder Low, um dem GPy mitzuteilen, dass er gewisse Dinge tun soll. Mit dem GPy versende ich dann meine Messdaten an meine Datenbank. Momentan versorge ich den GPy über einen USB-Anschluss am PC mit Strom auf dem die Software Visual Studio Code läuft. Mit dieser Software sehe ich auch den Output des GPy’s über ein Terminal. Über das Terminal versuche ich die momentanen Fehlermeldungen zu sammeln.
Im Schnitt lief das ganze immer 3-4 Tage problemlos mit LTE-M und der SIM-Karte von 1nce bis sich dann alles aufgehangen hat…
Einmal hatte ich einen Guru Meditation Error mit (LoadProbihibted) und einmal hing er sich bei der Datenübertragung über urequests.post auf. Hier kam keine Fehlermeldung. Er hat sich lediglich aufgehangen und die Datenübertragungsschleife stand still. Gestern habe ich beobachten können, wie der GPy die Fehlermeldung Guru Meditation Error mit (LoadProhibited) ausgegeben und direkt danach die Fehlermeldung Guru Meditation Error mit (StoreProhibited) ausgespuckt hat. In diesem Fall hat sich der GPy selbst neu gestartet und sich somit wieder gefangen und ich musste ihn nicht händisch erneut starten.
Ich werde am Montag die richtigen Fehlermeldungen in diesem Post zusammentragen und auch meinen kompletten Code posten (Ich habe mich an wtf’s Vorgehensweise orientiert, um Konnektivität herzustellen Erschließung von LTE Cat M1 und NB1 mit dem Pycom FiPy. Nochmal vielen Dank für die Verlinkung @clemens!). Es tut mir Leid, dass ich meinen Debug-Output und meinen Code noch nicht poste, aber ich muss mich erstmal abkühlen nach diesem Frust…
Könnt Ihr mir einen Tipp geben, wie ihr euren Debug-Output speichert? Packt ihr eine SD-Karte in das Expansion-Board und leitet danach den Debug-Output zur SD-Karte? Ich wollte meinen Adafruit Powerboost für den GPy verwenden, um unter Realbedingungen zu testen, da ja mein Messsystem später draußen messen soll. Vielleicht kommen die Fehler ja auch zustande, da mein USB-Port manchmal nicht genug Strom liefern kann…
Etwas hacky: Im erwähnten Code von fipy-nbiot-rtd behelfe ich mir des RTC-memorys um die Fehlermeldung wegzuspeichern (bspw. Zeile 399-412, also insb. 407-408). Da der Code bei möglichst jedem Error nen Neustart triggert wird nach jedem Start erstmal in den RTC-memory geschaut um zu gucken ob da ne Fehlermeldung rumgammelt und ggf. diese dann weggeschickt und gelöscht (Zeile 376-396).
Das ist insgesamt mit etwas Vorsicht zu genießen, weil man durchs Schreiben auf diesen Speicher selbigen über die Zeit degradiert. Nen externer Speicher (SD-Karte) wär da natürlich gut um den Speicher zu schonen.
Alternativ kann man sich natürlich auch etwas ausdenken, so dass man zum Debuggen immer auch in nem WLAN hängt und dort einfach all das, was man sonst (auch) auf der Seriellen ausgibt irgendnem Host entgegen wirft, der das dann bitte wegspeichert.
Oder eben einfach schlichtweg die Ausgabe auf der Seriellen aufheben [edit: und sicherstellen, dass dort auch alle exceptions ausgegeben werden]; das Gerät für den Langzeittest an nen Computer (Raspberry o.ä.) hängen und dort nen screen (mit erhöhtem scrollback-buffer) laufen lassen in den mensch dann entspannt wann später reingucken kann.
Vielen Dank für deinen Input und danke für die Erläuterung im Bezug auf die RTC-Memory. Mir war nicht bewusst, dass du darüber die Fehlermeldung abspeicherst. Die letztere Variante hört sich für mich sehr interessant an. Im Endeffekt würde ich ja so wie vorher agieren, außer dass ich den seriellen Output über die von dir verlinkte Software screen ausgeben lasse, der wie erwähnt von dir einen höheren scrollback-buffer hat.
Für mein Vorhaben könnte ich doch den Vorschlag von MKO verwenden: USB data-only cable for debugging while on batteries
Damit meine ich folgendes: Ich versorge den GPy über den VIN-Pin mit Strom und gleichzeitig nutze ich die Pins P0 und P1, um den Debug-Output abzugreifen. Die beiden Pins werden ja normalerweise für die Programmierung des GPy genutzt laut Datenblatt, aber gleichzeitig sendet er ja auch über diesen Pin den Debug-Output, wenn ich mich nicht täusche (Also die Sachen, die ich auf meinem Terminal sehe). Ihr könnt mich da gerne korrigieren.
Welche Firmware hast du denn auf dem GPy laufen, die original von PyCom oder die squirrel oder dragonfly von Andrea?
Hallo clemens. Es handelt sich um die Original-Firmware von PyCom. Auf die Geräte von PyCom bin ich auch erst wirklich letzten Monat gestoßen, weil ich vorher mit SIMCom-Modulen versucht habe meine Daten zu übertragen (SIM800L). Ich habe demnach erst letzten Monat einen GPy erworben und wollte es erstmal mit der Original-Firmware probieren. Ich würde dann auch mal eure ausprobieren wollen. Ich bin froh, dass die Community sich so sehr dafür einsetzt die PyCom-Firmware zu verbessern, sodass die PyCom-Geräte stabiler laufen. Ich wünschte, ich hätte die Möglichkeit besser zu helfen. Ich kann euch wahrscheinlich maximal nur als Tester eurer selbstgebackten Firmware dienen. :(
Die einzige Möglichkeit, die ich dann auch noch sehe, ist, dass es eventuell an meinem Code liegt. Momentan lese ich den Measurement-String vom Arduino ähnlich wie dieser User aus: Arduino sends data seriell, how to get them into WiPy ? **SOLVED** | Pycom user forum
Meine Sorge ist hier die Thematik Heap-Fragmentation, wenn ich meine Augen auf diese Zeile werfe:
length_str += char.decode("utf-8")
Im PyCom-Forum habe ich keine Antwort bekommen, ob ich da in Gefahr laufe mir den Arbeitsspeicher im Laufe der Zeit vollzumüllen. Beim Arduino nutze ich char arrays und gehe wie in diesem Post vor: Serial Input Basics Tutorial
Ich weiß nicht, welches Prinzip man bei der Nutzung von MicroPython anwendet und ich diese Arduino-Variante einfach porten kann. Ich werde am Montag einfach mal meinen gesamten Code hier publizieren und eure Firmware nutzen. Ich denke, dass ich dann die Squirrel-Variante nutzen sollte?
Ja versuche die andere firmware erst mal, siehe Squirrel firmware for Pycom/ESP32 konkret https://packages.hiveeyes.org/hiveeyes/foss/pycom/vanilla/GPy-1.20.2.rc6-0.10.1-vanilla-squirrel.tar.gz
Ein kleines Update von mir:
Der GPy hat am 8.9.2020 gegen 10:30 Uhr angefangen Daten an meine Datenbank zu übertragen und hat die letzte Datenübertragung am 11.09.2020 um 19:32 Uhr vollzogen.
Ich konnte einen Fehler um 9:27 Uhr am 11.9.2020 ausmachen, aber er hat sich wieder gefangen:
Guru Meditation Error: Core 1 panic'ed (StoreProhibited). Exception was unhandled.
Core 1 register dump:
PC : 0x40096d25 PS : 0x00060f33 A0 : 0x800958cf A1 : 0x3ffd3590
A2 : 0x3ffd37a0 A3 : 0x00000001 A4 : 0x3ffd3798 A5 : 0x00000001
A6 : 0x000000fe A7 : 0x3ffd7c40 A8 : 0x28000045 A9 : 0x9500003e
A10 : 0x3bf1f910 A11 : 0xffffffff A12 : 0x00000001 A13 : 0x3ffd7ca0
A14 : 0x00000002 A15 : 0x3ffd7c20 SAR : 0x00000008 EXCCAUSE: 0x0000001d
EXCVADDR: 0x95000042 LBEG : 0x40091b99 LEND : 0x40091bcd LCOUNT : 0x00000000
ELF file SHA256: 0000000000000000000000000000000000000000000000000000000000000000
Backtrace: 0x40096d25:0x3ffd3590 0x400958cc:0x3ffd35b0 0x40094473:0x3ffd35d0 0x4008e2eb:0x3ffd3610 0x4008e8a5:0x3ffd3650 0x4016835d:0x3ffd3690 0x40110d55:0x3ffd36d0
Guru Meditation Error: Core 1 panic'ed (LoadProhibited). Exception was unhandled.
Core 1 register dump:
PC : 0x40096bf8 PS : 0x00060c33 A0 : 0x80096125 A1 : 0x3ffd3070
A2 : 0x3ffd30e0 A3 : 0x3ffd3090 A4 : 0x00000040 A5 : 0x3ffc4124
A6 : 0x0000003b A7 : 0x3ffbf370 A8 : 0x00000000 A9 : 0xe67ec000
A10 : 0x3ffd34d0 A11 : 0x3ffc412c A12 : 0xe67ec000 A13 : 0x40083204
A14 : 0x3bf1f910 A15 : 0xffffffff SAR : 0x0000000a EXCCAUSE: 0x0000001c
EXCVADDR: 0xe67ec00c LBEG : 0x40092298 LEND : 0x400922a3 LCOUNT : 0x00000000
ELF file SHA256: 0000000000000000000000000000000000000000000000000000000000000000
Backtrace: 0x40096bf8:0x3ffd3070 0x40096122:0x3ffd3090 0x4008f7bd:0x3ffd30c0 0x4008f557:0x3ffd30e0 0x4008f6dd:0x3ffd3430 0x4008f50a:0x3ffd3450 0x4008f102:0x3ffd3490 0x4008f352:0x3ffd34b0 0x4008324e:0x3ffd34d0 0x40096d22:0x3ffd3590 0x400958cc:0x3ffd35b0 0x40094473:0x3ffd35d0 0x4008e2eb:0x3ffd3610 0x4008e8a5:0x3ffd3650 0x4016835d:0x3ffd3690 0x40110d55:0x3ffd36d0
Re-entered core dump! Exception happened during core dump!
Rebooting...
ets Jun 8 2016 00:22:57
rst:0xc (SW_CPU_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff8020,len:8
load:0x3fff8028,len:2140
ho 0 tail 12 room 4
load:0x4009fa00,len:19740
entry 0x400a05bc
Smart Provisioning started in the background
See https://docs.pycom.io/smart for details
[LTE] object created.
[LTE] initialized
[LTE] attached
[LTE] connected
[RTC] synced
Arduino RTC was set!
Ich habe mir den GPy heute mal angeschaut und es gab keine Fehlermeldung im Output des Terminals. Der GPy hat einfach keinen blauen Herzschlag gemacht und seinen Dienst verweigert nach der letzten erfolgreichen Üertragung.
Ich versorge den GPy über eine USB-Verbindung am PC mit Strom, um auch ganz bequem den Terminal-Output lesen zu können. Nachdem ich das USB-Kabel einfach wieder angesteckt habe, lief er wieder. Ich nehme an, dass der GPy zu einem gewissen Zeitpunkt nicht mehr mit genügend Strom über die USB-Verbindung versorgt werden konnte und deshalb einfach ausfiel… D. h. für mich, dass zum Debuggen eine Alternative für mich her muss was die Stromversorgung angeht, während ich den Debug-Output irgendwo anders abspeichere.
Edit:
Gerade eben hatte ich auch wieder einen Guru Meditation Error, aber auch hier ist der GPy wieder von alleine gestartet, jedoch konnte nach dem Neustart keine Verbindung zum Modem hergestellt werden:
Guru Meditation Error: Core 1 panic'ed (StoreProhibited). Exception was unhandled.
Core 1 register dump:
PC : 0x40096d1d PS : 0x00060f33 A0 : 0x800958cf A1 : 0x3ffd3590
A2 : 0x3ffd37a0 A3 : 0x00000001 A4 : 0x3ffd3798 A5 : 0x00000001
A6 : 0x000000fe A7 : 0x3ffd7c40 A8 : 0x00280000 A9 : 0x3f000038
A10 : 0xa9f1f910 A11 : 0xffffffff A12 : 0x00000001 A13 : 0x3ffd7ca0
A14 : 0x00000002 A15 : 0x3ffd7c20 SAR : 0x00000018 EXCCAUSE: 0x0000001d
EXCVADDR: 0xa9f1f918 LBEG : 0x40091b99 LEND : 0x40091bcd LCOUNT : 0x00000000
ELF file SHA256: 0000000000000000000000000000000000000000000000000000000000000000
Backtrace: 0x40096d1d:0x3ffd3590 0x400958cc:0x3ffd35b0 0x40094473:0x3ffd35d0 0x4008e2eb:0x3ffd3610 0x4008e8a5:0x3ffd3650 0x4016835d:0x3ffd3690 0x40110d55:0x3ffd36d0
Guru Meditation Error: Core 1 panic'ed (LoadProhibited). Exception was unhandled.
Core 1 register dump:
PC : 0x40096bda PS : 0x00060c33 A0 : 0x80096125 A1 : 0x3ffd3070
A2 : 0x3ffd30e0 A3 : 0x3ffd3090 A4 : 0x00000040 A5 : 0x3ffc4124
A6 : 0x0000003b A7 : 0x3ffbf370 A8 : 0xa9f1f910 A9 : 0x3ffd34b0
A10 : 0x3ffd34d0 A11 : 0x3ffc412c A12 : 0x00000027 A13 : 0x40083204
A14 : 0xa9f1f910 A15 : 0xffffffff SAR : 0x0000000a EXCCAUSE: 0x0000001c
EXCVADDR: 0xa9f1f91c LBEG : 0x40092298 LEND : 0x400922a3 LCOUNT : 0x00000000
ELF file SHA256: 0000000000000000000000000000000000000000000000000000000000000000
Backtrace: 0x40096bda:0x3ffd3070 0x40096122:0x3ffd3090 0x4008f7bd:0x3ffd30c0 0x4008f557:0x3ffd30e0 0x4008f6dd:0x3ffd3430 0x4008f50a:0x3ffd3450 0x4008f102:0x3ffd3490 0x4008f352:0x3ffd34b0 0x4008324e:0x3ffd34d0 0x40096d1a:0x3ffd3590 0x400958cc:0x3ffd35b0 0x40094473:0x3ffd35d0 0x4008e2eb:0x3ffd3610 0x4008e8a5:0x3ffd3650 0x4016835d:0x3ffd3690 0x40110d55:0x3ffd36d0
Re-entered core dump! Exception happened during core dump!
Rebooting...
ets Jun 8 2016 00:22:57
rst:0xc (SW_CPU_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff8020,len:8
load:0x3fff8028,len:2140
ho 0 tail 12 room 4
load:0x4009fa00,len:19740
entry 0x400a05bc
Smart Provisioning started in the background
See https://docs.pycom.io/smart for details
Traceback (most recent call last):
File "main.py", line 63, in <module>
OSError: Couldn't connect to Modem!
Pycom MicroPython 1.20.2.r3 [v1.11-d945d33ee] on 2020-03-08; GPy with ESP32
Pybytes Version: 1.3.1
Type "help()" for more information.
Ich habe mir einen zweiten GPy gekauft und werde die empfohlene Firmware von clemens auf den zweiten GPy spielen:
Des Weiteren werde ich mich um das Stromversorgungsproblem kümmern. Ich halte euch auf dem Laufenden, wie sich ein GPy mit der folgenden Firmware verhält:
Eventuell ganz interessant, was die Thematik angeht. Der user kjm meinte folgendes im Pycom-Forum:
We’re running brief data uploads through cat M1 on a gpy with deepsleep. Have been mercifully free of crashes for a year now with 1.20.1.r1/littleFS on the gpy & 41065 on the modem.
Der Global Moderator Gijs meinte dann darauf:
The 41065 modem firmware does seem to be a little ‘more better’ than the 47510 version. As the coredump does indeed seem to be related to the LTE modem UART connection. Thanks for the addition @kjm!
Die Verlinkung zu dem Thread:
Der Fragesteller hat ebenfalls einen neuen GPy mit der aktuellsten Modem-Firmware verwendet. Also bin ich nicht alleine mit meinem Problem, was die aktuellen factory firmwares angeht.
Ich werde auch noch versuchen, dass folgende Tutorial anzuwenden, damit ich Pycom die benötigten Informationen zu den coredumps geben kann: Troubleshooting Coredumps
Im gleichen Thread ist der Global Moderator Gijs auf die Methode eingegangen.
PS.
Ich habe nun endlich die Squirrel-Firmware und die ältere Modem-Firmware installiert. Ich bin gespannt. Nochmal vielen Dank für die Verlinkungen!
Mit der Installation der Modem-Firmware über die SD-Karte wollte es erst nicht klappen bis ich ein anderes Expansionboard (v3.1) genommen habe. Er mochte sd = SD() nicht… Ich denke, dass somit der SD-Kartenslot am Expansionboard irgendwo Probleme macht (Es handelt sich ebenfalls um die v3.1-Version und ein 2 Monate altes Expansionboard). Sehr ärgerlich.
from machine import SD
sd = SD()
Hallo, ich wollte meine derzeitigen Erkenntnisse und Erfahrungen mitteilen bei minütlichen Übertragungen von Daten.
Das Stromproblem scheint beseitigt zu sein. Ich habe keine weiteren Ausfälle mehr mitbekommen, bei denen der blaue Herzschlag (Heartbeat) des GPy ausgefallen ist und es keine Fehlermeldung gab. Momentan besuchen mich nur die Gurus…
Der GPy nutzt die folgende FW:
os.uname()
(sysname='GPy', nodename='GPy', release='1.20.2.rc6-0.10.1-vanilla-squirrel', version='v1.20.1.r2-120-g201315f4a-dirty on 2020-03-02', machine='GPy with ESP32')
Und die folgende FW für das Modem:
sqnsupgrade.info()
Welcome to the SQN3330 firmware updater [1.2.6] >>>
GPy with firmware version 1.20.2.rc6-0.10.1-vanilla-squirrel
Your modem is in application mode. Here is the current version:
UE5.0.0.0d
LR5.1.1.0-41065
Für das Debugging nutze ich momentan Putty und einen USB to TTL-Adapter, der mir über die Pins P0 und P1 den Debugging-Output auf meinen Rechner überträgt (Coole Anleitung von MKO!).
Der GPy lief jetzt 1,5 Tage erfolgreich bis er wieder einen Guru Mediation Error erlitt von dem er sich nicht erholen konnte. Leider wurde mir hier nicht der gesamte Output ausgegeben. Ich habe schon des Öfteren gesehen, dass bei diesen “Guru Meditation Error”-Meldungen manchmal die Hälfte fehlt. Das heißt, wieder anschmeißen und hoffen, dass die nächste Fehlermeldung komplett kommt…
Es hat den Core 0 betroffen und nur das wurde mir angezeigt:
Guru Meditation Error: Core 0 panic'ed (
Dafür gab es in diesen 1,5 Tagen 11 Guru-Fehler von denen sich der GPy aber wieder selbstständig erholt hat, aber nur Core 1 betroffen haben. Für diese liegen mir die vollständigen coredumps vor. Ich finde das Verhalten sehr zufällig, da kein klarer Zeitintervall erkennbar ist, nachdem es passiert. Es lagen nach 18 Stunden Laufzeit urplötzlich z. B. innerhalb einer Stunde 4 Guru-Fehler vor! Dann gab es 8 Stunden später wieder einen und davor lagen auch einige Stunden zwischen den Guru-Fehlern.
Die Guru-Fehler traten immer nach erfolgreichen Datenübertragungen auf:
Status code: 200
POST-request OK
Guru Meditation Error: Core 1 panic'ed (StoreProhibited). Exception was unhandled.
Core 1 register dump:
PC : 0x40096fe5 PS : 0x00060f33 A0 : 0x80095b97 A1 : 0x3ffd3610
A2 : 0x3ffd3820 A3 : 0x00000001 A4 : 0x3ffd3818 A5 : 0x00000001
A6 : 0x000000fe A7 : 0x3ffd7cc0 A8 : 0x28000045 A9 : 0x38000038
A10 : 0x9cf1f910 A11 : 0xffffffff A12 : 0x00000001 A13 : 0x3ffd7d20
A14 : 0x00000002 A15 : 0x3ffd7ca0 SAR : 0x00000010 EXCCAUSE: 0x0000001d
EXCVADDR: 0x9cf1f918 LBEG : 0x40091e25 LEND : 0x40091e59 LCOUNT : 0x00000000
ELF file SHA256: 0000000000000000000000000000000000000000000000000000000000000000
Backtrace: 0x40096fe5:0x3ffd3610 0x40095b94:0x3ffd3630 0x400946ff:0x3ffd3650 0x4008e42b:0x3ffd3690 0x4008e9e5:0x3ffd36d0 0x4016a771:0x3ffd3710 0x40110fcd:0x3ffd3750
Guru Meditation Error: Core 1 panic'ed (LoadProhibited). Exception was unhandled.
Core 1 register dump:
PC : 0x40096ea2 PS : 0x00060c33 A0 : 0x800963ed A1 : 0x3ffd30f0
A2 : 0x3ffd3160 A3 : 0x3ffd3110 A4 : 0x00000040 A5 : 0x3ffc4144
A6 : 0x0000003b A7 : 0x3ffbf370 A8 : 0x9cf1f910 A9 : 0x3ffd3530
A10 : 0x3ffd3550 A11 : 0x3ffc414c A12 : 0x00000027 A13 : 0x40083214
A14 : 0x9cf1f910 A15 : 0xffffffff SAR : 0x0000000a EXCCAUSE: 0x0000001c
EXCVADDR: 0x9cf1f91c LBEG : 0x40092524 LEND : 0x4009252f LCOUNT : 0x00000000
ELF file SHA256: 0000000000000000000000000000000000000000000000000000000000000000
Backtrace: 0x40096ea2:0x3ffd30f0 0x400963ea:0x3ffd3110 0x4008f8fd:0x3ffd3140 0x4008f697:0x3ffd3160 0x4008f81d:0x3ffd34b0 0x4008f64a:0x3ffd34d0 0x4008f242:0x3ffd3510 0x4008f492:0x3ffd3530 0x4008325e:0x3ffd3550 0x40096fe2:0x3ffd3610 0x40095b94:0x3ffd3630 0x400946ff:0x3ffd3650 0x4008e42b:0x3ffd3690 0x4008e9e5:0x3ffd36d0 0x4016a771:0x3ffd3710 0x40110fcd:0x3ffd3750
Re-entered core dump! Exception happened during core dump!
Rebooting...
Für den ersten Backtrace unter StoreProhibited bekomme ich:
xtensa-esp32-elf-addr2line.exe -fe .\GPy-1.20.2.r1-application.elf 0x40096fe5:0x3ffd3610 0x40095b94:0x3ffd3630 0x400946ff:0x3ffd3650 0x4008e42b:0x3ffd3690 0x4008e9e5:0x3ffd36d0 0x4016a771:0x3ffd3710 0x40110fcd:0x3ffd3750 multi_heap_malloc_impl
/Users/ehlers/pycom/pycom-esp-idf/components/heap/multi_heap.c:438
xTaskRemoveFromUnorderedEventList
/Users/ehlers/pycom/pycom-esp-idf/components/freertos/tasks.c:3189
prvInitialiseNewTask
/Users/ehlers/pycom/pycom-esp-idf/components/freertos/tasks.c:959
prvReceiveGenericFromISR
/Users/ehlers/pycom/pycom-esp-idf/components/esp_ringbuf/ringbuf.c:632
vRingbufferDelete
/Users/ehlers/pycom/pycom-esp-idf/components/esp_ringbuf/ringbuf.c:1021
esp_event_set_default_wifi_handlers
/Users/ehlers/pycom/pycom-esp-idf/components/esp32/event_default_handlers.c:470
TASK_LTE
/var/jenkins_home/workspace/micropython-sigfox_Release_v1.20/esp32/lte/lteppp.c:447
Und für den zweiten Backtrace unter LoadProhibited:
xtensa-esp32-elf-addr2line.exe -fe .\GPy-1.20.2.r1-application.elf 0x40096ea2:0x3ffd30f0 0x400963ea:0x3ffd3110 0x4008f8fd:0x3ffd3140 0x4008f697:0x3ffd3160 0x4008f81d:0x3ffd34b0 0x4008f64a:0x3ffd34d0 0x4008f242:0x3ffd3510 0x4008f492:0x3ffd3530 0x4008325e:0x3ffd3550 0x40096fe2:0x3ffd3610 0x40095b94:0x3ffd3630 0x400946ff:0x3ffd3650 0x4008e42b:0x3ffd3690 0x4008e9e5:0x3ffd36d0 0x4016a771:0x3ffd3710 0x40110fcd:0x3ffd3750 split_if_necessary
/Users/ehlers/pycom/pycom-esp-idf/components/heap/multi_heap.c:311
prvSampleTimeNow
/Users/ehlers/pycom/pycom-esp-idf/components/freertos/timers.c:648
BT_tx_if_init
??:?
esp_core_dump_write_binary
/Users/ehlers/pycom/pycom-esp-idf/components/espcoredump/src/core_dump_common.c:114
xPortGetCoreID
/Users/ehlers/pycom/pycom-esp-idf/components/freertos/include/freertos/portable.h:210
esp_core_dump_write_binary
/Users/ehlers/pycom/pycom-esp-idf/components/espcoredump/src/core_dump_common.c:82
panicHandler
/Users/ehlers/pycom/pycom-esp-idf/components/esp32/panic.c:309
esp_core_dump_to_uart
/Users/ehlers/pycom/pycom-esp-idf/components/espcoredump/src/core_dump_uart.c:103
_xt_user_exc
/Users/ehlers/pycom/pycom-esp-idf/components/freertos/xtensa_vectors.S:768
multi_heap_malloc_impl
/Users/ehlers/pycom/pycom-esp-idf/components/heap/multi_heap.c:438
xTaskRemoveFromUnorderedEventList
/Users/ehlers/pycom/pycom-esp-idf/components/freertos/tasks.c:3189
prvInitialiseNewTask
/Users/ehlers/pycom/pycom-esp-idf/components/freertos/tasks.c:959
prvReceiveGenericFromISR
/Users/ehlers/pycom/pycom-esp-idf/components/esp_ringbuf/ringbuf.c:632
vRingbufferDelete
/Users/ehlers/pycom/pycom-esp-idf/components/esp_ringbuf/ringbuf.c:1021
esp_event_set_default_wifi_handlers
/Users/ehlers/pycom/pycom-esp-idf/components/esp32/event_default_handlers.c:470
TASK_LTE
/var/jenkins_home/workspace/micropython-sigfox_Release_v1.20/esp32/lte/lteppp.c:447
Ich sehe da UART und LTE und verweise wieder auf diesen Thread:
Ich denke, ich werde einfach einen externen Watchdog nehmen, um das Problem irgendwie halbwegs gelöst zu bekommen bis Pycom genug Bugreports gesammelt hat, um das Problem zu lösen:
Mit einem externen Watchdog scheint sich das Problem gelöst zu haben. Ich sende jetzt seit 2.5 Tagen erfolgreich meine Daten an eine Datenbank ohne Unterbrechung, was mir vorher größtenteils nie gelang. Mit einem Arduino setze ich einfach immer den Reset-Pin am GPy low, falls dieser in einer gewissen Zeit sich nicht mehr bemerkbar macht (z. B. einen GPIO am GPy zwischen HIGH und LOW togglen und den Arduino das abhören lassen)
Der robertHH aus dem Pycom-Forum nutzt einen ATTiny als Watchdog für Pycom-Module:
https://github.com/robert-hh/ATTiny-Watchdog-for-MicroPython
Ein externer Reset mit einen zweiten Microcontroller kann zwar ein workaround sein, toll ist das natürlich nicht. Hast du den (internen) watchdog aktiviert?
Ich habe im Pycom-Forum gelesen, dass der interne Watchdog nicht so toll sein soll. Ich vertraue da besonders auf roberthh’s Aussage dahingehend und will mir einfach den Frust ersparen (Ich bin aber auch offen für andere Erfahrungen). Optimal ist es natürlich nicht, aber ich habe mich jetzt zu genüge mit dem GPy und dem Modem rumgeärgert und der Arduino ist sowieso fester Bestandteil meines Projekts.
Nichtsdestotrotz werde ich die Community-Firmwares für die Pycom-Geräte gerne weiterhin testen. Es freut mich, dass sich die Community da engagiert und ich hoffe, dass Pycom irgendwann mal Fortschritte macht, was die Modem-Firmware angeht. Die ganze Situation ist wirklich sehr ernüchternd und schade.
Danke für den Hinweis bezüglich des internen Watchdogs!