jase439

Hi Pete, I was just noticing that when I have profile-specific settings applied to a specific aircraft for axes and/or joystick calibration, the "profile-specific" option is automatically enabled for me when I revisit those tabs. Any subsequent changes I make are automatically made to the aircraft profile bound to the aircraft I'm currently flying. This is great. However, the Button+Switches tab does not behave this way. It always defaults to the global settings, even when I have previously created profile-specific buttons and switches for said aircraft. I must remember to tick "profile specific" every time I enter this tab or I inadvertantly end up changing my global button/switch bindings. Is there a reason this tab doesn't behave like the others and default to the profile-specific settings? Not a huge deal, but this asymmetry in the behavior of the user-interface I find to be a little counter-intuitive. As always, thanks for your great work. J

Any chance this option might be exposed through an option (or perhaps made "profile-specific")? I realize you are probably loathe to expose an "Enable the Bug" feature in your user interface, but having to restart the simulator and toggle this value manually via ini file is a bit of a pain. Perhaps such an option could be given an umm, graceful name such as "Use legacy throttle mappings" on joystick calibration page 3 or some such thing.

Pete, Thank you for the tip! I just needed to add "registry fix" to my search and I dropped right in on the solution. I applied the registry "tweak" and it worked like a champ. Also got rid of alot of spurious noise I was getting in the neutral positions on the yoke! Should anyone else experience this issue, you can find the answer here: http://www.saitekforum.com/showthread.php?p=89502 Cheers, Jason

Hello! I am in the process of setting up a new system. I am using FSUIPC 4.7.5.6 with FSX SP2 under Windows 7 x64. I have the Saitek ProFlight Yoke, Rudder Pedals, and a secondary Throttle Quadrant.I have the latest drivers from Saitek installed. The specific issue I'm having is with the primary throttle quadrant that is connected to the yoke via the PS/2 connector. The axes on this unit behave as expected in the Saitek calibration applet. That is, moving any of the levers results in a smooth gradual increase from min to max and visa-versa. Under FSX, however, these axes only report one of two *input* signals (-16384 or +16383). The transition edge occurs at the 50% point. Instead of a rising/falling slope on the input signal, it appears I am receiving only a step transition...signal high or low, like a switch. As an additional data point, my secondary throttle quadrant (connected over USB) behaves as expected with each level producing a smooth input signal. Third party add-ons include: Active Sky 2012, FEX, GEX USA/Canada, UTX USA/Canada, FSG NA Terrain and Landclass, Ultimate Traffic 2, and PMDG 737-6/7/8/900 NGX SP1b, and...of course...FSUIPC 4.7.5.6 :) I don't *think* this is an issue with FSUIPC as I have been able to observe this phenomenon in the sim with or without the FSUIPC.DLL in the Modules folder. However, the people here appear to be the most knowledgeable about such controller quirks. I'm hoping someone here can help or offer me something new to try, Attached, is my FSUIPC log with Debug=Please and LogExtras=x401 in case that reveals clues. Thanks in advance for any help! Cheers, Jason FSUIPC4.log.txt FSUIPC4.ini.txt

Ah, this is quite likely what's happening. I'll try again later with this option disabled. EDIT: Well, despite the fact that I am still unable to produce that debug log output (even with the revised settings), I can say that 4.294 does indeed appear to be "kinder" to PMDG. Where before, turbulence would result in oscillating rolls of increasingly greater magnitude (which ultimately results in a burn mark on the countryside), I am now observing the same +/- 20 degree deviations that you noted. Disabling turbulence immediately quells the problem. BTW, below is a snippet from my log: Module base=61000000 Wind smoothing fix is fully installed DebugStatus=15 140 System time = 01:29:25 140 FLT UNC path = REDACTED 140 FS UNC path = REDACTED 797 LogOptions=00001001 797 LogExtras=256 See anything here that would explain why I'm not getting any wind data written to the log?

