Timer Timeout Accuracy

I have a timer set for 5,000ms timeout and when the handler is called I have a log print statement. Looking at the time between print statements I can see the handler isn’t being called at 5,000ms rate. Sometimes the delta is 10,000ms or 20,000ms. Any thoughts as what could cause the thread to be held up.

Thanks,

Hey @dbeckwith,

Could you provide a minimum working code sample? Generally late timers are caused by other synchronous calls blocking the timer handler routine.

Cheers.

Is this timer running in an app that is doing other things? If the thread is handling other events your timer will be delayed

@nvd, @dfrey

Thanks for responding. The code is a simple timer setup to drive a state machine. I am using this model to make our sensorToCloud app more robust to potential network and AirVantage issues.

The only calls (which I assumed would be asynchronous) are to le_avdata_RecordX() and le_avdata_Push().

Thoughts about how best to diagnose the issue?

Hey @dbeckwith,

I’ve found the best approach for debugging these issues is to start removing dependencies (largest to smallest) until you see the behaviour you want (even better if you have an automated spec/unit test). After that you can investigate the dependency in isolation. I would start by removing the dependency on the AirVantage service by removing calls to le_avdata (or you could mock them out with simple print routines).

If you have unit tests, I would suggest making a new git branch where you remove one dependency in each commit. Then you can use git bisect to run your tests against each of these commits and identify when things are within the spec again.

Pay close attention to which services are connecting/disconnecting and in what order. There is command to essentially perform an ls of all service connections/bindings (different from app status) along with their state (running, stopped etc). I can’t recall this command but perhaps @dfrey or an old forum post could show it.

Happy hacking,
Nick

@nvd

Thanks for the tip. It turned out that some analog sampling was taking longer than our update interval.