Main.py update with OTA but with LTE

[Cédric Antenen]

In my internet research I often found how to update a main.py or the firmware with LoRa but with never how I can update my GPy with LTE.

In my thoughts I would do something like firstly in the boot.py setup the LTE and let it subscribe of MQTT where the new version of the program is. Then the GPy should start the update with the new file and get a new main.py.

Is this even possible or can I only update the main.py with LoRa? Next to this how could a code look like? I have to say I am quite new to the pycom and never used one before. What I can is simple micropython stuff for esp32.

Thank you for helping.

[Elizar]

@Cédric-Antenen
We have roughly 200 lines of code on both sides Gpy (Python) and update server (C).

Update speed depends on you files' size, signal quality and round trip time.
We have seen about 1...4 s per data block (data transmitted and acknowledge received).

Sorry, I can't share the code here, since solving such problems is what I do for a living :)

[Cédric Antenen]

Thank you Elizar for your response. So correct me if I am wrong but to get sure LTE as OTA is possible would I say yes with your response in mind.

It maybe sounds a bit weird but what would you assume as a code length, respectively the time consumed to do an OTA? I know you dont have further information about the project and it is a bit difficult to answer.

Thank you very much and have a nice day.

[Elizar]

Updating a Gpy over-the-air is not a big thing but it involves several steps.

First, there is no direct need to do this from boot.py although it is possible, too.

Second, it is important to understand that main.py is read/loaded (and compiled on the fly) at boot time only. Gpy does not access the file later. Therefore it is possible to update main.py in flash memory without interrupting a running main.py . The new main.py will be used automatically on next reboot.

Third, you need to establish a reliable connection between Gpy and an update server. Reliable means having a small protocol that sends a block of data to the Gpy and get an acknowledge back. If a block is lost, repeat it. Using checksums may be useful, too. Since UDP block size is somewhat limited you need to split the update file on the server side for transmission and merge the parts later on the Gpy side. Of course you may use MQTT instead of UDP if you really like.

Finally, invest some time to design the steps very carefully since small flaws can cause a lot of headache later. Try to avoid a situation where the Gpy becomes unresponsive because of a defect update.

Building a fully functional over-the-air update from scratch can be a very satisfying task that involves some coding fun. You may discover many additional features (and little pitfalls) underway that may be useful.