@Andrea-Zauli When using the updater tool, tick the "Advanced Settings" box, and then you can select later between FAT and LittleFS (LFS), and you can select erasing the device. Besides that, using LFS is the same as using FAT

@tuftec said in Software watchdog: @Andrea-Zauli Yes!!! Read here https://docs.pycom.io/firmwareapi/pycom/machine/wdt/ and here https://docs.pycom.io/firmwareapi/pycom/machine/ Peter. Many thanks!!

The unique ID is the same as the MAC address, you can use argument wmac to get it :) Gijs

Got it @catalin: thank you. I am going to test it soon. For now, I am preparing 3 LoPy4s for their first use (at least for me) in an orienteering event with 200 runners: 800m of meshed radio communication between the start line and the IT head quarter in a hilly forest. I hope it is going to work fine :-)

@Gijs said in Alter lora frequency without reset: Also, setting a timeout does not alleviate the issue of the taken semaphore. No, but on timeout the semaphore could be released too.

Thanks kjm! Wonder what functionalities I lost by accidentally downgrading..

@robert-hh Hi, I am using the firmware version you told me and now works, and the nanogateway version I have been using is the provided by pycom

@d-alvrzx I strongly support this request. I see, that restoring some of the data may cause trouble, if restore is executed multiple time w/o a save in between. Like the packet counters. But that is less cumbersome than loosing all data. See also my notes here to retrieve individual elements: https://forum.pycom.io/topic/5922/an-alternative-to-nvram_save-restore-using-the-sd-card/6?

@aen I had a different experience. This worked for me: >>> import sqnsupgrade >>> sqnsupgrade.info() <<< Welcome to the SQN3330 firmware updater [1.2.6] >>> >>> FiPy with firmware version 1.20.0.rc13 Your modem is in application mode. Here is the current version: UE5.0.0.0d LR5.1.1.0-46470 Then on the terminal: >>> sqnsupgrade.run('/dev/ttyACM0', 'NB1-41019.dup') <<< Welcome to the SQN3330 firmware updater [1.2.5] >>> Firmware file is too big to load via FFF method. Using ON_THE_FLY Attempting AT wakeup... Session opened: version 1, max transfer 8192 bytes Sending 5835531 bytes: [########################################] 100% Waiting for modem to finish the update... <<<=== DO NOT DISCONNECT POWER ===>>> Resetting............................. Your modem has been successfully updated. Here is the current firmware version: UE6.0.0.0 LR6.0.0.0-41019 When I tried your method (to upgrade) the result was an error: Upgrade failed with result failure[diffUpgrade,239] Patch didn't apply! So I figured I'd just upload the final image rather than a diff as the factory shipped firmware appeared to be some unknown number (46470) The documentation on all this is convoluted when its probably quite simple. Philip

Hello, I've just tried to update firmware of my Expansion Board v3.0 and faced the same issue. Does anyone knows how to fix it? Thanks in advance, w

@robert-hh Thanks!

hi @pytrackuser1 and @jcaron I've run an similar experiment, on Pysense, for some 12-14 hours and it didn't failed (sleep cycles were 20sec). I've used a 2Ah battery, and recharge it once during the experiment. I've met such situation, but the battery was weak, 3.6V showing on pysense.read_battery_voltage(), indeed it did not wake up. You could log into NVS last value of: the battery voltage, number(count) of restart, time from RTC, maybe we notice a pattern. Computer could go into in standby, and minimise USB power source; but you said you've used a power adapter... One question, after the block, you just cycle power and it works fine, isn't it? OK, I will try to monitor power usage, maybe I can detect something. To disable Pybytes: we’ve just released v1.20.2.rc3, which supports the method pycom.pybytes_on_boot(False) for the previous versions, there are 2 commands: >>> pybytes.smart_config(False) >>> pybytes.set_config("pybytes_autostart","false")