Lopy4 current timing

[sita]

Hello all,

I have one doubt regarding lopy4. Is there any command to show current running time in Lopy4 without connecting to internet?
As per my understanding; by using rtc we have to initialize the time. But my problem is while doing the experiment i cannot initialize every time and i want exact timing at that moment.
Could any one please suggest me idea for this problem.

Thanks in advance.

[railmonitor]

@jcaron Thanks for clarifying. Seems that LTE NB-1 is what i want. Then i can just use NTP like if i was on regular WiFi right? Or do i get access to that only with CAT-1? Seems that this is the easiest and solution, and not too expensive if i buy a M2M card (Machine to machine subscriptions)

[jcaron]

@railmonitor indeed, but as I wrote, when your server sends the downlink, it will not be sent to the device right away, but only right after it sends a message (uplink).

This is because to save power, LoRaWAN devices (class A devices are least) do not listen all the time. They listen only during two very short windows (RX1 and RX2) which are by default respectively 1 and 2 seconds after the end of an uplink.

So if your device only sends data one in a while, your packet with the current time may be delayed for hours.

Depending on the exact details (protocols used, latency, etc.), it may be possible for your server to send the data when it receives a request from the device, and have that data sent in the RX window right after the associated uplink, but it’s far from guaranteed.

So you would end up needing to do two uplinks in a row, one to send the request, and one just to get the answer, which would then be a bit delayed.

Add to that the fact that LoRaWAN frames can be quite slow to send (over a second for even the smallest frame at SF12), and that means that it will be very difficult to have any sort of precise time. If you just need minutes, that’s fine. If you need seconds or less, not quite.

But in many scenarios, you don’t actually need the device to actually have the time. At best, just having the time of the uplink is enough. In other cases, just storing a “time since boot” for each event and sending this time in your uplinks should be enough to know when the event happened.

[robert-hh]

@railmonitor Yes, you could use that mechanism. But using a public network like TTN is a little bit of work, and it will not very precise. Downlink messages are sent in response to an uplink message.
So you have to setup an own server (integration), which gets an uplink message, prepares a downlink message with the time, which will be delivered after the next uplink message. So your node has to send two uplink messages, and will eventually get the time stamp after the second message. There will be some error due to unknown lags in the communication between the TTN serve and your time service. And even if everything works, the downlink may be sent either 1 or 5 seconds after the uplink message.
If you set up your own Lora network, you can freely define messages and their protocol.
Using GPS or the like is much more precise.

[railmonitor]

@jcaron Thank you for answering.

Did a little diggin', found this: https://core-electronics.com.au/tutorials/your-first-lorawan-node-on-the-things-network.html

Seems that you can send an series of bytes using the downlink, so i imagine it would be possible to code something to handle the downlink message, and convert it to a date + time, which then can be used to set the RTC with.

[jcaron]

@railmonitor As long as you can receive data you can include the current time in that data.

However:

• This would not use NTP, so it would probably be less accurate (NTP can take into account round-trip time)
• In the case of LoRaWAN (and I suppose Sigfox as well, though I'm not familiar with the details), when you send data from the server to the device (downlink), it sits there until the device sends something to the network (uplink) and the network will reply with the data. So depending on how often the device sends data, it could be a long while if it is sent by the application. I believe options to have the network (gateway/LNS) send the current time in a response have been added in recent versions of the spec, I'm not sure those are implemented on the LoPy (nor if support in gateways and/or LNS is ubiquitous).
• For BLE, you would need "something" to send the time to the device. Depending on your scenario this could be trivial or not.

Remember that you can also get the time from GPS if you have GPS on board and you have a decent view of the sky.

[railmonitor]

I have a question in the same category:

What are the different possibilities for getting the RTC updated using a NTP server og something similar.

Say that my device need to be positioned somewhere, where there is no WiFi present.

What other possibilities are there to connect to a ntp server, or other means of setting the RTC? Can it be done using LTE (i assume it can), but how about LoRa, Sigfox or even BT?

[robert-hh]

@sita Unless you initialize the time, time.time() tells the elapsed time since reset. If you need the true time & date, you have to initialize that from a time source, like npt, or an internal or external RTC, or GPS. The internal RTC is hardly usable - it lacks a precise battery backed timebase- , ntp cannot be used, so you have to use an external RTC module, like a DS3231 with a backup battery, or GPS. The DS3231 has to be set at least once, GPS requires suitable receive conditions and and the receiver. Pycom offers Pytrack, but you can get others for a few Euro.

[sita]

@robert-hh Thanks for the reply. By using these (time.time() & time.ticks_ms()) we can know number of seconds since the Epoch. Is there any way to get time and date (2020 01 13 15 41 00 current date & time) like this ????

[robert-hh]

@sita time.time() is set to 0 at hard boot or machine.reset() and tells expired seconds since then. time.ticks_ms() counts ms starting from hard boot.