FS2004 Station load question

[vololiberista]

Although the maths is correct and the aircraft flies correctly I'm wondering if there is a bug in the station loads in the cfg file
station_load.0= 19482.000, 45.000, 0.000, -2.000
station_load.1= 16758.000, -35.000, 0.000, -2.000
Should not station load 0 be negative? I'm assuming that station load 0 is in front of the CoG. If I put a lot of weight there the tail trim is less than if the weight was in station load 1. With a T tail aircraft more weight at the back would assist in rotation and require less tail plane incidence.

 

[mgh]

why do you think StationbLoad.0 shouldn't be ahead of the datum?

 

[vololiberista]

why do you think StationbLoad.0 shouldn't be ahead of the datum?

The normal convention is it not at least in the sim is count back from station load 0. (being the front office) Whereas here it seems to count forwards.
In all David Maltby's models he only put a single station ie station load 0 eg station_load.0= 24000.000, 2.000, 0.000, 0.000
for the Trident.
However when he worked on the VC10 he did this
[WEIGHT_AND_BALANCE]
reference_datum_position= 0.000, 0.000, 0.000
empty_weight_CG_position= 0.000, 0.000, -2.000
max_number_of_stations=50
station_load.0= 13000.000, 45.000, 0.000, -2.000
station_load.0=27500.000, -34.000, 0.000, -2.000
empty_weight= 157000.000
empty_weight_roll_MOI= 16000000.000
empty_weight_pitch_MOI= 12000000.000
empty_weight_yaw_MOI= 12000000.000
empty_weight_coupled_MOI= 0.000
max_gross_weight= 335000.000
CG_forward_limit= 0.000
CG_aft_limit= 0.000
station_load.1= 11000.000, -35.000, 0.000, -2.000

Putting in effect two station load 0's. I did away with the last one.
The VC10 being a T tail there has to be a significant moment arm in front of the CoG datum. Having said that the aircraft flies correctly. Which is why I never bothered about it before. But now that I'm working on the tail plane incidence for take-off I need to get it correct. It would seem from what you're saying that the station number doesn't matter even though in this case it would appear to be back to front as it were.

 

[WarpD]

All of the offsets are from the reference_datum_position. Since it is being set at 0,0,0... which is the visual model center, which is typically 1/4 chord... then every position in the aircraft.cfg is referenced from that location. That positive value indicates that station_load.0 is forward of the reference_datum_position whereas station_load.1 is aft of the reference_datum_position.

 

[Roy Holmes]

The station load first entries are weights so they are always positive. Balance/CG calculations use the weight and distance/arm from reference to find moments. Some of the moments will be positive, some negative depending on their distance and the sum of the moments is what gives you CG position.
Roy

 

[vololiberista]

All of the offsets are from the reference_datum_position. Since it is being set at 0,0,0... which is the visual model center, which is typically 1/4 chord... then every position in the aircraft.cfg is referenced from that location. That positive value indicates that station_load.0 is forward of the reference_datum_position whereas station_load.1 is aft of the reference_datum_position.

Are you sure W? My understanding and indeed looking at cfg files for other aircraft suggest that negative values are forward of the datum and positive aft.
The arm is the horizontal distance from the reference datum to the center of gravity (CG) of an item. The algebraic sign is plus (+) if measured aft of the datum or to the right side of the center line when considering a lateral calculation. The algebraic sign is minus (-) if measured forward of the datum or the left side of the center line when considering a lateral calculation. I've always done it that way and I'm still alive!!

The station load first entries are weights so they are always positive. Balance/CG calculations use the weight and distance/arm from reference to find moments. Some of the moments will be positive, some negative depending on their distance and the sum of the moments is what gives you CG position.
Roy

I know Roy.
The confusion is that DM seems to have station 0 aft of station 1 i.e. more weight in the back of the a/c
My current calculation is:-

Based on a full pax load and fuel in the fin tank for a transatlantic crossing. Giving a tail plane incidence of 3.8 degrees.
The problem that I have come across is that the less weight fwd of datum the TPI increases whereas it should decrease.

 

[n4gix]

Are you sure W? My understanding and indeed looking at cfg files for other aircraft suggest that negative values are forward of the datum and positive aft.

