Accuracy of RTC

[loboris]

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.

[jmarcelino]

@loboris very interesting, thank you for sharing that.

Did you try it with the Pycom boards and a crystal on P19 + P20?

[littlebat]

@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]

@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]

@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.

[BluCode]

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.

[jmarcelino]

@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.

[BluCode]

@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.

[Colateral]

@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.

[robert-hh]

@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.

[Colateral]

@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." ?

[robert-hh]

@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.

[Colateral]

@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

[robert-hh]

@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.