Is anyone here using DevTimeReq to get time from v3 network?
I’m using the code example from MCCI LMIC. It works on v3, i get a time. But the calculated time is always ~18 seconds in the future.
I could not yet figure out, why. Thus, i would like to ask if anyone here can confirm that v3 delivers correct time?
Your probably using the wrong value of flux capacitors… 
Are you accounting for leap seconds? The result is, per spec, seconds after GPS epoch.
GPS epoch was at Jan 5, 1980. There are 18 leap seconds since then. See https://www.ietf.org/timezones/data/leap-seconds.list
You can safely add 18 to the resulting number.
There are currently no future leap seconds announced. As they get announced, you need to update your firmware.
Ok, it’s as simple. Thanks for this hint. I was into leap seconds already, but had 37 secs in mind. But this is since 1972, not 1980, and GPS epoch is 1980.
So, in the code on the node i will subtract (not add!) 18 leap seconds from the time value which is delivered by DeviceTimeAns.
But this leads us to another problem: adding leap seconds “at the edge” on a LORAWAN node sounds like a bad idea. Because with next leap second we need a firmware update on the node. So, why not delivering current time from network?
I agree that unix time is more useful for most end devices. I wasn’t in the LoRa Alliance technical committee when this was decided so I don’t know the background. My guess is twofold: 1) class B beacons use GPS too (directly from the gateway’s GPS) so the time is harmonized and it allows for faster beacon acquisition and verify that the beacon is authentic and not replayed and 2) it’s safer for end devices to not skip seconds (i.e. when counting things over time) than to explicitly skip seconds.
You can always send an application data downlink message whenever there’s a leap second announced and make your firmware aware of that.
As they get announced, you need to update your firmware.
Oh no 
Another decision made by the guys up there that doesn’t understand hardware.
I don’t really understand the problem. I’m happy to bring this in to TC but then I first have to understand why you want the end device to be aware of leap seconds.
If your use case is to show a wall clock, yes, you will need leap seconds. You will also need the timezone though, as well as daylight saving time and future changes to that. This is very much beyond the scope of LoRaWAN.
If your use case is for your end device to be aware of absolute time, which it uses to register events at a certain time, that are then aggregated, logged or transmitted later, it is perfectly fine to use GPS time, right? Your application in the cloud can apply leap seconds. Plus you won’t get weird glitches in the measurements.
Only if your use case is for your end device to do something exactly on top of every hour, then sure, you need to know the leap seconds on the end device. Still, some time zones are +/-hh:15 and +/-hh:30, so you need a side channel to communicate that offset. Also, with firmware or battery life of 10 years, you can expect 4 seconds or so. I really don’t get the issue.
For values of sending a value that gets stored in a variable and/or flash - not a whole firmware update!
Fully agreed.
You could implement programmable offsets in the end node, with offset in seconds and valid-from time. Then set them from a downlink msg. You could update devices before the new leap-second occurs.