Litjan

Oh, you are saving your replay and then playing it back later on? This will most likely not work, sorry. Cheers, Jan

Hi guys, back at home. The turnaround state is configured in the way we did it with my airline when I used to fly the 737. Fuel pumps are ON (they will only be turned off when leaving the airplane) Window heat is OFF (this is part of the parking items) Hydraulics are ON (they will be left ON all day long, because every time you depressurize a system, you would need a ground-hydraulic-clearance to pressurize again) Air conditioning is AS REQUIRED, Isolation valve will rarely be moved out of AUTO, certainly not as part of normal procedures. Position lights are AS REQUIRED and certainly OFF during the day. Ignition switch would be left on L or R, that is correct - but we have to pick something, so BOTH is certainly viable, and if we picked L then we´d get bug reports on almost 50% of all days... MCP SPD I am not sure - it should be in the last position, unless the plane was unpowered (which it wouldn´t for a normal turnaround). Parking brake is most likely OFF (with chocks in place) as that allows cooling of the brakes a bit better. I realize that there may be many different ways to do this - but we had to pick something. Jan

Hi Michael, I tried this before and it worked correctly for me. I will try one more time just to make sure... Cheers, Jan

Hi, this would depend on the airlines procedures, and most stuff you mentioned was not handled that way when I flew the 737. Jan

Yes, look for the official FCOM and other documentation, there are plenty to be found on the web. Jan

Hello Bernardo, thanks for the feedback! we are looking into allowing VNAV to work for climb and cruise even if there is no valid E/D waypoint in the route - the FMS won´t be able to calculate a descent, but using VNAV for the other part should be possible. It is customary procedure for most airlines to always enter the expected approach and runway while still on the ground, this way the FMS will give you more accurate predictions - and then change the STAR and approach later on, if necessary. I think flying without this entered is one of those "simmerisms" that Cpt. Randazzo is talking about, but we will probably cater to it, nonetheless (I am not even sure if it works in the real aircraft, I have never tried it in 16 years of flying Boeings...). The descent calculations are still buggy, and Tom will be working on them shortly - there are some more pressing issues to take care of, first, though. As for your approach speeds being way off - I don´t know who put a weight of 315.900 lbs (or kg?) into the FMS, but for that weight, I would consider 577 kts appropriate . That being said, we should probably reject values this high, and I will forward that as an enhancement request to avoid user error to Tom. Jan

Yes, I see it is lit on the movies - I will just check my movies at home - it is possible that it might be a version thing, but it is equally possible that we have this behaviour wrong . Thanks again, Jan

Hmm, ok - thanks for the report - I don´t get that, so it´s hard to reproduce. Could it be a conflict with another plugin (SoundMaxx, JAR, etc.)? Jan

Excellent - finally someone found out how to reproduce this - I will try myself and add to the list immediately! Thanks, jan

Yes, in the real world the transponder needs to be on on the ground, but Mode C will not start until airborn. But the ATC radar will receive the Mode S blip, so they can see the airplane (and its identifier) on the ground movement radar screen. I suspect that this feature is not supported on VATSIM etc., so those networks depend on Mode C to see aircraft on the ground. Jan

Hehe, the places you people fly to! Thanks for the report - it is the same iteration of the known bug, where the FMS is having a tough time with conditional waypoints and their desired direction... Jan

Hi and thanks for the report. I think the weird route in pic 2 is caused by the plane not being able to make the second waypoint after the bypass. To cure this, try to put RIDSU right after ODAVU or reduce the speed at ODAVU. This is a classical "double bypass" situation, where the FMS has a tough time. We will improve on this eventually. Just for grins: The real FMS will lock up on a "triple bypass" situation (where it can´t make three waypoints in a row), so you have to be careful with the way you code procedures or enter waypoints. Cheers, Jan

The ADF functionality is a function of X-Plane´s ADF system. It will not allow selection of 0.5 kHz and only go to a certain range (999 kHz). Sorry. Jan

Hi Julian, I will doublecheck with my cockpit videos, but I am pretty certain that the FD master lights extinguish when an AP is in CMD. Thanks, Jan

Hi and thanks for the report -- I have never seen this, but could think of a few causes: The N1 should go to the value specified on the TAKEOFF REF page - depending on environmental factors, a derate or thrust reduction selected this could be between 83 and 93% (or so). If the A/T is not achieving this N1 after pushing the TO/GA buttons, it is most likely because either the THR HOLD speed is reached before the A/T is done (this is at 84kts), or because the users joystick is interfering. This would happen if you move the joystick thrust lever down a bit during the takeoff run. The logic interprets this as an attempt to reject the takeoff, and the thrust control is handed back to the joystick thrust lever. To avoid this, follow the procedure that we suggest in the tutorials: After pushing TO/GA buttons, advance your joystick thrust lever ALL THE WAY FORWAR TO THE STOPS immediately. Don´t try to follow the "ghost throttles" or try to adjust to the correct position. All the way forward very rapidly, then don´t touch them. Let me know if this helps, Jan

