Flexman

Hello, I have a WinWing Orion Throttle base. It has several rotary knobs (every rotational click is a button signal) and I want to set those up to control the MCP of the PMDG 777 in P3Dv5. I've managed to get it to work but there's at least 2 or 3 seconds of lag from when I start rotating the control to when I see a reaction in the sim. The alternative that I'm using now is to use FSUIPC6 to assign keyboard commands to these buttons and simply set up those key commands in the FMC menu of the airplane. This way I can avoid the lag but the control responsiveness is not very fast and if I rotate the knobs too fast the in sim control keeps rotating as if it's got a queue of signals to finish with. I'm not an expert in Linda (been using it for just 2 days). Could anyone help me troubleshoot this lag? Hints: -Whenever I try to set up the function of a button in the Joysticks menu in Linda, the selected input keeps changing as if Linda was constantly receiving inputs. I cannot see those inputs in WinWing's software (SimAppPro). -Logging in FSUIPC6 is deactivated. -The Linda Console is full of text and it doesn't stop printing more and more events. Like this non stop (In Console Standard mode) [EVNT] Execute Command = "PR:4098BE620:30" [EVNT] Execute Command = "PR:4098BE620:31" [EVNT] Execute Command = "PR:4098BE620:66" [EVNT] Execute Command = "PR:4098BE620:68" [EVNT] Execute Command = "PR:4098BE620:69" [EVNT] Execute Command = "PR:4098BE620:74" [EVNT] Execute Command = "PR:4098BE620:75" [EVNT] Execute Command = "PR:4098BE620:77" [EVNT] Execute Command = "PR:4098BE620:87" [EVNT] Execute Command = "PR:4098BE620:90" [EVNT] Execute Command = "PR:4098BE620:5" [EVNT] Execute Command = "PR:4098BE620:18" [EVNT] Execute Command = "PR:4098BE620:24" [EVNT] Execute Command = "PR:4098BE620:30" [EVNT] Execute Command = "PR:4098BE620:31" [EVNT] Execute Command = "PR:4098BE620:66" [EVNT] Execute Command = "PR:4098BE620:68" [EVNT] Execute Command = "PR:4098BE620:69" [EVNT] Execute Command = "PR:4098BE620:74" [EVNT] Execute Command = "PR:4098BE620:75" [EVNT] Execute Command = "PR:4098BE620:77" [EVNT] Execute Command = "PR:4098BE620:87" [EVNT] Execute Command = "PR:4098BE620:90" [EVNT] Execute Command = "PR:4098BE620:5" [EVNT] Execute Command = "PR:4098BE620:18" [EVNT] Execute Command = "PR:4098BE620:24" [EVNT] Execute Command = "PR:4098BE620:30" [EVNT] Execute Command = "PR:4098BE620:31" [EVNT] Execute Command = "PR:4098BE620:66" [EVNT] Execute Command = "PR:4098BE620:68" [EVNT] Execute Command = "PR:4098BE620:69" [EVNT] Execute Command = "PR:4098BE620:74" [EVNT] Execute Command = "PR:4098BE620:75" [EVNT] Execute Command = "PR:4098BE620:77" [EVNT] Execute Command = "PR:4098BE620:87" [EVNT] Execute Command = "PR:4098BE620:90" [EVNT] Execute Command = "PR:4098BE620:5" [EVNT] Execute Command = "PR:4098BE620:18" [EVNT] Execute Command = "PR:4098BE620:24" [EVNT] Execute Command = "PR:4098BE620:30" [EVNT] Execute Command = "PR:4098BE620:31" [EVNT] Execute Command = "PR:4098BE620:66" [EVNT] Execute Command = "PR:4098BE620:68" [EVNT] Execute Command = "PR:4098BE620:69" [EVNT] Execute Command = "PR:4098BE620:74" [EVNT] Execute Command = "PR:4098BE620:75" [EVNT] Execute Command = "PR:4098BE620:77" [EVNT] Execute Command = "PR:4098BE620:87" [EVNT] Execute Command = "PR:4098BE620:90" [EVNT] Execute Command = "PR:4098BE620:5" [EVNT] Execute Command = "PR:4098BE620:18" [EVNT] Execute Command = "PR:4098BE620:24" [EVNT] Execute Command = "PR:4098BE620:30" [EVNT] Execute Command = "PR:4098BE620:31" [EVNT] Execute Command = "PR:4098BE620:66" [EVNT] Execute Command = "PR:4098BE620:68" [EVNT] Execute Command = "PR:4098BE620:69" Thanks!

