Pyboard D RTC accuracy

The official PYBD running MicroPython, and its accessories.
Target audience: Users with a PYBD
Post Reply
User avatar
pythoncoder
Posts: 5956
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Pyboard D RTC accuracy

Post by pythoncoder » Thu Jan 16, 2020 7:36 am

[EDITED]
I measured this against a DS3231 precision RTC using two samples, an SF2W and an SF6W. The SF2W was out by 8ppm which is about 4mins/year, the SF6W was spot-on. Note that the DS3231 is rated at +-1 minute/year.

Code used may be found here: ds3213_port_test.py.
Peter Hinch
Index to my micropython libraries.

chuckbook
Posts: 135
Joined: Fri Oct 30, 2015 11:55 pm

Re: Pyboard D RTC accuracy

Post by chuckbook » Thu Jan 16, 2020 11:57 am

This sounds too good to be true. Doesn't the DS3231 datasheet claim +/-2 ppm which (roughly) means +/-1 min/a?
Anyhow, this is still a very good result.

User avatar
pythoncoder
Posts: 5956
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: Pyboard D RTC accuracy

Post by pythoncoder » Thu Jan 16, 2020 2:04 pm

Apologies, you are right and that message was a complete pig's ear :( To avoid confusion I'm editing it to present correct results.
Peter Hinch
Index to my micropython libraries.

User avatar
MostlyHarmless
Posts: 166
Joined: Thu Nov 21, 2019 6:25 pm
Location: Pennsylvania, USA

Re: Pyboard D RTC accuracy

Post by MostlyHarmless » Thu Jan 16, 2020 6:35 pm

Note that the DS3231 has an "aging" register that can be used to adjust the TCXO slightly. The register is a signed 8-bit value and controls a capacitor array that is part of the crystal's load capacitance. The DS3231 documentation states that one LSB of the register equals approximately 0.1ppm speed up or slow down.

I am working on code that sets a DS3231's time based on a NEO-6M GPS receiver and then uses both module's PPS signals and the aging register to slew the DS3231 to within 1us of difference with maximum 0.2ppm drift. Once adjusted that precise the DS3231 should be reasonably good as a time source for a month or so.

At the heart of the slew process is a function that I added to my MicroPython checkout. time_pulse2_us(). Like the existing time_pulse_us() it measures the time in us between one edge and another. However, it takes two pins and levels plus a timeout as arguments. The result is microseconds from pin1 transitioning to level1 until pin2 transitions to level2. If pin2 transitions first the result will be negative. A timeout will raise an exception.

User avatar
pythoncoder
Posts: 5956
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: Pyboard D RTC accuracy

Post by pythoncoder » Fri Jan 17, 2020 8:42 am

I can see many uses for machine.time_pulse2_us() for example in digital phase locked loops. Have you considered submitting a PR?

I hadn't considered syncing a DS3231 to GPS. Neat. I used it as a reference time source for calibrating a Pyboard 1.x RTC to achieve typical "wall clock" precision. Clearly your solution is an order of magnitude more precise ;)
Peter Hinch
Index to my micropython libraries.

User avatar
MostlyHarmless
Posts: 166
Joined: Thu Nov 21, 2019 6:25 pm
Location: Pennsylvania, USA

Re: Pyboard D RTC accuracy

Post by MostlyHarmless » Fri Jan 17, 2020 1:17 pm

pythoncoder wrote:
Fri Jan 17, 2020 8:42 am
Have you considered submitting a PR?
I have. There is one small problem left with it that I still haven't figured out how to minimize.

The whole thing is obviously based on two while() loops, the first waiting as long as both pins are unequal the requested levels, the second waiting until both are and taking microsecond ticks between and at the end. Apparently the time it takes to break out of the first loop, taking the current ticks and entering the second loop is about 6us. This doesn't feel right and I am still wondering where my code is spending that much time.


Regards, Jan

Post Reply