Hi Graeme, yes, I think you are onto the core of this matter - the only question is if the "REAL WORLD" VOR is also displaying this "wrong" behaviour or not. I have seen it on many VOR´s in California, for example. The published course between VOR´s on V-airways are not corresponding with the magnetic bearings between the VOR´s. I would expect the "VOR NORTH" value to be published along with the database by navigraph or Aerosoft, This is the corresponding line from the earth_nav.dat for the ROI VOR: 12 66.56253900 025.82040800 661 11770 50 0.0 ROI ROVANI VOR/DME The "0.0" before ROI seems to be the VOR NORTH value, and it looks like it is 0 in the default nav-database.... maybe it is wrong in the database you are using? Cheers, Jan

Yep, it is a bug - we are tracking it and hoping to fix it soon! Thanks for reporting it, Jan

Yeah, this is something we have seen occasionally - it is on the list, thanks! Jan

Hi Graeme, To clarify things when I spot differences like that, this is what I do: I output the MagVar and other parameters on the screen. For EFRO I get 11.9 deg var East in X-Plane. Skyvector has a variation of 10.0 deg East. This calculator: http://www.ngdc.noaa.gov/geomag-web/ has it at 11.2 East (and changing to more east fairly rapidly each year, so X-Plane will be more accurate in the next years...) Now there might be a local distortion to the calculated field at EFRO, and X-Plane could not allow for that unless it moved to a tighter grid of var datatables, but since they are mostly "handfilled", this is not feasible. The VOR NORTH value I am not familiar with, but I would assume that this is the TRUE direction that the 360 radial is pointing at (otherwise you would have to change this value again with every shift of the magnetic field). So (just an assumption) this would be the true direction of the magnetic north (the variation) at the time the VOR was INSTALLED (not todays!). There are also some (accepted) discrepancies in procedure design in the real world, I guess. Look at KPHX ILS 08. The runway is TRUE 090. The variation is 10W. The magnetic runway track should be 080, yet the official ILS chart calls for 078... Jan

All correct, but not relevant to the question - this is the barometric decision height used in a CAT I approaches and will never be set on the ADI DH window. That window is exclusively for radar altitude decision heights, and those are only used for CAT II and CAT IIIa approaches. For the 737 the DH is around 100 feet for CATII (you can find the value on the charts) and always 50´ for CAT IIIa approaches. So you need to dial that value to -20 for most approaches (that way it blanks and doesn´t call minimum), UNLESS you do a low-visibility CAT II or CAT IIIa approach. Jan

Difference in EGT/Oil Qty and pressue is normal and intended - different levels, different engine age, it is random. If you open the crossfeed, fuel will never balance if you keep all pumps on - this is a common misconception! One set of pumps is always a "bit" stronger than the other, and if you understand fluid dynamics, you will see that that tank will then supply fuel exclusively. To balance fuel: Turn open crossfeed. Turn OFF the fuel pumps for the tank with less fuel (memorize: Low fuel - low pressure). Wait until levels equalize, then turn on all pumps again and close crossfeed. Jan

The subject is very complicated and not many people can understand and follow an explanation of this. Just in a nutshell: The variation in X-Plane is not always accurate - I made it and it is going to be accurate in 2020 and a bit inaccurate before and after that (it gets worse later, then I will have to make a new table for Austin). The radials of most VOR´s are not accurate - i.e. Radial 360 is not pointing in the direction of 360. This is because the variation changes, and they would have to physically adjust the VOR´s to keep up, and they don´t do that. So it is perfectly normal to track a VOR radial with a different magnetic track than the radials "name". Jan

Thanks for the log - this will help us narrow down on these problems and fix them! Jan

We support LAT/LON as far as they can be found in the FIX database. Jan

The intersect field will take data for a runway intersection takeoff - either the displacement in meters, or the name of the intersection. In the real plane the position of the FMS will update to the runway beginning when you press the TOGA buttons. If you take off from an intersection, this update would be erroneous, since you are not actually at the beginning. So you can enter an intersection value (i.e. 900m) and the updated position will be correct. If the FMS position is being fed GPS data, this update will not be taken into account - so it does not matter if you enter anything or not. The IXEG 737 will always have GPS updating, so entering anything (or nothing) into this field will have no effect. Cheers, Jan