Thanks for the follow up, Pete. I'm glad you were able to recreate the phenomenon (at least to a limited degree). The magnitude of the A/P deviations could be a function of many things, including wind speed, rate of change, fuel and balance, or frame rates (in the case of 4.285 at least - hopefully fixed in 4.294). Moreover, the observation that this behavior is unique to the PMDG 747 A/P and only PMDG is also consistent with my own. I have not seen anything that suggests FSUIPC is doing anything but what it should be doing. This does - at the surface - appear to be a bugaboo in PMDG's control logic that is elicited by FSUIPC's turbulence modelling. I hope PMDG is following this thread, but for the time being, I'm content to use FS2K4-style behavior. J PS. The violent flickering was indeed caused by the FSUIPC variable display. BTW, I'm still having trouble getting FSUIPC to forcibly "generate turbulence" using only FSX weather. I've been setting a moderate turbulence layer (in both wind and cloud) and nothing happens. The turbulence effect only seems to kick in if I use an external weather program like ASX or FSMeteo in tandem with "generate random turbulence". I don't know if it's because I'm loading a saved situation file (whose WX environment was originally created by ASX) or if I'm just setting the turbulence at the wrong station (should I be setting "per-station" weather or global weather?).

Is there supposed to be a space between Add and Debug? EDIT: Well, my world has gone from bad to worse. I am unable to get any kind of turbulence generation at all (is there any way to set the odds to 100%?) Even with situations that were saved with turbulence, I get nothing. My frame rates are in the basement. I'm not getting any of the logging you described (but maybe that's because there is no turbulence). And my panel is flickering violently. Gone back to 4.285 for now. Incidentally, I'm thinking about switching back to my old tried-n-true FSMeteo. It still uses FSUIPC's NWI for programming weather parameters, right? I feel like FSUIPC and ASX are constantly fighting for control of the weather. Moreover, what I see in the ASX UI for the active METAR and ALOFT data doesn't correlate to what's happening in the sim (often, there appears to be no relationship between the two whatsoever). ASX has a much sexier UI, but I don't feel like I'm in control of my weather environment - not to the same degree as I did with FSMeteo/FSUIPC. I just purchased the upgrade to FSMeteo v8.0 and hoping it still uses the same tried-n-true FSUIPC wx interfaces as v6 and v7.

Sure thing. I'll give this a go and report back with my findings. EDIT: I have the new build (I guessed the URL :^), but I don't know how to enable the logging you're showing in your previous post. Let me know and I'll give it a look.

Here's the latest update info (that I know of): http://forums.avsim.net/dcboard.php?az=9454&page= For you, I imagine they would probably just point you to a brand new installer if you ask.

It could be related to a recent update. I am running with their latest (2.10 build 40 or something). BTW, I should qualify my earlier - and unfair and overly broad - characterisation of the 47's "poor control logic". In all other respects, the aircraft is behaving admirably and is a fine product. I merely "suggest" it may be a flaw in the 47's control logic that is elicited or exacerbated by the new turbulence effect as other aircraft are seemingly unperturbed by it. But to qualify it as "poor" was unfair (and equally inaccurate). Also, to your earlier question. While I have been testing this problem in the context of cloud turbulence, I don't think it's restricted to cloud-triggered turbulence. This problem first surfaced for me in seemingly clear skies (unless I was passing through some unseen ultra-sparse cloud layer). I suspect people are simply encountering random cloud-generated turbulence "more often" than its wind-triggered counterpart, hence the perception that it's only cloud turbulence. Regards, J

