Open bomilkar opened 4 years ago
I have quantified the issue. Maybe it helps making a decision. I have sensord running along with variod, and a FLARM. Counting the sentences in the nmea log from XCSoar I get the following numbers: GPRMC = 1149 POV,P = 11634
So that means for 1149 GPRMC sentences I find 11634 POV,P sentences. That means on average we get 10.125 POV,P sentences per second. (Of course I cleaned up the log to the portion where it had a stable GPS fix and double checked the time stamps of the GPRMC sentences. 1149 GPRMC sentences means precisely 1149 seconds elapsed.)
So with usleep(12500) I would have expected 8 POV,P per second, and even less if we take into account that pressure_measurement_handler() and NMEA_message_handler(sock) take some time, too.
The bottom line: we are really far from a predictable timing.
The PR I put in should address the timing issue by keeping track of the system time when the conversion is initiated and using the difference between the conversion times.
Looking at the inner loop (a bit simplified):
So the time per loop is definitely more that 12.5 msec. I can't say how much time is spend outside of usleep() but there is some I2C I/O involved which takes time, etc.
Have you thought about using a system timer to control the loop? Or is it not so important how much time passes between sensor reads? Think about vario=delta_h/delta_t !