Hard Landings

[joefremont]

I have seen a number of flights recently with very high touchdown vertical speeds, in the last 30 days we have had more than 35 flights where the VS is more than 10000 fpm. 10000 fpm = 99kns or 182km/h which I would think is fatal in all situations. Since most pilots have crash detection turned off, what should we do in this situation.

Do nothing?

Have a 'hard landing penalty' if landing speed is above a certian level?

Register it as a crash if the landing speed is a certian level?

I belive that if the aircraft bounces several times while landing the landing speed of each bounce is added together to get the number thats on the flight report, so for the hard landing situation we would act on the single hardest bounce.

[CAPFlyer]

Joe, I have proposed on several occasions a remedy to this situation that was based on inputs from others. I have been told several times that the ideas that were proposed to resolve this and the maintenance issue would be brought into the program, but it's never happened.

From the thread "Crash Detection", posted to the Staff forum in January -

Konny/Joe/Claudio -

Can we setup the client and/or the website to detect a crash separate of FlightSim? Because of the glitchy FS crash detection, it is reccommended by many to disable crash detection all together. Since this is the case, would it be possible for FSAirlines to detect crash conditions separately and report it as such? FSPassengers has a similar independent capability.

The actual detection itself is probably pretty straightforward. The Client needs to know the following things -

1) Landing Gear Up/Down
2) Engines On/Off (individually)
3) Impact Force (i.e. V/S at touchdown)
4) Location (On/Off Airport)
5) Surface (Land/Water)

These items are already available via FSUIPC and SimConnect, so I don't see a data issue.

The Execution

A "Hard Landing" would be detected whenever the impact force is greater than 400 FPM and less than 750 FPM and the aircraft is on an airport. The damage done to the landing gear (main gear mostly) would start at 10% at 400 FPM and move exponentially to 90% at 750 FPM. Between 751 FPM and 1000 FPM, the chance of a total landing gear failure would vary from 10% at 751 FPM and 100% at 1000 FPM. Above 1000 FPM a crash would be detected and structural damage would occur.

A "Crash Landing" will be detected if the airplane lands with the gear up or the gear fails. Structural damage begins at 10% for a "minimal failure" (i.e. gear up at less than 400 FPM or gear failure between 400 FPM and 750 FPM) to total destruction of the aircraft above 1500 FPM. At 1000 FPM, the damage would be somewhere around 75% damage (i.e. extremely extensive repairs required).

An "Off-Airport Landing" will be detected if the aircraft lands with the gear down on a location not recogized as an airport. Damage to the gear will begin at 5% for any landing below 450 FPM and above 450 FPM will be incurred like a hard landing. If the aircraft lands off airport with the gear up, damage to the aircraft will begin at 20% and ramp up in line with the previous curve with ultimate failure of the structure (100% damage) occuring at 1000 FPM.

In all cases where a "Hard Landing," "Crash Landing," or "Off Airport Landing" is detected, the aircraft will be grounded. If more than 90% destroyed, the aircraft will be permenantly grounded without option to repair, only to scrap. Scrap value will decrease from standard scrap value at 90% to 20% of standard scrap value at 100%.

