[Dprglist] PID-tuned Clock in Python?

[Murray Altheim]

On 19/02/21 6:03 am, John Swindle via DPRGlist wrote:
> Going back to a previous topic regarding jitter in timing intervals.

Hi John,

I was trying to find a paragraph of text that I saw a few days ago on some
web page about how the combination of Linux and Python simply couldn't
provide the kind of precise timing guarantees one can expect on a
microcontroller, and I certainly don't contest that notion, i.e., this
mirrors my own experience.

Just to reiterate the issue (and I hope I've got all this correctly), Linux
is a time-sharing operating system that cannot guarantee precise timing at
an application level, even when the hardware it is running on (e.g., a
Raspberry Pi or Intel 5.3GHz i9) has an accurate system clock, and may even
have access to an RTC -- noting that an RTC provides an extremely accurate
long-term clock but typically provides resolution only down to a second,
not milli- or nanosecond. I.e., an RTC is a bit of a red herring.

So running on a time-sharing OS means that any given application can't be
guaranteed that it will be able to create precise time intervals at a
nanosecond or millisecond level, since the application's code is sharing
system resources with the system itself as well as other applications.

One of those applications is the base Python/CPthon interpreter, which is
an imperfect handler of timing, given its imperfect control of internal
threading.

So an application can ask the system clock for the number of milliseconds
or nanoseconds since the Epoch (1 Jan 1970), and the number returned will
be accurate, but if the application itself is running a timing loop it
will be polling the system clock limited by its time share, not the system
clock. So effectively, the loop will falter but know it's faltering by
being able to compare its time with the system clock.

> Why can't parameters used in calculations be scaled by the actual 
> sample interval? I understand 50ms is chosen because it gives 
> optimum control without undue overhead. When the actual interval is,
> say, 47ms, why not scale the time-related parameters to 47/50 of what
> they nominally are, just for that interval? If the next interval is
> 74ms, scale the parameters to 74/50. Is this impractical? Is the
> uncertainty of measuring the time interval too large? This is, if
> Python says the time interval is 47ms, is the error, say, +/- 10ms?

So given our understanding of the limitations of timing loops within a
Python application running on Linux (i.e., not the operating system's
internal clock), we can assume that with two levels of "indirection" any
clock loop will run imprecisely.

So a 50.00ms loop in Python will return values like 50.01ms, 51.3ms,
49.1ms, etc., and during a surge where another application pulls a lot
of system resources the values might run 54.33ms, 57.56ms, etc. In other
words, imprecise, intermittently and unpredictably so. You suggested
that over a longer period, say several minutes, the average may be close
to 50.0ms but that's not necessarily a safe assumption since the
cumulative values are subject to cumulative error, and that error can
be high. One can compare the value with the (accurate) system clock,
or even with an RTC. But that's not solving the problem, which is having
a very accurate millisecond timing loop.

So the other alternative would be to write code to simply assume an
imprecise clock and capture the per-loop error. The problem is that we
haven't escaped the basic problem of "being in situ" with our code. And
that would also make our code more complicated. A PID controller is
itself already rather tricky to tune. Having an imprecise clock doesn't
make that any easier.

I'm looking into another alternative, since my KR01 has an Itsy Bitsy M4
on board that is currently not being used. I'm thinking of using it as
an external clock, triggering a GPIO pin as an interrupt on the Pi.

Cheers,

Murray

...........................................................................
Murray Altheim <murray18 at altheim dot com>                       = =  ===
http://www.altheim.com/murray/                                     ===  ===
                                                                    = =  ===
     In the evening
     The rice leaves in the garden
     Rustle in the autumn wind
     That blows through my reed hut.
            -- Minamoto no Tsunenobu