I repeated my earlier tests with 4.287 and as you surmised, the results were not any different than 4.285. I then decided to fool with the turbulence parameters. To help rule out some variables I: 1. Left ASX running but disabled all wind and cloud turbulence as well as wind shear functions; only random turbulence in wind and clouds were enabled in FSUIPC. 2. I suppressed wind variance via FSUIPC so the only "perceivable" effect of turbulence was jitter in wind speed. With the default turbulence settings (TurbulenceRate/TurbulenceDivisor), the aircraft was uncontrollable. I find this curious because my earlier suspision was the shift in wind direction was throwing the 47's control system out of whack. However, wind direction was steady here, and only wind speed varied (+/- 3 knots or so) and the aircraft went bananas. Indeed, suppressing turbulence via FSUIPC immediately corrected the problem. Unsuppressing it, the aircraft began its slalom maneuvers. Adjusting TurbulenceRate only affected the magnitude of the wind shift. Not surprisingly this is what the documentation says it does :) Dialing it down, didn't appear to have much impact - it just took a little longer for the plane to begin rocking uncontrollably. Dialing this value up just made the aircraft roll over on its head that much sooner. Adjusting TurbulenceDivisor had no perceptable impact on this problem that I could tell. I tried adjusting the first two divisors from 20,20 to 30, 40, 60, and 100. I couldn't tell you 100 was any better or worse than 20 with respect to this issue. Well, given - for example - a 5 knot shift in wind speed, that transition happens in about 1/2 second to a second. My frame rate was around 20 in this example. Your document says the update rate is about 5-10Hz, and I would say it seems to be about that. I guess it's rapid compared to my 1kt(degree)/second wind smoothing. It might be helpful - from a diagnostic standpoint - if there was a config parameter to override the frame-rate-based logic and specify an explicit update frequency. I dunno. It's a tough call. Personally, it "seems" like a fundamental problem with the lateral navigation control logic in PMDG. It tries to overcorrect as if it's making it's corrections based on the immediate values of wind direction and speed. I would expect a system like this to employ some kind of hysteresis to absorb or filter the "noise" . I know the Level-D 767 has something like this and it is entirely unperturbed by turbulence and wind shear. Based on the observation, I don't think FSUIPC is "causing" this any more than ASX is causing this. I think it's just poor (or bugged) control logic in the aircraft - but again, I can only speculate (maybe FSUIPC is tainting some simulator variable in some way that the PMDG controller depends on)...who can say? It does strike me as odd to me that even 1kt turbulent shifts in wind speed (speed not direction, mind you) alone can cause the 747 to start rocking violently (but only turbulence seems to induce this behavior - the aircraft handles normal wind shifts - moving from one wx station to the next - just fine). Initially - in turbulent winds - the degree of banking may only be +/- 5 degrees, but it quickly escalates to +/- 15, and once you're beyond this event horizon you're about 60 seconds away from rolling the aircraft upside down and becoming bug squat on the countryside :) I'm open to ideas, but I'm stumped as to where to go from here (beyond disabling turbulence entirely).

Yes. Running 4.285, but will grab 4.287 and give that a go (although, it's worth pointing out I was able to recreate the problem without ASX running). Sorry, if I was unclear. I was not comparing wind vs cloud turbulence but the effect of FSX vs FSUIPC turbulence. I was seeing deltas of apx. +/- 2 kts in wind speed, but it was changing rapidly (in comparison to FSX's own turbulence modelling). It didn't seem to me that the magnitude of the shift was as important as the frequency of the change. I would agree with that assessment. But it is curious to note that the 747's guidance systems appears to tolerate it better. In fact, when the wind did shift (as a result of turbulence in FSX), the magnitude of the shift was larger than that modelled by FSUIPC but much less frequent. Let me play with these (in addition to trying the 4.287 build) and see if I can't conjure up a better result. Thanks for the feedback. J

I found this thread after following a link in the PMDG forums. I too am having this problem with lateral navigation control in the presence of turbulence. I am running ASX SP3 and FSUIPC 4.28. I have observed that: 1. If I enable cloud turbulence in ASX and leave this option unchecked in FSUIPC, I get uncontrollable LNAV behavior 2. If I disable cloud turbulence in ASX but enable this option in FSUIPC, I get uncontrollable LNAV behavior 3. If I check "suppress cloud turbulence" in FSUIPC (regardless of settings in ASX), the aircraft recovers quickly and tracks the desired course 4. If I do not run ASX, but simply load a saved scenario with cloud turbulence enabled in FSUIPC, LNAV is equally uncontrollable 5. If I do not run ASX or FSUIPC but enable turbulence via the weather interface in FSX, LNAV behavior is fine Wind stablisation in ASX is off (cases 1-3). Wind smoothing in FSUIPC is enabled in cases 1-4. Key observation (I think). Both FSUIPC and ASX seem to model turbulence by introducing high frequency "jitter" in wind direction and speed. Even though the variance is small, the rate at which the sim vars are updated seems to be quite high. When I enable turbulence in FSX, this jitter also occurs but does so at a MUCH lower frequency. In fact, it seems to model turbulence differently than either ASX or FSUIPC. It seems to add artificial perturbations to the indicated airspeed (even though reported wind speed may be constant). It may be that the LNAV guidance in PMDG's 747 simply cannot tolerate the high-frequency "jitter" caused by the turbulence modelling in FSUIPC and ASX. Is there anyway to "throttle" this effect (as a test)?

I'm not flying the 747-400, but seeing the same behavior (violently gyrating wind directions/speeds) with ASX SP3 and Wind Stablization. I'm turning this feature off in favor of FSUIPC's wind smoothing. I'll report back how it goes.

Thanks, Pete. I posed this same question to the LDS dev team. It would appear that LDS hooks the save at a higher level (UI/keystroke handling) - and therefore their stubs are missed when AutoSave does its thing. They seem to be on top of this issue going forward, so we will keep our fingers crossed and hope! Cheers, J

