PDA

View Full Version : Recording flight test data



PRB
February 25th, 2014, 15:59
I'm using AFSD to record flight test data. It's very useful. You can set up a custom report to "watch" only the items you're interested in, and then you can log a couple seconds and save the results to a file. Fantastic. It's almost perfect...

The custom report maker only lets you select 10 items to watch. 10 is actually enough, so that's not a big deal. The bigger issue is that I can't save "air range" or "true range", which is one of the values on the Fuel page. It isn't among the items you can select on the custom report. So I have to also log a couple of seconds from the fuel report to get everything I need.

This is not a terrible situation, by any means. AFSD is a great tool.

I'm wondering if there are any other tools out there that I'm overlooking.

NachtPiloten
February 25th, 2014, 16:49
ASFD tool?

PRB
February 25th, 2014, 17:55
Oops. I meant AFSD. Makes it hard to Google the other way... It's available here:

http://www.terra-brasilis.org/forum/index.php?topic=432.0

fliger747
March 4th, 2014, 08:09
Great tool to actually find out what is going on. I suspect that the air and true range are left out due to the input of sim atmospherics and weather to those parameters.

great tool, highly recommended.

t

PRB
March 8th, 2014, 12:04
Rgr Tom, a great tool indeed. You can get the range data, but you have to go to the fuel page. You just can't select those parameters from the list when building a custom report page.

Speaking of AFSD, I've run into an odd problem. The new Robert Richardson Gloster Meteors for FSX cannot be read by AFSD. AFSD reports the following error message: "Error in reading aircraft data files. (Error cause: Error reading basic air file pointers and/or data). In addition, the Robert Richardson Vampires and Venoms can be read by AFSD, but there is no range data reported. All range related numbers read "N/A".

I've been go9ing over the aircraft.cfg files looking for stray characters but so far no luck. I even tried "washing" the air file through AirWrench, but still the problem persists. That's really weird because AirWrench rebuilds the entire air file. It does look like the original air files were made using AirWrench.

fliger747
March 12th, 2014, 18:33
I have certain aircraft that experience this issue. In some cases it might be that some module is used to modify or control the flight parameters.

cheers Tom

Dev One
March 13th, 2014, 06:51
Sometimes it can be something simple like a wrong dimension in the fuel location, or a comma missing in the aircraft.cfg.
Keith

fliger747
March 13th, 2014, 09:05
Indeed, I have seen CFG issues with grammar conventions do this, as this comma instead of a period. You wouldn't think so, but they are computers....

tom

PRB
March 16th, 2014, 08:24
Well, the issue with the Meteor is somewhere in the air file. I re-built the aircraft.cfg from a clean notepad file, leaving out all comments and white space, with no change. Then I tried simply swapping out another aircraft.cfg. No change. Then I pointed aircraft.cfg to the T-45 air file, and AFSD now reads the data without problems. Now to figure out where the problem is within the air file....

PRB
March 16th, 2014, 09:11
I fixed the Meteor! So I started comparing the Meteor air file with the latest T45 air file, which I know has no issues. Turns out the Meteor air file was missing table 430 (*Delta CDo(M) Mach Drag vs. Mach *2048). After copying that table from the T-45 to the Meteor air file, AFSD reads it.

fliger747
March 16th, 2014, 09:40
Interesting indeed. One can use Air.ed to add entries if they are missing, or did you use AAM?

cheers. Tom

PRB
March 16th, 2014, 10:41
Interesting indeed. One can use Air.ed to add entries if they are missing, or did you use AAM?

cheers. Tom

AirEd. You right click a table from the "source air file" and select "copy to clipboard. Then in the "destination air file", right click any table or other entry and select "Add from clipboard". You can also replace an existing entry by selecting "Replace from clipboard".

fliger747
March 30th, 2014, 07:21
Yes I use aired for that sort of stuff but AAM for any of the hex tables etc. a long time ago I tried direct hex work but AAM is much better.

t

ViperPilot2
April 1st, 2014, 07:11
Greetings!

Recently, I have been flying the Boeing Model 40 for FS9, made by Chris Herring. I have noticed a peculiar issue with the Tachometer, and I'm wondering if there's a fix for its errant behavior...

I find that whenever I make small Power setting changes like decreasing the Throttle slightly, there's no corresponding decrease from the Tachometer. The needle just stays at 2300 RPM.
It's not until I chop the Throttle substantially, like to Idle, that the Tachometer needle slowly drops until eventually it will bottom out at around 700 RPM.

Is there something I can tweak in the Aircraft.cfg file that will smooth out the Tachometer function? It's not a huge deal, but I would like to have a Tachometer that is somewhat accurate!

