rX

FMC position update upon TO/GA selection based on runway threshold + RWY REMAIN setting in FMC when no other navigation available is missing in PMDG 737NGX and the MD-11. I have not yet tested 777 as I do not own it. Tricky thing is that the FMC provides the option to set this but it's just cosmetic as it does nothing.

Ryan, If you remember I reported the exact same issue back when NGX was released. After I managed to track down all steps required to reproduce the TCAS module programmer created a new version that fixed this issue. Could it be that the new code didn't end up in the 777 eventually? I can't test as I don't own the 777.

Thank you Bryan for the quick reply. Have monitored approaches ever been Boeing SOP?

The feature list IS authentic.

I remember the older version of FS2Crew (the one for the FS2002 PMDG 737) had the feature of monitored approaches. Looking through the Boeing latest NP and FCTM there is no separate procedure to be done in low visibility. Was this not Boeing procedure but local SOP for some airline or was it in the old Boeing documents and removed now? Basically the question is what happened to monitored approaches in real life and why were they removed? What do you do now in low visibility? Does the PF (assuming no HGS) use the instruments until minimums and at minimums look outside for a second then go around? Thanks, Eric

Hallo, Trying to get familiar with all modes of IRS update I ended up trying to use RWY REMAIN feature of the IRS update in lieu of GPS or other position update features. However trying everything I couldn't see it in action. First test was with VOR L/R DME L/R, ILS L/R and GPS L/R set as failed and IRS set with slight offset coordinates. Afterwards I taxied the aircraft to the end of the runway, selected the correct runway and depressed TO/GA. Second test was with not failures but in NAV STATUS> NAV OPTIONS page I have turned off DME, LOC, VOR and GPS updates and used an intersection takeoff and entered the remaining runway in RWY REMAIN field. Upon selection of TO/GA in both cases the position didn't update to the runway threshold (or THR + distance) and remained in the wrong coordinates. Can anyone confirm if they have tested this previously? Is my testing method flawed? Or is the feature actually not implemented? Thank you,

Exact RGBs have nothing to do with how it will look in a specific rendering engine. So the spot color (not RGB by the way) used in the real livery would be useless in this case. What you need to do is adjust and compare in FS X many times until you get it right. Your eyes are the precious, rarely utilized tool used here.

Ok. This somewhat works. After shutdown I switched from APU to APU/EX mode and asked ground "Please connect external G P U now". This time he heard me and connected it. Then he confirmed by saying "external GPU now connected and you can shut down engine #1". Of course engine number 2 was off. Also if in preflight even if switching to APU/EXT ground won't reply at this point anymore. So if after starting the 2nd leg preflight if you later decide to add GPU to turn off APU there is no way to do it except force it outside FS2Crew. Bryan, thus my request as detailed above, for a true mode for APU switching to EXT PWR reaching stand remains on request.

Thanks. If this works it will be the answer I was looking for all along 12 posts ago.

Damien, Although I have reports that all airlines operating at this airport do this the same way and at least one other report from an airline that does not fly here (granted not double checked) what I am asking is not individual airline policy. What I am asking is flexibility on behalf of the ground crew independent of the mode you are using. If I ask him to connect the GPU on APU mode he should. To elaborate, if I am on a 30 minute turnaround I will only be using the APU (a common situation of a low cost airline operating 737s) but if due to some delay brings me over the 45 minute mark with the APU operating I will need to ask the ground crew to bring around the GPU and connect it. How do I do that now?

2. Yes, I know. *I* requested them in Mantis. But in preflight? 1. The original post describes everything. You cannot ask the ground staff to connect the GPU when under some modes. Because, what is written in the original post.

Damien, Thanks for your feedback. What you say certainly makes sense to me however not being Chief Pilot for the Boeing 737 series for this company there is nothing I can do at this moment to change this procedure. The company is TAROM. Bryan, Can the Ground Engineer be open to doing what the captain asks him rather then what he thinks is right? PS. Quick bug report just so I don't forget for later: saying one of the FMAs out loud during preflight will result in the F/O replying checked. Should this be limited to before takeoff to after takeoff?

