More accurate time reporting

[dhalbert]

Several users have asked for time reporting that's more precise than the millisecond ticks provided by time.monotonic(). Use cases and proposals welcome here.

[CameronDevine]

I was attempting to work with a 433Mhz radio transmitter which required writing to a pin at 200 microsecond intervals. Even if a function similar to the Arduino micros() had less than 1 microsecond resolution this would allow time calculations that are not possible with the time.monotonic() function.

[tannewt]

@CameronDevine Interesting! How much data do you know you need to write ahead of time? Something like PulseOut might be adequate. It looks like it requires a carrier PWM signal though it could just be constant.

[dhalbert]

came from here: asking there as well: https://forums.adafruit.com/viewtopic.php?f=60&t=129222

[l8gravely]

I too would like to see something better than monotonic, since it's not stable and loses precision as time goes on. Or maybe I just need to learn the CircuitPython way to do longer term ramping up/down of a NeoPixel, while not doing a busy wait, so I can handle other inputs that come in.

Right now I just try to do:

timetofire = timer.Monotonic() + delay
while True:
now= timer.Monotonic()
if (now > timetofire):
timetofire = now + delay
# do NeoPixel incremental update here

continue on looking for keyboard input, etc.

Does this make sense? I also wish it was more clearly documented what resolution monotonic is counting in, since it's not quite seconds, but maybe milliseconds?

[tannewt]

@l8gravely On the SAMD21 it is millisecond.

I'm still unsure we want to provide precise timing because we pause the VM from time to time to do other things. I'm worried about making timing promises we don't always keep. If we did, I think we could introduce a precisetime module for it.

@l8gravely also follow #619 for a different way to do things concurrently.

[CameronDevine]

Would it be possible to have a variable which states the approximate interval at which time.monotonic() is increased? This would save people form having to write code to guess what the interval is, since it appears to change based on which board is being used.

[jepler]

like @l8gravely I want a monotonic time source which doesn't lose precision. In my project, I want to show the seconds and fractions of seconds based on NTP time, but it starts to lose precision as the monotonic() value gets large.

For me, directly exposing common_hal_time_monotonic(), possibly via the microcontroller module, seems like a good first step. I'm not sure whether exposing it as a 64-bit value (restricting it to devices with support for longs) is better, or exposing it as unix-style (seconds,microseconds} is better. The latter is sure less convenient for doing math on, and forces the choice of a fractional second size of microseconds or coarser (rather than nanoseconds or 2^-32s) in order to avoid overflows while doing arithmetic (+, -) on timestamps with limited integer precision available.

[tannewt]

I was thinking we could add a precise_time module too.

[margaret]

I'm going to take a stab at this (pycon sprints)

[CBMalloch]

I'm trying to sample a 1kHz modulated light beam at 100µs intervals. About every 1/32 sec I go into a coma for almost 1/32 sec while the system does its other things. More precise timing would not help unless we also had a "suspend the other system things for a mo while I do this time-critical thing" function...

[tannewt]

@CBMalloch how is the light beam being interfaced to the microcontroller? We may be able to add a C helper for it.

It's highly unlikely we'll ever allow for predictable timing in Python execution. There are too many critical things happening around the VM to do it.