Dennis, > No, that addition is a fixed increment on the initial starting > time, and is NOT relative to the ending of a sleep.
> No, that addition is a fixed increment Yep. > on the initial starting time Nope. If pythons sleep is worth its salt it ends exactly on the time provided in "t". Thus the subsequent addition to that "t" is releative to the end of the sleep just before it. > The subtraction in the sleep call is what adjusts for the processing > time between sleeps Yep. /All/ the time in between them. Not just from the "t +=" you mentioned onwards (ignoring the time spend on switching the pin and the loops jumping-back). > ??? Not sure what you describe here My apologies, I should have been clearer. Its the time difference I saw when using a hard 300 uSec delay in the loop (cycle-time longer that 300 uSec), compared to a drift-compensated delay of the same (cycle time exactly 300 uSec). I attributed the difference to the time as spend in the code between sleeps (loop jumping, toggeling of the pin and calculation of the new end time - possibly the sleeps argument calculation too) Regards, Rudy Wieser -- https://mail.python.org/mailman/listinfo/python-list
