This post is a follow up of this older post

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 dynamic performance, 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.

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 dynamic performance, 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, 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

[f,m]=phasemag(repfreq(q,250))

10^(m/20)

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

[f,m]=phasemag(repfreq(q,124))

10^(m/20)

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.