@kjm I never worked with Gpy, but with LoPys the speed of the firmware is nearly the same. What changed are the windows when the i2c module is ready to communicate. So you can start some i2c stuff before the whole system was completly initialized. But these windows/frames moved between firmware versions and became larger or smaler. So it was not reliable to use them. Maybe pycom moved some of their internal i2c stuff into more reliable regions. I do not recommend to stay on older firmware versions and optimise the timings for them. The ESP32 and the IDF cause too many problems. IMHO pycom is on the development branch too far behind the actual IDF version. If you have huge scripts, you can save some time by using precompiled or frozen modules. If you have some complicated stuff to do, you can do this before the Modem is ready. Yes, fast boot times will be fine, but I preferre signals, callback or variables which tell me, if the hardware is ready to use. I wasted too many time to find windows inbetween init states :)

@rfinkers the Pymesh Docs page is under that link : https://docs.pycom.io/firmwareapi/pycom/network/lora/pymesh.html , it will be updated shortly with the Border router documentation.

@steve-williams , I did some power mesurements here on the same setup I mentioned in my previous post to give you a clear picture about the current consumption while the modem is trying to attach so as to help you identifying the problem , in first trial I intentionally powered off the CAT-M1 network in office and run a script on GPY trying to attach you can see that the modem current consumption increases after sending attach request and keep trying to attach periodically, you can see that the Avg.current consumption when trying to attach can reach 285mA (150mA more than normal). The following image is when CAT-M1 network is back online and attaching is successful :

@paul-thornton Sorry Paul, I never saw your reply until today. Unfortunately our load is pretty complicated; we have one thread for each I2C bus we configure (1 or 2 depending on the system) and two threads doing socket communication (one for outgoing and one watching for incoming). We're keeping track of resets and will monitor the systems. If it doesn't improve with later firmware releases then I'll have to look at debugging the crash. Do you have instructions on how to go about that? -- Mike

@arneme Yup. Thats Correct.

@paul-thornton The timing is rather critical. Couldn't you extend the time window for updating to let's say 30s?

See also my post here https://forum.pycom.io/topic/4130/pinout-pysense-etc

@stevo52 Yes, from the distance, it sounds like a hardware problem with the board. Maybe a broken wire or a bad solder point at the P2 pin.

@robi90 I misunderstood your first post, assuming a hard crash. I just tried your example and agree, that this is not good and must be fixed, because the device locks up in an unresponsive state. I tried that with version 1.20.0.rc4. The situation is a little bit better with Ctrl-F, because then the device falls at least back to safe boot, from which it can be restarted with machine.reset(). But only from the USB port. Using telnet is only possible then, if you use the default settings for WiFi.

Ill raise this internally. seems like a good idea.

Never Mind. Saw post with info.

@robert-hh Es läuft jetzt. Ds Update ging nicht weil ich das Board für den Fipy überbrückt habe das es im batterie Modus läuft. nach entfernen des kabels ging auch das Update. Jetzt kann es weiter gehen. Danke für deine Mithilfe.