Maybe this animation explains better what I'm looking to do.

Hello, I've been wondering if there's a way to change the camera center in Prepar3d. I don't mean panning the camera left or right I mean shifting how much cockpit we see left or right by shifting the vanishing point position so that it's not centered in the monitor (kind of what would happen with a tilt shift lens on a camera). I place my camera such that in my 27" monitor I see the whole MCP and my PDF (FO seat). To achieve that, I have to move the camera to the left and that leaves me uncentered with my PFD/control column, like you would sit in the actual cockpit. Is there a way to change the render center so that the new center of the render shifts to the right of the monitor while keeping my control column centered with the PFD? I made an animation (with photoshop) that I hope explains what I mean. Notice how the vanishing point is shifted to the right (which is what I want) and there's more render to the left of it. Thanks

Airport Elevation and Threshold elevation in P3D should be identical as airports are completely flat.

Fair enough 😆

The LANDING ALTITUDE REFERENCE BAR starts at the LANDING ALTITUDE INDICATION. The first 500 feet of the bar are amber and the last 500 ft are white. We call 500 CONTINUE or GO AROUND exactly at the point where the landing altitude reference bar changes from white to amber. When parked on the platform in the real non-flat world, if you change the departure runway you can see how the landing altitude reference bar moves up or down. So it's definitely threshold elevation. In P3D airports are flat, so airport elevation should always be equal to threshold elevation anyway. From my experience with FS2CREW SOP3, the 500 continue call doesn't happen when the reference bar changes from white to amber. I thought the problem could be that it was RA based but since your code is correct maybe the problem is not on your side but on the PMDG SDK..I'll ask in their forum. Thanks

Thank you, but that's just how the procedure is. You don't need to be flying over a mountain for RA to be different than aerodrome level. At the time you are 500ft above the airdrome, the radio altimeter will be reading hills, the sea, trees and what not. Even in very flat areas you can see a difference of 100ft or 200ft. airports along shores have this too, where the radio altimeter will show you a higher height than how high you really are with reference to the threshold. What matters is that in real life the trigger for 500 continue or 500 go around is the amber bar in the landing altitude reference bar in the altimeter, not the radio altimeter 500ft reading. Thanks for looking into it. I'm just pointing out the differences between SOP3 and the procedures in the company on which they are based on, for which I happen to fly for.

Hello, In SOP3, the "500 continue" call on approach should happen at 500ft AAL not RA. That means it should happen at the beginning of the amber bar in the Landing Altitude Reference bar in the altimeter and not when the radio altimeter reads 500ft. Is there a chance to get this fixed or is there a sim limitation? Thanks!

There's just too many little things that change every year. Basically most of SOP3 is outdated now. It's ok for a regular simulator user though.

Hello, Is there any way to change a trigger phrase or even a procedure? I use SOP3 and some of the callouts are a bit outdated. Thanks

Oh yeah true. EI-DAC is still around. It's been based in OPO lately.

You think about graphics on the PMDG needing updates. I think that's useless. We're on a super old version of the FMC and AFDS and, if anything, that's the main thing that PMDG need to start working on. Even the 777 and the 747 have outdated softwares that no real world airline is using right now.

All you have to do is select the new altitude on the MCP Altitude Window and hit ALT INTV. The airplane will descend on VNAV PTH at a fixed rate of 1000fpm. If you plan to stay long enough at that new altitude, just set up a new CRZ ALT in the CRZ page and change the FLT ALT on the presurization panel. If that's not a new cruise level and you expect to continue descending, when they give you a new cleared level, just set it in the MCP, the airplane will catch the new VNAV PTH and fly it. Sometimes the instruction is "descend now" and some other times it's "descent at discretion". In one case, you don't have to start your descent until you hit your TOD. In the other case, ATC expect you to descend with at least 500fpm.

I don't think you'll find one. Make it yourself as part of the project and then you could upload it for others to use. Shouldn't be hard considering you'll only have to do single case letters, numbers and just a few other characters.

