jsbsim-devel — JSBSim development issues

[Jsbsim-devel] Trim options in initialisation file

[Sean M. <se...@se...>]

Hi

Is there a specific reason why the only trim options available in the initialization file are 'ground trim'  and no trim?

- trim (0 for no trim, 1 for ground trim)

Cheers

[Jsbsim-devel] fcs/{left, right}-brake-cmd-norm used directly for brake output

[Michael D. <mik...@gm...>]

fcs/{left,right}-brake-cmd-norm drive the brake groups directly. And
they are command properties, written to by FlightGear controls. That
means there is no way to model brake serviceability and brake
regulator/antiskid entirely in JSBSim without relying on external
logic and fragile hacks.

Case in point: in Tu-144 I had to make external aliases
fcs/{left,right}-brake-inp-norm for FlightGear controls, and overwrite
the -cmd- props with the <output> tag of the brake logic's final
function, because it somehow refused to work if I put it directly in
its name="" instead.

On FlightGear mailing list I was suggested to take -brake-cmd-norm as
input in some function and also put <output> of the same function
there. That would probably work, but it is unobvious to whoever might
discover this code later. Moroever it can break if something in the
way properties are handled changes.

Kind regards,
Mike

[Jsbsim-devel] FlightGear: unable to control JSBSim engines from within JSBSim.

[Michael D. <mik...@gm...>]

The "starter", "cutoff" and "seized" engine properties are not exposed
to JSBSim tree. The ones under "/engines/engine[*]" of FlightGear are
boolean and do not accept other data types.

This means if engine control system is written in JSBSim, it has no
clean way of outputting to those properties, especially because JSBSim
can not output bools.

I have to rely on external logic to convert those values and pass them
to FlightGear properties, which makes the engine control code fragile.

Kind regards,
Mike

Re: [Jsbsim-devel] JSBSim test suite

[Sean M. <se...@se...>]

Hi Erik

This is a known issue, take a look at - 

https://github.com/JSBSim-Team/jsbsim/issues/31

Cheers

-----Original Message-----
From: Erik Hofman <er...@eh...> 
Sent: Tuesday, June 5, 2018 3:19 PM
To: Development issues <jsb...@li...>
Subject: [Jsbsim-devel] JSBSim test suite


Hi,

FlightGear has been generating JSBSim binaries themselves for some time, particularly for creating JSBSim and AeromatiC++ for all supported platforms.

But now the build process gets stuck when calling the automatic tests
(TestInputSocket):


http://build.flightgear.org:8080/job/JSBsim/172/console

Is there a way to skip the tests or to pass TestInputSocket properly 
automatically?

Erik

-- 
http://www.adalin.com - High performance virtual reality audio software.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Jsbsim-devel mailing list
Jsb...@li...
https://lists.sourceforge.net/lists/listinfo/jsbsim-devel
_______________________________________________
The JSBSim Flight Dynamics Model project
http://www.JSBSim.org
_______________________________________________

[Jsbsim-devel] JSBSim test suite

[Erik H. <er...@eh...>]

Hi,

FlightGear has been generating JSBSim binaries themselves for some time, 
particularly for creating JSBSim and AeromatiC++ for all supported 
platforms.

But now the build process gets stuck when calling the automatic tests 
(TestInputSocket):


http://build.flightgear.org:8080/job/JSBsim/172/console

Is there a way to skip the tests or to pass TestInputSocket properly 
automatically?

Erik

-- 
http://www.adalin.com - High performance virtual reality audio software.

Re: [Jsbsim-devel] cg-x-percentage

[Sean M. <se...@se...>]

Hi Anders



Yep so I guess something along the following lines? Just tested it briefly and it seems to work.



So in the aircraft file, for example 737.xml


  <system file="cgutils">
    <property value="600">metrics/mac-leading-edge-x-in</property>
  </system>



And then in cgutils.xml which we could potentially ship in the systems folder in the default JSBSim repository.


<system name="cgutils">

    <function name="inertia/cg-x-mac-percentage">
      <product>
        <value> 100.0 </value>
        <quotient>
          <difference>
            <property> inertia/cg-x-in </property>
            <property> metrics/mac-leading-edge-x-in </property>
          </difference>
          <product>
            <property> metrics/cbarw-ft </property>
            <value> 12 </value>
          </product>
        </quotient>
      </product>
    </function>

</system>



So from the aircraft user's perspective I guess 2 or 3 minor inconveniences compared to adding built-in support? More verbose in terms of 3 lines to define the MAC leading edge, can't use units, not grouped within the metrics section.


  <metrics>
    <chord unit="M">              4.12  </chord>
    <mac-leading-edge unit="M">  14.67  </mac-leading-edge>



Cheers



-----Original Message-----
From: Anders Gidenstam <and...@gi...>
Sent: Wednesday, May 30, 2018 8:13 PM
To: Development issues <jsb...@li...>
Subject: Re: [Jsbsim-devel] cg-x-percentage



On Wed, 30 May 2018, Sean McLeod wrote:



>

> Hi

>

>

>

> A number of aircraft (virtually all airliners?) use cg-x percentage of

> MAC (Xcg (%MAC)) to report their cg position and for their weight and

> balance limits etc.

>

>

>

> However I haven?t seen any automatic support in JSBSim?s FGMassBalance

> to calculate it and provide it as a property.



Hi,



Might that not easier be done by a generic system that you load and define the MAC leading edge position in the structural frame as a property as you do?



E.g. like this in the aircraft:



  <system name="CG-as-percentage-of-MAC">

   <property value="...">metrics/mac-leading-edge-x-in</property>

  </system>



Formulating the computation itself as a system would not be hard.



This as an alternative to increase the amount of C++ code.



Cheers,



Anders

--

---------------------------------------------------------------------------

Anders Gidenstam

WWW: http://github.com/andgi

      http://www.gidenstam.org/FlightGear/

Re: [Jsbsim-devel] cg-x-percentage

[Anders G. <and...@gi...>]

On Wed, 30 May 2018, Sean McLeod wrote:

> 
> Hi
> 
>  
> 
> A number of aircraft (virtually all airliners?) use cg-x percentage of MAC
> (Xcg (%MAC)) to report their cg position and for their weight and balance
> limits etc.
> 
>  
> 
> However I haven?t seen any automatic support in JSBSim?s FGMassBalance to
> calculate it and provide it as a property.

Hi,

Might that not easier be done by a generic system that you load and define 
the MAC leading edge position in the structural frame as a property as 
you do?

E.g. like this in the aircraft:

  <system name="CG-as-percentage-of-MAC">
   <property value="...">metrics/mac-leading-edge-x-in</property>
  </system>

Formulating the computation itself as a system would not be hard.

This as an alternative to increase the amount of C++ code.

Cheers,

Anders
-- 
---------------------------------------------------------------------------
Anders Gidenstam
WWW: http://github.com/andgi
      http://www.gidenstam.org/FlightGear/

[Jsbsim-devel] cg-x-percentage

[Sean M. <se...@se...>]

Hi

A number of aircraft (virtually all airliners?) use cg-x percentage of MAC (Xcg (%MAC)) to report their cg position and for their weight and balance limits etc.

However I haven't seen any automatic support in JSBSim's FGMassBalance to calculate it and provide it as a property.

Users could implement a function to calculate it themselves based on inertia/cg-x-in but since it's a fairly common calculation I was thinking of adding automatic support for it to FGMassBalance. The idea being that if an aircraft model includes a leMAC (leading edge of MAC) property in it's metrics section then FGMassBalance will calculate cg-x-mac-percentage during each simulation time step and export it to the property tree and include it in the initial mass balance report that gets printed.

    <metrics>
        <chord unit="FT"> 12.31 </chord>
        <leMAC unit="FT"> 51.25 </leMAC>

Cheers

Re: [Jsbsim-devel] JSBSim Continuous Integration (CI)

[Richard H. <rj...@za...>]

> https://github.com/JSBSim-Team/jsbsim/releases
>

That's really excellent news; I appreciate the amount of work required 
to get this sort of thing working and it's fantastic that you've all got 
it working.

Re: [Jsbsim-devel] JSBSim Continuous Integration (CI)

[Bertrand C. <bco...@gm...>]

Le dim. 27 mai 2018 à 13:53, Sean McLeod <se...@se...> a écrit :

> Hi
>
>
>
> Just an FYI. Agostino and Bertrand have been working on getting a CI
> system going for code checked into the JSBSim Github repository.
>

Sean also made major contributions to the Windows build and Willem Eerland
initiated the JSBSim setup for Travis CI (Linux).

>
>
> So any code checked in, including pull requests, kicks off a CI build on
> Travis for a Linux build and on AppVeyor for a Windows build. The CI build
> status for each one is displayed at the top of the README.md. In addition
> you can check the CI build status for a pull request’s particular commit
> even before it is merged into the master branch. This also allows you to
> confirm that any code you’ve submitted works on both Linux and Windows
> especially for contributors who don’t have both Windows and Linux installed.
>
>
>
>
>
> Successful builds are also released as ‘Releases’ on Github which means
> you can quickly and easily download a pre-built version of JSBSim and
> aeromatic without having to grab the latest code and build it yourself.
>
>
>
> https://github.com/JSBSim-Team/jsbsim/releases
>
>
>
> In the latest update to the AppVeyor CI build we now make use of CMake to
> build JSBSim and aeromatic, i.e. the Linux and Windows builds are now in
> sync in terms of making use of the same CMakeLists.txt (i.e. no concern in
> terms of whether the Visual Studio project files are out of date/sync etc.).
>
>
>
> Cheers
>
>

