Almost 100% percent of our devices have an embedded cellular modem for communications over cell carrier, mvno(s) all VPNd with at min double-redundancy to our NOC (server).
We hardly remember what an ethernet cable is, i.e. our stuff is in the brittle sticks…remote.
When we need to update the C# application on our device(s). We OTA (over-the-air) transmit this new application, stick it on SD and via inFieldUpdate(…) update the device / G120.
In general we call these new applications cdapp_XXXX.HEX
If one of our techs was local, they could update the device via Fez Config. Usually, this is not the case…remote.
We also have another file that (sometimes) needs to be updated simultaneously with the new application. This file configures the device for specific geo-site needs as well if say a new cell modem, LoRaWan, etc needs deployment. In general we call this file config.csv.
We also cell modem FOTA (Firmware-Over-The-Air) updates that need to be performed.
Whether we are updating the application, config file, or modem FW…we OTA (download) to SD and reboot our device. Upon reboot, the updates get set.
We have, over the years, developed essentially a check list of how to update (OTA) our device(s).
Sometimes it is just a straight forward OTA. One and done.
Sometimes we must downgrade the device and then in specific order update the device in a sequence so that we don’t ‘Brick’ the unit…Such is prone to error, a pain-in-the-ass, and very costly to roll a tech to such remote environs.
If we had a way to zip all updates, OTA updates, reboot, unzip and apply all updates in a sequence determined locally by the device…would be a huge improvement to what we do now.
As a less important consideration, being able to simply compress files (big log files) on our device so that cell data transmission is decreased and hence cost is certainly something we want and need.
As said, trade-offs are part of building a full system. We would like to shorten this list of trade-offs…!