RTC Bug?

[pythoncoder]

Thank you. I have today expanded it to provide current consumption data for a use case where a sensor is read and the reading sent via a radio link to a base station. It also includes suggestions on using the RTC backup registers for nonvolatile storage.

As for your code example, I modified it to replace the print statement with one which toggles an onboard LED: I have doubts about printing coexisting with the Pyboard power saving modes. I ran it with the Pyboard powered from USB firstly with Vbat disconnected, then with Vbat linked to 3V3. In both cases the LED toggled every 30 seconds.

Code: Select all

import pyb
import micropython
micropython.alloc_emergency_exception_buf(100)
ledy = pyb.LED(3)

rtc = pyb.RTC()
sleepInterval = 30000 # in ms
interrupt_RTC = 0 # RTC Wake Event

def callback_RTC(line):
   global interrupt_RTC
   interrupt_RTC = 1

def mainloop():
   global interrupt_RTC
   while True:
      if(interrupt_RTC == 1):
         interrupt_RTC = 0
         ledy.toggle()  
      
      pyb.stop() # go to sleep until next wakeup

rtc.wakeup(sleepInterval,callback_RTC) # every sleepInterval wake   
mainloop()

[JimTal001]

Peter have you found a way to avoid having to reset the time in code yet when using suspend()?

Code: Select all

	if (stm.mem32[stm.RTC + stm.RTC_BKP1R] == 0):
		rtc.datetime((2015,10,1,4,10,47,0,0))

[pythoncoder]

Sorry if I'm being dumb here but I'm struggling to follow the nature of your problem. I've been using the RTC and suspend mode extensively and haven't experienced an issue. To clarify the conditions under which I've tested it, I'm not using Vbat but am powering the Pyboard continuously via Vin. For the lowest power consumption I've also tested disabling the regulator and powering it via 3V3, but again it was continuously powered. I have not tested a configuration where Vbat is provided and the main power source is interrupted. As I said in my previous posts I think you might need to do use the WUTF but this is based on reading not coding

Under the power conditions above the following code works reliably. I set the RTC on initial boot only: the code uses one of the RTC backup registers to ensure that the RTC is set (to a fixed arbitrary value) only after power up: it is not set on subsequent wakeup events and I have tested that it free-runs for the duration that power is applied.

Code: Select all

import pyb, stm
rtc = pyb.RTC()

usb_connected = pyb.Pin.board.USB_VBUS.value() == 1
if not usb_connected:
   pyb.usb_mode(None) # Save power

if stm.mem32[stm.RTC + stm.RTC_BKP1R] == 0:     # first boot
   rtc.datetime((2015, 8, 6, 4, 13, 0, 0, 0))   # Code to run on 1st boot only

 # code to run every time goes here
rtc.wakeup(20000)
stm.mem32[stm.RTC + stm.RTC_BKP1R] = 1 # indicate that we are going into standby mode
if not usb_connected:
   pyb.standby()

I think if I, or anyone else, is going to be able to help you need to provide a concise code sample which doesn't work as you would expect. Also a description of the power conditions under which failure occurs. Unless we can replicate the problem it's hard to offer solutions.

[JimTal001]

My last question was more general, I did not know you were not using the VBAT battery.

If you were to sell a product, like your low power data logger, of course you would not expect your customer to change code (date/time) each time they activate the data logger.

I've had so many issues with VBAT powered I'm thinking it useless to power it.

[pythoncoder]

In my code samples I hard code the RTC's time on initial power up because I am using the RTC omly as a source of wakeup events. I use a radio link to send the data to another Pyboard and it is that second Pyboard which will maintain the time of day.

The purpose of Vbat is to enable the RTC to keep time in applications where the Pyboard is powered down for long periods, like the battery backed clock in a PC. In a continuously powered application like a battery powered data logger the role of Vbat would be to maintain the time for the duration while the main battery was being changed. Arguably this could equally well be achieved with a supercap on the main supply so that the logger was continuously powered. But this wouldn't fix the case where the main battery was allowed to run flat. In a commercial situation there would always be cases where the RTC needed to be set if maintaining an accurate time of day matters.

So you need to devise some mechanism for setting or resetting the RTC, which might involve plugging it into a laptop. @dyhlands' rshell program seems to set the RTC automatically, although I haven't tested this thoroughly.

It's also worth noting that the Pyboard's RTC needs calibration if accuracy is important.

[JimTal001]

It's also worth noting that the Pyboard's RTC needs calibration if accuracy is important

I've noted the time being off over a few days by few minutes.
What would you suggest as the best way to calibrate the RTC?

[blmorris]

For a crude first-order correction, you can measure how far off it is over the course of a day or two and convert that to parts-per-million. You can use that number with the RTC calibration method: http://docs.micropython.org/en/latest/l ... b.RTC.html
If you have access to a high-precision time signal - for example, the pulse-per-second (PPS) output from a GPS - then you can achieve a one ppm calibration in 32 seconds. I wrote some crude code to do part of this job, though it might take some time to find it and clean it up.
-Bryan

Edit: Here is a link to some prior discussion of RTC drift on the pyboard - note that the RTC calibration method was added after this discussion: http://forum.micropython.org/viewtopic.php?f=6&t=598

[JimTal001]

Since I do't have a GPS I'll just try the simple way first.

Thank you