[Jsbsim-devel] JSBSim Continuous Integration (CI)

[Sean M. <se...@se...>]

Hi

Just an FYI. Agostino and Bertrand have been working on getting a CI system going for code checked into the JSBSim Github repository.

So any code checked in, including pull requests, kicks off a CI build on Travis for a Linux build and on AppVeyor for a Windows build. The CI build status for each one is displayed at the top of the README.md. In addition you can check the CI build status for a pull request's particular commit even before it is merged into the master branch. This also allows you to confirm that any code you've submitted works on both Linux and Windows especially for contributors who don't have both Windows and Linux installed.

[cid:image001.png@01D3F5BF.5CEAD990]

Successful builds are also released as 'Releases' on Github which means you can quickly and easily download a pre-built version of JSBSim and aeromatic without having to grab the latest code and build it yourself.

https://github.com/JSBSim-Team/jsbsim/releases

In the latest update to the AppVeyor CI build we now make use of CMake to build JSBSim and aeromatic, i.e. the Linux and Windows builds are now in sync in terms of making use of the same CMakeLists.txt (i.e. no concern in terms of whether the Visual Studio project files are out of date/sync etc.).

Cheers

Re: [Jsbsim-devel] 'Slippery' trim?

[Erik H. <er...@eh...>]

On 05/26/2018 08:39 PM, Sean McLeod wrote:
> Why is *vtrue* calculated when we already have *Vt*? We seem to be going 
> from *Vt* to *Mach* and then from *Mach* back to *vtrue*.

Usually this is done to firstly get a ball-park value for Mach (based on 
an known value, Vt in this case), then do the actual calculation of Mach 
  and the get the proper Vt for the re-calibrated Mach number.


Erik


-- 
http://www.adalin.com - High performance virtual reality audio software.

Re: [Jsbsim-devel] 'Slippery' trim?

[Sean M. <se...@se...>]

Hi Dave

The current code modifies CAS effectively by cos(alpha) based on the pitot angle.

Which was Alan's original issue and that it shouldn't.

Tony agreed that a cos(alpha) wasn't a good model after I sent a link to the naca report.

So the first step is to remove this cos(alpha) modification of CAS.

Cheers



On Sat, May 26, 2018 at 9:47 PM +0200, "daveculp" <dav...@co...<mailto:dav...@co...>> wrote:

Hi Sean,

I get the feeling we are all talking about different things.  I'll be out of town for a couple weeks, so I should stop now before my efforts diverge more others.

As for vPitot, that's what allows one to define a pitot angle other than the default zero.  Are you sure this is the part you want to change?  It seems unrelated to the discussion as I understand it.

Aloha,

Dave



Sent from my Verizon, Samsung Galaxy smartphone

-------- Original message --------
From: Sean McLeod <se...@se...>
Date: 5/26/18 11:39 AM (GMT-08:00)
To: Development issues <jsb...@li...>
Subject: Re: [Jsbsim-devel] 'Slippery' trim?


Hi Dave



Our current code already does that, i.e. it goes from Vt to Mach and then from Mach and atmospheric conditions to CAS using:



vcas = VcalibratedFromMach(MachPitot, in.Pressure, in.PressureSL, in.DensitySL);



I posted the relevant code and the proposed changes to the mailing list yesterday, here is the relevant snippet:



So in effect Alan is suggesting code changes along these lines, from:



   Mach = Vt / in.SoundSpeed;


  // Pitot

  vWindUVW(eU) = Vt;
  vPitotUVW = mTw2p * vWindUVW;
  Vpitot = vPitotUVW(eU);
  if (Vpitot < 0.0) Vpitot = 0.0;
  MachPitot = Vpitot / in.SoundSpeed;
  pt = PitotTotalPressure(MachPitot, in.Pressure);

  if (abs(MachPitot) > 0.0) {
    vcas = VcalibratedFromMach(MachPitot, in.Pressure, in.PressureSL, in.DensitySL);
    veas = sqrt(2 * qbar / in.DensitySL);
    vtrue = 1116.43559 * Mach * sqrt(in.Temperature / 518.67);
  } else {
    vcas = veas = vtrue = 0.0;
  }



To the following:



   Mach = Vt / in.SoundSpeed;


  if (abs(Mach) > 0.0) {
    vcas = VcalibratedFromMach(Mach, in.Pressure, in.PressureSL, in.DensitySL);
    veas = sqrt(2 * qbar / in.DensitySL);
    vtrue = 1116.43559 * Mach * sqrt(in.Temperature / 518.67);
  } else {
    vcas = veas = vtrue = 0.0;
  }



Why is vtrue calculated when we already have Vt? We seem to be going from Vt to Mach and then from Mach back to vtrue.



I’ll submit a pull request with these changes as a first step.



Cheers



-----Original Message-----
From: Dave Culp <dav...@co...>
Sent: Saturday, May 26, 2018 6:47 PM
To: jsb...@li...
Subject: Re: [Jsbsim-devel] 'Slippery' trim?





I found a method for deriving CAS from Mach, so in the simulation we could go from TAS to Mach to CAS without using a pitot model.  In the linked paper it's the third equation from the bottom:



http://www.mathpages.com/home/kmath282/kmath282.htm



In pseudo code:



double a = 1116.45;      // speed of sound at sea level double b = 2.236067978;  // sqrt(5) double c = 3.5;          // 7/2 double d = atmosphere->GetPressure(alt) / 2116.22;   // pressure ratio double f = 0.285714286;  // 2/7



vcas = a*b*sqrt(pow(d(pow(1+M*M/5,c)-1)+1,f)-1);





I don't have time to test it now, and might not for a couple weeks. If it all works properly then we can have a derived CAS rather than a measured CAS.  I assume the next step would be to make IAS exactly equal to CAS, so we would also have a derived IAS?



If we go this route then I think we should still have a pitot model, but what to do with the result?  Would this break anything?





Dave



------------------------------------------------------------------------------

Check out the vibrant tech community on one of the world's most

engaging tech sites, Slashdot.org! http://sdm.link/slashdot

_______________________________________________

Jsbsim-devel mailing list

Jsb...@li...<mailto:Jsb...@li...>

https://lists.sourceforge.net/lists/listinfo/jsbsim-devel

_______________________________________________

The JSBSim Flight Dynamics Model project

http://www.JSBSim.org

_______________________________________________

Re: [Jsbsim-devel] 'Slippery' trim?

[daveculp <dav...@co...>]

Hi Sean,
I get the feeling we are all talking about different things.  I'll be out of town for a couple weeks, so I should stop now before my efforts diverge more others.
As for vPitot, that's what allows one to define a pitot angle other than the default zero.  Are you sure this is the part you want to change?  It seems unrelated to the discussion as I understand it.
Aloha,
Dave 


Sent from my Verizon, Samsung Galaxy smartphone
-------- Original message --------From: Sean McLeod <se...@se...> Date: 5/26/18  11:39 AM  (GMT-08:00) To: Development issues <jsb...@li...> Subject: Re: [Jsbsim-devel] 'Slippery' trim? 


Hi Dave
 
Our current code already does that, i.e. it goes from Vt to Mach and then from Mach and atmospheric conditions to CAS using:
 
vcas = VcalibratedFromMach(MachPitot, in.Pressure, in.PressureSL, in.DensitySL);
 
I posted the relevant code and the proposed changes to the mailing list yesterday, here is the relevant snippet:
 
So in effect Alan is suggesting code changes along these lines, from:
 
   Mach = Vt / in.SoundSpeed;
 
 
// Pitot
 
  vWindUVW(eU)
 = Vt;
  vPitotUVW
= mTw2p
* vWindUVW;
  Vpitot = vPitotUVW(eU);
 
if (Vpitot < 0.0) Vpitot = 0.0;
  MachPitot = Vpitot / in.SoundSpeed;
  pt = PitotTotalPressure(MachPitot, in.Pressure);
 
 
if (abs(MachPitot) > 0.0) {
    vcas = VcalibratedFromMach(MachPitot, in.Pressure, in.PressureSL, in.DensitySL);
    veas = sqrt(2 * qbar / in.DensitySL);
    vtrue = 1116.43559 * Mach * sqrt(in.Temperature / 518.67);
  }
else {
    vcas = veas = vtrue = 0.0;
  }
 
To the following:
 
   Mach = Vt / in.SoundSpeed;
 
 
if (abs(Mach) > 0.0) {
    vcas = VcalibratedFromMach(Mach, in.Pressure, in.PressureSL, in.DensitySL);
    veas = sqrt(2 * qbar / in.DensitySL);
    vtrue = 1116.43559 * Mach * sqrt(in.Temperature / 518.67);
  }
else {
    vcas = veas = vtrue = 0.0;
  }
 