That way may be correct but it is not the only way. While I know about only this airline from the SOP I have briefly seen in other airlines this procedure as well. From my own limited experience at my local airport I have never seen an aircraft ask the GPU to be connected while *any* engine was running (including only engine #1). I will check with some ground staff to confirm this but at least this is a confirmed procedure. I'd like the Ground Services to be flexible in this regard and not only accept predefined situations.

All the manual options for arrival except APU only mode involve turning off one engine then connecting GPU then turning off the other. I have read the manual and implied in the OP. And using the APU mode for landing will not allow the ground services to recognize commands such as "please connect the GPU now".

Bryan, It may be possible but I may just not be saying the right things. At my local airport with the local airline they follow one of two procedures regarding ground services, depending if on stand or on gate. As far as I can figure out I can't do either of them in FS2Crew without going around it. I may be wrong and if so please tell me how. This is in regard to interacting to ground Services. #1. On gate, they have integrated external power and air. However the procedure here is that after landing they act as if coming in on APU, by starting it putting it on the bus and on gate they turn off both engines and then after the beacon is off the ground connects headset and they ask them if the electrical and a/c is available and if so they ask them to connect them. After they connect them they verify the electrical is within limits and if fine and stable they bring the external power on the bus and then turn off the APU. In SP1 I set the APU as the mode for power for arrival. However when reaching the gate asking the ground units to connect GPU and A/C are not recognized in that mode. For departure if all the above was performed they will turn on the APU for engine start then ask ground to disconnect. This can presently be done with FS2Crew and it switches properly to APU mode. #2. On stand, GPU cart only mode. A/C (air conditioning, not alternative current) is never available. As before on arrival they come in on APU and after engines off they ask for GPU verify stability and if everything on they bring it on the bus and if A/C not required they turn off APU. If A/C will be required like on hot days they may leave the APU on only for A/C but use the GPU for power to reduce fuel consumption. In FS2Crew if you come in on APU it will not accept that you want to connect the GPU. Also loading a situation with GPU only will add the A/C in electrical powerup. The APU/EXT mode may be what I am looking for but it is unclear when the A/C is added and how is this handled when selected on arrival. On departure when A/C is deemed required they will bring the APU online and then use it for power shortly before engine start and disconnect GPU before engine start. This is possible in FS2Crew as at #1. -- A possible idea is to allow the discutions to ground crew be independent so I can ask him to connect either the GPU or only the A/C or ask him to disconnect either/or in any situation. Right now I can for example use the video marshalar to do this, but otherwise following FS2Crew voice commander flows much of this is not possible, especially reaching the gate on APU and then switching to GPU. Thanks for your time,

Just choose to use a fixed Aircraft Option Configuration. The hours are saved in that file and will now transfer to any aircraft you fly. The downside will be you will only have the same options on equipment independent of livery/company. You could also cut/paste in the text files themselves.

After a case like this in the Real World would you need to run through Preliminary preflight procedures and on through Preflight again? Damien?

From my experience I use NGX starting up in VC mode, EZdok and FS2Crew from RTM to SP1 through all the betas without any issues in starting up in VC mode directly. At this point I see no reason for changing that. Bryan?

I'd like to know that too - this is exactly my setup and I have a developer licence for P3D and planning to use it for my installation next time I format.

Awesome. Only if you think it as appropriate. Don't change something just for me. I'm thinking adding more phrases it might make voice recognition mistakenly understand something else more often. If it won't then that would be lovely and the usual awesome bryan-esque after sale service. Speaking of CDU. According to the CRM practices in the Boeing 737 NP.11.3 the Pilot Monitoring should make the inputs to the CDU and the PF should confirm before executing. But I recon the amount of AI required to accomplish that task in most cases would not be available. But it might be worth looking at being able to select UP select DIRECT TOs?

That gives me a ton of headaches. I am used to saying "Bug UP speed" from our SOPs and during takeoff I revert to old habits. Eventually I'll learn it

ATC-wise there is something else you are missing. Any non-ILS approach will have less separation than an ILS one, especially in Low Visibility Operations but in normal conditions as well. Let me put it this way, on an ILS on an runway we need to have 6 miles between two planes on the same ILS beam. However the minimum separation between two planes landing the same runway is that the runway must be empty by the time the 2nd one crosses the threshold. That's more like 3 miles for a medium jet same speed. So we're basically wasting 3 miles. All because of the ILS' beam radio unreliability, as said above. You can make up for it by getting a departure in there, or in case weather is no factor (most of the times) you can get in there the 2nd aircraft on a non-precision approach. Any one like NDB, VOR or RNAV will do and will allow you to give better separation. Or in the case of FAA-land, a visual approach. We are not allowed to offer visual approaches over here, only pilot must request them. Choosing between non-precision approaches pilot-wise, I'd say both NDB and VOR, even though programmed in FMS and flyable in VNAV/LNAV for aid, you must still monitor the raw data. The RNAV approach frees you of that hassle so a clear winner. But for me the choice between ILS and RNAV/RNP can be pretty blurred. If we don't take into account the minimums since most of these approaches are flown in well above minimums weather then the way to fly these approaches in a Boeing is identical. Boeing seems to have worked very hard to allow this and it turned out really well. However we can't forget the weather since since Instrumental Approach is designed to be able to bring you down to the airport, and usually the landing runway, while you are unable to see the runway so this is their primary function.Right now all over Europe because of commonality the ILS are still the primary means of approaching a runway but I expect a quick shift toward using RNAV approaches in priority to ILS in normal weather as the majority of planes get this capability because of the reasons I have stated in the first paragraph. The lower separation is more important then lower minimums given the traffic that we get.

That's done it. All is ok now. But the betatester in me wants to know why that was happening in the first place. Might have been the font. Bryan, can you confirm that it needs to install a font?

Just tested after modifying the Standard.XML file with CTRL. FS X in controls shows that CTRL is set as the button for that action however it doesn't run that action on CTRL. I have tested with Gear Toggle as well to see if it would do anything even outside FS2Crew but it seems to filter it out even though it looks fine.So the two issues that I have remain. Regarding the font: what font does FS2Crew use for the textboxes? Maybe it simply was not installed if it is custom.

No. The later edit was only in regard to the "big panel" comment. The text or the panel itself never changes size indifferent of FS window size and there are no handles to resize it, so there is absolutely no change to the "rendering" of the font inside it.For now I can guess what is in the PWR window by clicking once and a 2nd time according to the manual. I have no idea what are the arrows in the PB REQ window however but I will find it in the manual. Now you go to sleep and catch some well earned rest and we will figure this out the following days. Good night :)