RTC Clock calibration question
RTC Clock calibration question
I found that my pyboard RTC clock is running 70 second slower than my PC clock (adjusted by network) over a 1 hour test period.
That is 70/3600 -> 1.9% -> 19000 ppm. As per the documents it is only adjustable from -488 to +488 ticks.
What is the adjustment method in this case?
Note: my cpu is running at 120 mHz
That is 70/3600 -> 1.9% -> 19000 ppm. As per the documents it is only adjustable from -488 to +488 ticks.
What is the adjustment method in this case?
Note: my cpu is running at 120 mHz
Re: RTC Clock calibration question
That is much too far off for a properly functioning RTC crystal; if correct, it seems like something is broken.
There have been some other reports of RTC measurements on different pyboards, all of the measured offsets were reported to be less than 200ppm, or a few seconds per day (which is still a lot for this kind of crystal.)
-Bryan
There have been some other reports of RTC measurements on different pyboards, all of the measured offsets were reported to be less than 200ppm, or a few seconds per day (which is still a lot for this kind of crystal.)
-Bryan
Re: RTC Clock calibration question
I verified my results again with an over night test. Over a total test time of 57849 sec (16 hr) the RTC lost 1079 second.
1079/57849 -> 1.86% -> 18,600 ppm
In boot.py I have: pyb.freq(120000000)
I am using the following code which uses standby() and a 10 sec sleep between wake and print the current time.
1079/57849 -> 1.86% -> 18,600 ppm
In boot.py I have: pyb.freq(120000000)
I am using the following code which uses standby() and a 10 sec sleep between wake and print the current time.
Code: Select all
import pyb, stm
import micropython
rtc = pyb.RTC()
sleepTime = 10000 # in ms
def main():
if (stm.mem32[stm.RTC + stm.RTC_BKP1R] == 0): # first boot, Code to run on 1st boot only
rtc.datetime((2015,10,19,1,16,45,0,0))
print(rtc.datetime())
print(rtc.datetime())
rtc.wakeup(sleepTime)
stm.mem32[stm.RTC + stm.RTC_BKP1R] = 1 # indicate that we are going into standby mode
pyb.standby()
main()
Re: RTC Clock calibration question
I assume that you have your REPL on one of the UARTs rather than on USB? The 'standby()' command will kill any USB connection, of course.
Asking because I would like to replicate your setup to see what I get. I know that the RTC on my board runs closer to real time, and going into standby mode shouldn't affect the RTC, but I would like to check.
-Bryan
Asking because I would like to replicate your setup to see what I get. I know that the RTC on my board runs closer to real time, and going into standby mode shouldn't affect the RTC, but I would like to check.
-Bryan
Re: RTC Clock calibration question
Hello Bryan,
In boot.py I have:
I am running a test now with the CPU running at 168 MHz and after 1 hr it appears that the RTC is off by over one minute.
My next test is to not use suspend() mode. I will report findings.
In boot.py I have:
Code: Select all
import pyb
import micropython
pyb.usb_mode(None)
uart = pyb.UART(4,115200)
pyb.repl_uart(uart)
pyb.main('time_cal.py')
My next test is to not use suspend() mode. I will report findings.
Re: RTC Clock calibration question
Bryan,
I removed suspend() from the code, as follows:
and after 1-1/2 hour, the RTC offset from the PC clock is virtually nil. Therefore, there must be a bug related to suspend() mode and the RTC clock.
Note: my RTC clock is not currently powered by VBAT
next test: Power VBAT and use suspend() mode.
Results of Test: VBAT power does not fix issue.
I removed suspend() from the code, as follows:
Code: Select all
import pyb, stm
import micropython
rtc = pyb.RTC()
def main():
while True:
print(rtc.datetime())
pyb.delay(10000)
rtc.datetime((2015,10,20,2,10,35,0,0))
main()
Note: my RTC clock is not currently powered by VBAT
next test: Power VBAT and use suspend() mode.
Results of Test: VBAT power does not fix issue.
Re: RTC Clock calibration question
JimTal001 - That is good news, in a way; at least the RTC hardware on your board isn't broken or defective.
I come to the same conclusion as you, software bug in the interaction between pyb.standby() and pyb.rtc()
The thing to do now is to open an issue on GitHub with a simple code example to replicate the issue (what you have pretty much done here.) I could open the issue for you if you don't want to do it yourself, but you ought to get credit for finding it
Unfortunately I haven't had a chance to run your tests myself and won't get to dig in to it today, but this is certainly solid enough to report.
-Bryan
I come to the same conclusion as you, software bug in the interaction between pyb.standby() and pyb.rtc()
The thing to do now is to open an issue on GitHub with a simple code example to replicate the issue (what you have pretty much done here.) I could open the issue for you if you don't want to do it yourself, but you ought to get credit for finding it
Unfortunately I haven't had a chance to run your tests myself and won't get to dig in to it today, but this is certainly solid enough to report.
-Bryan
Re: RTC Clock calibration question
I will do so but don't know the official path to open the issue. I'll dig around for it.
Re: RTC Clock calibration question
Goto https://github.com/micropython/micropython and then click on "Issues" over on the right hand side (<> Code should be selected by default).
Once there, you should find a green "New Issue" button. To paste in code, use triple backticks, something like:
The word python after the triple backticks tells it what language the block is (you can also just use triple backticks with no language specified). If there is a language specified it will try to colorize it using language specific knowlegde.
Once there, you should find a green "New Issue" button. To paste in code, use triple backticks, something like:
Code: Select all
```python
print('Your python code here')
```
Re: RTC Clock calibration question
Thanks Dave,
Currently I'm testing pyb.stop() to see if it behaves like pyb.standby(), after this final test I'll report the issue.
Addon: The mode pyb.stop() does NOT have this issue. Issue uploaded to GitHub (#1523)
Currently I'm testing pyb.stop() to see if it behaves like pyb.standby(), after this final test I'll report the issue.
Addon: The mode pyb.stop() does NOT have this issue. Issue uploaded to GitHub (#1523)