Why is vtrue calculated when we already have Vt? We seem to be going from
Vt to Mach and then from Mach back to vtrue.
 
I’ll submit a pull request with these changes as a first step.
 
Cheers
 
-----Original Message-----

From: Dave Culp <dav...@co...> 

Sent: Saturday, May 26, 2018 6:47 PM

To: jsb...@li...

Subject: Re: [Jsbsim-devel] 'Slippery' trim?
 
 
I found a method for deriving CAS from Mach, so in the simulation we could go from TAS to Mach to CAS without using a pitot model.  In the linked paper it's the third equation from the bottom:
 
http://www.mathpages.com/home/kmath282/kmath282.htm
 
In pseudo code:
 
double a = 1116.45;      // speed of sound at sea level double b = 2.236067978;  // sqrt(5) double c = 3.5;          // 7/2 double d = atmosphere->GetPressure(alt) / 2116.22;   // pressure ratio double f = 0.285714286;  // 2/7
 
vcas = a*b*sqrt(pow(d(pow(1+M*M/5,c)-1)+1,f)-1);
 
 
I don't have time to test it now, and might not for a couple weeks. If it all works properly then we can have a derived CAS rather than a measured CAS.  I assume the next step would be to make IAS exactly equal to CAS, so we would also
 have a derived IAS?
 
If we go this route then I think we should still have a pitot model, but what to do with the result?  Would this break anything?
 
 
Dave
 
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! 
http://sdm.link/slashdot
_______________________________________________
Jsbsim-devel mailing list
Jsb...@li...
https://lists.sourceforge.net/lists/listinfo/jsbsim-devel
_______________________________________________
The JSBSim Flight Dynamics Model project
http://www.JSBSim.org
_______________________________________________
 

Re: [Jsbsim-devel] 'Slippery' trim?

[Sean M. <se...@se...>]

Hi Dave



Our current code already does that, i.e. it goes from Vt to Mach and then from Mach and atmospheric conditions to CAS using:



vcas = VcalibratedFromMach(MachPitot, in.Pressure, in.PressureSL, in.DensitySL);



I posted the relevant code and the proposed changes to the mailing list yesterday, here is the relevant snippet:



So in effect Alan is suggesting code changes along these lines, from:



   Mach = Vt / in.SoundSpeed;


  // Pitot

  vWindUVW(eU) = Vt;
  vPitotUVW = mTw2p * vWindUVW;
  Vpitot = vPitotUVW(eU);
  if (Vpitot < 0.0) Vpitot = 0.0;
  MachPitot = Vpitot / in.SoundSpeed;
  pt = PitotTotalPressure(MachPitot, in.Pressure);

  if (abs(MachPitot) > 0.0) {
    vcas = VcalibratedFromMach(MachPitot, in.Pressure, in.PressureSL, in.DensitySL);
    veas = sqrt(2 * qbar / in.DensitySL);
    vtrue = 1116.43559 * Mach * sqrt(in.Temperature / 518.67);
  } else {
    vcas = veas = vtrue = 0.0;
  }



To the following:



   Mach = Vt / in.SoundSpeed;


  if (abs(Mach) > 0.0) {
    vcas = VcalibratedFromMach(Mach, in.Pressure, in.PressureSL, in.DensitySL);
    veas = sqrt(2 * qbar / in.DensitySL);
    vtrue = 1116.43559 * Mach * sqrt(in.Temperature / 518.67);
  } else {
    vcas = veas = vtrue = 0.0;
  }



Why is vtrue calculated when we already have Vt? We seem to be going from Vt to Mach and then from Mach back to vtrue.



I’ll submit a pull request with these changes as a first step.



Cheers



-----Original Message-----
From: Dave Culp <dav...@co...>
Sent: Saturday, May 26, 2018 6:47 PM
To: jsb...@li...
Subject: Re: [Jsbsim-devel] 'Slippery' trim?





I found a method for deriving CAS from Mach, so in the simulation we could go from TAS to Mach to CAS without using a pitot model.  In the linked paper it's the third equation from the bottom:



http://www.mathpages.com/home/kmath282/kmath282.htm



In pseudo code:



double a = 1116.45;      // speed of sound at sea level double b = 2.236067978;  // sqrt(5) double c = 3.5;          // 7/2 double d = atmosphere->GetPressure(alt) / 2116.22;   // pressure ratio double f = 0.285714286;  // 2/7



vcas = a*b*sqrt(pow(d(pow(1+M*M/5,c)-1)+1,f)-1);





I don't have time to test it now, and might not for a couple weeks. If it all works properly then we can have a derived CAS rather than a measured CAS.  I assume the next step would be to make IAS exactly equal to CAS, so we would also have a derived IAS?



If we go this route then I think we should still have a pitot model, but what to do with the result?  Would this break anything?





Dave



------------------------------------------------------------------------------

Check out the vibrant tech community on one of the world's most

engaging tech sites, Slashdot.org! http://sdm.link/slashdot

_______________________________________________

Jsbsim-devel mailing list

Jsb...@li...<mailto:Jsb...@li...>

https://lists.sourceforge.net/lists/listinfo/jsbsim-devel

_______________________________________________

The JSBSim Flight Dynamics Model project

http://www.JSBSim.org

_______________________________________________

Re: [Jsbsim-devel] 'Slippery' trim?

[Bertrand C. <bco...@gm...>]

Don't forget that :

A. we have the property 'atmosphere/delta-T' that affects the speed of
sound including at Sea level. So can it be hardcoded ?
B. There is a shock wave in front of the Pitot tube when Mach > 1.0. This
is accounted for by the current code.

Bertrand

Le sam. 26 mai 2018 à 18:47, Dave Culp <dav...@co...> a écrit :

>
> I found a method for deriving CAS from Mach, so in the simulation we
> could go from TAS to Mach to CAS without using a pitot model.  In the
> linked paper it's the third equation from the bottom:
>
> http://www.mathpages.com/home/kmath282/kmath282.htm
>
> In pseudo code:
>
> double a = 1116.45;      // speed of sound at sea level
> double b = 2.236067978;  // sqrt(5)
> double c = 3.5;          // 7/2
> double d = atmosphere->GetPressure(alt) / 2116.22;   // pressure ratio
> double f = 0.285714286;  // 2/7
>
> vcas = a*b*sqrt(pow(d(pow(1+M*M/5,c)-1)+1,f)-1);
>
>
> I don't have time to test it now, and might not for a couple weeks. If
> it all works properly then we can have a derived CAS rather than a
> measured CAS.  I assume the next step would be to make IAS exactly equal
> to CAS, so we would also have a derived IAS?
>
> If we go this route then I think we should still have a pitot model, but
> what to do with the result?  Would this break anything?
>
>
> Dave
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Jsbsim-devel mailing list
> Jsb...@li...
> https://lists.sourceforge.net/lists/listinfo/jsbsim-devel
> _______________________________________________
> The JSBSim Flight Dynamics Model project
> http://www.JSBSim.org
> _______________________________________________
>
>

Re: [Jsbsim-devel] 'Slippery' trim?

[Dave C. <dav...@co...>]

I found a method for deriving CAS from Mach, so in the simulation we 
could go from TAS to Mach to CAS without using a pitot model.  In the 
linked paper it's the third equation from the bottom:

http://www.mathpages.com/home/kmath282/kmath282.htm

In pseudo code:

double a = 1116.45;      // speed of sound at sea level
double b = 2.236067978;  // sqrt(5)
double c = 3.5;          // 7/2
double d = atmosphere->GetPressure(alt) / 2116.22;   // pressure ratio
double f = 0.285714286;  // 2/7

vcas = a*b*sqrt(pow(d(pow(1+M*M/5,c)-1)+1,f)-1);


I don't have time to test it now, and might not for a couple weeks. If 
it all works properly then we can have a derived CAS rather than a 
measured CAS.  I assume the next step would be to make IAS exactly equal 
to CAS, so we would also have a derived IAS?

If we go this route then I think we should still have a pitot model, but 
what to do with the result?  Would this break anything?


Dave

Re: [Jsbsim-devel] 'Slippery' trim?

[Alan T. <ajt...@v-...>]

It might be clearer if I had used “error” instead of “correction” in my last post (see below).  So here is another attempt:-


Whatever the outcome  of this discussion I would like to have the option of specifying my own CAS errors.

The whole concept of JSBSim is that I specify my own derivatives, coefficients etc.  It does not seem logical to have a fixed, built-in CAS error function, especially when the errors vary from aircraft to aircraft.

If CAS  errors are to be included within JSBSim, then CAS should be  classed as a sensor, and the ability to output clean data should be available. This is how the accelerometers and gyros are meant to work.

Normally I would expect the errors to be added externally , e.g. as a Flightgear system sending airspeed to the airspeed indicators and Air Data systems.

The only need I see for including the errors within JSBSim is when CAS is used within a JSBSim autopilot.

Alan


--------------------------------------------------------------------------------



From: Alan Teeder 
Sent: Saturday, May 26, 2018 12:10 AM
To: Development issues 
Subject: Re: [Jsbsim-devel] 'Slippery' trim?

Whatever the outcome  of this discussion I would like to have the option of specifying my own CAS errors.

