@jcaron No the rtc.ntp_sync fails to connect to time.google.com a lot on wifi & the default 1970 timestamp is what the rtc defaults to when it's not synced. I have to resync the rtc after each wakeup on the gpy because it doesn't keep time during deepsleep.

@paul-thornton said in How to send/receive LORAWAN MAC Commands?: https://docs.pycom.io/firmwareapi/pycom/network/lora.html#lorastats I'm not sure whether lora.stats() rx_timestamp is of use, it does not seem to represent a time value, but if it does, how do I convert it? [LORA ] 2019/02/21 04:51:55 (rx_timestamp=0, rssi=0, snr=0.0, sfrx=0, sftx=0, tx_trials=0, tx_power=14, tx_time_on_air=0, tx_counter=0, tx_frequency=0) [LORA ] 2019/02/21 04:52:04 (rx_timestamp=30539834, rssi=-45, snr=7.0, sfrx=3, sftx=5, tx_trials=1, tx_power=0, tx_time_on_air=57, tx_counter=0, tx_frequency=0) [LORA ] 2019/02/21 04:52:11 (rx_timestamp=38155453, rssi=-38, snr=8.0, sfrx=3, sftx=5, tx_trials=1, tx_power=0, tx_time_on_air=47, tx_counter=1, tx_frequency=0) [LORA ] 2019/02/21 09:04:47 (rx_timestamp=45778581, rssi=-43, snr=8.0, sfrx=3, sftx=5, tx_trials=1, tx_power=0, tx_time_on_air=47, tx_counter=2, tx_frequency=0) [LORA ] 2019/02/21 09:15:32 (rx_timestamp=690412324, rssi=-47, snr=6.0, sfrx=5, sftx=5, tx_trials=2, tx_power=0, tx_time_on_air=57, tx_counter=4, tx_frequency=0) [LORA ] 2019/02/21 09:15:38 (rx_timestamp=696682500, rssi=-48, snr=6.0, sfrx=5, sftx=5, tx_trials=1, tx_power=0, tx_time_on_air=57, tx_counter=5, tx_frequency=0) [LORA ] 2019/02/21 09:15:44 (rx_timestamp=702935506, rssi=-47, snr=6.0, sfrx=5, sftx=5, tx_trials=1, tx_power=0, tx_time_on_air=57, tx_counter=6, tx_frequency=0)

@gabrielapb You could try the following: save the current timestamp to NVS before going to sleep on wake-up: retrieve the saved timestamp from NVS retrieve the "remaining sleep" from the Pysense using pysense.get_sleep_remaining current timestamp is approximately saved + sleep interval - remaining Note this won't get you a very precise time (as it doesn't take into account boot time, and I'm not sure of the accuracy of the Pysense clock), and the offset to the real time will increase with the number of sleep periods, but it's helpful to have at least of rough idea of the time until you can get the actual time through other means. The alternative is to use the module's deep sleep rather than the Pysense's deep sleep, but that may not be possible depending on your actual use case.

@misterlisty A technique to pass object references from main.py to other modules is to create a 'dummy' module to pass items like rtc and i2c. To make this work you first need to create an empty file called 'shared.py'. Then you can use it as follows: in main.py -- from machine import RTC, I2C import shared rtc = RCT() i2c = I2C(0, I2C.MASTER) shared.rtc = rtc share.i2c = i2c Then in the module you want to reference/use rtc or i2c, include an import to shared as follows: import shared shared.rtc.now() shared.i2c.scan()

@misterlisty Have a look at the Python methods for string formatting, either the % operator for strings or str.format().

@alexpul Neat work around, Good job!

@tuftec In fact, lorawan callback in the network operator that i have used (objenious and orange) doesn't allow dynamic downlink data setup via callback service. I have to prepare the downlink data and when (even several hours/day later) the device send an uplink message the downlink data is send to the device. So, if you know the periodicity of your uplink frame you can predict the time to send to your device on his next uplink frame and set your operator downlink frame in advance. With Sigfox, when the device send an uplink frame with download request bit (by device choice) set, there 2 choices -default call back method can send back to the device network time and some static data -you have 20 secondes to send back from your device (from your own callback service) some data and time. With NB-IOT , network time availability is not mandatory so it depend of your network provider.

@charly86 thank you, I will try it

@robert-hh I have the same impression. I had a 15 minutes deep sleep cycle running the night and the time was ~4 minutes off in the morning.

@andrethemac Thanks for letting me know! Your library is just what I was looking for.

@arno Unfortunately the deepsleep shield does not have any such functionality

i'm having a dou't wether we can use lopy4 as a access point or are we able to use this as a wifi hub that may be join to computer after which can it be used as a usb dongle.

@rolandvs said in Is the time in the RTC preserved after hard reset w/o power down?: If true it makes the use of the RTC sort of worthless in situations where you want to keep time with an attached battery without the possibility to use Wi-Fi to NTP your time like with LoPy or SiPy... It doesn't solve the original issue, but you can update time without network connection using GPS receiver, e.g. on the pytrack extension board.

@joeri How accurate does it need to be? You could store the time before entering deep sleep and then when the board comes back you'd know it's the stored value + your deep sleep time + small adjustment to account for boot-up (which on my tests is about 1.9s but you should check for yourself) That should quickly give you a good approximation. Of course on the Pytrack you can get then get the GPS time.

@cfaessler did yoy fix this issue?

@Thosch42 currently only machine.deepsleep(5000) is supported - this is only wakeup "source" - we all waiting for more :)

@anacleto utime.localtime(utime.time()) contains the day of week