Braking News!

Ivan

Charter Member
Some Aircraft seem to be much easier to fly than others when doing low level high speed passes. One of the nice things about opposite rotation of the engines is that there is no noticeable lateral or directional trim changes. There is also quite a lot more acceleration.

Did lots more tuning on the P-38J. Some of these edits were quite radical and I am still not all that close to final yet.

One of the funniest things I encountered was braking too hard and flipping (!) the aeroplane.
That wasn't hard to fix, but it was an interesting surprise to flip an aeroplane with a nose wheel.

The Flight model I was working on had three fuel tanks per side:
A 90 Gallon Main Tank behind the main spar of the wing.
A 60 Gallon Reserve Tank ahead of the main spar.
A 55 Gallon Tank in the leading edge of each wing outboard of the engines.

I came across an earlier version of the AIR file (from about 2000 or so) and noted that the model I was trying to build was a P-38J-10.

The early models of the P-38, without the chin scoops, had their intercoolers built into the outboard leading edge of each wing.
This was quite an inefficient setup with the supercharger in the middle of each boom piping charge air out to the wing tips before it went into the engine.
The leading edge intercoolers were efficient for streamlining, but also didn't cool the air that well before it went into the engine. This was the main limitation to running the engines at higher power settings before detonation would start.
With the J model, the intercoolers were moved under the engines next to the oil coolers. That greatly increased the maximum speed because although the airframe drag was higher, the engine power was much higher.

At some point, fuel tanks were installed where the intercoolers were, but those fuel tanks were not present in the J-10 model.

Another feature that was not present in the early J models was the dive brake under each wing to aid recovery in a high speed dive. In trying to add in some compressibility effects, I tried quite a few high speed dives starting from around 35000 feet altitude. Many of them ended up as crashes because elevator effectiveness at very high speeds is greatly reduced and the P-38 gains speed in a dive VERY quickly and ghe maximum diving speed is very low. In fact the limit (460 mph IAS at low altitude) is about the same as for a late model Japanese Zero but for very different reasons. (At high altitude it is only 420 mph IAS.)

This is one of the parts I really like about flight sims: Reading about compressibility effects and dive limitations is interesting, but actually "experiencing" and being able to experiment with the effects gives a much better appreciation of how things worked.
Perhaps this is a bit circular because we try to program in the documented behaviour and then test for the same behaviour.

Current Performance:
1417 HP @ 500 ft for 344 mph
1477 HP @ 25,000 ft for 421 mph
Actual Maximum speed is 427 mph @ 22,500 ft
Service Ceiling was not tested but should be considerably higher with a bit more engine power and less fuel.

Lots more left to tune. Hopefully I can figure some of it out.

- Ivan.
 

Attachments

  • P-38EJ_LowPass1.jpg
    P-38EJ_LowPass1.jpg
    52.7 KB · Views: 0
Braking Factor

Sometimes something sits right before your eyes and has hints that it might not be what people tell you it is....
(Advance Warning: I am gonna get VERY long-winded here.)

The Background:
A few days ago, I was very surprised when I came in for a rather hot landing in the P-38J.
I had lined it up after wobbling all over the place and finally had it centered on the runway.
When I applied brakes, the aeroplane flipped. Imagine my surprise at having a nosewheel aeroplane flip!

That is not sposta happen, but the P-38 is an interesting combination:
It has a fair amount of weight on the nosewheel unlike most aeroplanes with a tricycle gear.
It also has a CoG that is fairly high: Almost even with the Engine Thrust Line which is where I set it for thie visual model and AIR File.

Fixing it was pretty easy.
The Braking Factor is a 16 bit Integer as described in both AirEd and FDE config files.
Maximum value is 32,767 and Minimum value would be -32768.

I have entries in my notebook from testing many years ago that Positive values seem to prevent the aeroplane from planting its nose into the runway when braking too harshly.

I had therefore made it a habit to use negative values so that if the pilot goofed, it aeroplane would oblige by sitting on its propeller. I also had noted that there didn't seem to be much variation when using negative values, but that very low negative values had too harsh braking and would flip too easily.

I reset the P-38J's brakes to a reasonable positive number that reduced speed pretty well but didn't cause the aeroplane to "hop" much when slowing down.

This Evening's Events:
Since I am working on a P-38J AIR File and do testing and archiving on several different machines, I can seriously alter the AIR file on my test machine without regard for accidentally damaging my working copy of any particular AIR File.
The P-38J was the perfect subject for testing because it does not pull to either side on the take-off run.
It will track straight under full power acceleration unlike any other CFS aircraft I have encountered.

I was not satisfield with what I had in my notes from earlier testing of negative values; They seemed way too similar.
I needed to be able to test full braking to quantify it but without being able to flip the aeroplane.
First corruption of the AIR file was to move the nosewheel contact point from 100 inches ahead of the CoG to 200 inches ahead.
The aeroplane pitched a bit on the take-off run but was controllable otherwise. It also no longer flipped.

First test was to see what effect the positive values actually had and do it in such a way that I could quantify it in my notebook.
It could be seen fairly quickly that low values had nearly no effect and high values braked faster but cause the aeroplane to hop.
From 0 - 32,767, I had already chosen to use 22.000 for fairly good braking but with very little hopping.
Results were as expected and very predictable though I won't claim that the effect is linear. There is a much greater observable difference between 500 and 10,000 than between 22,000 and 32,767.

Second test was for negative values. The extremes at -1 and -32,768 all seemed too harsh with the wheels hopping but neither value would flip the aeroplane thanks to my extended nose wheel.
-1 seemed to brake quicker but I could not tell by how much.