Thanks for looking!

PRB
April 1st, 2014, 11:19
Hi VP2. I looked at this plane. It has a constant speed prop. If you look at the [propeller] section of the aircraft.cfg, the propeller_type=0, which is for a constant speed. When I adjust the RPM with the RPM control, the RPM responds as a constant speed prop would. I did some Googling and apparently this plane really did have a constant speed prop, in 1927! It must surely have been one of the first to be so equipped.

PRB
April 1st, 2014, 11:28
Yes I use aired for that sort of stuff but AAM for any of the hex tables etc. a long time ago I tried direct hex work but AAM is much better.

t

How do you make AAM look in the FSX folder for planes? I can only get it to look at FS9 planes.

EDIT: Belay my last, found it :)

ViperPilot2
April 1st, 2014, 15:00
Paul,

That's an interesting bit of info! I too was always under the impression that both the Model 40 and the 221 Monomail weren't so equipped!

Well, looks like I'll have to experiment with Prop Pitch a little...

Thank you for looking at this airplane for me; I'm really starting to like how this bird flies around!

ViperPilot2
April 1st, 2014, 23:22
Now that I've had a chance to fly the Model 40 using Prop Pitch and Mixture, I'm getting much better results. Thanks, Paul!

This now brings up another interesting question... looking at the Aircraft.cfg under the [piston engine] section, I find that the
Engine parameters are a bit off, as well as a couple of items in the [propeller] section...

('proper' parameters and/or questions, are in red)

[piston_engine]
power_scalar = 1.0
cylinder_displacement = 149.0 (should this be changed to reflect increased HP?)
compression_ratio = 8.5 (should this also be changed to reflect increased HP?)
number_of_cylinders = 12 (should be 9 cylinders to reflect the real P & W R-1340)
max_rated_rpm = 2200
max_rated_hp = 500 (should be 600 HP to reflect the real P & W R-1340)
fuel_metering_type = 0
cooling_type = 1
normalized_starter_torque = 0.3
turbocharged = 0
max_design_mp = 0 (should this value remain at 0, or does it need to be changed?)
min_design_mp = 0
critical_altitude = 10.000
emergency_boost_type = 0
emergency_boost_mp_offset = 0
emergency_boost_gain_offset = 0
fuel_air_auto_mixture = 0
auto_ignition = 0
max_rpm_mechanical_efficiency_scalar = 1.0
idle_rpm_mechanical_efficiency_scalar = 1.0
max_rpm_friction_scalar = 1.0
idle_rpm_friction_scalar = 1.0

************************************

[propeller]
thrust_scalar = 1.17
propeller_type =0
propeller_diameter =8.000000 (does this value need to be changed?)
propeller_blades =3 (should be 2 blades, as Modeled and on the real airplane)
propeller_moi =14.100000 (does this value need to be changed?)
beta_max =65.000000
beta_min =15.000000
min_gov_rpm =337.500000
gear_reduction_ratio =1.000000
fixed_pitch_beta =30.000000
low_speed_theory_limit =80.000000
prop_sync_available =0
prop_deice_available =0
prop_feathering_available = 0
prop_auto_feathering_available = 0
min_rpm_for_feather = 0
beta_feather = 0
power_absorbed_cf = 0
defeathering_accumulators_available = 0
prop_reverse_available = 0
minimum_on_ground_beta = 0
minimum_reverse_beta = 0
prop_tc=0.010000

I'm just looking to obtain closer real world parameters with regards to the two thingys on the front of the airplane... any insights and/ or admonishments are welcomed.

In case the "If it ain't broke, don't fix it" suggestion should prevail, I shall cease any attempts to meddle... :biggrin-new:

Thanks! :wavey:

fliger747
April 3rd, 2014, 07:42
The original adjustable props were either ground adjustable where you loosened a collar for each blade and rotated the blade to a new position, and a generally two position prop, adjustable from the cockpit. The early Spitfire had this setup, high and low pitch. Unfortunately FS does not support such adjustable props and only supports either a single fixed pitch or constant speed.

As as good as it often is, it's not perfect!

cheers. Tom

fliger747
April 3rd, 2014, 07:49
VP:

in answer to your questions about the engine CFG, yes the values should be changed to the real numbers. That is a starting point. Further work can be done in the air file to attempt to get the power outputs at say typical cruise RPM and MP into line. This can be done in the table that controls friction vrs RPM. Also useful for tuning max power, increase the max RPM friction and total power decreases etc. AAM is an excellent tool for adjusting such parameters. The above mentioned AFSD is great for your flight test, and always make sure to set weather to clear which sets up ISa conditions.

