Magic Carpet

[sevenhelmet]

If a pilot enters in zero Ship's Speed by mistake, when it should have been around 25 knots or so, I'm estimating it could put the SRVV cue on to the edge of the deck where the aircraft might shear off the landing gear and go sliding off into the drink.

Anybody tried it out in the simulator? As in, enter zero knots for a ship that is going 25 knots and see what happens. Does the SRVV (aka, delta path indicator, "walk" toward the nearest edge of the deck on approach?

Note: I am not speculating on the cause of any mishap here.

To answer your question, I never tried it, but that's certainly a possibility. Correctly inputting and updating ship's speed is very important to PLM working properly and the SRVV being in the correct place. I saw several situations early in my last deployment where things didn't quite line up as expected, which might have contributed to me becoming a "rate" ball flyer. (the vast majority of my airwing used Path). It was never enough that I threw a turd as a result, but I can see how I could have if things had been more egregious. That said, there might be more pilot input than expected, but if you fly the ball all the way to touch down, you ain't gonna hit the back of the boat.

Anyone know if F-35 has some kind of data link, or is it a manual (HOTAS-adjustable) speed entry like the F/A-18?

 

[Hopeful Hoya]

In the F-35, we get ship’s speed automatically from JPALS (along with precision approach capability and legacy TACAN functions).

In the event that JPALS is not available, we can manually enter ship’s speed as well. There isn’t any HOTAS functionality to change ship’s speed, and you have to go a couple of levels deep on the glass to enter it which can be annoying, but I can count the number of times I had to do this on one hand during workups/deployment.

And yes, if you have a lower ships speed entered, it will cause you to go low on glide slope and you will be constantly pulling back on the stick to hold a centered ball. However, it is important to note that using DFP doesn’t relieve you of your requirement to fly the ball and honor what the IFLOS is showing you.

 

[MachTuck]

Correctly inputting and updating ship's speed is very important to PLM working properly and the SRVV being in the correct place.

Thanks for the responses, I'm just learning about Magic Carpet PLM and not speculating. Hope the Navy releases all info later.

In looking at a video recently, I'm seeing the aircraft's own velocity vector (flight path vector) symbol is decluttered (erased from view) when PLM is active, at least in this one case.

For the case of an incorrect ship's speed reaching an F-35, if the flight path vector symbol is gone, and the SRVV is the only thing the pilot has, then the pilot would not notice the weirdness of seeing the flight path vector coinciding with the SRVV cue all the time, not telling the pilot he didn't get the Ship's Speed in there right. And he'd lose the Lead of the carrier touchdown point, actually lagging toward the end of the carrier as he got closer (walking toward the tail end of the carrier).

This is all kind of new and interesting for me. I've worked on 9 different aircraft (HUD, autopilot, simulation modeling, etc.) in the past, and it's certainly nothing like ILS/Glideslope from ground emitters

 

[Hopeful Hoya]

For the case of an incorrect ship's speed reaching an F-35, if the flight path vector symbol is gone, and the SRVV is the only thing the pilot has, then the pilot would not notice the weirdness of seeing the flight path vector coinciding with the SRVV cue all the time, not telling the pilot he didn't get the Ship's Speed in there right. And he'd lose the Lead of the carrier touchdown point, actually lagging toward the end of the carrier as he got closer (walking toward the tail end of the carrier).

I think you’re overestimating the effect of the SRVV. Yes it’s nice to have, but inside 3/4 of a mile you are flying primarily a visual scan. Using the SRVV is nice because it declutters some stuff from the HMD and makes it easier to reference a visual scan, but “just put the SRVV on the wires” as some people on the internet talk about is still a bad idea for a lot of reasons.

The only real data I personally glean from the SRVV inside of the ball call is the magnitude of the correction I’m making: i.e. how much distance am I putting between the SRVV and the 3.5 degree glideslope reference bar in the HMD. Still though, once you call the ball, DFP, SRVV, Magic Carpet, and all the tools in the world won’t help you if you don’t honor the rules of ball flying and respect what the lens is showing you.

 

[MachTuck]

And yes, if you have a lower ships speed entered, it will cause you to go low on glide slope and you will be constantly pulling back on the stick to hold a centered ball. However, it is important to note that using DFP doesn’t relieve you of your requirement to fly the ball and honor what the IFLOS is showing you.

Tunnel vision, on the narrow task of fixating on the SRVV only, without checking the ball, etc. might happen to a tired person. I'm not a pilot, but aircraft "Human Factors" is an area we non-pilot engineers can get some insight from.
I would agree that multiple cross-check opportunities are in the environment which should compensate for failure of any one part. (I used to always try to code "Reasonableness Cross-Checks" into flight controls & HUD software code back in the day, just to detect problems and take corrective action.)

OK, thanks to Hopeful Hoya's and sevenhelmet's excellent communication skills here, I think I'm getting the main points of this.

If I were a pilot doing a PLM landing, I'd want to see the aircraft flight path vector just above and to the right of the SRVV to tell me I've got the lead I need on a ship relatively drifting to the right and moving forward too. Could be that flight path vector is there on some jets, and not on others, or an option.

 

[sevenhelmet]

Using the SRVV is nice because it declutters some stuff from the HMD and makes it easier to reference a visual scan, but “just put the SRVV on the wires” as some people on the internet talk about is still a bad idea for a lot of reasons.

The only real data I personally glean from the SRVV inside of the ball call is the magnitude of the correction I’m making: i.e. how much distance am I putting between the SRVV and the 3.5 degree glideslope reference bar in the HMD. Still though, once you call the ball, DFP, SRVV, Magic Carpet, and all the tools in the world won’t help you if you don’t honor the rules of ball flying and respect what the lens is showing you.

This, for sure. I can count on the fingers of one hand SRVV on the wires would have worked as a technique, but it was a good yardstick for how big of a correction I was making, since throttle position doesn't necessarily equate to energy state with DLC. Usually the the boat would adjust their speed between me inputting ship's speed and actually rolling out at the start, so the SRVV could be more or less anywhere, including well on the near side of the ball to maintain a crester and not blow it off the top (weird, but it happened).

Bottom line, FTBATWTTD, & paddles is always right. At least until the LSO debrief.

 

[Hopeful Hoya]

If I were a pilot doing a PLM landing, I'd want to see the aircraft flight path vector just above and to the right of the SRVV to tell me I've got the lead I need on a ship relatively drifting to the right and moving forward too. Could be that flight path vector is there on some jets, and not on others, or an option.

I'm not saying that wouldn't be useful, but when you only have 15-18 seconds of ball flying, allocating time to scan and interpret that wouldn't be worth it, IMO. And unless you're using JPALS with data-linked ship speed, you still wouldn't know if you have the "right" ship's speed entered.

Again, in the short time you have available, the simplest solution is fly the jet based on what the lens is showing you or what paddles is telling you. Then, if there was any weirdness in how the jet was flying, you'll take a look at in the debrief if maybe you had an incorrect setting or something else was going on. The last thing you ever want to do is try to start troubleshooting things when you're already flying the ball.

 

[MIDNJAC]

Yeah as was said, a great thing about PLM is that IMO, it relieves you of the need to look at anything in the HUD (at least for the most part). At night, I'd dim that thing down as low as it would go without turning off. Then just look outside, look long, all that stuff, and keep the indexer lights in your scan. On the unusual occasion that you boltered, just turn the HUD back up as you climb out. Probably bad technique, but it was pretty common at that point in time I think. You'd be surprised how much more clarity you get looking at the IFLOLS when there isn't a bunch of HUD symbology washing it out until about IM.

Conclusion: the SRVV, GRL, etc were of no use to me at the boat. I will use them during a shore based approach if I want to land somewhere specific, like the very first few feet of the runway because I need it all.

 

[Brett327]

If a pilot enters in zero Ship's Speed by mistake, when it should have been around 25 knots or so, I'm estimating it could put the SRVV cue on to the edge of the deck where the aircraft might shear off the landing gear and go sliding off into the drink.

Anybody tried it out in the simulator? As in, enter zero knots for a ship that is going 25 knots and see what happens. Does the SRVV (aka, delta path indicator, "walk" toward the nearest edge of the deck on approach?

You still have to fly the ball. DP isn’t set and forget.

 

[MachTuck]

The real value of the PLM flight control laws are the way it controls airspeed (autothrottles) for you, and does the direct lift control DLC thing. An airplane with a canard is really good at DLC in the landing task. On the JAS39 Gripen flight sim I was working on for the Swedish AF (U.S. company contract), I'd have some landing fun experimenting with simple canard-to-flaps interconnects (set at the ratio of the surface effectiveness stability derivatives), at night with popcorn & coke off-hours, and was able to set the mains down with the nose gear probably an inch above the runway, on the money, every time. That's what geeks do in their spare time when given an expensive simulator, full cockpit, and Silicon Graphics visuals, which were good in 1992 ! Even earlier than that, I tried to get Honeywell to let me implement DLC in the landing task for an MD-11 using spoilers to no avail, only to watch pilots over the last 30 years have accidents in flare occasionally due to pushing the tail down late in the flare (non-minimum-phase control is a bee-atch). MD-11 management didn't respect my argument that "Hey, the L-1011 has it, and we really need it on this beast." Or, "Let me do this; it's easy with eigenstructure poles-zeros assignment like in my grad school thesis." I scared them I guess.

 

[MachTuck]

.............. great thing about PLM is that IMO, it relieves you of the need to look at anything in the HUD (at least for the most part). At night, I'd dim that thing down as low as it would go without turning off. Then just look outside, ..................

Wish the Eglin F-35 accident pilot would have done exactly what you describe. Instead, a misaligned HMD distracted him.

https://www.afjag.af.mil/Portals/77/AIB-Reports/2020/May/Eglin%20AFB%20F35A%20AIB%20Report_Signed.pdf

 

[taxi1]

it's easy with eigenstructure poles-zeros assignment

Why use a simple pole-zero plot when you can use a 10-layer neural net?

https://media-exp1.licdn.com/dms/image/C5622AQERCm0WWyV7Sw/feedshare-shrink_800/0/1594650054053?e=1648684800&v=beta&t=tYh_Biw2URbh0KyT7ciWOU17OS_G5DzigumsdPfRwh0

 

[sevenhelmet]

You guys have officially gone down the rabbit-hole of nerdery.