Why is this bit of cabbage being re-chewed?

http://www.fsdeveloper.com/forum/threads/visual-model-origin-vmo.414254/

See also this image from the MS developers:
https://msdn.microsoft.com/en-us/library/cc526949.aspx

This image depicts the algebraic sign for each quadrant, assuming that the VMO, e_w_CG, and reference_datum are all congruent in modeling space:

 

[WarpD]

Are you sure W?

I'm 1000% sure. I have no idea where you get the idea that values forward of the reference point are negative.

 

[vololiberista]

I'm 1000% sure. I have no idea where you get the idea that values forward of the reference point are negative.

Because that's the convention in the UK and Europe All these arms are aft of the firewall ie. equal to datum zero. Therefore everything in front of the datum has a negative arm.
...............weight.............arm(inches).....moment
Aircraft.......1190.................+38.5............45815
Pilot.............160.................+39.0.............6240
Fuel.............135.................+42.0.............5670
Passenger.....160.................+39.0..............6240
.................1645.....................................63965 = CoG 38.88 aft of datum

It would appear that MS does it differently. Look at this example below

Here I'm calculating total traffic load without fuel. I'm looking for %MAC of over 14% so 23.3+(23.3*-35.76%) = 14.9672
The actual calculation comes to 14.352 which is pretty close. When calculating total payload especially in an aircraft like the VC10 more traffic load weight has to be in front of the datum to maintain correct flying charateristics.
Try as you might you will only get a %mac of 14+ if the arm is negative ie. in front of the datum.
In this example the payload is correctly positioned at station 0 with a negative arm.

This example uses the MS convention and I get a %mac of 16 instead of 15.145

And in this example I get 39.252. BUT it doesn't agree with 15.145 as calculated using MS convention
So in effect MS is wrong!! Looking through my aircraft.cfg files some are one way and some are the other. So noone is sticking to a standard. My guess is that some developers do it the MS way and some the proper way.

Using the negative arm forward of datum correctly increases the TPI angle the more weight is put there. Doing it the MS way
decreases the TPI angle as more weight is added in front of the datum. Which is most certainly not correct.
I think MS thought that "all" aircraft are the same as a light aircraft with a zero datum at the firewall. Whereas in reality for jet transports for example there's quite a lot of aircraft in front of the datum.

 

[WarpD]

The entries in the aircraft.cfg have nothing to do with your TPI calculations. It has to do with the physical x/y/z positions of loads (like pilot seat, etc). It is referenced off the entry called 'reference_datum_position'. In all but exactly one aircraft I've designed for real world training in Prepar3D... the reference_datum_position was located forward of the aircraft. In the aircraft.cfg, based on the way the sim is designed... any value aft of the reference_datum_position is a negative value for calculations in the sim... any value forward of the reference_datum_position is a positive value for calculations in the sim. Read that again... in the SIM aft of the datum is NEGATIVE. It really doesn't matter what aircraft designer 'x' wanted to use. They didn't write the code for the sim.

Your reference_datum_position in the aircraft.cfg you are referencing is not based on the real world value for the actual aircraft unless you're telling me that the reference_datum_position for your VC10 is exactly at 1/4 chord?? In fact, I'm willing to bet you don't truly understand what value the reference_datum_position should be for the sim. It really is all about the sim and it's calculations and absolutely nothing to do with your TPI calculations one bit. You don't understand what you're messing around with enough and yet you're here telling us we don't know what we're talking about. LOL

 

[vololiberista]

The entries in the aircraft.cfg have nothing to do with your TPI calculations. It has to do with the physical x/y/z positions of loads (like pilot seat, etc). It is referenced off the entry called 'reference_datum_position'. In all but exactly one aircraft I've designed for real world training in Prepar3D... the reference_datum_position was located forward of the aircraft. In the aircraft.cfg, based on the way the sim is designed... any value aft of the reference_datum_position is a negative value for calculations in the sim... any value forward of the reference_datum_position is a positive value for calculations in the sim. Read that again... in the SIM aft of the datum is NEGATIVE. It really doesn't matter what aircraft designer 'x' wanted to use. They didn't write the code for the sim.