Pete, This speciifcally relates to AutoSave and its behavior when running the LDS 767. I have a question about how AutoSave triggers a save in the simulator. I have noticed that the save files generated by AutoSave do not contain all of the state data that is generated by the LDS sim when you explicitly chosoe "File | Save Flight" from the menu. I don't know if that is an artifact of how LDS "hooks" the save, or if that is an artifact of how AutoSave "hooks" the save. In either event, only a partial save is generated when AutoSave generates a situation file w/ the LDS 767 active. When you subsequently load that situation file, its basically useless as almost all of the LDS specific data has been lost. The panel must be reconfigured from end to end. This is particularly unfortunate as the LDS 767 is one of the few complex aircraft panels that fully implements load/save. Is there something that either you or the LDS developers could do to bridge this gap so that you are all using the same "pathway" for saving? J

I recently noted the addition of a feature "Enable wind smoothing only while airborne" When this option is enabled, I am finding that when I load an existing situation in which the wx conditions were previously set by a third-party app using the AWI, FSUIPC no longer attempts to smooth my winds. If I disable this checkbox the smoothing seems to work as it did previously. Any ideas as to why this might be? J

Hmmm. Does taxi wind only kick in when the aircraft is in contact with the ground or is there a psuedo-taxi-wind-layer just above the surface that the aircraft passes through as it's landing? Jason

I have indeed. Wouldn't fly without it!

I have a feature request for a future version of FSUIPC. Would it be possible to add a ramp to the auto taxi wind feature? One situation I find myself in frequently, is when I'm landing in a stiff crosswind >= 15 kts and I'm applying alot of rudder action (especially during the flare and kickout - talking about the big iron here) to get the nose pointed down the centerline. As soon as the mains touch the ground, the taxi wind kicks in and my wind drops immediately from XX kts to 1. This results in an immediate somewhat abrupt over-correction due to applied rudder. I believe if the taxi wind effect could rapidly, but smoothly, ramp the wind speed down when activated, it would be easier to maintain control of the aircraft when the wheels hit the pavement. A similar thing on takeoff could also be worthwhile (although it's somewhat less of an issue under that condition). Thanks. Hope you enjoyed your break. J

Pete, You are truly 'da man. I knew you'd lick the wind problem sooner or later. It was bugging you way too much to let it go :). Rock solid. Perserverence at its finest. Thank you. J

To rule out any potential funny business involving third party aircraft, I decided to find a test case using a stock MS aircraft and a simple global weather setting consisting of a single cloud and temperature layer favorable for icing: Here are the parameters I used: I started with the default KSEA situation, using the Cessna 182S. I modified the default fair weather theme, and selected global weather, then using the advanced weather editor I changed the following: * Changed the lower cloud deck from cumulus to stratus. Changed the coverage to overcast. Set tops at 5000, bottoms at 1000. Icing to Severe (initially). * Changed the surface temperature to 5C and the dewpoint to 5C. * Visibility to 1 mile (just for giggles - should have no bearing on this, but mentioned here for completeness :) With each icing level I ran two tests. The first was with the pitot heat off. This was to verify that icing conditions, did in fact exist. I verified this by observing the airspeed indicator drop to zero shortly after passing 1000' and entering the cloud layer. In ALL cases, I was able to verify that valid icing conditions existed. In the second round of tests, I ENABLED pitot heat on the ground while motionless on the runway. I departed KSEA and allowed the aircraft to climb into the clouds. With SEVERE icing enabled and pitot-heat ENABLED, my airspeed indicator dropped to zero passing 1200' MSL. The gauge remained frozen for over a minute, at which time I began to cycle the pitot-heat off and on again using SHIFT+H. Within 10 seconds, my airspeed indicator returned and I had no further icing conditions. The same behavior was observed with MODERATE icing save the fact that it took a bit longer before the AS indicator froze. Again, cycling the pitot-heat using SHIFT+H after a minute or longer with the AS gauge frozen eventually brought the AS indicator back. LIGHT and TRACE icing DID NOT yield these results. They behaved as they did in FS2002. If the pitot-heat was enabled on the ground (or at anytime in flight), I did not observe any freezing of the AS indicator. If I turned it off while in the air, it froze up very shortly, and would "unfreeze" shortly after turning it on again - as one would expect. I repeated the SEVERE and MODERATE tests using the PMDG 737-600 SU1. I observed similar behavior as that observed in the Cessna 182 - although the freeze ups were somewhat intermittent and much less predictable. I did not observe any definitive benefit one way or another with engine or wing anti ice. These latter tests with TAI were inconclusive at best. The behavior of the pitot heat (or probe heat as it would be in the 737), however, was more or less the same. In all cases, LIGHT or TRACE icing caused no problems at all. As Mark states, while this might not be a bug per se, the way icing strength is modelled in FS9 is different and can render third party panels designed for FS2002 helpless in icing conditions. I certainly believe it would be helpful if apps like AS and FSMeteo could deal with this at their level - but the problem is still present even for those who would set their weather globally - so i believe an icing threshold is a good candidate for a future FSUIPC release. Hope this is helpful. Cheers, J