The whole concept of JSBSim is that I specify my own derivatives, coefficients etc.  It does not seem logical to have a fixed, built-in CAS error function, especially when the errors vary from aircraft to aircraft.

If CAS  errors are to be included within JSBSim, then CAS should be  classed as a sensor, and the ability to output uncorrected data should be available. This is how the accelerometers and gyros are meant to work.

Normally I would expect the corrections to be done externally , e.g. as a Flightgear system sending airspeed to the airspeed indicators and Air Data systems.

The only need I see for making the correction within JSBSim is when CAS is used within a JSBSim autopilot.

Alan

Re: [Jsbsim-devel] 'Slippery' trim?

[Alan T. <ajt...@v-...>]

Whatever the outcome  of this discussion I would like to have the option of specifying my own CAS errors.

The whole concept of JSBSim is that I specify my own derivatives, coefficients etc.  It does not seem logical to have a fixed, built-in CAS error function, especially when the errors vary from aircraft to aircraft.

If CAS  errors are to be included within JSBSim, then CAS should be  classed as a sensor, and the ability to output uncorrected data should be available. This is how the accelerometers and gyros are meant to work.

Normally I would expect the corrections to be done externally , e.g. as a Flightgear system sending airspeed to the airspeed indicators and Air Data systems.

The only need I see for making the correction within JSBSim is when CAS is used within a JSBSim autopilot.

Alan

Re: [Jsbsim-devel] 'Slippery' trim?

[Alan T. <ajt...@v-...>]

From: Tony Peden 
Sent: Friday, May 25, 2018 5:53 PM
To: Development issues 
Subject: Re: [Jsbsim-devel] 'Slippery' trim?

My contention is that had the designers of early pitot-static systems been able to avoid the sea level assumption then they would have.  They knew the error being introduced and were simply  limited by the technology of the time.

CAS at altitude is junk, at high subsonic speeds the error can easily be 200-300 knots. 


----------------------------------------------------------------------------------
Tony

Agreed  - CAS or IAS is not close to TAS or ground speed at altitude.

See this pair of trims that I have just made with my WIP.
It is level flight, flaps 35 degs, 200 kts at sea level and at 30000 ft.  (And no,  I don´t advise flaps 35 and U/C down at that altitude)

      alt,ft alpha ic/vc-kts vc/kts vg/kts u/kts vtrue/kts vc/cos(alpha) 
      0 11.36 200 196.1 200.1 196.2 200.1 200.0  
        12.1 200 195.4 318.7 311.6 318.7 199.8  

     


The incidence is 11.36 at SL, and 12.1 at 30000 ft. – hardly any change.
TAS and ground speed are 200kts at SL.  However they are  318.7 at 30000 ft. where, you say, they are not closely related to CAS. The ASI will read  118 kts lower than TAS.
However look at the last column, which is CAS without JSBSim’s cosine correction. It is. 200 kt at both altitudes.

Many things the pilot does are related to CAS which tells him his flap and gear selection speeds, as well as stall speed. If  CAS really is junk then it (becoming IAS when it reaches the ASI) would not continue to be the prime measure of speed in the cockpit.

On the other hand TAS is the speed to use for navigation and calculation of turn radius.

Regards

Alan

Alan

Re: [Jsbsim-devel] CAS

[Tony P. <ton...@co...>]

I was referring to the difference between CAS and TAS not IAS to CAS.



--
Tony
Follow your heart, don't give up, and try like hell to not be stupid. Repeat when, not if, the latter occurs.

> On May 25, 2018, at 12:06 PM, Sean McLeod <se...@se...> wrote:
> 
> Trying with image attached due to 100KB message limit.
>  
> From: Sean McLeod 
> Sent: Friday, May 25, 2018 8:25 PM
> To: Development issues <jsb...@li...>
> Subject: RE: [Jsbsim-devel] CAS
>  
> Hi
>  
> I would imagine for the majority of JSBSim users modeling an aircraft they would have access to this sort of position error calibration chart for the real aircraft and so they could take the CAS value and convert it into an IAS value using a function table etc.
>  
> <Image attached>
>  
> Cheers
>  
> From: Tony Peden <ton...@co...> 
> Sent: Friday, May 25, 2018 7:57 PM
> To: Development issues <jsb...@li...>
> Subject: Re: [Jsbsim-devel] CAS
>  
> Both are reasonable.  I can see use cases for having facilities to control airspeed error in JSBSim itself
> 
> --
> Tony
> Follow your heart, don't give up, and try like hell to not be stupid. Repeat when, not if, the latter occurs.
> 
> On May 25, 2018, at 10:40 AM, Sean McLeod <se...@se...> wrote:
> 
> Hi Dave
>  
> I disagree. What is ‘measured CAS’? The pilot sees IAS on their ASI and then based on flight testing with a static trailing cone etc. can look up an offset in a table from IAS to CAS and where this offset table will often also be indexed on whether the flaps are down or not etc. and it’s not as simple as looking at alpha and beta.
>  
> And from the NACA report that I linked to and Nelson’s textbook the error from the pitot-static tube is generally larger due to errors with it’s measurement of static pressure as opposed to it’s measurement of total pressure. The graphs from the NACA report show the variation in the total pressure error with AoA.
>  
> But you could be flying with the same AoA but different configuration, e.g. clean versus full flap and you’ll see a different error due to the change in static pressure distribution around the aircraft and around the pitot-static tube.
>  
> From NACA report:
>  
> “As noted in the next chapter, the static pressure at successive points along lines of airflow past a body can vary widely, whereas the total pressure along these lines of flow remains constant. For this reason, the measurement of total pressure is much less difficult than the measurement of free-stream static pressure. The measurement of total pressure is also easier because the problem of total-pressure tube design is less difficult than the design problem for static-pressure tubes.”
>  
> “Total- and static-pressure errors of the pitot-static installation”
>  
> “The static-pressure error can be quite large, whereas the total pressure error is generally negligible”
>  
> “The pressure field created by the airflow may change with the configuration of the aircraft and with Mach number and angle of attack.”
>  
> From Nelson’s ‘Flight Stability and Automatic Control’:
>  
> “The total pressure measured by a Pitot static probe is relatively insensitive to flow inclination. Unfortunately, this is not the case for the static measurement and care must be used to position the probe so as to minimize the error in the static measurement. If one knows the instrument and position errors, one can correct the indicated airspeed…. ”
>  
> So as Alan mentions the correction table is generated via test flights using trailing static cones to be able to subtract out the static pressure measurement error in the pitot-static tube etc. In your Cessna you’ll get a placard but obviously in ‘digital’ airliners etc. this correction table from flight tests can be loaded into the system.
>  
> So I wouldn’t suggest introducing 2 CAS properties.
>  
> I would suggest we remove the current cos(alpha) ‘error’ that we currently introduce when calculating CAS and simply calculate CAS based on TAS and atmospheric conditions.
>  
> If users want to render/use IAS then they could provide their own function which takes CAS (velocities/vc-kts) and applies whatever errors they wish to model in terms of the position and instrument errors of their aircraft’s pitot-static setup.
>  
> The other question is whether we want to provide some ‘default’ or available default position and instrument error model for users to use in their models if they want IAS.
>  
> Cheers
>  
> From: Dave Culp <dav...@co...> 
> Sent: Friday, May 25, 2018 6:29 PM
> To: jsb...@li...
> Subject: Re: [Jsbsim-devel] 'Slippery' trim?
>  
> Tony,
> 
> I agree we'll need to keep the measured CAS, but we could offer several options including a derived CAS.
> 
> 1)  The existing default models a pitot aligned with the aircraft x axis.
> 
> 2)  The existing option is to define a pitot angle from the x axis.
> 
>         <pitot_angle unit="{RAD | DEG}"> {number} </pitot_angle>
> 
> 3)  A proposed option is a FIXED or SWIVEL attribute for the above.
> 
>       <pitot_angle unit="{RAD | DEG}" type="{FIXED | SWIVEL}"> {number} </pitot_angle>
> 
> 4)  A proposed new property called "airspeed/vcas-derived" which we can calculate because we have a "God's eye" view of the simulation and thus direct knowledge of dynamic pressure.
> 
> 
> I'd also like to see Erik's formula applied to the above options 1 and 2.  For option 3, "SWIVEL" we can declare the swivel has no gimbal limits, so it's always perfectly aligned.
> 
> 
> Dave
> 
>  
> On 05/25/2018 08:07 AM, Tony Peden wrote:
> Very good, that’s quite enlightening.  
>  
> The error varies quite a bit, anything from a case of where cos(alpha) isn’t terrible to it being quite awful.
>  
> It also demonstrates why shielded pitots are attractive for flight test measurement.
>  
> So, at this point, I’ll concede that the error due to    design and/or installation varies too much and that the only reliable one is the sea level assumption built into the CAS equations.  
>  
> I will not concede, however, that CAS should be treated as anything but a measured quantity and thus including measurement error in it is completely appropriate.
>  
>  
> 
> --
> Tony
> Follow your heart, don't give up, and try like hell to not be stupid. Repeat when, not if, the latter occurs.
> 
> On May 25, 2018, at 1:37 AM, Sean McLeod <se...@se...> wrote:
> 
> Hi Tony
>  
> The link you listed below references a NACA report – “NASA-Reference Paper-1046, Measurement of Aircraft Speed and Altitude”. Here is a link to it –
>  
> http://www.dtic.mil/dtic/tr/fulltext/u2/a280006.pdf
>  
> In particular they have a section dedicated to ‘Tubes Inclined to the Flow’ and publish results for a number of different pitot designs through a large range of angles, typically at least -45 to +45 degrees and across a range of Mach numbers.
>  
> “When a pitot tube is inclined to the flow, the total pressure begins to decrease at some angle of inclination. The angular range through which the tube: measures total pressure correctly is called the range of insensitivity to inclination. In this text, the range of insensitivity is defined as the angular range through which the total-pressure error remains within 1 percent of the impact pressure. For a criterion based on a smaller total-pressure error, the range of insensitivity would, of course,  be smaller than that quoted for the tubes to be described in this chapter.”
>  
> “In an effort to devise fixed (as opposed to swiveling) total-pressure tubes that would be insensitive to inclination and suitable for use on both operational and flight-test aircraft, the NACA conducted a series of wind-tunnel tests on a variety of tube designs from 1951 to 1954 (ref s. 4 through 9). The tests were conducted in five wind tunnels at Mach numbers ranging from 0.26 to 2.40 and at angles of inclination up to 67.”
>  
> Here is one example, i.e. thin-wall cylindrical tube at Mach 0.26. Looks roughly insensitive all the way up to +-30 degrees. Some like the Kiel design are insensitive up to about +-45 degrees.
>  
> <Image>
>  
> Cheers
>  
> From: Tony Peden <ton...@co...> 
> Sent: Friday, May 25, 2018 2:58 AM
> To: Development issues <jsb...@li...>
> Subject: Re: [Jsbsim-devel] 'Slippery' trim?
>  
> Does any of that literature also discuss how CAS came to be?  It exists because solely because of pitot static systems.   If it had been possible to properly measure true airspeed way back when then that’s what airspeed indicators would show today and we wouldn’t even know what CAS is.
>  
> I found some agreement here
> http://www.matronics.com/wiki/index.php/Calibrating_the_Pitot-Static_System
>  
> It *might* be that the error stays flatter and grows more quickly as alpha goes above 15-20 degrees.  That might be, I don’t know, I’ve not seen actual data.  But the error is real.
>  
> The issue, I do believe, is that FGInitialCondition doesn’t calculate it the same way.  So, we end up with the disagreement you see.
>  
> --
> Tony
> Follow your heart, don't give up, and try like hell to not be stupid. Repeat when, not if, the latter occurs.
> 
> On May 24, 2018, at 4:19 PM, Alan Teeder <ajt...@v-...> wrote:
> 
>  
>  
> From: Tony Peden
> Sent: Thursday, May 24, 2018 11:49 PM
> To: Development issues
> Subject: Re: [Jsbsim-devel] 'Slippery' trim?
>  
> Pitot probes are mounted to the body 
> and don’t pivot to stay pointed into the wind so
> I’d think the error should grow with alpha
>  
> --
> Tony
>  
> Unfortunately that is not the case and pitot static tubes are less sensitive to small angles of incidence and sideslip than you might think. They definitely do not follow a cosine law, and the actual errors vary from installation to installation.
>  
> CAS is defined in all references as a function of TAS/EAS, and altitude.  Incidence and sideslip DO NOT, repeat DO NOT, affect the calculation of CAS.
>  
> If we want JSBSim /Flightgear to be realistic then an model of the pitot static error should be applied to CAS. We should not be using a private, non-standard definition of CAS.
>  
> Alan
> ------------------------------------------------------------------------------
> 
>  
> <position-error-correction.jpg>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Jsbsim-devel mailing list
> Jsb...@li...
> https://lists.sourceforge.net/lists/listinfo/jsbsim-devel
> _______________________________________________
> The JSBSim Flight Dynamics Model project
> http://www.JSBSim.org
> _______________________________________________
> 

