Wednesday, June 19, 2013

Pitot Simulation block

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.

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

Wednesday, June 5, 2013

I've just uploaded the sketch for Arduino board to drive the 8mm Hemispherical Pitot tube. Following the website indications you can make your own Pitot tube from the ground up. Experimental data have been added.

Please find

Proposed velocity probe can be straigh forward used with other micocontrollers.