Next step was to remove as much subjectivity as possible from the testing.
This was made much easier by an aeroplane that had no tendency to crab or pull to either side on take-off.
The test protocol was the following:
1. Load Aeroplane into simulator.
2. Start Engines and go to Chase view.
3. Set the Speed Display at the top of the screen.

4. Use Full Engine Power for acceleration until Aeroplane reaches 95 knots.
5. Bring Engines to Idle.
6. Apply Full Brakes when Speed drops to 90 knots while starting Timer.
7. Stop Timer when Speed drops to Zero.

Here is where things get interesting:
Braking Factor of -32768 went from 90 to 0 in 11.31 Seconds
Braking Factor of -1 went from 90 to 0 in 6.56 Seconds

OK, So far, so good, but I was a bit disappointed that the Negative values that allowed a flip didn't allow as much control as the Positive values.
I figured that as long as I had a working protocol, I should also see how the Positive values compared.
There was no point in testing the value for Braking Factor Zero since it was pretty much no Brakes at all.

Ready for this?

Braking Factor of +32767 went from 90 to 0 in.... 11.31 Seconds

Hey! Wait a minute!

If the greatest Positive Braking Factor is only equal to the weakest Negative Braking Factor is there something here we are not seeing? This is where I started seeing a lot of Neon signs lighting up.

Here is a little explanation on the most common way that computers represent SIGNED Integers in Binary:
(Skip if you already know this.)

Zero is simple in a 16 bit number (Extra Spaces added for Clarity.) (I am representing this as a Big Endian)
0 000 0000 0000 0000

One is (Just add 1 to Zero)
0 000 0000 0000 0001

Negative One is (Just Subtract 1 from Zero) (Note that the first bit here is the sign bit: 0 for Positive, 1 for Negative.)
1 111 1111 1111 1111

The Largest Integer 32767 is
0 111 1111 1111 1111

The Lowest Negative Integer -32768 is
1 000 0000 0000 0000

Now if we still have a 16 big number but treat it as an UNSIGNED Integer, we can only represent numbers from Zero to 65535.
If we use the same bit patterns we had earlier:
What we thought was Zero remains Zero.
What we thought was 32767 remains 32767.
What we thought was Negative 32768 now becomes Positive 32768 which is pretty close to 32767.
What we thought was Negative 1 now becomes Positive 65535.

What this leads me to believe is that the value we thought was a 16 bit SIGNED Integer with range -32768 to 32767 is really an UNSIGNED Integer with range 0 to 65535.

The testing thus far has pretty much convinced me, but I still need to do a few more experiments.

Good Night.
- Ivan.
 
Thanks Smilo,

I thought that perhaps these posts might be useful information for "Flight" model tuning and I wasn't sure anyone else knew where to find them in the "Conspicuous By Their Absence" Thread. After all these years, this is one of the few things I have actually "Discovered" and I don't even know if I was the first one to do so.

- Ivan.
 
Great discovery Ivan! :applause:

I suppose that this was buried somewhere in the Smörgåsbord thread. They're is more to the eye in the kingdom of AIR file...

Great testing method too. Still using a stop watch?

That one will go in my AirEd.ini file.
 
Hello Hubbabubba,

I am not sure what you mean by

"They're is more to the eye in the kingdom of AIR file..."

I had a pretty good idea what I was looking for in the "Conspicuous" thread so it only took me a couple minutes.

One of the problems with AirEd is that it can't really handle types that are not pre-defined in the program.
In this case FDE can't really handle a 16 Bit unsigned integer either.....

Yes, I still have a stopwatch next to my computer.
I think it is essential for Flight Testing whether Virtual or Real
It is kind of hard to test something like Roll Rates without one.

I could not find my original one, so I just bought another off of eBay a couple days ago for about $3.50 or so.
I may end up buying yet another one for about $1.90 (found a cheaper price) just to have a spare.

- Ivan.
 
What I meant, feebly paraphrasing the bard, was that many AIR files entry, no matter the editor, are still unknown or, worse, misinterpred.

For timing, and other things as well, I use a screen capture program and simply note the time stamp on the screen, Whatever fits your bill is quite ok.
 
What Numbers Do We Use?

Hello All,

If the Braking Factor ranges from 0 - 65535 and the AIR File Editors expect a
16 bit SIGNED Integer ranging from -32768 - 32767,
What numbers should we enter?

1. If the number is below 32768, then use the number directly.

2. If the number is 32768 or higher, then subtract 65536 from the number.

Example:
If we want a Braking Factor of 50,000, we subtract 65,536 to get -15,536 which would be the actual number we enter.

No, the method is not intuitive but without being able to control type definitions in the AIR File Editors, this is what should be done.

- Ivan.
 
Hello Ivan,

You know that feeling of déjà-vu? Your discovery gave me that same feeling.
I had seen that before, but where? Then it came back in a flash; SCASM!

In it, you can use polar coordinates to set the angle of a POV, a glue part or a polygon. In turn, SCASM translate these commands into signed integers, defining right-left, up-down, and so on...

... and it does the exact same calculation you just described.

Just not to sound silly, I double-checked in Wikipedia and found that link; https://en.wikipedia.org/wiki/Binary_scaling#Binary_angles

Why they did it this way - signing and unsigned integer I mean - I have no idea, only guesses.
 
Hello Ivan,
An interesting, useful and necessary discovery. Thanks for the users´explanations too!
I´ll proceed immediately with the Braking factor for the Heinkel Jet.
Cheers,
Aleatorylamp
 
Back
Top