Re: [Jsbsim-devel] CAS

[Sean M. <se...@se...>]

Trying with image attached due to 100KB message limit.

From: Sean McLeod
Sent: Friday, May 25, 2018 8:25 PM
To: Development issues <jsb...@li...<mailto:jsb...@li...>>
Subject: RE: [Jsbsim-devel] CAS

Hi

I would imagine for the majority of JSBSim users modeling an aircraft they would have access to this sort of position error calibration chart for the real aircraft and so they could take the CAS value and convert it into an IAS value using a function table etc.

<Image attached>

Cheers

From: Tony Peden <ton...@co...<mailto:ton...@co...>>
Sent: Friday, May 25, 2018 7:57 PM
To: Development issues <jsb...@li...<mailto:jsb...@li...>>
Subject: Re: [Jsbsim-devel] CAS

Both are reasonable.  I can see use cases for having facilities to control airspeed error in JSBSim itself
--
Tony
Follow your heart, don't give up, and try like hell to not be stupid. Repeat when, not if, the latter occurs.

On May 25, 2018, at 10:40 AM, Sean McLeod <se...@se...<mailto:se...@se...>> wrote:
Hi Dave

I disagree. What is ‘measured CAS’? The pilot sees IAS on their ASI and then based on flight testing with a static trailing cone etc. can look up an offset in a table from IAS to CAS and where this offset table will often also be indexed on whether the flaps are down or not etc. and it’s not as simple as looking at alpha and beta.

And from the NACA report that I linked to and Nelson’s textbook the error from the pitot-static tube is generally larger due to errors with it’s measurement of static pressure as opposed to it’s measurement of total pressure. The graphs from the NACA report show the variation in the total pressure error with AoA.

But you could be flying with the same AoA but different configuration, e.g. clean versus full flap and you’ll see a different error due to the change in static pressure distribution around the aircraft and around the pitot-static tube.

From NACA report:

“As noted in the next chapter, the static pressure at successive points along lines of airflow past a body can vary widely, whereas the total pressure along these lines of flow remains constant. For this reason, the measurement of total pressure is much less difficult than the measurement of free-stream static pressure. The measurement of total pressure is also easier because the problem of total-pressure tube design is less difficult than the design problem for static-pressure tubes.”

“Total- and static-pressure errors of the pitot-static installation”

“The static-pressure error can be quite large, whereas the total pressure error is generally negligible”

“The pressure field created by the airflow may change with the configuration of the aircraft and with Mach number and angle of attack.”

From Nelson’s ‘Flight Stability and Automatic Control’:

“The total pressure measured by a Pitot static probe is relatively insensitive to flow inclination. Unfortunately, this is not the case for the static measurement and care must be used to position the probe so as to minimize the error in the static measurement. If one knows the instrument and position errors, one can correct the indicated airspeed…. ”

So as Alan mentions the correction table is generated via test flights using trailing static cones to be able to subtract out the static pressure measurement error in the pitot-static tube etc. In your Cessna you’ll get a placard but obviously in ‘digital’ airliners etc. this correction table from flight tests can be loaded into the system.

So I wouldn’t suggest introducing 2 CAS properties.

I would suggest we remove the current cos(alpha) ‘error’ that we currently introduce when calculating CAS and simply calculate CAS based on TAS and atmospheric conditions.

If users want to render/use IAS then they could provide their own function which takes CAS (velocities/vc-kts) and applies whatever errors they wish to model in terms of the position and instrument errors of their aircraft’s pitot-static setup.

The other question is whether we want to provide some ‘default’ or available default position and instrument error model for users to use in their models if they want IAS.

Cheers

From: Dave Culp <dav...@co...<mailto:dav...@co...>>
Sent: Friday, May 25, 2018 6:29 PM
To: jsb...@li...<mailto:jsb...@li...>
Subject: Re: [Jsbsim-devel] 'Slippery' trim?


Tony,

I agree we'll need to keep the measured CAS, but we could offer several options including a derived CAS.

1)  The existing default models a pitot aligned with the aircraft x axis.

2)  The existing option is to define a pitot angle from the x axis.

        <pitot_angle unit="{RAD | DEG}"> {number} </pitot_angle>

3)  A proposed option is a FIXED or SWIVEL attribute for the above.

      <pitot_angle unit="{RAD | DEG}" type="{FIXED | SWIVEL}"> {number} </pitot_angle>
4)  A proposed new property called "airspeed/vcas-derived" which we can calculate because we have a "God's eye" view of the simulation and thus direct knowledge of dynamic pressure.


I'd also like to see Erik's formula applied to the above options 1 and 2.  For option 3, "SWIVEL" we can declare the swivel has no gimbal limits, so it's always perfectly aligned.


Dave

On 05/25/2018 08:07 AM, Tony Peden wrote:
Very good, that’s quite enlightening.

The error varies quite a bit, anything from a case of where cos(alpha) isn’t terrible to it being quite awful.

It also demonstrates why shielded pitots are attractive for flight test measurement.

So, at this point, I’ll concede that the error due to    design and/or installation varies too much and that the only reliable one is the sea level assumption built into the CAS equations.

I will not concede, however, that CAS should be treated as anything but a measured quantity and thus including measurement error in it is completely appropriate.


--
Tony
Follow your heart, don't give up, and try like hell to not be stupid. Repeat when, not if, the latter occurs.

