New firmware release v1.7.8.b1
Thanks again, @jmarcelino.
Yes. I know. I am just venting my frustration. The one pycom constant, at least for me, is that something is always amiss.
Moreover, the most recent code changes I've incorporated (from posts last week) have resulted in higher power consumption, not lower. I'm hoping for battery life measured in in weeks or months, but I'm seeing only two days (on 2000mAh lipo).
No doubt I'm doing many things wrong, but I've yet to see a full example of how to send a LoRa packet, deepsleep, and repeat on a schedule that achieves the least power consumption. And, no doubt, the new nvram functions will change that anyway.
So, somewhat tongue in cheek, I think I will just throw the LoPy in a drawer for a few months and see what I find in the fall.
Well the updater really has nothing to do with seeing the device over USB, that's all handled by the FTDI drivers (if you use the official Pycom expansion board) so I urge you to search out the many posts already on the topic - especially this great checklist https://forum.pycom.io/topic/763/firmware-upgrade-troubleshooting-checklist-procedure - or open a new a one if you're still struggling with it.
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..