Pitot Lag and Simulation

Some time ago at the airfield playing around with a pressure sensor  with sample rate of 50 Hz I noticed a really poor unexpected performance of my carbon fiber Pitot. You know, the measure system is quite simple, one digital pressure sensor connected to an Arduino board, two pressure lines , the static pressure port and the total pressure port. I ended the post fly analysis with a sole sure fact, I haven’t a math model for the pneumatic transmission line. I needed such a model to calculate the relationship between the amplitude of the port pressure and the pressure at sensor at different frequencies, syntetically I needed the transfer function. With a transfer function it is straightforward to determinate the overall measurement system performance and even compensate for undesired transmission line behavior. Refer to the below figure 1 for the schematics of a pneumatic line.

Figure 1 Pneumatic line layout

Input pressure cannot be present at the very same time at the pressureport and at the sensor port, it take some time for the pressure wave to propagate trough the transmission line.

At last I found a text where the authors integrated the Navier-Stokes equations to achieve a closed form solution, from now on I will proceed according to reference[1] [Theoretical and experimental results for the dynamic response of pressure measuring systems] .
Is very important to considerate the model assumptions, here below  the list from [7] pag 7

Length/Radius >> 1
Variable nominal values variations are small
Laminar flow inside the tubing

To get a numeric example let’s pretend we have the following, possible,  parameters values

Internal radius R of line [1 ; 2 ; 3] mm
Length of pressure line L 0,6 m
Volume of the sensor Vu 50e-9 mm^3

Let’s consider now three different cases from the same base design, only variable is the line internal radius R, results plotted in the decimal scaled graphic below.

Figure 2 Frequency response of pneumatic line

 You can download the scilab source here
By inspection of the figure it’s correct to assert that if the radius increase the frequency of resonance is increased too, with a wider transmission line volume the pressure transmission and the resonance have a higher magnitude. Without correcting our sensor readings we can use only frequencies that have a gain equal to unity, so it’s clear that transmission lines can have a heavy impact on the performance, according to figure 2 we can use safetly frequencies under 15 Hz.
During the use of an instrument in non steady conditions the frequency of pressure variation at pressure ports should be considerate, if not you probably will waste resources using better sensors of pressure and have poor results. Operating with a wider bandwidth may have some drawback, the first of all is some degree of increased vulnerability with respect to unwanted pressure oscillations due to buffeting or eddies.
In figure 1 schematics the transmission line have a constant diameter, by experience, that it’s more common to have at last one variation in the line diameter, this case is well covered by papers and maybe worth a future post.
Reference [7] have a plethora of figures that illustrate different cases, also the conclusion section is quite clear and concise, of course it worth the time to read through it.
So at the end the problems that I’ve got in the past can be explained, and some times avoided, taking into account the dynamic of the pneumatic line.


Simulation is one of the basic tools for modern instrumentation design. Numerical simulation can be used during early design stage as well during the final integration phase. It’s a very ductile tool and due to it’s intimate mathematical nature can take different forms. Even more the same software can carry out simulation, do software in the loop and hardware in the loop tasks so development of complex systems is really speed up. Simulation is also needed, for example but not only, during system identification and data validation tasks. l will show how to make a simulation of a DIY Pitot tube with Scilab, model parameters will be setup in a mparam.sce file that must be run prior to Xcos simulation. The working hypothesis from now on is that electronics devices included in the measure chain are so fast that do not have practical impact on overall dynamicperformance, other assumptions and data come straight forward from previous pitot analysis. I will use Scilab Xcos as simulation software but everything shown here can be ported to a different simulation software. Xcos use a block paradigm, that means that every block have well defined inputs and outputs, so it’s quite natural to implement system dynamics with transfer functions. Just to mention it, a different approach is that proposed by Modelica , here the simulation models are defined directly with equations, that’s no needed anymore to decide at priori what variable will be an input or an output. It’s available a free Modelica modeling and simulation environment that’s called Openmodelica . I warmly advise you to give it a try.