On May 25, 2018, at 1:37 AM, Sean McLeod <se...@se...<mailto:se...@se...>> wrote:
Hi Tony

The link you listed below references a NACA report – “NASA-Reference Paper-1046, Measurement of Aircraft Speed and Altitude”. Here is a link to it –

http://www.dtic.mil/dtic/tr/fulltext/u2/a280006.pdf

In particular they have a section dedicated to ‘Tubes Inclined to the Flow’ and publish results for a number of different pitot designs through a large range of angles, typically at least -45 to +45 degrees and across a range of Mach numbers.

“When a pitot tube is inclined to the flow, the total pressure begins to decrease at some angle of inclination. The angular range through which the tube: measures total pressure correctly is called the range of insensitivity to inclination. In this text, the range of insensitivity is defined as the angular range through which the total-pressure error remains within 1 percent of the impact pressure. For a criterion based on a smaller total-pressure error, the range of insensitivity would, of course, be smaller than that quoted for the tubes to be described in this chapter.”

“In an effort to devise fixed (as opposed to swiveling) total-pressure tubes that would be insensitive to inclination and suitable for use on both operational and flight-test aircraft, the NACA conducted a series of wind-tunnel tests on a variety of tube designs from 1951 to 1954 (ref s. 4 through 9). The tests were conducted in five wind tunnels at Mach numbers ranging from 0.26 to 2.40 and at angles of inclination up to 67.”

Here is one example, i.e. thin-wall cylindrical tube at Mach 0.26. Looks roughly insensitive all the way up to +-30 degrees. Some like the Kiel design are insensitive up to about +-45 degrees.

<Image>

Cheers

From: Tony Peden <ton...@co...<mailto:ton...@co...>>
Sent: Friday, May 25, 2018 2:58 AM
To: Development issues <jsb...@li...<mailto:jsb...@li...>>
Subject: Re: [Jsbsim-devel] 'Slippery' trim?

Does any of that literature also discuss how CAS came to be?  It exists because solely because of pitot static systems.   If it had been possible to properly measure true airspeed way back when then that’s what airspeed indicators would show today and we wouldn’t even know what CAS is.

I found some agreement here
http://www.matronics.com/wiki/index.php/Calibrating_the_Pitot-Static_System

It *might* be that the error stays flatter and grows more quickly as alpha goes above 15-20 degrees.  That might be, I don’t know, I’ve not seen actual data.  But the error is real.

The issue, I do believe, is that FGInitialCondition doesn’t calculate it the same way.  So, we end up with the disagreement you see.

--
Tony
Follow your heart, don't give up, and try like hell to not be stupid. Repeat when, not if, the latter occurs.

On May 24, 2018, at 4:19 PM, Alan Teeder <ajt...@v-...<mailto:ajt...@v-...>> wrote:


From: Tony Peden
Sent: Thursday, May 24, 2018 11:49 PM
To: Development issues
Subject: Re: [Jsbsim-devel] 'Slippery' trim?

Pitot probes are mounted to the body
and don’t pivot to stay pointed into the wind so
I’d think the error should grow with alpha

--
Tony

Unfortunately that is not the case and pitot static tubes are less sensitive to small angles of incidence and sideslip than you might think. They definitely do not follow a cosine law, and the actual errors vary from installation to installation.

CAS is defined in all references as a function of TAS/EAS, and altitude.  Incidence and sideslip DO NOT, repeat DO NOT, affect the calculation of CAS.

If we want JSBSim /Flightgear to be realistic then an model of the pitot static error should be applied to CAS. We should not be using a private, non-standard definition of CAS.

Alan
------------------------------------------------------------------------------

Re: [Jsbsim-devel] CAS

[Tony P. <ton...@co...>]

Both are reasonable.  I can see use cases for having facilities to control airspeed error in JSBSim itself

--
Tony
Follow your heart, don't give up, and try like hell to not be stupid. Repeat when, not if, the latter occurs.

> On May 25, 2018, at 10:40 AM, Sean McLeod <se...@se...> wrote:
> 
> Hi Dave
>  
> I disagree. What is ‘measured CAS’? The pilot sees IAS on their ASI and then based on flight testing with a static trailing cone etc. can look up an offset in a table from IAS to CAS and where this offset table will often also be indexed on whether the flaps are down or not etc. and it’s not as simple as looking at alpha and beta.
>  
> And from the NACA report that I linked to and Nelson’s textbook the error from the pitot-static tube is generally larger due to errors with it’s measurement of static pressure as opposed to it’s measurement of total pressure. The graphs from the NACA report show the variation in the total pressure error with AoA.
>  
> But you could be flying with the same AoA but different configuration, e.g. clean versus full flap and you’ll see a different error due to the change in static pressure distribution around the aircraft and around the pitot-static tube.
>  
> From NACA report:
>  
> “As noted in the next chapter, the static pressure at successive points along lines of airflow past a body can vary widely, whereas the total pressure along these lines of flow remains constant. For this reason, the measurement of total pressure is much less difficult than the measurement of free-stream static pressure. The measurement of total pressure is also easier because the problem of total-pressure tube design is less difficult than the design problem for static-pressure tubes.”
>  
> “Total- and static-pressure errors of the pitot-static installation”
>  
> “The static-pressure error can be quite large, whereas the total pressure error is generally negligible”
>  
> “The pressure field created by the airflow may change with the configuration of the aircraft and with Mach number and angle of attack.”
>  
> From Nelson’s ‘Flight Stability and Automatic Control’:
>  
> “The total pressure measured by a Pitot static probe is relatively insensitive to flow inclination. Unfortunately, this is not the case for the static measurement and care must be used to position the probe so as to minimize the error in the static measurement. If one knows the instrument and position errors, one can correct the indicated airspeed…. ”
>  
> So as Alan mentions the correction table is generated via test flights using trailing static cones to be able to subtract out the static pressure measurement error in the pitot-static tube etc. In your Cessna you’ll get a placard but obviously in ‘digital’ airliners etc. this correction table from flight tests can be loaded into the system.
>  
> So I wouldn’t suggest introducing 2 CAS properties.
>  
> I would suggest we remove the current cos(alpha) ‘error’ that we currently introduce when calculating CAS and simply calculate CAS based on TAS and atmospheric conditions.
>  
> If users want to render/use IAS then they could provide their own function which takes CAS (velocities/vc-kts) and applies whatever errors they wish to model in terms of the position and instrument errors of their aircraft’s pitot-static setup.
>  
> The other question is whether we want to provide some ‘default’ or available default position and instrument error model for users to use in their models if they want IAS.
>  
> Cheers
>  
> From: Dave Culp <dav...@co...> 
> Sent: Friday, May 25, 2018 6:29 PM
> To: jsb...@li...
> Subject: Re: [Jsbsim-devel] 'Slippery' trim?
>  
> Tony,
> 
> I agree we'll need to keep the measured CAS, but we could offer several options including a derived CAS.
> 
> 1)  The existing default models a pitot aligned with the aircraft x axis.
> 
> 2)  The existing option is to define a pitot angle from the x axis.
> 
>         <pitot_angle unit="{RAD | DEG}"> {number} </pitot_angle>
> 
> 3)  A proposed option is a FIXED or SWIVEL attribute for the above.
> 
>       <pitot_angle unit="{RAD | DEG}" type="{FIXED | SWIVEL}"> {number} </pitot_angle>
> 
> 4)  A proposed new property called "airspeed/vcas-derived" which we can calculate because we have a "God's eye" view of the simulation and thus direct knowledge of dynamic pressure.
> 
> 
> I'd also like to see Erik's formula applied to the above options 1 and 2.  For option 3, "SWIVEL" we can declare the swivel has no gimbal limits, so it's always perfectly aligned.
> 
> 
> Dave
> 
>  
> On 05/25/2018 08:07 AM, Tony Peden wrote:
> Very good, that’s quite enlightening.  
>  
> The error varies quite a bit, anything from a case of where cos(alpha) isn’t terrible to it being quite awful.
>  
> It also demonstrates why shielded pitots are attractive for flight test measurement.
>  
> So, at this point, I’ll concede that the error due to    design and/or installation varies too much and that the only reliable one is the sea level assumption built into the CAS equations.  
>  
> I will not concede, however, that CAS should be treated as anything but a measured quantity and thus including measurement error in it is completely appropriate.
>  
>  
> 
> --
> Tony
> Follow your heart, don't give up, and try like hell to not be stupid. Repeat when, not if, the latter occurs.
> 
> On May 25, 2018, at 1:37 AM, Sean McLeod <se...@se...> wrote:
> 
> Hi Tony
>  
> The link you listed below references a NACA report – “NASA-Reference Paper-1046, Measurement of Aircraft Speed and Altitude”. Here is a link to it –
>  
> http://www.dtic.mil/dtic/tr/fulltext/u2/a280006.pdf
>  
> In particular they have a section dedicated to ‘Tubes Inclined to the Flow’ and publish results for a number of different pitot designs through a large range of angles, typically at least -45 to +45 degrees and across a range of Mach numbers.
>  
> “When a pitot tube is inclined to the flow, the total pressure begins to decrease at some angle of inclination. The angular range through which the tube: measures total pressure correctly is called the range of insensitivity to inclination. In this text, the range of insensitivity is defined as the angular range through which the total-pressure error remains within 1 percent of the impact pressure. For a criterion based on a smaller total-pressure error, the range of insensitivity would, of course,  be smaller than that quoted for the tubes to be described in this chapter.”
>  
> “In an effort to devise fixed (as opposed to swiveling) total-pressure tubes that would be insensitive to inclination and suitable for use on both operational and flight-test aircraft, the NACA conducted a series of wind-tunnel tests on a variety of tube designs from 1951 to 1954 (ref s. 4 through 9). The tests were conducted in five wind tunnels at Mach numbers ranging from 0.26 to 2.40 and at angles of inclination up to 67.”
>  
> Here is one example, i.e. thin-wall cylindrical tube at Mach 0.26. Looks roughly insensitive all the way up to +-30 degrees. Some like the Kiel design are insensitive up to about +-45 degrees.
>  
> <Image>
>  
> Cheers
>  
> From: Tony Peden <ton...@co...> 
> Sent: Friday, May 25, 2018 2:58 AM
> To: Development issues <jsb...@li...>
> Subject: Re: [Jsbsim-devel] 'Slippery' trim?
>  
> Does any of that literature also discuss how CAS came to be?  It exists because solely because of pitot static systems.   If it had been possible to properly measure true airspeed way back when then that’s what airspeed indicators would show today and we wouldn’t even know what CAS is.
>  
> I found some agreement here
> http://www.matronics.com/wiki/index.php/Calibrating_the_Pitot-Static_System
>  
> It *might* be that the error stays flatter and grows more quickly as alpha goes above 15-20 degrees.  That might be, I don’t know, I’ve not seen actual data.  But the error is real.
>  
> The issue, I do believe, is that FGInitialCondition doesn’t calculate it the same way.  So, we end up with the disagreement you see.
>  
> --
> Tony
> Follow your heart, don't give up, and try like hell to not be stupid. Repeat when, not if, the latter occurs.
> 
> On May 24, 2018, at 4:19 PM, Alan Teeder <ajt...@v-...> wrote:
> 
>  
>  
> From: Tony Peden
> Sent: Thursday, May 24, 2018 11:49 PM
> To: Development issues
> Subject: Re: [Jsbsim-devel] 'Slippery' trim?
>  
> Pitot probes are mounted to the body 
> and don’t pivot to stay pointed into the wind so
> I’d think the error should grow with alpha
>  
> --
> Tony
>  
> Unfortunately that is not the case and pitot static tubes are less sensitive to small angles of incidence and sideslip than you might think. They definitely do not follow a cosine law, and the actual errors vary from installation to installation.
>  
> CAS is defined in all references as a function of TAS/EAS, and altitude.  Incidence and sideslip DO NOT, repeat DO NOT, affect the calculation of CAS.
>  
> If we want JSBSim /Flightgear to be realistic then an model of the pitot static error should be applied to CAS. We should not be using a private, non-standard definition of CAS.
>  
> Alan
> ------------------------------------------------------------------------------
> 
>  
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Jsbsim-devel mailing list
> Jsb...@li...
> https://lists.sourceforge.net/lists/listinfo/jsbsim-devel
> _______________________________________________
> The JSBSim Flight Dynamics Model project
> http://www.JSBSim.org
> _______________________________________________
> 

