Accuracy of RTC
-
Has any testing been done on the accuracy of the RTC, especially while in deep-sleep mode? How accurate is the wake-up time that's passed in the deep_sleep() call?
Will the external 32KHz crystal be supported in the near future? And if so, what is the expected accuracy of the RTC with the crystal?
PS - I'm not clear on what clock source is used by the ESP32 in deep-sleep mode, especially if there is no external 32KHz crystal.
-
@Colateral I used the same circuitry (10 pF capacitors) and a crystal with 12.5 pF load capacitance. The model is called MS1V-T1K from Micro Crystal Switzerland. It was the one easy to get from a local store. The 12.5 pF load capacitor would lead to ~22pF C1 C2 capacitors. Since I have a set-up with the LOPY4 development board + a carrier board +..., there is already a lot of unknown stray capacitance. Therefore the 10 pF work. I did however not run a test over a day yet to see the clock drift. I just measured the frequency of the crystal while running. But I can do this time drift test in the next days.
-
@robert-hh said in Accuracy of RTC:
You can slightly vary the frequency of a crystal by changing it's capacitive load. It is however anyhow difficult to get the crystal working with a development board, since the capacitive load is not known and may vary when moving the device. Actually I could net get stable oscillation when trying it once.
Edit: I repeated the test, and the oscillator worked, even with a little low amplitude of 400mV. The frequency seems OK. Observing it with an SDR shows 32768 Hz at a resolution of 0.1Hz. Note that FiPy is using the XTAL pins for the LTE modem.Thank you Robert. Can you point me which crystal and electrical schema (capacitors) have you use for this ? ... or FiPy used crystal and capacitors. I used the below schema with L04 ... but seems that I'm loosing 30s / day
The cristal and capacitors and L04 are on PCB mounted by a pick and place machine
-
@Colateral You can slightly vary the frequency of a crystal by changing it's capacitive load. It is however anyhow difficult to get the crystal working with a development board, since the capacitive load is not known and may vary when moving the device. Actually I could net get stable oscillation when trying it once.
Edit: I repeated the test, and the oscillator worked, even with a little low amplitude of 400mV. The frequency seems OK. Observing it with an SDR shows 32768 Hz at a resolution of 0.1Hz. Note that FiPy is using the XTAL pins for the LTE modem.
-
@robert-hh Thanks robert. It is not clear for me if you set RTC(0,RTC.XTAL_32KHZ) at the beg of program (main) , if pycom is working with this RTC.XTAL_32KHZ config. when is called utime.localtime() or is working with internal oscillator. I made a test and seems that both are working the same.
Can you explain how " You may get better precision by trimming it." ?
-
@Colateral 1 sec/day is a deviation of ~12ppm. That is within the typical tolerance of a crystal. You may get better precision by trimming it.
-
@jmarcelino I used an external 32Khz cristal on P19, P20.
I set first line of main, rtc= RTC(0,RTC.XTAL_32KHZ). I let the board powered monitored the time over 3 days and after that period I observed a delay of almost 3 secs (utime.localtime()) over the ntp time. I believe is a bug in the RTC using RTC.XTAL_32KHZ configuration
Another question: after machine.deepsleep(1) ... it is required always to reinit RTC(0,RTC.XTAL_32KHZ) ? ... or once keeps RTC.XTAL_32KHZ until hard reset or power off.
-
@jmarcelino My goal is to make a watch, so I unfortunately don't have space for that. I guess I will have to wait and see what the devs do, and maybe make my own micropython port.
-
@BluCode
I recommend you use an external RTC for now for those applications.For example the DS1307 is easy to interface over I2C and very very cheap (full module inc external eeprom can be had for <$1 http://www.ebay.com/itm/Arduino-I2C-RTC-DS1307-AT24C32-Real-Time-Clock-Module-For-AVR-ARM-PIC-SMD-/170910326110
Also it's self-battery powered, it'll keep the time for many years with issues caused by firmware upgrades or others.
-
If at all possible it would be great if there was an option to keep the RTC powered during deepsleep, as I will be using my board in an application the needs to know the time (or some relativity accurate estimation of the time) immediately after waking from deepsleep, in some cases without internet.
-
@loboris
Thanks, was just catching up with the ESP32 forum myself."Note that we are observing issues on some boards with 32k xtal startup time... That's part of the reason why you don't see 32k xtal support in master yet. We are now working these issues."
https://www.esp32.com/viewtopic.php?p=7269#p7269
So wait and see I guess.
-
@jmarcelino said in Accuracy of RTC:
@loboris very interesting, thank you for sharing that.
Did you try it with the Pycom boards and a crystal on P19 + P20?
I've tested it with SparkFun ESP32 Thing. The 32.768 Khz crystal is connected to 32K_XP&32K_XN pins (P19+P20 on Pycom) so it should work on Pycom boards the same.
The changes has to be made in couple of source files, I think it's better to wait the esp-idf team to finish the job. I've tested it with deep-sleep example and it works much better than with 150KHz wich has error of ~10%.
-
@jmarcelino said in Accuracy of RTC:
In either case I don't think there is, for now, an intention to keep the time updated on the RTC while in deep sleep. The recently announced deepsleep shield for example seems to turn everything off.
Yes but only for the pycom device revisions with the hardware issue. Of course soon there will be new revisions and some of us run on other hardware so hopefully it is flexible.
-
@loboris very interesting, thank you for sharing that.
Did you try it with the Pycom boards and a crystal on P19 + P20?
-
In the latest esp-idf there is the code for enabling RTC with external 32.768 crystal, but there are still some bugs and incompleteness. components/esp32/cpu_freq.c, for example, has a bug (probably left there intentionally because of incompleteness in other code). I have tested it, and very precise time is kept during the deep sleep, so I expect the complete code to be available soon.
There is also an option in menuconfig to select external 32.768 xtal.
-
@littlebat
That may well be true and thank you for your thoughts on it. The ESP32 documentation isn't very clear and I was going by this http://esp-idf.readthedocs.io/en/latest/api/system/deep_sleep.html"RTC controller has a built in timer which can be used to wake up the chip after a predefined amount of time. Time is specified at microsecond precision, but the actual resolution depends on the clock source selected for RTC SLOW_CLK. See chapter “Reset and Clock” of the ESP32 Technical Reference Manual for details about RTC clock options.
This wakeup mode doesn’t require RTC peripherals or RTC memories to be powered on during deep sleep."
In either case I don't think there is, for now, an intention to keep the time updated on the RTC while in deep sleep. The recently announced deepsleep shield for example seems to turn everything off.
-
@jmarcelino No I don't think that's true. The RTC counter IS used for deep sleep and the "simple timer" is just a threshold register which is loaded with the current RTC value + timer value.
https://github.com/espressif/esp-idf/tree/master/examples/protocols/sntp
-
@Eric24
The RTC doesn't operate in the deep sleep with timer wake up mode. The ESP32 only maintains a simple timer for the wake up trigger.The wake up time for the deep sleep is specified in microseconds, but I believe the clock for that is only 150 KHz.
It's all in the "Reset and Clock" section of the ESP32 Technical Reference.Also at wake up the ESP32 will have to reboot and reload the MicroPython task including your code so there'll be a relatively large and possibly variable delay depending on firmware version and other startup factors.
The hardware does support higher power modes with the full RTC enabled but not the software yet. If you need accurate time you could use an external RTC chip or re-syncing time, for example via NTP, at start.