Models and simulations can be setup in different ways, I’ve chose a Xcos block intended for continuous time simulation in the optic that usually it will be integrate in a closed loop regulator. Refer to the following figure for a possible layout that can use our Pitot block. The scheme is quite simple as our goal is to describe pitot model usage
Figure PS.1 Pitot as primary sensor for longitudinal speed regulator
At first our concern is to have a good math representation of the physical behavior of pitot tube, that information can be gathered form previous analysis . At glance the predominant phenomenon is the pressure lines pneumatic lag. The reference shows how to calculate the response of the system at different frequencies, the used math model was validated by the authors with experimental data so it’s safe to rely on it. Albeit the reference report exactly the relationship between input and output pressure it’s comfortable to have that information under the form of a linear low order transfer function. Since we dispose of the behavior of pitot tube in the frequency domain it’s possible to identify a transfer function that lead to this behavior, it’s possible to use the Scilab command
fdt=frep2tf(frequencies,modelResponses,orderDesired) that returns directly the searched transfer function with the order (2)desired.
Identification is good(under certain aspects), you can visualize it running this file (scilab mparam.sce) with the “graphics” variable set to 1, you will get the following figure output.
Figure PS.2 Original frequency/magnitude relationship in black superimposed with second order identified transfer function in blue
When the frequencies are under 8Hz the pressure present at the sensor is exactly the pressure at the port, as frequency increase the transmission line act as an amplifier up to the resonance frequency (in the figure PS.2 125,5 Hz). When the resonance peak effect is vanished the pneumatic line act as an attenuator. You can have a look to the transfer function issuing the command ‘q’ at the Scilab command prompt, look also at the root locus with the command evans(q). Note that the transfer function is stable but have a positive zero, so we have a system that have no minimum phase, we will refine our system identification and usage in a future post.
Now that the we have focused on the modeling problem let’s setup a simple Xcos test layout, check the following figure for the proposed open loop test bench. For your ease download Xcos file here, parameters are those contained in Scilab file, that you should run before Xcos simulation.


Figure PS.3 Open loop test bench layout
The operating conditions block generate a IAS periodic waveform, to reproduce some kind of gusting(link) at the desired frequency, and supply the pitot static port with the current atmospheric pressure. Scopes section collect IAS from operating conditions, real world status, and from pitot reading, with this data the plot of Pitot error=(IASreal-IASPitot) can be visualized.
Figure PS.4 Pitot block detail
In figure PS4 you can have a look to the pitot block internals. First block rebuild the total pressure at total pressure port using input IAS, so it passes Total pressure Pa and Atmospheric pressure Pa to the Sensor block. Sensor block mimic the conversion of differential pressure at ports in IAS speed, this include pneumatic lag on static and total pneumatic lines. Random generator injects a gaussian distribuited value, the mean is 0 and the deviation corresponds with pitot calculated deviation (0,2 m/s), in early design stages this random generator can be turned off. Please be sure that the frequency of noise signal is consistent with the band of interest, noise is a very sensitive topic. Regarding sensor block please note that pneumatic lag impact on the static line is of little magnitude or zero is the atmospheric pressure is slowly changed or held constant, it can be found by inspection of following figure.


Figure PS.5 Pitot block pneumatic lag detail


Now is time to experiment with some input gusts, it’s better to turn off noise setting deviation to 0, measurement noise will always generate a tainted output waveform that need to be statistically interpreted.

See PS.6 for the IAS pitot error, IAS is a step of 20 m/s at 0 s, after the transitory period IAS real = IAS pitot so IAS pitot error is zero.

Figure PS.6 Input frequency 0 Hz, step 20 m/s. IAS pitot error [m/s]
Now set to 250 Hz the input frequency, your simulation should be like that of figure PS.7
Issue the following Scilab commands
you should get 0.7708058, note that phase is -172° so the two signals are almost opposite in phase.
By inspection of figure PS.7 max black value variation is 21-19,995 = 1,005, at the same time instant t=0,117 max green variation 20-19,222=0,778 so we have a magnitude of transfer function equal to 0,778/1,005=0,774 that is according to our attended value.
Figure PS.7 Input frequency 250 Hz, step 20 m/s. Real IAS [m/s black] Pitot reading [m/s green]
Make another run with the input set to124 Hz sine signal, just to check calculate at the command line
You should get 5.95 that is the ratio between output amplitude and input amplitude, you should read the same values on the simulation plot.
You have the pitot math model so you understand what frequencies will be distorted, if you integrate the pitot block into your air platform simulation you can determine if your instrument setup can be used in any particular flight condition of your choice.
A strong conservative approach is do not rely on pitot data if is expected to exceed the unitary gain band frequency, doing so you can trash every Pitot dynamic information and substitute the pitot with a unary gain block. Complexity increase when you eventually need higher working frequencies, for example for a rotating head pitot setup. For my average application I usually go in the conservative way.
H. Tijdeman, “Theoretical and experimental results for the dynamic response of pressure measuring systems by H.Bergh and H.Tijdeman.” Unpublished, 1965 [Online]. Available: https://doi.org/10.13140/2.1.4790.1123