Re: [Jsbsim-devel] CAS

[Sean M. <se...@se...>]

Hi Dave

I disagree. What is ‘measured CAS’? The pilot sees IAS on their ASI and then based on flight testing with a static trailing cone etc. can look up an offset in a table from IAS to CAS and where this offset table will often also be indexed on whether the flaps are down or not etc. and it’s not as simple as looking at alpha and beta.

And from the NACA report that I linked to and Nelson’s textbook the error from the pitot-static tube is generally larger due to errors with it’s measurement of static pressure as opposed to it’s measurement of total pressure. The graphs from the NACA report show the variation in the total pressure error with AoA.

But you could be flying with the same AoA but different configuration, e.g. clean versus full flap and you’ll see a different error due to the change in static pressure distribution around the aircraft and around the pitot-static tube.

From NACA report:

“As noted in the next chapter, the static pressure at successive points along lines of airflow past a body can vary widely, whereas the total pressure along these lines of flow remains constant. For this reason, the measurement of total pressure is much less difficult than the measurement of free-stream static pressure. The measurement of total pressure is also easier because the problem of total-pressure tube design is less difficult than the design problem for static-pressure tubes.”

“Total- and static-pressure errors of the pitot-static installation”

“The static-pressure error can be quite large, whereas the total pressure error is generally negligible”

“The pressure field created by the airflow may change with the configuration of the aircraft and with Mach number and angle of attack.”

From Nelson’s ‘Flight Stability and Automatic Control’:

“The total pressure measured by a Pitot static probe is relatively insensitive to flow inclination. Unfortunately, this is not the case for the static measurement and care must be used to position the probe so as to minimize the error in the static measurement. If one knows the instrument and position errors, one can correct the indicated airspeed…. ”

So as Alan mentions the correction table is generated via test flights using trailing static cones to be able to subtract out the static pressure measurement error in the pitot-static tube etc. In your Cessna you’ll get a placard but obviously in ‘digital’ airliners etc. this correction table from flight tests can be loaded into the system.

So I wouldn’t suggest introducing 2 CAS properties.

I would suggest we remove the current cos(alpha) ‘error’ that we currently introduce when calculating CAS and simply calculate CAS based on TAS and atmospheric conditions.

If users want to render/use IAS then they could provide their own function which takes CAS (velocities/vc-kts) and applies whatever errors they wish to model in terms of the position and instrument errors of their aircraft’s pitot-static setup.

The other question is whether we want to provide some ‘default’ or available default position and instrument error model for users to use in their models if they want IAS.

Cheers

From: Dave Culp <dav...@co...>
Sent: Friday, May 25, 2018 6:29 PM
To: jsb...@li...
Subject: Re: [Jsbsim-devel] 'Slippery' trim?


Tony,

I agree we'll need to keep the measured CAS, but we could offer several options including a derived CAS.

1)  The existing default models a pitot aligned with the aircraft x axis.

2)  The existing option is to define a pitot angle from the x axis.

        <pitot_angle unit="{RAD | DEG}"> {number} </pitot_angle>

3)  A proposed option is a FIXED or SWIVEL attribute for the above.

      <pitot_angle unit="{RAD | DEG}" type="{FIXED | SWIVEL}"> {number} </pitot_angle>
4)  A proposed new property called "airspeed/vcas-derived" which we can calculate because we have a "God's eye" view of the simulation and thus direct knowledge of dynamic pressure.


I'd also like to see Erik's formula applied to the above options 1 and 2.  For option 3, "SWIVEL" we can declare the swivel has no gimbal limits, so it's always perfectly aligned.


Dave

On 05/25/2018 08:07 AM, Tony Peden wrote:
Very good, that’s quite enlightening.

The error varies quite a bit, anything from a case of where cos(alpha) isn’t terrible to it being quite awful.

It also demonstrates why shielded pitots are attractive for flight test measurement.

So, at this point, I’ll concede that the error due to    design and/or installation varies too much and that the only reliable one is the sea level assumption built into the CAS equations.

I will not concede, however, that CAS should be treated as anything but a measured quantity and thus including measurement error in it is completely appropriate.


--
Tony
Follow your heart, don't give up, and try like hell to not be stupid. Repeat when, not if, the latter occurs.

On May 25, 2018, at 1:37 AM, Sean McLeod <se...@se...<mailto:se...@se...>> wrote:
Hi Tony

The link you listed below references a NACA report – “NASA-Reference Paper-1046, Measurement of Aircraft Speed and Altitude”. Here is a link to it –

http://www.dtic.mil/dtic/tr/fulltext/u2/a280006.pdf

In particular they have a section dedicated to ‘Tubes Inclined to the Flow’ and publish results for a number of different pitot designs through a large range of angles, typically at least -45 to +45 degrees and across a range of Mach numbers.

“When a pitot tube is inclined to the flow, the total pressure begins to decrease at some angle of inclination. The angular range through which the tube: measures total pressure correctly is called the range of insensitivity to inclination. In this text, the range of insensitivity is defined as the angular range through which the total-pressure error remains within 1 percent of the impact pressure. For a criterion based on a smaller total-pressure error, the range of insensitivity would, of course, be smaller than that quoted for the tubes to be described in this chapter.”

“In an effort to devise fixed (as opposed to swiveling) total-pressure tubes that would be insensitive to inclination and suitable for use on both operational and flight-test aircraft, the NACA conducted a series of wind-tunnel tests on a variety of tube designs from 1951 to 1954 (ref s. 4 through 9). The tests were conducted in five wind tunnels at Mach numbers ranging from 0.26 to 2.40 and at angles of inclination up to 67.”

Here is one example, i.e. thin-wall cylindrical tube at Mach 0.26. Looks roughly insensitive all the way up to +-30 degrees. Some like the Kiel design are insensitive up to about +-45 degrees.

<Image>

Cheers