That's exactly how the old 757 I used to fly did it. If you're high, it'd go VNAV SPD and if I remember correctly, it'll open the speed window on the MCP for you to increase speed to catch up. In fact that's one of the hardest parts I found when learning to manage our version of the 737. The fact that VNAV PTH has such a large tolerance when above the path, that the airplane will not think twice before diving. People tell me it will happily exceed MMO/VMO... haven't tried in the real airplane. In the sim, with steady winds, it didn't hit barber pole. Most people I fly with don't question it because, in this company, most people have only flown for this company, so they don't have a comparison point (flight sim or other boeing airplanes). It was very strange for me to see on a 250kt descent, the bug slowly crawling to 220 after a decel point. My initial interpretaion was that the airplane was so bad at keeping that speed in a poorly calculated idle VNAV PTH, that FMS was just giving up and matching the actual speed of the airplane. Now I know what the airplane is doing but since the speed window is closed, I've had to train myself to look at the descent page to know what final speed it's going for, and whether it'll be able to reach it or if it'll require flaps. I don't really like that feature to be honest. In the 757, the bug would just jump instantly from 250 to 220 or whatever speed you had set up in the next waypoint or restriction. No need to look at the CDU.

My bad. I can confirm our airplanes are on U13.0. U13 came out in April 2017. Just checked my FCOM and it says that some older ones are still on 10.8A which is strange because I flew EI-DAD a few days ago and I remember it having RTE2 and all, so maybe, it being the oldest airplane in our fleet AFAIK, I'd assume they've all been updated to U13.0. I also know U14.0 is coming with the MAX and will probably be retrofitted in the whole fleet because we already have FCOM bulletins talking about the "bugs" that we can expect to be corrected in U14.0

Yeah. Well. We have many simulators in my company. Of course the full flight sims are exactly like the real airplane because they follow pretty much the same update schedule, so they all have RAAS and the latest of the latest that you'll also find in the real airplanes. In fact some things appear first in the simulators for testing and training content creation and then they put them in the real airplanes, like the GLS that we're starting to use in some bases. Having said that, we also have quite a few less complex sims that all pilots can book and use for training and some of those have older versions of AFDS and FMS. Some are on U10.8 for the FMS just like the NGX. Our real airplanes have U14.0 with RTE2 and other nice things. The NGX is just astonishing to be honest. I can use it to prepare exactly how I'll configure the real airplane on some of the approaches. We have airport briefs that tell us the most likely shortcuts we'll get by ATC during terminal operations and being able to prepare those at home as part of my pre-flight preparations is just amazing. When your company wants you to turn the airplane around in 25 minutes, the more you've self-briefed at home, the better. THE VNAV THING This is how the NGX does it. You're descending perfectly on path, engines idle, at the perfect FMC SPEED in VNAV PTH and it's all good. But suddenly ATC gives you a shortcut. Now you have less miles to descend so you're suddenly some 2000 ft high. What the NGX does is it reverts to VNAV SPD, which is a fancy level change with FMS level restrictions. The airplane will do an idle VNAV SPD descent at the same speed you were at when all was perfect. The airplane will not catch the path at that speed. In VNAV SPD, the airplane will not dive and it's up to the pilot to increase the speed and maybe use speed brakes to catch up with the descent. Of course we don't do that. What we do is select a higher speed in the CDU to find a speed path that is closer to how high we're left and we fly that and try to get on a faster VNAV PTH instead of the ECON one dictated by cost index... sorry cost index, we tried. This is how the real plane does it (unless your company doesn't invest in updating these things). You're on path and you're given a vector and now suddenly you're high. The airplane doesn't care about how high you are. It just stays in VNAV PTH. VNAV PTH doesn't care about your speed at all, so it will just dive like there's no tomorrow to get back on path and speed will increase by a lot, hopefully, without exceeding Vmo or Mmo (I said hopefully). When it catches on with the new lower path, you're still in VNAV PATH but you're fast. It's a big threat as you have a lot of excess energy now. It's an important skill for a pilot to know how to overcome this because it's not correct. It's not correct to dive like crazy at a speed you have not commanded, to catch up with a path that was programmed for a slower speed. The correct thing is to select a faster descent path and, only if necessary, use speedbrake to fine tune your speed while entering that new path. The more time you have to correct, the less necessary the speed brakes are. For you guys to know. The NGX is so good that this little VNAV behavior is the only little thing that I notice is different between the real airplane I fly and the NGX (among the things that are simulated, of course). The other differences are of course because of the lack of full ARINC 424-19 compatibility in the FMS and the poor 3rd party navdata databases that we have to work with. That's not PMDGs fault, but I do hope they find the time to make an FMC that supports all ARINC 424-19. Sometimes I'm in the real airplane and notice how some terminal procedures are just 2 legs in my CDU while in the NGX it takes 5 or 6 points to draw the same magenta line (arcs, procedure turns, etc).