I almost forgot - if the client detects the landing to be with water and the aircraft is amphibious or a flying boat (we'll need to add that to the database), damage to the hull due to a hard landing will be treated as if a "crash landing" with gear failure (i.e. use the "Structural Damage" scale above for a "Crash Landing"). Below 400 FPM, no crash will be detected if the plane lands on water and is amphibious or a flying boat.

Pilots will be grounded after all crashes as usual, but we won't "kill" them.

Also, the numbers were put up as a good "average", I do realize that some aircraft are designed to normally handle landing descent rates of up to 600fpm, but it is not uniform. The standard for what constitutes a "heavy" landing seems to average around 400fpm, but if we wish to revise where the thresholds are, then that's more than fine with me.

[hezza]

Something seems to have changed with the most recent client release, and the landing data which has never been great is now worse than ever.

My last few flights have been recorded with much higher landing speeds than normal, including one at nearly 900ft/min which is frankly laughable.
At no time in the final approach was the descent rate that high.

I some cases the "bing-bong" showing the client has recognized a landing occurs when the aircraft is still some distance above the threshold, and at others after exiting the runway!

Coupled with the fact that there are also some landings detected with 0 or -1ft/min, it is my view that the landing detection code is not actually reliable enough to mean anything.

Should it not in fact be disabled?

G

[CAPFlyer]

If it's being detected early, you need to be sending us bug reports with the log.out file attached so we can look at it. We've asked this time and again that people report problems and provide details. I haven't seen you post a single problem on this problem ever, so how are we supposed to know that it was "bad" and has "gotten worse"?

Overall, I would venture to guess that landing data has been doing quite well since we released the program. We are not seeing high landing rates and not seeing problems reported prior to yours, so unless everyone is just ignoring it, then there is something that is happening on a limited number of systems, that while a definite problem that needs to be looked at, is not as bad as you want to make it out to be.

[PCD001]

Nice idea Joe,
I like the idea of "doing something" with the Landing rate of descent.

Could it be implemented like this :-
0-700fpm = Normal (as we are now) deduction from the Aircraft Maintenance Status.
701-1100fpm = a 15% Reduction in Aircraft Maintenance Status (so if it was 95% it will go down to 80%) and a mandatory "A-Check"
1101-1600 fpm = a 40% reduction in Aircraft Aircraft Maintenance Status and a Mandatory "B-Check".
1601fpm - . . . . . Crash
Would that be simple and easy to implement ?

[alemaobaiano]

Looking back over our last 10 landings by three different pilots only one was greater than -10fps (-273fps) and several were 0fps, so either we are excellent pilots or the detection isn't that reliable.

I would certainly like to see this implemented, but if the detected rate is not reliable there will be numerous complaints about unfair penalties which probably isn't worth the effort. IIRC back in the days of Flynet Beta the detection was accurate but something changed along the way and now we routinely see 0fps touchdowns.

Chris, I take your point about log.out files, but, as with flight time, touchdown rate doesn't currently have any effect on aircraft status or airline/pilot reputation, so it's pretty much a non-issue, although if this idea was implemented that would obviously change.

TTFN

[CAPFlyer]

Yes, but your touchdown rate is a problem and a concern now because we need to be detecting the phases of flight correctly. We also need to ensure that the data we're generating (which is used in the Integration Pack) is accurate. When the touchdown rate is not being properly detected, then the integration pack info isn't being generated properly, nor are our records being kept well. In addition, picking up touchdown before it happens throws off the tracker and it can affect the times reported as well. We need to ensure it's done right.

BTW, a "0 fpm" landing is certainly possible because your average descent rate may be under .5 fpm, which would cause a round-down. A good "greaser" landing would have wheel touchdown at much less than a foot per minute as the idea is that you're barely descending at the actual point of touchdown. Thus, the gear would feel hardly any strain. Some pilots are routinely able to make sub- 1 fpm landings, so I wouldn't discount the detection just because it says 0 without having watched the landing in person or having a better log of information.

[joefremont]

I kind of like the idea that above 500fpm its detected as a hard landing with lower rating for the pilot and above 1000 hard landing with mandatory A-Check and about 2000fpm its detected as a crash. Rather than saying above a certain fpm its additional damage, I think it might be better to change the formula that determines how much damage is done to the aircraft. Right now the formula is linear, 250fpm = 0.25%, 500fpm = 0.5%, 1000fpm = 1%. It might be useful to turn it into a function of the velocity squared where 250fpm = 0.0125%, 500fpm = 0.5% and 1000fpm = 2%, this would keep the damage proportional to the aircraft's kinetic energy when it hits the ground, and not hard to implement.

We could probably also look into the damage caused by crashes, right now a bump into the terminal is the same as cratering the aircraft from 30,000ft, maybe 'crashes' at speeds less than a certain minimum should not be considered crashes at all.

Gear up and water landings for non amphibians being automatic crashes maybe a good idea, but I'm not sure the client can gather all the needed information through the interface.

[hezza]

If it's being detected early, you need to be sending us bug reports with the log.out file attached so we can look at it. We've asked this time and again that people report problems and provide details. I haven't seen you post a single problem on this problem ever, so how are we supposed to know that it was "bad" and has "gotten worse"?

Ok, point taken to a limited extent.
Often if pilots post a problem here the response is of a "we are giving our time for free why is it that you only complain and never praise?" or "the software works perfectly and the error is caused by the pilot using incorrect procedures" nature, even though that response is often not appropriate.
As such we are reluctant to mention things which we think could actually be improved, especially if they are relatively minor.
(If we pilots posted every time there was a problematic issue the forum would certainly be much more active than it currently is. )

There are many excellent features of FSA but the touchdown data generated by the FSA client is not among them. The numbers have always been suspect and are not, in my opinion, so believable as those produced by other freeware logging software. But in the past the discrepancies have not been so large as they are currently, and were tolerable (so not mentioned).

I am an experienced FS pilot with over 5500 hours of real time in my logbook, half of which has been on both IVAO and VATSIM.
My flying habits/skills have not changed recently, but FSA client's data on landing speed has, so I think something is wrong there to the level of undesirability. That is why I mention it now and not before, in the hope of improving the system for all.

I think it would be great if hard landings were to be penalized with increased wear or even damage to the aircraft, but ideally it would be based on credible data which seems unfortunately to be not currently the case.
What do you think is more likely; A good pilot with a proven record starts making extremely heavy landings, or a section of code behaves in a way which differs from that it was intended?

Regards

G

[PCD001]

The "New" pilot client decent rate seems to have gone two ways for people.

1 - It has become LESS sensitive (as mentioned by Tony above) where his pilots get between 0 and -273fpm with several 0fps
2 - It has become MORE sensitive (as mentioned by Graham) with decent rates of -900fpm.

Perhaps we need to check how the Client is reading the data from FS (fsuipc or simconnect) to see if there is a discrepancy somewhere, otherwise we will not have a level playing field and some peole will be penalised unfairly and others not penalised at all. My setup, uses fsuipc and I never seem to get more than -150fps. (but I do "float" a lot of my landings).

[Brian Peace]

I had a pretty hard landing today. I even went "oooof" as I watched it. Client registered it as about -150 something. I usually score better than -75. seems to be working right for me.

[alemaobaiano]

Bob

My setup is with the full version of FSUIPC, if that information helps anyone.

But, just to confuse the issue, I put in a lovely smooth touchdown yesterday (long runway, light A340-300, stabilised ILS approach, no crosswind component) and this shows as -581 fpm. That would have resulted in screams from the back and rattled fillings There are times when I do put it down "positively", such as Congonhas in the wet, but that flight wasn't one of those occasions.

Like most of those who have contributed to this thread I would love to see this idea implemented, but I have my reservations about accurate detection.

TTFN

[Motomad1]

Well it is intersting how diffrent FSpassengers and FSA CLient Touchdown rates are. Well i say this i end flight in FSP and it Might say a -161fpm Touch down, but the FSA Client Gives me a -280fpm Touchdown...

[Vjacheslav]

I had another situation where I used Flight Keeper, together with the FSA client.

The value of Touchdown v/s in the FSA was always less than the same value shown Flight Keeper, few exceptions, when I was to fly on turboprop ATR72 (then the values were almost similar)

ps. values that I got through the Flight Keepper I wrote in comments to the flight, if it can be of interest for developers, I find all my records from which we can compare these values

because of confusing errors when using the same time, these two programs to record flight data, that led to the destruction of the FSX, for the second flight in one session, I stopped using Flight Keeper

[flightsimer]

im all for the aircraft to recieve a higher status loss, however i dont think their should be a pilot rep loss becuase if you were to add that then you need to add weather observation into the client because there are times were there will be a hard landing and its not the pilots fault. (sudden wind change, downdrafts, heavy turbulence, Crosswinds,etc) so instead of having to add alot more info into the client it just seems to me to be easier to leave the pentalty out.