That would be with anti-icing enabled. Right. From what I have observed, I *think* ActiveSky 2004 will randomly add icing regardless of whether the user specified it in FSUIPC. It does not seem to care whether "random icing" is checked or unchecked. FSMeteo, on the other hand, doesn't explicitly introduce icing; if you enable it in FSUIPC you get it from time to time...otherwise you don't get it at all. I am new to AS2K4, so am not quite as familiar with it as FSMeteo. Good question. I don't know the answer to this. I have never seen it personally. The only times I've been able to get icing conditions is if I download my weather through a 3rd party app (like AS2K4 or FSMeteo) or I explicitly create the icing conditions by hand. Well, "trace" seems to work fine - all the time for me. From what I've read from others is that the problem is isolated to "severe" icing (which has led to the theory that the pitot-heat cannot cope with severe icing). Let me create some conditions and experiment with different aircraft and see if I can't pull together a more controlled test case for you. More to follow. Thanks, J

Hi Pete, There's a number of reports over at AVSIM - 'specially in the ActiveSky, PMDG, and PSS forums on this subject if you'd like to look into the problem further (see posts related to icing and IAS tapes dropping to zero). With the winter weather settling in up north, there are an increasing number of reports of people experiencing pitot-heat failure in FS9. So far, in each of these cases, it has been traced back to FSUIPC's random-icing or third party wx program. Unfortunately, there is no option in ActiveSky to control icing. The conditions, however, can be recreated manually by creating a cloud layer in FS with moderate to severe icing. I've seen this first hand myself where pitot-heat fails. By the accounts I have read (including my own encounter with this problem) - the problem is most reproducible when enabling pitot-heat on the ground followed subsequently by encountering icing conditions aloft. In some cases, flipping the pitot heat off and then on again (via with SHIFT+H) a few times will sometimes kick the sim out of its "frozen" state, but if you simply leave the pitot heat on, the icing problem persists and the ASI indicator reads zero. Some have eluded to the notion that FSUIPC is to blame, but a developer for PMDG says the problem is a known bug in FS9; and their recommended practice is to disable all icing in FSUIPC and third party wx programs. This seems like an unfortunate tradeoff. The ActiveSky folk might implement a workaround for this problem in a coming update (similar to what I describe), but it seems like such a feature would be generally useful to the FSUIPC customer since random icing is something that can be enabled with or without a third party wx program. Anyway - chances are you haven't heard of this because people rarely raise the issues in your forum. They just ***ch about them elsewhere :). Anyway, Damian Clark or Marc Philibert might have more insight to the underlying problem than I can offer here. I'm not sure what the "correct" fix is or where that fix is best applied. Seems like an FSUIPC'ish sort of thing, though. Some say the pitot heat isn't working at all. Others suggest it's "insufficient" to counter-act the icing effects. It could also have something to do with the state of the pitot heat variable getting silently reset to OFF unbeknownst to the user - so maybe the problem is in the pitot heat logic and not the icing. Not sure what the root cause of the problem is, but it's very reproducible for me by creating icing conditions, turning pitot-heat ON while on the ground, and then flying into the clouds. Anyway, that's my $0.02 :) Thanks, J

Pete, Would it be possible to have an option in FSUIPC which prevents icing levels from exceeding a certain threshold. Alot of people who would like to enable icing either through FSUIPC or thirt-party wx program and are unable to do so because of the FS9 bug which prevents the pitot heat from doing its job. Apparently this is a geneal problem for all icing levels except for "trace". It would be awesome if FSUIPC could provide a facility which effectively "capped" the threshold for icing. Is this doable? J