From: Tony Peden <ton...@co...<mailto:ton...@co...>>
Sent: Friday, May 25, 2018 2:58 AM
To: Development issues <jsb...@li...<mailto:jsb...@li...>>
Subject: Re: [Jsbsim-devel] 'Slippery' trim?

Does any of that literature also discuss how CAS came to be?  It exists because solely because of pitot static systems.   If it had been possible to properly measure true airspeed way back when then that’s what airspeed indicators would show today and we wouldn’t even know what CAS is.

I found some agreement here
http://www.matronics.com/wiki/index.php/Calibrating_the_Pitot-Static_System

It *might* be that the error stays flatter and grows more quickly as alpha goes above 15-20 degrees.  That might be, I don’t know, I’ve not seen actual data.  But the error is real.

The issue, I do believe, is that FGInitialCondition doesn’t calculate it the same way.  So, we end up with the disagreement you see.

--
Tony
Follow your heart, don't give up, and try like hell to not be stupid. Repeat when, not if, the latter occurs.

On May 24, 2018, at 4:19 PM, Alan Teeder <ajt...@v-...<mailto:ajt...@v-...>> wrote:


From: Tony Peden
Sent: Thursday, May 24, 2018 11:49 PM
To: Development issues
Subject: Re: [Jsbsim-devel] 'Slippery' trim?

Pitot probes are mounted to the body
and don’t pivot to stay pointed into the wind so
I’d think the error should grow with alpha

--
Tony

Unfortunately that is not the case and pitot static tubes are less sensitive to small angles of incidence and sideslip than you might think. They definitely do not follow a cosine law, and the actual errors vary from installation to installation.

CAS is defined in all references as a function of TAS/EAS, and altitude.  Incidence and sideslip DO NOT, repeat DO NOT, affect the calculation of CAS.

If we want JSBSim /Flightgear to be realistic then an model of the pitot static error should be applied to CAS. We should not be using a private, non-standard definition of CAS.

Alan
------------------------------------------------------------------------------

Re: [Jsbsim-devel] 'Slippery' trim?

[Tony P. <ton...@co...>]

I concur.

--
Tony
Follow your heart, don't give up, and try like hell to not be stupid. Repeat when, not if, the latter occurs.

> On May 25, 2018, at 9:29 AM, Dave Culp <dav...@co...> wrote:
> 
> Tony,
> 
> 
> I agree we'll need to keep the measured CAS, but we could offer several options including a derived CAS.
> 
> 
> 1)  The existing default models a pitot aligned with the aircraft x axis.
> 
> 2)  The existing option is to define a pitot angle from the x axis.
> 
>         <pitot_angle unit="{RAD | DEG}"> {number} </pitot_angle>
> 
> 3)  A proposed option is a FIXED or SWIVEL attribute for the above.
> 
>       <pitot_angle unit="{RAD | DEG}" type="{FIXED | SWIVEL}"> {number} </pitot_angle>
> 
> 4)  A proposed new property called "airspeed/vcas-derived" which we can calculate because we have a "God's eye" view of the simulation and thus direct knowledge of dynamic pressure.
> 
> 
> I'd also like to see Erik's formula applied to the above options 1 and 2.  For option 3, "SWIVEL" we can declare the swivel has no gimbal limits, so it's always perfectly aligned.
> 
> 
> Dave
> 
> 
> 
> 
> 
> 
>> On 05/25/2018 08:07 AM, Tony Peden wrote:
>> Very good, that’s quite enlightening.  
>> 
>> The error varies quite a bit, anything from a case of where cos(alpha) isn’t terrible to it being quite awful.
>> 
>> It also demonstrates why shielded pitots are attractive for flight test measurement.
>> 
>> So, at this point, I’ll concede that the error due to    design and/or installation varies too much and that the only reliable one is the sea level assumption built into the CAS equations.  
>> 
>> I will not concede, however, that CAS should be treated as anything but a measured quantity and thus including measurement error in it is completely appropriate.
>> 
>> 
>> 
>> --
>> Tony
>> Follow your heart, don't give up, and try like hell to not be stupid. Repeat when, not if, the latter occurs.
>> 
>> On May 25, 2018, at 1:37 AM, Sean McLeod <se...@se...> wrote:
>> 
>>> Hi Tony
>>>  
>>> The link you listed below references a NACA report – “NASA-Reference Paper-1046, Measurement of Aircraft Speed and Altitude”. Here is a link to it –
>>>  
>>> http://www.dtic.mil/dtic/tr/fulltext/u2/a280006.pdf
>>>  
>>> In particular they have a section dedicated to ‘Tubes Inclined to the Flow’ and publish results for a number of different pitot designs through a large range of angles, typically at least -45 to +45 degrees and across a range of Mach numbers.
>>>  
>>> “When a pitot tube is inclined to the flow, the total pressure begins to decrease at some angle of inclination. The angular range through which the tube: measures total pressure correctly is called the range of insensitivity to inclination. In this text, the range of insensitivity is defined as the angular range through which the total-pressure error remains within 1 percent of the impact pressure. For a criterion based on a smaller total-pressure error, the range of insensitivity would, of course, be smaller than that quoted for the tubes to be described in this chapter.”
>>>  
>>> “In an effort to devise fixed (as opposed to swiveling) total-pressure tubes that would be insensitive to inclination and suitable for use on both operational and flight-test aircraft, the NACA conducted a series of wind-tunnel tests on a variety of tube designs from 1951 to 1954 (ref s. 4 through 9). The tests were conducted in five wind tunnels at Mach numbers ranging from 0.26 to 2.40 and at angles of inclination up to 67.”
>>>  
>>> Here is one example, i.e. thin-wall cylindrical tube at Mach 0.26. Looks roughly insensitive all the way up to +-30 degrees. Some like the Kiel design are insensitive up to about +-45 degrees.
>>>  
>>> 
>>>  
>>> Cheers
>>>  
>>> From: Tony Peden <ton...@co...> 
>>> Sent: Friday, May 25, 2018 2:58 AM
>>> To: Development issues <jsb...@li...>
>>> Subject: Re: [Jsbsim-devel] 'Slippery' trim?
>>>  
>>> Does any of that literature also discuss how CAS came to be?  It exists because solely because of pitot static systems.   If it had been possible to properly measure true airspeed way back when then that’s what airspeed indicators would show today and we wouldn’t even know what CAS is.
>>>  
>>> I found some agreement here
>>> http://www.matronics.com/wiki/index.php/Calibrating_the_Pitot-Static_System
>>>  
>>> It *might* be that the error stays flatter and grows more quickly as alpha goes above 15-20 degrees.  That might be, I don’t know, I’ve not seen actual data.  But the error is real.
>>>  
>>> The issue, I do believe, is that FGInitialCondition doesn’t calculate it the same way.  So, we end up with the disagreement you see.
>>>  
>>> --
>>> Tony
>>> Follow your heart, don't give up, and try like hell to not be stupid. Repeat when, not if, the latter occurs.
>>> 
>>> On May 24, 2018, at 4:19 PM, Alan Teeder <ajt...@v-...> wrote:
>>> 
>>>  
>>>  
>>> From: Tony Peden
>>> Sent: Thursday, May 24, 2018 11:49 PM
>>> To: Development issues
>>> Subject: Re: [Jsbsim-devel] 'Slippery' trim?
>>>  
>>> Pitot probes are mounted to the body 
>>> and don’t pivot to stay pointed into the wind so
>>> I’d think the error should grow with alpha
>>>  
>>> --
>>> Tony
>>>  
>>> Unfortunately that is not the case and pitot static tubes are less sensitive to small angles of incidence and sideslip than you might think. They definitely do not follow a cosine law, and the actual errors vary from installation to installation.
>>>  
>>> CAS is defined in all references as a function of TAS/EAS, and altitude.  Incidence and sideslip DO NOT, repeat DO NOT, affect the calculation of CAS.
>>>  
>>> If we want JSBSim /Flightgear to be realistic then an model of the pitot static error should be applied to CAS. We should not be using a private, non-standard definition of CAS.
>>>  
>>> Alan
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Jsbsim-devel mailing list
>>> Jsb...@li...
>>> https://lists.sourceforge.net/lists/listinfo/jsbsim-devel
>>> _______________________________________________
>>> The JSBSim Flight Dynamics Model project
>>> http://www.JSBSim.org
>>> _______________________________________________
>>> 
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Jsbsim-devel mailing list
>>> Jsb...@li...
>>> https://lists.sourceforge.net/lists/listinfo/jsbsim-devel
>>> _______________________________________________
>>> The JSBSim Flight Dynamics Model project
>>> http://www.JSBSim.org
>>> _______________________________________________
>>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> 
>> 
>> _______________________________________________
>> Jsbsim-devel mailing list
>> Jsb...@li...
>> https://lists.sourceforge.net/lists/listinfo/jsbsim-devel
>> _______________________________________________
>> The JSBSim Flight Dynamics Model project
>> http://www.JSBSim.org
>> _______________________________________________
>> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Jsbsim-devel mailing list
> Jsb...@li...
> https://lists.sourceforge.net/lists/listinfo/jsbsim-devel
> _______________________________________________
> The JSBSim Flight Dynamics Model project
> http://www.JSBSim.org
> _______________________________________________
>