Boris_The_Spider

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.

Ok, that was a quick answering of my own question! For anyone interested, yes, it works fine. Just create duplicate entries in the panel.cfg, obviously giving them different numbers, and change the idents (I used 10000 and 10001, valid entries for miscellaneous panels are from 10000 to 19999). You can then open them from the views->instruments menu and the VC copies remain docked.

Does anyone here know how to undock a panel, and leave it docked as well? What I want, is to have the PFD and ND of the NGX in the virtual cockpit on my main big monitors, but also have them duplicated on a second monitor, so that I can see the displays within the VC on the big monitors when I'm in pilots-eye view, but when I'm hand flying and have changed the VC view, for example to do something on the overhead, I want them on the second monitor to glance at. I am guessing I can duplicate the entries in panel.cfg, giving them a different ident, so that when I open them from the menu the main panel stays docked, but I'm not 100% sure as I've never tried before. I'll go and experiment anyway, but if anyone can confirm (or deny) my idea that would be helpful.

Picture, if you will, a polar stereographic projection of the polar region (the projection you'd get if you stuck a light bulb at the centre of a hollow, semi-transparent globe, and projected onto a flat sheet of paper that touched the earth at the pole, and was perpendicular to the surface at that point). So the meridians are straight lines, fanning out in a circular way from the middle of the page (the pole), and the parallels of latitude are concentric circles. Now great circles are, to a close approximation, straight lines on a polar stereographic, so you draw your intended great-circle track on the chart, and unless you happen to be heading due north or due south, you're going to find your true direction is going to change a lot as you continue along the line. That's convergence, and it's a big problem near the poles where it's very large, becoming smaller and smaller as you move towards the equator. So align your DI to North, fly a little way (you're near the pole, so you'll soon cover a good few degrees of longitude) and all of a sudden, your DI no longer points North - it continues pointing to the space direction that you aligned it to, but Earth North has shifted beneath you. That's not even all though, since the magnetic variation would also be changing a lot near the poles, so all in all you'd be lost pretty rapidly. Nowadays, you'd use GPS or INS. Convergence wouldn't be a problem, and nor would magnetic variation. In days of yore, for polar flying, a "gyro north" was arbitrarily chosen, and a grid of straight lines was overlaid over the chart. Say gyro north was chosen to be equal to true north at 20E. You could then fly a grid heading which would not change along your straight line drawn on the chart. Along the 20E meridian in our example, grid track and true track would be the same - everywhere else, the two would differ. You'd use various voodoo to convert back and forth from grid to true, so as to relate your grid position to your true position, since the grid position/track/heading is, as I said, arbitrary and means nothing to anyone else such as ATC. It's just a practical way to actually accomplish the navigation in the air, since it eliminates using a reference (True North) which is changing rapidly. Instead, a reference that doesn't change has been arbitrarily chosen. Now if you can find me a commercial pilot (or at least one who doesn't actively fly in polar regions) who can remember what grivation (or indeed an isogriv) is without looking it up, I'll eat my hat.

Well I'm presuming the textures are pretty big - they take quite a while to install even locally on a very fast machine with SSDs. From a slow laptop, over a wifi LAN at probably a couple of meg per second, I can imagine it taking a very long time.

Hi Mad Dog, Thanks for the reply. I suppose I could use REXE for textures instead (I generally do) but I would like to keep the option to use AS2012 textures and I can't install textures over the network (the laptop is on wifi and I want to keep it that way), so that would be an issue. I'd also really like to keep the option to run AS2012 on the desktop PC, if the laptop is inop or just not in use that session for some reason. I guess I might need two licenses in that case, it's a shame there's no provision for it in the licensing, unless I'm misunderstanding it. Thanks anyway - I will certainly take a look at the documentation in any case.

Hi, I have AS2012 SP2 on my P3D box, and would like to try a network install (on my laptop) as well to see if I get any improvement in fps on the sim. I read a post where it was said you needed to have only one AS2012 online at a time, because of licensing. So it occurs to me that xgauge probably won't work, and nor will 122.0/122.02, because I'd need AS2012 to be running both on the P3D box (to provide 122.0 and possibly for the xgauge), and also on the laptop (for weather injection) So to do what I'm thinking about, I'd need two licenses, and even then, I'd still need to be running as2012 on the desktop machine and hence probably wouldn't really benefit in terms of taking some load off that machine. Have I got this right? Thanks

OK I'm a little confused. What is the advantage of this configuration? I already have a "Boeing 737-800 PMDG Mixed Class.txt" file in my configurations folder for TOPCAT. Is that for the older FS9 type 737??? I don't get it, because my configuration folder also contains files relating to an iFly 737, and I thought that was a recent aircraft, so I am presuming that perhaps these files are downloaded and updated by TOPCAT??? I thought the TOPCAT figures were based on real aircraft, so I'm guessing the only reason there are different files in the topcat configuration folder (like separate files for PMDG vs iFly) is to account for differences in which particular individual 737 has been modelled - like there will be differences in weight due to the equipment fit. Is this correct?

Likely to be the PSU I'd say, is it a decent make? I don't know the power requirements for your CPU and GPU, but I'd imagine a quality 450w supply would be enough, but a poor, no-brand one won't. If you do need to replace it and don't want to spend more than necessary, something like an Antec Basiq would be a good choice. Enermax also make good PSUs. Even if you think you're under 450w, I'd probably err on the side of getting a 550w just for some headroom. I do agree with the other posters that it could be the CPU overheating also. If so, and you need a good cheap heatsink, the CoolerMaster Hyper 212 Evo is very cheap for excellent performance.

Hi Word Not Allowed, I got a G13 recently and I'm considering trying to use it for something in FSX, only thing I will say is the thing is really designed for left-handed use (and is obviously intended as such, and is great for games or applications when the right hand is on the mouse). In the sim, I think I'd find myself needing a third hand to use it for EZCA views when hand-flying!!! I'm sure I'll come up with a way to put it to good use though.

Anyone else that's experiencing this issue - please can you post in the thread at the official P3D forum so we can get this resolved. Link below. http://www.prepar3d.com/forum-5/?mingleforumaction=viewtopic&t=1788#postid-9243

Yeah, definitely not a driver issue - reinstall tried already. The depth in the nvidia control panel does the same thing as the depth wheel on the emitter, so it's not that either. It was fine with FSX. Charlie Chew - are you running surround, or just 3D on one monitor?