Openvario / sensord

Daemon to poll air data from Openvario sensorboard
6 stars 11 forks source link

timing of the inner loop not well defined #9

Open bomilkar opened 4 years ago

bomilkar commented 4 years ago

Looking at the inner loop (a bit simplified):

        // main data acquisition loop
        while(sock_err >= 0)
        {
            usleep(12500);
            pressure_measurement_handler();
            sock_err = NMEA_message_handler(sock);
        }

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 !

bomilkar commented 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.

hpmax commented 4 years ago

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.