# Using DevTimeReq to get time on V3

**URL:** <https://www.thethingsnetwork.org/forum/t/using-devtimereq-to-get-time-on-v3/49488>\
**Category:** V3 Applications\
**Created:** [July 6, 2021, 7:33am UTC](https://www.thethingsnetwork.org/forum/t/using-devtimereq-to-get-time-on-v3/49488 "2021-07-06T07:33:33Z")\
**Posts on this page:** 16\
**Page:** 1

<div class="post-metadata">

**Author:** ![Verkehrsrot](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/verkehrsrot/32/46588_2.png) [@Verkehrsrot](https://www.thethingsnetwork.org/forum/u/Verkehrsrot)\
**Post date:** [July 6, 2021, 7:33am UTC](https://www.thethingsnetwork.org/forum/t/using-devtimereq-to-get-time-on-v3/49488/1 "2021-07-06T07:33:34Z")

</div>

Is anyone here using DevTimeReq to get time from v3 network?  
I’m using the [code example](https://github.com/mcci-catena/arduino-lmic/blob/master/examples/ttn-otaa-network-time/ttn-otaa-network-time.ino) 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?

---

<div class="post-metadata">

**Author:** ![Jeff-UK](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/jeff-uk/32/35697_2.png) [@Jeff-UK](https://www.thethingsnetwork.org/forum/u/Jeff-UK)\
**Post date:** [July 6, 2021, 7:49am UTC](https://www.thethingsnetwork.org/forum/t/using-devtimereq-to-get-time-on-v3/49488/2 "2021-07-06T07:49:55Z")

</div>

🤔 Your probably using the wrong value of flux capacitors… 🤣

---

<div class="post-metadata">

**Author:** ![johan](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/johan/32/45177_2.png) [@johan](https://www.thethingsnetwork.org/forum/u/johan)\
**Post date:** [July 6, 2021, 8:15am UTC](https://www.thethingsnetwork.org/forum/t/using-devtimereq-to-get-time-on-v3/49488/3 "2021-07-06T08:15:51Z")

</div>

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](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.

---

<div class="post-metadata">

**Author:** ![Verkehrsrot](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/verkehrsrot/32/46588_2.png) [@Verkehrsrot](https://www.thethingsnetwork.org/forum/u/Verkehrsrot)\
**Post date:** [July 6, 2021, 8:37am UTC](https://www.thethingsnetwork.org/forum/t/using-devtimereq-to-get-time-on-v3/49488/4 "2021-07-06T08:37:48Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![johan](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/johan/32/45177_2.png) [@johan](https://www.thethingsnetwork.org/forum/u/johan)\
**Post date:** [July 8, 2021, 7:38am UTC](https://www.thethingsnetwork.org/forum/t/using-devtimereq-to-get-time-on-v3/49488/5 "2021-07-08T07:38:10Z")

</div>

> [@Verkehrsrot](#):
>
> 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.

---

<div class="post-metadata">

**Author:** ![jpmeijers](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/jpmeijers/32/44875_2.png) [@jpmeijers](https://www.thethingsnetwork.org/forum/u/jpmeijers)\
**Post date:** [July 8, 2021, 7:44am UTC](https://www.thethingsnetwork.org/forum/t/using-devtimereq-to-get-time-on-v3/49488/6 "2021-07-08T07:44:57Z")

</div>

> 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.

---

<div class="post-metadata">

**Author:** ![johan](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/johan/32/45177_2.png) [@johan](https://www.thethingsnetwork.org/forum/u/johan)\
**Post date:** [July 8, 2021, 8:44am UTC](https://www.thethingsnetwork.org/forum/t/using-devtimereq-to-get-time-on-v3/49488/7 "2021-07-08T08:44:02Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![descartes](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/descartes/32/47220_2.png) [@descartes](https://www.thethingsnetwork.org/forum/u/descartes)\
**Post date:** [July 8, 2021, 8:51am UTC](https://www.thethingsnetwork.org/forum/t/using-devtimereq-to-get-time-on-v3/49488/8 "2021-07-08T08:51:19Z")

</div>

> [@jpmeijers](#):
>
> > 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.

For values of sending a value that gets stored in a variable and/or flash - not a whole firmware update!

---

<div class="post-metadata">

**Author:** ![Verkehrsrot](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/verkehrsrot/32/46588_2.png) [@Verkehrsrot](https://www.thethingsnetwork.org/forum/u/Verkehrsrot)\
**Post date:** [July 8, 2021, 6:23pm UTC](https://www.thethingsnetwork.org/forum/t/using-devtimereq-to-get-time-on-v3/49488/9 "2021-07-08T18:23:49Z")

</div>

Fully agreed.

---

<div class="post-metadata">

**Author:** ![strooom](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/strooom/32/45441_2.png) [@strooom](https://www.thethingsnetwork.org/forum/u/strooom)\
**Post date:** [December 10, 2022, 5:03pm UTC](https://www.thethingsnetwork.org/forum/t/using-devtimereq-to-get-time-on-v3/49488/10 "2022-12-10T17:03:45Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![arg02](https://www.thethingsnetwork.org/forum/letter_avatar_proxy/v4/letter/a/e68b1a/32.png) [@arg02](https://www.thethingsnetwork.org/forum/u/arg02)\
**Post date:** [May 26, 2024, 10:44pm UTC](https://www.thethingsnetwork.org/forum/t/using-devtimereq-to-get-time-on-v3/49488/11 "2024-05-26T22:44:59Z")

</div>

Hi All,  
I managed to get [this example](https://github.com/mcci-catena/arduino-lmic/blob/master/examples/ttn-otaa-network-time/ttn-otaa-network-time.ino) to work with TTN using an RP2040 board.  
Now i’m trying it with an M0.  
It joins, but i keep getting ‘USER CALLBACK: Not a success’  
Has anyone managed to get network time using an M0 board?  
Thanks

---

<div class="post-metadata">

**Author:** ![descartes](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/descartes/32/47220_2.png) [@descartes](https://www.thethingsnetwork.org/forum/u/descartes)\
**Post date:** [May 28, 2024, 5:31pm UTC](https://www.thethingsnetwork.org/forum/t/using-devtimereq-to-get-time-on-v3/49488/12 "2024-05-28T17:31:27Z")

</div>

The Feather M0 is a first class device for LMIC - ie it’s one of the preferred ones, so this is somewhat surprising.

Are ‘normal’ join & uplinks working OK?

Can you do a manual downlink (just the one)?

---

<div class="post-metadata">

**Author:** ![arg02](https://www.thethingsnetwork.org/forum/letter_avatar_proxy/v4/letter/a/e68b1a/32.png) [@arg02](https://www.thethingsnetwork.org/forum/u/arg02)\
**Post date:** [June 1, 2024, 10:08pm UTC](https://www.thethingsnetwork.org/forum/t/using-devtimereq-to-get-time-on-v3/49488/13 "2024-06-01T22:08:21Z")

</div>

Hi Nick, thanks so much for getting back.  
A quick question before i dig into what i’m seeing on uplinks/downlinks…  
I have both MCCI\_Arduino\_LoRaWAN\_Library and also MCCI\_LoraWAN\_LMIC\_library in my Arduino libraries folder.  
The header of the ttn-otaa-network-time example includes \<lmic.h\>  
How can you tell if the Arduino IDE is actually using the LMIC library?

![Screenshot 2024-06-01 at 23.06.55](https://www.thethingsnetwork.org/forum/uploads/default/original/3X/1/1/11b3e91f044cf7db395b124dae278605e36852eb.png)  
 ![Screenshot 2024-06-01 at 23.07.13](https://www.thethingsnetwork.org/forum/uploads/default/original/3X/0/f/0f8a43cf5cbad51f5e5d6ffbb0a6c9b15a4fd4da.png)

---

<div class="post-metadata">

**Author:** ![descartes](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/descartes/32/47220_2.png) [@descartes](https://www.thethingsnetwork.org/forum/u/descartes)\
**Post date:** [June 2, 2024, 4:04pm UTC](https://www.thethingsnetwork.org/forum/t/using-devtimereq-to-get-time-on-v3/49488/14 "2024-06-02T16:04:24Z")

</div>

> [@arg02](#):
>
> How can you tell if the Arduino IDE is actually using the LMIC library?

Look at the compile logs to see if it had to make a choice?

But as LMIC is only in the MCCI LoRaWAN LMIC library because RTFM will show you that the Arduino library is a wrapper to simplify the LMIC library, like me, [there can be only one](https://youtu.be/sqcLjcSloXs).

---

<div class="post-metadata">

**Author:** ![arg02](https://www.thethingsnetwork.org/forum/letter_avatar_proxy/v4/letter/a/e68b1a/32.png) [@arg02](https://www.thethingsnetwork.org/forum/u/arg02)\
**Post date:** [June 2, 2024, 8:27pm UTC](https://www.thethingsnetwork.org/forum/t/using-devtimereq-to-get-time-on-v3/49488/15 "2024-06-02T20:27:26Z")

</div>

It works now!  
I added #define LMIC\_ENABLE\_DeviceTimeReq 1 to the lmic\_project\_config.h and now it works!  
☺

---

<div class="post-metadata">

**Author:** ![descartes](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/descartes/32/47220_2.png) [@descartes](https://www.thethingsnetwork.org/forum/u/descartes)\
**Post date:** [June 2, 2024, 11:15pm UTC](https://www.thethingsnetwork.org/forum/t/using-devtimereq-to-get-time-on-v3/49488/16 "2024-06-02T23:15:55Z")

</div>

RTFM for the win!