Your reference_datum_position in the aircraft.cfg you are referencing is not based on the real world value for the actual aircraft unless you're telling me that the reference_datum_position for your VC10 is exactly at 1/4 chord?? In fact, I'm willing to bet you don't truly understand what value the reference_datum_position should be for the sim. It really is all about the sim and it's calculations and absolutely nothing to do with your TPI calculations one bit. You don't understand what you're messing around with enough and yet you're here telling us we don't know what we're talking about. LOL

Obviously the sim does it differently!

In the Standard VC10 on which DM modelled his weight distribution as for the Super VC10 Station 1263(aft of pax cabin) - station 298 (forward cabin wall) = 965 i.e. 80feet.
In the cfg DM put station load 0 at 45feet and station load 1 at -35feet therefore the datum I assume is in between.
The greater the traffic load the greater the tail plane incidence required for take-off. So unless someone can come up with a totally different way of calculating the TPI I can't see how to get round it.

 

[WarpD]

The datum in the aircraft.cfg doesn't match the real world aircraft datum point.

If the value of reference_datum_position is 0,0,0... then the reference_datum_position is defined as being at the visual model center. Aerodynamically speaking the sim treats that same coordinate as the 1/4 chord position.

So... your picture doesn't match your aircraft.cfg.

 

[n4gix]

Forget the "Real World" and concentrate on the "Sim World" for the moment. Did you even look at the image I posted, or read the SDK's description of reference datum?

Positions of aircraft components are given relative to the datum reference point for the aircraft, in the order: longitudinal, lateral, vertical. The convention for positions is positive equals forward, to the right, and vertically upward. Units are in feet.
The datum reference point itself is specified in the weight_and_balance section.

Nota bene: emphasis in bold red is mine.

 

[mgh]

FS9 SDK contains FSEdit. Figure 3 seems relevant here:

 

[vololiberista]

Another thing I've discovered during this exercise is that DM in effect used the same overall aircraft dimensions for the Super VC10 as he did for the Standard. For example the Super is actually 13ft longer and also the wingspan is bigger. He placed the fin tank for example in the same position as the centre tank. I'll have to scrutinise all the numbers to see if any other adjustments are needed. Looks like he compensated by just changing some internal numbers.
I've always been unsure of how to deal with the fin tank so I left it alone. But I might have to address that now.

 

[n4gix]

I think one factor that may confuse some is that negative offsets from an arbitrary reference datum such as that illustrated in the drawing Gerry posted can nonetheless still be viewed as having a positive direction: -3.0 is 'more positive' than -6.0 for example!

 

[vololiberista]

I think one factor that may confuse some is that negative offsets from an arbitrary reference datum such as that illustrated in the drawing Gerry posted can nonetheless still be viewed as having a positive direction: -3.0 is 'more positive' than -6.0 for example!

Yes it is confusing when there are different conventions. The correct tail plane incidence can only be calculated in one way which appears opposite to that of MS. As weight is added to the front of the aircraft the TPI increases and vice versa. The only way to get that to work correctly in the sim is to relate it (in the case of this model) to the negative number.
for example fwd station0 weight x arm=(-35+empty arm) and aft station1 weight x arm=(45-empty arm) so the -35 and +45 are swapped compared to the stations in the cfg file. I then do the calculations for %MAC and inches either way of datum to give the degrees to set TPI for take-off. It works even though it appears back to front. The numbers I get are comparable and quite often exact to real tables and load sheet settings. Also they stay within the highlighted white range on the TPI panel instrument. The two station loads represent 53% fwd and 47% aft. If I calculate the traffic loads to match I get zero inches and 3.8 TPI degrees which is a perfect match. MS thinks that the fwd compartment is heavier than the aft compartment and the TPI calculation correctly indicates a higher setting. So it does work. If I kill all the first class passengers and throw out their luggage and mail the the TPI setting is only 3 degrees because now there is much less weight fwd of the datum.

 

[mgh]

If for example the horizontal Arbitary Reference Datum is ahead of the nose then all other horizontal datums are negative.

 

[WarpD]

You keep making the exact same error, every single time.

 

[mgh]

I agree.