@robert-hh Ahh Ok, tks for the explanation.

@jc_serg That looks bad then. Since 3.3V is an output of the board, it means that the board is not working. Are you sure you plugged in the board in the right orientation?

@catalin Ok, I will try the licensing then. Thank you very much.

@kjm said in File system problems & solutions: the windows version of this CLI The CLI program should probably just be the same .exe file which is also the graphical thing. According to [1], its default location might be c:\Program Files (x86)\Pycom\Pycom Firmware Update\pycom-fwtool-cli.exe. [1] https://community.hiveeyes.org/t/setup-commandline-based-micropython-development-environment-on-linux-macos-and-windows/1639/15

Pybytes (2.0) / Pybytes-legacy (1.0) is a cloud-based device management platform. You can use it to visualize the sensors data, see the status and geolocation of your devices and you can also perform Firmware Over the Air updates. Pybytes version 1.0 and 2.0 are built on top of the low-level firmware. The legacy firmware contains the old low-level modules of the Pycom devices without pybytes. It contains the micropython interface, FreeRTOS and all the drivers (LTE, Wifi, Bluetooth, i2c, sockets, Lora, etc).

@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