As as to min Mp, something like 9" is typical though you could go as low as 5".

cheers. Tom

ViperPilot2
April 3rd, 2014, 12:28
Tom,

Thank you for the valuable insights, and your recommendations about altering the Aircraft.cfg!

Time to dive back into the technical data I have and try to pull some figures...

I guess my tinkering is more just to match what the Model looks like in the Sim.

Now that you and Paul (PRB) have enlightened me with regards to the C/S prop, once I set pitch and Mixture properly, everything works like a charm!

Thanks for all the help!

Mike71
April 6th, 2014, 05:31
I use an EXCEL spreadsheet, set up to record in columns:

Altitude GW KIAS KTAS IMN Total Fuel Flow Notes

This is particularly significant for jet aircraft, since fuel consumption (fuel flow) decreases significantly as weight decreases. Also, the optimum altitude vs GW is significant. After a few tests, I can develop an optimum range profile. Of course you need to do some data collection regarding taxi fuel, takeoff and climb to altitude, enroute descent from a typical altitude, approach and taxi in fuel.

Using PAUSE you can easily record the desired data.

Looking on the web you can usually find valid comments regarding what the real plane actually burns. You can then adjust the aircraft.cfg file "fuel_flow_scalar=" factor to get close to the real thing if you have some credible cruise information.

I have a couple of freeware gauges for accurate fuel flow, ram and static temperature, and KTAS that I have put in a special flyout "Test Panel" window, which helps me out a lot

PRB
April 6th, 2014, 12:43
Interesting, Mike (welcome aboard, BTW). I've been using AFSD to record those, and a few other, numbers, but, to get an idea of maximum range I've been testing at various altitudes, filling up with gas, letting the speed stabilize, then start AFSD's logging feature. I wonder now if the "air range" and "true range" reported by AFSD takes into account the fuel flow changes that will result as the weight decreases, as fuel is burned off. It's really one of those problems that calculus was invented to solve: a formula that depends on variables that are not constant over time. I'm guessing my method is "adequate" but now I'm curious...

fliger747
April 7th, 2014, 19:28
My interpretation of the AFSD fuel range data is that it is a quite simple point sample of fuel, speed and fuel consumption rate. The 747 FMC was slightly better including enroute winds and step climbs plus anticipated weight change. Supposedly we included approach etc but we always ended up a couple of tons short.

The fuel flow scalar is not the end all as the thrust curve is the most important as required thrust is the variable to achieve a set speed at altitude for a given weight. Fuel flow falls out from the thrust. A lot of time was spent to derive a reasonable EPR workaround for the Milviz 737-200 and get the thrust and fuel flow parameters pretty close. FS does not provide enough data points for many engine parameters to do more than get a best fit.

Cheers: Tom

PRB
April 16th, 2014, 14:39
I suspect you are correct, Tom. It has to be calculating, but how involved are those calculations? A good test would be to get to altitude, stabilize speed, fill up with gas, then write down what ASFD says your TTE, ETE, range, etc. is at that point. Then start the clock and see what the real numbers end up being when you run out. I'd be surprised if the TTE as calculated at “T0” ends up being accurate. Even the “FMC” in the FA-18, the real one, called FPAS (Flight Performance Advisory System) relies on lookup tables stored in the computer, which come from flight test data...

PRB
April 20th, 2014, 05:40
Did a test to see how accurate FS's range and TTE calculations are at the start of a run with full tanks. The results were surprising, but not where I expected:

Test Aircraft: Just Flight A6M2
Test Altitude: 10,000 FT

Predicted at T0 (full)
TTE: 3:47
RNG: 1054
FF: 67.71879

Actual at T1 (empty)
Elapsede time: 2:00
RNG: 1063
FF: 67.64984

So the fuel flow remained almost constant throughout the flight. Perhaps the difference would be greater if I tested a plane that carried more fuel... The range prediction was also pretty close to actual and was a little greater, probably because of slightly less fuel flow as time went on. What really surprised me was the calculation for "time until empty." Prediction at T0 was almost four hours, but in fact the Zeke's engine sputtered to a stop exactly 2 hours later! Something doesn't add up. Either the clock gauge is running fast, or the gauge I was using to predict TTE is off. I was running the sim at 16X time compression too. Wonder if that affected the test.

PRB
April 20th, 2014, 13:55
Ran the test again, without time compression, and this time the predicted TTE of 3:50 correlated perfectly with the elapsed timer. So, apparently, there is relativistic time strangeness in FS! :)