New firmware release v1.7.8.b1

[daniel]

Hello,

A new firmware release is out. The version is 1.7.8.b1. Here's the change log:

• esp32: Rework the LoRa NVRAM API to add separate methods for save and restore.

• esp32: Fix GATT client notifications registration.

  Add .value() method to retrieve the stored value of a GATTC characteristic.

• esp32: Cleanup of machine_wake_reason function.

• esp32: Make the FTP server support paths with spaces.

• esp32: Increase FTP server timeout to 10 seconds.

• esp32: Report correctly file sizes larger than 2MB.

• esp32: Make sure that UART ISR handlers are only registered once.

In order to get the new firmware it, please user the updater tool that can be downloaded from here: https://www.pycom.io/downloads/

Cheers,
Daniel

[robert-hh]

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

[jmarcelino]

Thanks for breaking out the LoRa save/restore functionality into lora.nvram_save() and lora.nvram_restore() - this is much better.

I noticed a rather harmless typo on the source code, two repeated calls to modlora_nvs_set_uint(E_LORA_NVS_ELE_UPLINK, UpLinkCounter); https://github.com/pycom/pycom-micropython-sigfox/blob/8a4f37dc1181384860e6fd5a4684b2cad7579428/lib/lora/mac/LoRaMac.c#L4278

[jcaron]

@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?

[daniel]

@jcaron I totally agree. We will plan to implement that as well! Thanks!

[Frida]

Why is I have this picture, I have the latest version.

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