Imp.wakeup(float, function) - timing issue

Has anyone used imp.wakeup() for any tight timing issues and had problems? The imp documentation says the following:

The timer has only centisecond (0.01s) resolution: a call to imp.wakeup(0.0, function) acts like imp.onidle(function), while a call to imp.wakeup(0.000001, function) acts like imp.wakeup(0.01, function).

I’m talking to devices at various baud rates (300-19k2). Some devices have specific spacings between frames and bytes. I’m finding that the float values that I’m passing to the imp.wakeup seem to be rounded down, rather than rounded up as the documentation suggests. I’m aware that imp.wakeup performance is affected by other squirrel routines and internal servicing of other imp functionality, but I would then allow for the fact that the wakeup could trigger AFTER the time I’ve specified. Instead, I see it trigger BEFORE the time I specified, which can be problematic. before For example, if use imp.wakeup(0.006875,timeoutFunc), the callback is invoked within 1-4ms. I would have expected circa 10ms.

I’ve looked at the code, and I believe this is due to the current time being quantized in 10ms periods too, ie the ticker might be just about to tick when you set the timer.

ie, if the current elapsed time is 1.019 seconds, and you do a 0.01 second imp.wakeup, it will fire at 1.02 seconds - this is because as far as the system is aware, the current time is 1.01, and 1.01+0.01 = 1.02.

Does adding 0.01 to your wait value work in this application? You could also check the time with hardware.millis() if required, and sleep again if it fires too early.

Yes, if I ask for 0.02s, I’ll get something between 0.01 and 0.02. I’ll add a compensating amount, but I think the documentation or the imp code should be changed to be consistent.
Ideally, if I ask for imp.wakeup(0.02,func), I should be confident that that is a minimum. Currently, it could be more or less, depending on how loaded the imp is with other tasks.