New firmware release v1.7.8.b1

[daniel]

@Frida thanks for reporting it. You do have the latest tool indeed. We'll check why that message is incorrectly displayed.

[daniel]

@Frida it's fixed, but you'll have to download a new linux updater from our website.

[johncaipa]

@jmarcelino Do you know if there are any examples available implementing these new functions?

[jmarcelino]

@johncaipa
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.

[jalperin]

Downloaded firmware installer for osx. Indicates 1.1.2 outside, but version inside is 1.1.1 from February.

[jmarcelino]

@jalperin
known issue https://forum.pycom.io/post/9529

[jalperin]

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).

[jmarcelino]

@jalperin
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.

[jalperin]

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.

[jcaron]

@jalperin I do have a board here running 1.7.8b1 with a Pysense running 0.0.4 that does just that: send a packet over LoRaWAN, deep sleep 150 seconds, and repeat.

I haven't measured the power consumption, but it's been running on a 2500 mAh LiPo for well over 48 hours and the battery still reports 4.1V.

We're probably not yet on the scale of months or years in this setup, but I think weeks is perfectly doable.

[jalperin]

Thank you @jcaron. Very helpful (especially after I expressed my frustration).

May I please see the code? Are you saving nvram?

My own experience when sending a packet every 2 minutes and using deepsleep was 4 days and 6 hours from fully charged at 4.16v to dead board final battery reading of 3.31v on 2000mAh LiPo.

Since switching to pysense gotosleep I have gotten inconsistent results, but never more than 36 hours and final bat 3.95. Obviously my code is faulty.

I was eventually able to get 1.7.8.b1 installed. Took two hours and many tries. Have now fully charged LiPo and restarting my test.

[athtest800]

Will the "nvram save" break the flash - lopy after some time, due to many writes?

[jmarcelino]

@athtest800
While the flash chip is rated for 100,000 program/erase cycles the Non-volatile storage library used to store these value does it's own kind of wear levelling so I'd expect a lot more, well into the millions.