Thanks! The 757 I flew behaved like the NGX does but the 737 I fly now has this crazy thing that, unless you intervene speed during a descent, it stays in VNAV PATH even if it's high above path. I prefer the version modelled in the NGX. I'm not sure it's safer towards preventing high energy approaches, but it's just more confortable. It's like: Hey, you're high, here the speed window, now you fix it. I thought it was an old/new thing but I guess it's just an option you can get from Boeing.

Hello, Can we expect PMDG to update some of the AFDS logics in the NGX before a new full release comes out? Particularly I mean the way the real 737 now stays in VNAV PTH always during descent, unless the pilot pushes speed intervent to open the speed window to engage VNAV SPD. In the real 737, if you stay high and then you engage VNAV, AFDS will activate VNAV PATH and the airplane will just dive with no respect for speed. VNAV PATH does not care about speed when trying to get back on path. It's supposed to not exceed MMO or VMO, but it often does and you can easily hear the clacker. The NGX has the old mode in which if you go VNAV when you're really high off the intended descent path as per the speed in the descent page, it will stay in VNAV SPD and it will not dive unless you increase the speed in the now open speed window in the MCP. Also, I've noticed FMC SPEED bug in the real airplane will not move instantaneously to a new speed (ie a preset restriction) and it will slowly roll back as the airplane decelerates. Are these things to expect in the coming releases or something that we could see as an update to the current NGX?

Hi, does anyone know if, now that the 747 has been released, PMDG will dedicate some time to polishing the 737? There are a few bugs that have been ignored by the company, having all their resources dedicated to new projects understandably. I don't know the list of bugs that there are, but I know one if them is the incorrect position of the speedbrake lever when in the down position, that makes it hard to click on certain CDU keys when using VR (the lever goes too far in and goes past its actual physical stop). Maybe the company has plans to bring their most iconic product up to current standards. I think the NGX hasn't aged a bit. It feels like it was released yesterday, but it would be so nice if it got some love from the developers.

An RMI shows you your instantaneous QDM and QDR of the tuned VOR. A localizer does not emit radials that an on board equipment can read comparing phases. Localizers work on a whole different principle (depth modulation), so there's nothing for an RMI to point at.

My seating position when using the rift is the position a real pilot would have while at his station. Yes, you can lean to the side and around to see the key, but the problem is the clicking with leapmotion (you use your actual hand in the air. It's impossible to press the CDU key without arming the speedbrake. I've had no issues with the Rift. I'm not a super long flight kind of guy but I've flown probably 3 hours without taking it off once and it does not get warm anywhere where your face touches the headset. Summer is coming, so we'll see how sweaty my face gets when it's hotter than it is now. No eye strain. At all. You need a good graphics card though as, in order to make all screens readable at normal seating distance, in an airplane like PMDG's, you need to set a very high resolution. I've a 980ti and it works perfectly. Should have waited for the GTX 1080 probably.

I sent a ticket already. Here's a better depiction of the problem.

I will. I'll let you know how it goes.

Guys, trust me, it's not the camera. The lever is just in the wrong "up" position, period. This is what's happening. See the physical stop circled in red? That's where the speed brake take-off warning switch is. That thing is correctly modelled in the NGX. In the real 737, the lever, when pushed fully fwd, stops there. What's happening with the NGX is that the lever continues to pivot into that thing. The lever is correctly modelled but the rigging is not. The lever is traveling FWD more than it should. You can see for yourself. Just place the camera next to the speed brake from the side, push it forward, and you'll see it going as if that chunk wasn't there. Shouldn't be hard to fix. It must be a single value in some text file.