Metro M7: without 32768Hz RTC crystal, RTC timekeeping is not accurate

[twrackers]

I discovered that when a Metro M4 and Metro M7 are running the same code which acts upon a fixed period of time passing (measured by calls to time.monotonic()), my newly purchased M7 claims the time period has completed in only ~85% of the real time required by the M4. Both are sending begin and end messages via serial to a Raspberry Pi 400 which is listening to the serial via another Python code which measures the elapsed times. The Metro M4, as well as a Trinket M0, Gemma M0, and Circuit Playground Express, all come within 1% of the expected time.

Full details can be found in my forum post at https://forums.adafruit.com/viewtopic.php?p=1039811. The test procedure I used, as well as results, are posted there as well.

[twrackers]

Don't know if this is a clue, but the actual runtime was closer to 83% of what was expected, which is very close to 5/6. Maybe some counter or prescaler is specified incorrectly.

UPDATE: Actually a bit more than 5/6 with further testing. Hopefully I didn't just happen to get a defective M7 somehow. Waiting for further word on this.

[joehopfield]

Not a bug (except that monotonic() returning a 32bit float should not exist and I bet most naive uses are incorrect)

The test is misusing time.monotonic(), essentially comparing it across machines, and against actual elapsed time.

from the test:

stop_at = time.monotonic() + time_sec
...
while time.monotonic() < stop_at:
pass

docs:

... Only use it to compare against other values from time.monotonic() during the same code run.

On my esp32-s3 qt-py a loop like that only takes about 8 microseconds, and your M7 is much faster - you're exceeding your 22 bits of precision in monotonic's short-float value.

(IMHO time.monotonic should either throw an exception when this happens or should be deprecated. 32bit float is inherently broken for time.monotonic's very vague semantics)

[twrackers]

So time.monotonic() returns a float which is NOT measured in elapsed seconds? Does time.monotonic_ns() return integer nanoseconds, even if that clock does not have nanosecond resolution? I'm actually trying to pace a loop of code that's running at 10 or 20 Hz while it interacts with code on another Arduino or CircuitPython micro.

I can expect that using too much precision will make the timing not quite periodic, but if monotonic or monotonic_ns are really returning seconds or nanoseconds, the average rate should be about right as long as the master clock oscillator isn't way off.

So what WOULD be a valid way to write a timing loop that forces code to pace itself at a desired rate if I can't trust the monotonic clocks?

[Neradoc]

Your code is correct, it sets a stop time 600 seconds in the future, and waits for that stop time to be reached.
There should be approximately 10 minutes between prints on the receiver side, as you have seen on all other boards.
Since it's only available in the forum post, let me paste it here:

import time

# Test will run for this long, measured by this board's clock.
time_sec = 600

# Allow time for receiving code on Pi to start up.
time.sleep(30)

# Test will stop at this time.
stop_at = time.monotonic() + time_sec

# Change next line to identify board this is saved to.
print("Metro M7")

# Wait for stop time.
while time.monotonic() < stop_at:
    pass

# Identify what the test period was set to.
print(time_sec)

I can use a serial tool like tio with timestamps on to check that the result time does fall within milliseconds of the expected time on all boards I have tried on 9.2.1 (including a Teensy). But I don't have Metro M7 to test.

[00:35:46.584] Pro Micro
[00:45:46.608] 600

[joehopfield]

The docs (https://docs.circuitpython.org/en/latest/shared-bindings/time/#time.monotonic) suggest time.monotonic_ms() for measuring elapsed time safely. (your test code.py would be easy to change).

docs for the monotonic* funcs are inconsistent (is value "always increasing" or "can never go backward"? both descriptions are used) and has at least one typo/error where #monotonic_ns mentions monotonic.

If the M7 has a bug, a monotonic_ns version of the test will make a clean test case.

(I too wish there were better high resolution time control - squashing to milliseconds on 100+mhz cpus feels restrictive)

[joehopfield]

Comparing a change in monotonic() to an external clock would seem to violate the first paragraph of its doc, no?

[Neradoc]

They are measuring a 100 seconds difference on a 10 minutes test, the precision of time.monotonic() is not an issue here. It takes over a day for monotonic() to get it's precision to reach a second. Even then that would be enough to measure 10 minutes with 1% accuracy.

This test is not comparing to an external clock, it's comparing to itself to last 600 seconds.
While the starting point of monotonic() is arbitrary, it's still supposed to measure seconds.

[anecdata]

There is a calibration here:
https://docs.circuitpython.org/en/latest/shared-bindings/rtc/index.html#rtc.RTC.calibration
But it's relatively small and may not be enough to compensate for this.

[joehopfield]

Sorry, I think I believed the "always increasing value" in the monotonic() doc. It is monotonic (never decreasing), not strictly increasing. I read "always" as implying it needed to increment by a ns to always increase.
Looking at the code in time/init.c, I see you're correct.
Sorry again - code > docs. :-P

[twrackers]

This test is not comparing to an external clock, it's comparing to itself to last 600 seconds.
While the starting point of monotonic() is arbitrary, it's still supposed to measure seconds.

@Neradoc is correct.

Metro M7 (device under test): Hello, Pi400, I'm going to use my clock to mark the start and end of what I consider to be a 10 minute interval. Please use your clock and tell the user how long you measured that time period to be. Minor variations from 10 minutes are to be expected.

Pi400: Wow, M7, I clocked you at way less than 600 seconds.

(Sorry, I get a bit dramatic at times. :) )

[twrackers]

From @anecdata :

There is a calibration here: https://docs.circuitpython.org/en/latest/shared-bindings/rtc/index.html#rtc.RTC.calibration But it's relatively small and may not be enough to compensate for this.

I figure if I'm within one or two percent of the expected rate, I'm doing well enough. It's not a precision application I have in mind, nominal rate will probably be 10 Hz.

[twrackers]

From @Neradoc again:

[00:35:46.584] Pro Micro
[00:45:46.608] 600

Using Arduino's Serial Monitor with timestamps:
20:19:42.487 -> Metro M7
20:28:17.790 -> 600

Difference: 515.303 sec, 85.9% of expected 600 sec

(My) M7 is definitely running faster than it believes.