It is possible, but would take a long time and is not likely to be reliable.
Depending on distance from the gateway, spreading factor used etc, your payload would be limited so sending a firmware update at 10-20 bytes per response, taking into account the duty cycle in your area. I did some rough calculations a while ago and worked out that it could take between 4 and 5 weeks to send a 200K image file at 20 bytes on a 5 minute polling. Each payload would need a checksum and sequence including, this then adds extra bytes, reducing your usable payload size.
and … depending on technology u use on nodes, ROM/Flash, battery operated. it would normally take higher current to flash the firmware (and of course to download the whole firmware), hence reduce operation duty cycle.
But this would be way above the fair usage policy. But even ignoring that restriction, the gateway could only update one device every 5 weeks if there’s no broadcasting, which imo makes it impracticable for real life.
The aspect of large scale deployment & remote management of LPWAN nodes attracted my attention from the earliest beginning. Soon after looking to the constraints of LPWAN in general, I realized that low power out of band management would be the best route to take. So I took some concepts from the classical IT like Wake on LAN, Software Control & Distribution solutions like Puppet and the WLAN power of the Espressif ESP32 chipset. That all mixed together has led to the idea of time triggered WLAN assisted LoRa Node device management. In rural areas a drone will be the mobile update proxy. In city and sensor dense areas, both a car or bike equiped with an update proxy and public Wifi hotspots like Fon will be in place.
Any can do specialist interested who like to jonitly develop a prototype of this concept?
Core technology of the solution would be the Lopy from Pycom (to be released in 2 months), Sodaq ONE, OpenWRT for the out of band management SBC (might become the Onion Omega2 - to be released in 4 months) and possibly some Python, YAML and Arduino Sketch skills.
Back in the ZX Spectrum 48K days there used to be major FM radio stations which transmitted games and software over the air, people would plug in their FM receiver to the Spectrum tape port during the show and prepare to load.
With fully integrated FM chips now costing <US$0.5, very basic antenna requirements and availability of community radio stations in some regions - often unused during the evening - I wonder if an agreement could be reached to broadcast OTA firmware updates over that channel.
back in the commodore days, every saturday they had a special broadcast, if you taped that you could load it into your VIC 20
the technique behind that audio/data transmission is well suitable for updating nodes I think.
but, updating what ? firmware or application software, anyway, there is a lot to be done on the security part.
its not that simple…
All the required hardware stuff has been delivered. Fancy descriptive name will be: WLAN assisted remote management of LPWAN IoT devices. Ubuntu Snap will be the first SC&D technique to use for this idea. Stay tuned. Specs have been worked out and some prototype results might be expected in Januar 2017.
Hi, I’m interested on this topic, I was reading the mentioned post “Firmware Updates over Low-Power Wide Area Networks”.
BTW: It is a great work!
But, I have some questions
As far as I understand you are proposing this mechanism to be included in the LoRaWAN specification, but I think that regardless the standarization of this process, you’re going to continue working on provide this solution.
You mentioned that you have a application layer in charge of the update. This application will be available for the community? will be a part of thethingsindustries? or It is going to be responsability of each user to create its own updating application layer?
This proof of concept is running on a enhanced version of TTN? Since I read that TTN currently doesn’t support class C communications.
When do you estimate that it will be released? (class C support and application update layer)
Yes. If anything is going to be part of LoRaWAN spec, it would be setting up the multicast group and potentially the fragmentation session. It would be good to have this standardized, if not in LoRaWAN, then in another spec.
The multicast group and fragmentation session specs will be open source, whether or not part of LoRaWAN. This is to be discussed in the LoRa Alliance TC. The current spec status is draft and application-layer.
The Update Server that we use in the demo is being developed by The Things Industries, like almost the entire The Things Network open source stack. It will be available in TTI private networks for sure.
In any case, half of the magic of FOTA is in multicast group and fragmentation session setup, and this we want to bring to the community for sure, both open source on GitHub and hosted in the public community network. Best would be as part of LoRaWAN, otherwise either custom TTN MAC commands or implemented in the application-layer.
Yes, this is a test TTN installation supporting class C.
Class C is coming in a new version of TTN. We will make an announcement very soon.
In the meantime, we’re working with ARM and the community on an end-to-end demo of FOTA, so including hardware. If everything goes well with the new TTN version, I think somewhere mid-Q4.
@Lenar sorry for the late reply. It is still in specification by a Working Group in the LoRa Alliance Technical Committee. We did not get approval to release it yet. Stay tuned.
Hi @Yogesh_B still early days yet but TTN & ARM (plus others) have been thinking hard on this and have proposals in the works. See this video from TTN Conf
Some early supporting application extensions (not core LoRaWAN functionality requirements specifications) and associated standards within LoRa Alliance expected to clear through 1H18.
Suggest look back through earlier parts of this thread
How can we send data from multitech conduit to mDot lora device, other than NODE-RED. Whether we can write a code to send data? If any example is available, it will be more helpful.
