Pitot driver timing inconsistencies for I2C sensors (MS4525, DLVR_L10D)

[jmajew]

Recently I have started to write a driver for DLVR-L10D (currently it seems to work quite well) and during testing I have found a bit puzzling behavior related to scheduler.

INAV

The general pitot reading thread is scheduled with 100Hz (10ms) but according to logic analyzer it takes total ~40ms.

There are two packets - first to wake all (my understanding) and data read:

[2] is dummy read (to force wake all, I guess):

[10] is data read - it reads 2x 4 bytes of data

Timings - [2] to [10] ~20ms and [10] to [2] ~20ms = total ~40ms

In short the inav algo for any pitot sensor looks like:

pitot.start(..)            <- dummy read to potentially wake sensor (e.g., MS4525)    
ptDelayUs( pitot.delay)    <- delay is set to 10ms
pitot.get(..)              <- read dpressure

pitot.calculate(..)
filter(..)
ptDelayUs( pitot.delay)    <- delay is set to 10ms
airspeed calculation

The thread by itself has total 20ms delay so there is no chance to fit into requested 10ms.
The same situation happens for DLVR-L10D driver - even if function start(..) is empty.

Ardupilot

To have some reference I have looked at ardupilot which imho is much cleaner. In short, the pitot read is scheduled every 20ms and checking with analyzer it is executed, as requested, every 20ms.

On the output from logic analyzer there is also communication with baro ([4], [16]) and mix ms4525 and baro [20].

The communication with ms4525 is - read 2x 4bytes and write dummy byte (wake all)

according to the algo:

if _first_time_
  _measure()      <- dummy read/write to potentially wake sensor

if _time_from_last call_ > 10ms
  _collect()        <- read dpressure
  _measure()        <- dummy read/write to potentially wake sensor

Conclusion?

I would then propose to reorganize the inav pitot algorithm such that function start would be dropped (now is used only by ms4525, (even driver for dlvr_l10d does not need it) and rearrange rest in such way that the final communication would be similar to that from ardupilot. What do you think all about this?

In case I can volunteer to do this fix. I already have ms4525 and dlvr-l10d sensors so I can run tests for both i2c pitot sensors.

[jmajew]

Apparently everyone is on vacation :).

I have done the rewriting of the pitot sensor and together with driver for DLVR-L10D I am planning to submit a PR (after thorough cleaning...)

After the changes

I have set in fc_tasks.c the desired refresh period to 12ms and here is communication according to logic analyzer:
MS4525

and DLVR-L10D

The both follow quite closely the required value.

The detailed communication looks like:
MS4525

and DLVR-L10D

wchich is more or less the same as it is on ardupilot.
The MS4525 ardupilot packet was shown in previous message and the ardupilot analyzer output for DLVR-L10D is here:

apparently they look the same.

Filtering

During playing with pitot driver I found a small issue related to the calibration of the pitot sensors. The calibration was using filtered pressure with the result that estimated pressure zero was usually too small. At least that was the case for DLVR-L10D sensor. After moving the filtering process out of calibration loop the results have improved.

I rises a point for discussion if it would be beneficial to add also filtering on final product i.e. air speed or not.