Boris_The_Spider

Hi I have a set of PMDG 737NGX manuals (no posters) for sale including Fight Crew Ops Manuals 1 & 2, Flight Crew Training Manual, QRH, Lights & Switches, Jeppesen Charts & Laminated Checklists. I'm based in the UK bt happy to ship worldwide if size/weight limits allow. PM me for further details.

I think they were using a Matrox dualhead2go there (or a triplehead2go with only 2 screens connected). Alternatively, AMD eyefinity might let you span two screens. nvidia surround definitely doesn't - it's 3 screens or nothing.

This pretty much covers it. V1 can be limited by runway length, climb performance, brake energy limits, vmcg. Vmcg constrains V1 at the low end (you can't continue with TOGA thrust on one engine at less than the speed at which you can keep straight with rudder and nosewheel steering), nor can you go unless the remaining TODA at the point of failure is enough to reach 35' by the end, at the high end of the V1 calculation you cannot stop unless the brakes and tires can cope, nor can you reject after rotating. You actually end up with a range of possible V1 speeds, at the bottom of that range you can only just go, at the top of that range you can only just stop. Below the bottom of the range you cannot go, above the top of the range you cannot stop. From that possible range of V1 speeds, you'd then pick one right in the middle ideally, since that would mean either a reject, or a decision to continue, made near V1 would have a margin of error, however in reality you'd normally increase weight (or derate thrust) both of which make it harder to continue and harder to stop, so this narrows the range of V1s (by increasing V-min-can-go and decreasing V-max-can-stop) until you end up with a single V1 at which you can barely stop and barely go. If you want to see a field-length limited stop, you'll need to do your calculations properly with TOPCAT to ensure you have a field length limited situation. When you do that, you will find that the modelling is actually pretty accurate, and you really have to be on the ball to stop on the runway - V1 is not actually the "decision speed" although it's often referred to as that, it's actually the speed at which you have to take the first action to stop, so the decision must actually be made slightly before V1. You then have to get the throttles closed, speedbrakes up, reversers at full, max braking all rather quickly to stop. V1 is also based on net performance (ie. an average) so it's possible that your aircraft won't actually stop, if I remember rightly there is no factoring (no margin of error) in V1 calculation, because it's already considered sufficiently unlikely that you'll try to initiate an RTO exactly at V1 (and max v1 from the range at that), on a limiting field so no additional factoring is required. In the go case, you do have factoring in the climb performance calculations, so an RTO near V1 is far more dangerous than continuing to go. In most cases (ie. a simple engine failure) it's much better to continue given that you have a perfectly flyable aeroplane, than attempt to stop. If you don't have TOPCAT, here are a couple of example situations to try, which are field length limited so should test your ability to stop on the runway: Situation 1: EGMD (Lydd), RW21, departing to Innsbruck (LOWI). WX at Lydd 210/29, +11, 1007, dry 118 pax on board, 1534kg of luggage 5815 kg of fuel on board TOW 59343kg Flaps 25 Derate to TO-2, with a flex temperature of +33c which gives you 87.7% N1 (according to TOPCAT, but the thrust normally ends up very slightly different in the NGX, not sure why) V1 = 133, Vr=133, V2=133 Situation 2: Same as above, but with a wet runway. Flaps 25 TO-2, no flex V1 = 120, Vr=133, V2=133 Notice that Vr and V2 are the same in both these cases - because the only difference with a wet runway is that it's harder to stop, therefore V1 must reduce (for the same weight) but the speed at which you rotate, and the TOSS remain the same. Example 3: LOWI, RW26, WX is 270/08, +2c, 1023, wet runway 160 pax, 7286kg of baggage, 6415kg of fuel on board TOW 69027 Flaps 25, no derate (TO thrust setting, no flex) V1=131, Vr=143, V2=143 Example 4: Same as above, except with a dry runway. This is now no longer a runway limited situation, but rather a climb limited one. That means you can put a bit more weight on board, but we're at MZFW, so we'll have to do it as extra fuel - bump the fuel up to 8375kg on board, then have an engine failure at V1 and continue - you'll just manage to maintain minimum terrain clearance if you fly it correctly. I can't remember how it's calculated, it's quite complex how the obstacle clearance area is shaped and what the requirements are within that area - it's all inherent in the departure procedure and OEI performance requirements for certification, so as a pilot you don't actually need to know it in detail. V1=141, Vr=142, V2=146

Hi, In the 737NGX SP1c, with FMC U10.8A I am seeing behaviour that I don't believe is correct, regarding the speed commanded by the FD with an engine out. I also have a separate question regarding the behaviour of the autothrottle in this scenario. With VNAV and LNAV armed on the ground, I set the sim up to give me a V1 cut, roll, have the engine failure, get airborne and the FD commands V2 correctly (rather than V2+20 for an all-engines takeoff). At this point, the active pitch mode is TO/GA, with VNAV armed. At 500' AGL (baro) or 400RA (I'm not sure which, perhaps someone can clarify?) two things happen, and I have a question about both: 1. The active pitch mode changes from TO/GA to VNAV SPD, as this happens the speed bug moves to V2+20 - this seems reasonable (since we are now at a "safe height"), but can anyone confirm that VNAV SPD should be commanding V2+20 (rather than V2) with an engine out? 2. At the same time as the pitch mode changes, the autothrottle trips out. That doesn't seem right? Nothing has changed on the engine DU at this point - the N1 bugs are still at TO. I am aware that Boeing do not recommend the use of autothrottle with an engine out, but should it automatically disconnect (and remain disabled so it cannot be re-selected)? Now, the thing I am pretty much sure is wrong is this: At EO ACCEL HT as set in TAKEOFF REF page 2 (set in this case to 800') I don't get an acceleration commanded, instead the speed bug remains at V2+20 (and that's what the FD pitch bar keeps commanding). It remains that way until 3000' AGL (the all-engines acceleration height, as set on TAKEOFF REF page 2) when the command airspeed bug moves up to clean manoeuvering speed and the acceleration is commanded. The FCTM says: I believe on the real airplane, this was a bug (the FD behaviour at EO accel ht) but that it had been fixed in U10.8, so since the 737NGX is simulating U10.8A, I believe with an engine out, acceleration for flap retraction should be automatically commanded by the FD at the set EO acceleration height.

It'll work with the 5xx series cards if you use 2 identical (same model, not necessary to be the same make) cards in SLI. 2 x 570s will do surround, but you can't have an additional fourth monitor (what nvidia call an accessory display) active at the same time as having the three in surround. I don't know if the accessory display can be used in FSX/P3D anyway - I seem to remember it can't. Whether you'll be able to use 3 different monitors in surround, I can't say. I've never tried. In 3D surround, you have to have all 3 absolutely identical, that's not the case for 2D surround but I can't remember the exact requirements - as someone else said, it's not actually the size that matters, rather the resolution and refresh rate, however I'm not sure if they have to have the same _native_ resolution - I'd imagine they do, and that you can't just use varying monitors but drive them all at the same resolution, in any case, if you did that the image quality wouldn't be great due to the interpolation.

You can use mixed sizes if all you want to do is undock views to the smaller monitors (either 2d instruments, or views out of the cockpit) but you cannot "span" across one big virtual monitor unless they are all the same size and resolution. Actually, that might be a slight lie. I believe you can use softth to span different size monitors in almost any configuration, but performance is not good, and it's buggy. Having tried 3 monitors in portrait, I'm sold. If you don't have room for 3 in landscape, perhaps you could try portrait surround? It's very nice because the combined aspect ratio of 3 screens in portrait is far more natural than the extremely wide (and narrow, vertically) view you get with 3 in landscape.

I don't have a job yet, but I am a fully trained (apart from a type rating) commercial pilot in the European system (EASA license and IR) - if I can help, drop me a PM.

OK, done. An extremely slipping turn (a right turn, with a bootfull of left rudder, and enough right aileron to overpower that and keep the RXP TC indicating rate one) resulted in the RXP gauge underindicating the turn, which took 1:45. The RealAir TC in the VC indicated as before (on the R rather than the line above it). An extremely skidding turn (a right turn, with a bootfull of right rudder, and enough left aileron to counter the consequent overbanking tendency) saw the RXP gauge overindicate (the turn took 2:15) while the RealAir TC kept it's same relationship to the RXP gauge (wing on the R again). I've never tried making uncoordinated turns using a real TC. I'm trying to imagine the effect on them given what I know about their construction, and it actually seems to me they'd do the same as the RXP does, the out of balance forces tending to tilt the gimbal that's attached to the needle out of a slipping turn, and into a skidding one. I'm happy to report that the Duke (at least the RealAir one) put up rather nicely with my flagrant mishandling, and the peril was always kept at manageable levels! I agree. Just like in a real TC, you can't interpolate or extrapolate - you can only rely on it to read correctly at exactly rate-one, but in my testing it's quite consistent in that it always gives the same (over)indication in an actual rate-one turn, so all that needs doing is to move the marks on the gauge graphics.

Absolutely sure. I just tested again, and with the yaw damper on the result is the same - the RXP gauge indicates correctly in a rate one turn (ball in the middle, wingtip on the rate one mark), but the VC gauge needs the wings over on the L/R marks, well past the rate one mark. I tried that to see what would happen to the VC gauge - if I tried to add rudder to hasten the turn, if I added any appreciable amount of rudder, I ended up having to hold opposite aileron otherwise the wings on the TC (the RealAir one) bank over more, indicating a faster turn. The more rudder you add, the more opposite aileron you'll have to hold, to keep the instrument indicating rate one. But no matter how you manipulate the ailerons and rudder, if the instrument is indicating rate-one, you don't actually get a 2-minute turn, rather you get a 3 minute turn.

Not that the behaviour of the TC bothers me (I didn't even notice it until this thread) but this doesn't seem to explain it. If the Duke somehow needs more rudder for a rate one turn, it doesn't explain why I get proper rate one turns out of it, using the RXP FLN TC. If I put the ball in the middle on that instrument, and fly to the rate-one marks on that gauge, I can do timed turns accurately. So the airplane is flying a rate-one turn (as verified by the heading and stopwatch) and the sim is reporting the turn correctly (because the RXP instrument reads correctly), the gauge (the TC in the VC) is just misreading. Just to clarify, I'm using a stopwatch - not the FSX clock.

Quite so. As far as I'm aware, you can't. I haven't tried, I use them in 2D panels.

I'd never noticed this before, since I use external 2D gauges with the duke (Reality XP Flightline N and T) which I'd highly recommend (even though I am annoyed at RXP for not responding to requests for a Prepar3D version of them, and their GNS units). Not only do you get a TC that works correctly (although you still have to hold rudder through the turn to keep the ball in the middle and achieve an actual rate one turn, but that's just FSX), you also get an ADF that dips (and jumps around realistically), DI/HSI that drifts or is coupled according to airplane fit and various other excellent instruments, and you can click them to put a rubber suction-cup cover over them to practise partial-panel work. As you said, the TC in the duke VC doesn't work properly. I just timed some turns, holding rate one using the reality XP TC, and for a standard 2-minute turn, the reality XP TC was correctly indicating rate one while on the duke VC instrument, I had the needle well past the rate-one markings, pointing approximately at the middle of the "R" and "L" letters beneath the rate lines. Although you can't interpolate or extrapolate on a real TC, you can of course just memorise these positions to make proper rate one turns in the duke using the VC version of the TC. I'd still highly recommend the flightline gauges, which are not only realistic, but very nice to look at, and easy to read. If you decide to purchase them and would like my RXP ini-files (which configure the gauges for the duke, putting stuff like ASI white arcs, blue-line etc. in the right places) let me know and I'll send them to you, I also have a set of panels with different AI presentations (generic, KI256) and different nav fits (either HSI and RMI for the duke, or a stone-age DI and ADF for more basic aircraft), which I can send you, although you may have to do some editing on them because some of the gauges are not RXP (they are from other payware) so if you didn't have the acft they came from you'd have to find an alternative.

Despite what some people have said, I do have some success using SLI with FSX. Perhaps because I'm at quite a large resolution (triple 1920x1080 surround) so the usual CPU bound argument applies a little less, because there's a lot more work for the GPUs to do than there would be at 1080p. I see you are using a catleap, so at your resolution you might see an improvement by trying another 580, and I think you wouldn't be risking a lot, since if you picked up a second hand one and were not happy with the performance, you could resell it for close to what you paid. Are you planning surround or eyefinity at any point? If so, it may be worth looking at AMD instead, as eyefinity generally looks a lot more flexible and capable than surround, and people seem to say performance is better at surround resolutions.

Believe it or not, I screwed the damn things to my desk! I did try velcro, which would probably be fine for a single panel, but as you said when they are stacked the leverage applied at the bottom is quite strong, in fact, despite having wood screws through the bottom panel's surround, they have still worked a tiny bit loose and have a little bit of wobble due to the leverage working the screws against the wood.

The captains PFD is "Zoomed Left Outboard DU", and captains ND is "Zoomed Left Inboard DU". It looks like there is only one gauge (PMDG_737NGX!DU) which an argument (LEFT_OUTBD or LEFT_INBD) is passed to in the panel.cfg So I added to [Window Titles] window25=Extra Left Outboard DU window26=Extra Left Inboard DU Then further down, at the bottom of panel.cfg, I appended: // // Extra Left Outboard DU // [Window25] BACKGROUND_COLOR=30,30,30 size_mm=555, 555 window_size = 0.28906, 0.46250 position=3 visible=0 ident=10000 zorder=95 gauge00=PMDG_737NGX!DU, -57, -48, 677, 636, 1 LEFT_OUTBD #11 ZOOM // // Extra Left Inboard DU // [Window26] BACKGROUND_COLOR=30,30,30 size_mm=555, 555 window_size = 0.28906, 0.46250 position=4 visible=0 ident=10001 zorder=95 gauge00=PMDG_737NGX!DU, -57, -48, 677, 636, 1 LEFT_INBD #12 ZOOM Of course the next unused window numbers may not be 25 and 26 for you (I have other stuff that's added windows like voxatc and the AS2012 Xgauge), and they do have to be contiguous with the the existing window numbers if I remember rightly, otherwise they don't show up.