New firmware release v1.7.8.b1
Thank you @jmarcelino
The known issue post claims that the number is wrong but the updater is correct. This seems inconsistent with the February date of the 1.1.1 updater contained in the 1.1.2 container.
Once again I can't see the LoPy via USB, so I think I'll just wait (superstitiously).
Downloaded firmware installer for osx. Indicates 1.1.2 outside, but version inside is 1.1.1 from February.
I have not tried yet (need to buy more LoPys - all of mine are in use!) but seems like a simple matter of calling lora.nvram_save() when you want to save your LoRa state (e.g. before entering deep sleep) and then lora.nvram_restore() when you're back.
Maybe if you explain the context of the example you're looking for the Pycom team can help you better.
@jmarcelino Do you know if there are any examples available implementing these new functions?
@Frida it's fixed, but you'll have to download a new linux updater from our website.
@Frida thanks for reporting it. You do have the latest tool indeed. We'll check why that message is incorrectly displayed.
Why is I have this picture, I have the latest version.
@jcaron I totally agree. We will plan to implement that as well! Thanks!
@daniel Great! We can now have both deep sleep and LoRaWAN working together!
However, even though we now have something that works, I feel there's a lot more state that should be saved and restored, including at least:
- the channels used (as returned by the network) -- currently the LoPy will keep using only the default channels after going to deep sleep
- any ADR adjustments
- duty cycle timing info, to make sure we stay compliant with LoRaWAN specs and local regulations.
I know the last one is currently not very relevant as the firmware is delivered in "test mode" with duty cycles disabled, but at some point this will/should be fixed, and still work while going through deep sleep.
Not necessarily extremely urgent, but probably something to keep in mind before the new API is set in stone?
Thanks for breaking out the LoRa save/restore functionality into
lora.nvram_restore()- this is much better.
I noticed a rather harmless typo on the source code, two repeated calls to
@daniel Files size larger than 2 GB are now correctly shown, but there is a now problem with the file modification dates as returned by uos.stat(). They are treated now as unsigned too, but then the result may get a long int, which cannot supplied any more into localtime(), which seems to expect a short int as parameter..