search

ARMmbed / mbed-os-example-lorawan-fuota

Mbed OS 5 Firmware update over LoRaWAN example application
Apache License 2.0
71 stars 31 forks source link

why the clock synchronization? #7

Closed kqorany closed 5 years ago

kqorany commented 5 years ago

I see the Fuota's routine starts with clock synchronization and then establishes the multicast and fragmentation sessions but I wonder why the clock synchronization is required. I mean I don't see the devices have to be synchronized to do the Fuota except for the start time of class C, which is defined by time to start so devices can be clock desynchronized and still perform this. In this case, what would happen if the devices ignore the clock synchronization phase?

janjongboom commented 5 years ago

The time to start is passed in as GPS time. So the device requires an accurate clock to know when the multicast session needs to start. If you have alternative means for a clock you can omit this.

kqorany commented 5 years ago

Thanks! Jan.

Yes, I think just passing the time-to-start as a relative time from now ( like start after 2 mins from now) wouldn't need the devices to be synchronized in the first place. For sure this comes at the expense of a bit of extra coding at the server-side to calculate the time-to-start for every device individually. Thanks anyway!

janjongboom commented 5 years ago

I think just passing the time-to-start as a relative time from now

If I were you I'd adhere to the official specification. This will make your life a lot easier if you ever need to deploy on a different network server.

Originally we had time-to-start implemented as per your suggestion, but this was changed as it requires exact knowledge of device transmissions by the update server (which might not be the same as the network server). By using absolute time this is no longer the case.