Pete Dowson

I suspect that's pretty realistic. In severely turbulent conditions I'm pretty sure the pilot has to take control -- or if it looks like continuing long, seeking avoidance by climbing or descending (with permission, of course). Yes, okay, but I may just have fixed it in 4.233, so please give that a whirl for a while first -- with all suppressions off please, and preferably avoiding "Severe" weather for now! ;-) Regards Pete

Odd, it's always worked in FS2004 and before. I'll try here with the latest ... ... It is certainly okay with 3.783, from the Other Downloads announcement above. One thing I just noticed though. If you read it first it contains 0. In other words it isn't a STATUS indicator, that's 31F0. If your software only sends something if it is different to what you are reading (for instance like pmSystems) then you'll need to write 3 first, then 0. But writing 0 does work, even when it is 0. I might fix it so it reflects the status too, though that shouldn't be necessary. Regards Pete

On the basis of some feedback regarding turbulence, especially in clouds, I've made some changes to the way the turbulence is handled. Please see if version 4.233, now available in the FSX Downloads announcement, is better. Regards Pete

As an experiment, I've made some changes to the way the turbulence is handled. Please see if version 4.233, now available in the FSX Downloads announcement, is better. Regards Pete

I've done some experiments and made some changes to the way the turbulence is handled. Please see if version 4.233, now available in the FSX Downloads announcement, is better. Regards Pete

I've made some changes to the way the turbulence is handled. Please see if version 4.233, now available in the FSX Downloads announcement, is better. Regards Pete

You need to tell me the version of FS, and also of FSUIPC. Then I can investigate. Such information is always needed. There is a lot of difference, version to version. Assuming you mean FSX, then I notice from the Offset Status documentation that so far no one has confirmed whether or not this offset is working. If you do really mean FSX, then I can at least mark down that values 1, 2 and 3 work, your report being the first for this offset. I'll just try 0 now ... ... It works okay here. That's with FSUIPC 4.232 (the latest from the FSX Downloads Announcement above), and FSX + SP1 + SP2. I can't really do much more for you until you give me more information, please. Regards Pete

The program originally supplied within the FSUIPC ZIP package which allows you to view all the weather data at the aircraft, or at any weather station or LAT/LON. By default it shows weather at aircraft position. It is also able to manipulate weather at weather stations, but that is not relevant here. For FSX it has been packaged separately and has been available, along with WeatherSet (the global weather manipulator, mainly for FS2002 and before) in the FSX Downloads Announcement above -- for 18 months now. If you scroll down past the (rather long) FSUIPC4 update details you'll find it, and a lot of other stuff you may not have known existed. ;-) Yes, but they suppress the stuff that FSUIPC has control over. The ACTUAL weather details, if you read them, might show that FSX was doing stuff beyond FSUIPC's (current) control. That's the point of this testing -- to find out. Unfortunately without correlating what you see with what FSX tells us it is doing (i.e. the weather reports as viewable in WeatherSet2), we are none the wiser. Where else did you see that the "IAS was changing" if not shown by FSX? Do you have another monitor for this? I don't know whether FSX's gust simulation is made to reflect in the wind vector/Shift+Z values -- those are certainly affected by anything FSUIPC does. But in previous versions of FS, none of gusting, turbulence or variance affected wind indicators, because really, in a real aircraft, these do not show the ACTUAL wind (how can they?) but the computed wind calculated from the observed tracking error using one or more of GPS, IRS or VOR triangulation position following. That takes time and is not subject to "twitching". The fact that FSUIPC's method of inducing oscillations for these effects also twitches the wind indicator is unfortunate. I cannot avoid that I'm afraid. But FS itself can avoid such things, of course. Gusts are taken to be only wind speed changes, "Variance" is the term here used to mean directional variability. Often I would expect them to go hand in hand, but they are simulated separately even when they occur together. Regards Pete

Other reports seem to indicate that the only option causing a problem is CLOUD turbulence, so you could try allowing all the other stuff except that. If this turns out to be correct (and I don't understand it at present), then maybe I should change the defaults, allowing Variance but suppressing cloud turbulence only. I'd like to get to the bottom of it though. I'll be doing some experiments on this, probably Monday now. Regards Pete

Where were you observing that the wind was 'steady'? Did WeatherSet2 show any wind turbulence, variance or gusts? With that sort of variation I would expect it to mention gust speeds of up to 20knots over the base wind speed. Gusts are more likely to be widely spaced, like 2 secs -- turbulence is very quick, frame-by-frame or faster, and less drastic. And gusting is more likely in the lower (usually surface) wind layers. I'd need to know the wind layer details -- gust, turbulence, variance -- before agreeing or disagreeing with that. The two need to be compared, each time there's anything out of the ordinary. Gusts will change the IAS reading noticeably. Regards Pete

That is really weird, because there's only one piece of code in FSUIPC doing turbulence, and both the cloud and wind settings use it. Maybe FSX itself is doing something different with cloud turbulence which interacts badly with what FSUIPC is doing, and it doesn't do the same for wind turbulence. I am mightily puzzled! Pete

FSUIPC emulates turbulence identically no matter whether it is from clouds or wind inputs. There's no difference, it's the exact same piece of code. With turbulence suppressed the variance suppression is doing nothing unless the winds are variable (i.e. non-zero variance in WeatherSet2), set in METARs by nnnVnnn or just "VRBL" for light variable winds. So, basically, what you've found is that the PMDG autopilot somehow reacts badly to even small flickering of the windspeed (even without direction changes). Weird. PMDG said they'd come back to me about this. I hope it can be explained. With turbulence level 2 (moderate) you'd get wind speed variations randomly about the current setting (or smoothing changing setting) of +/-2 knots, with the new default TurbulenceRate of 1.0. It is very hard to understand why such changes can affect the A/P so badly. You haven't got the random features enabled in FSUIPC I take it? And didn't the A/P go wrong then too? For a level 3 turbulence the wind speed would be changing +/- 3 knots, that's up to 6knot changes in all, That should have been worse than the ones you got in cloud. Regards Pete

You didn't need to do that. Just delete or rename your FSUIPC.INI file. That's where all yuor assignments and calibrations are saved. If FSUIPC is doing anything it is only because you, or another program, is asking it to. First try removing the INI file before loading FS9. If that fixes it then it is obviously something you've set there. If it doesn't then we'll need to look for other programs or gauges or DLLs using FSUIPC. In that case you have evidently not tried to calibrate it at all! There are very simple step-by-step instructions provided in the user guide. Please follow those. Pete

You are in the wrong forum. The links in all my software and documentation, and even on the main download site at http://www.schiratti.com, point to "Pete Dowson's FS Modules" forum, not very far from here. Please use that next time. Meanwhile, since I'm here, there are two ways to sort this out. The official way is by raising a "problem ticket" with SimMarket, explaining the problem. That's usually quite quick. The other way is to send me both the FSUIPC and the WideFS registration receipts/details and tell me exactly which you want updated. ZIP them and send to petedowson@btconnect.com. It being Saturday evening I'm clocking off till late tomorrow morning, so you won't get an immediate reply I'm afraid. Regards Pete

4.232 is available now. Please change to that. The "variance" is now suppressed by default, separately from the other wind effects. I need to find out what component of all this is (sometimes?) upsetting the PMDG 747X autopilot's lateral control -- is it wind smoothing itself, with the effects being irrelevant, or is it wind variance, or turbulence, or is it completely indeterminate (as it would appear to be from the results so far reported here). Once I know what is causing it (and I am asking PMDG to help here too) I might be able to allow for it somehow, but the way things appear to be at present, with it being unpredictable, I would have to document a warning to all PMDG users to avoid the facility altogether. And of course I'd rather not do that. Oh, you can play more easily now with pressure and temperature smoothing (on the Miscellaneous page). And the turbulence amplitude is adjustable by an INI parameter (but not in FSX whilst flying). I've turned it down by default to half what it was -- down to its value in 4.217. Looking forward to some really insightful analytical feedback, if you can manage it! Thanks & Regards Pete

Okay, 4.232 is available now. Please change to that. The "variance" is now suppressed by default, separately from the other wind effects. I need to find out what component of all this is upsetting the PMDG 747X autopilot's lateral control -- is it wind smoothing itself, with the effects being irrelevant, or is it wind variance, or turbulence, or is it completely indeterminate (as it would appear to be from the results so far reported here)? Once I know what is causing it (and I am asking PMDG to help here too) I might be able to allow for it somehow, but the way things appear to be at present, with it being unpredictable, I would have to document a warning to all PMDG users to avoid the facility altogether. And of course I'd rather not do that. Oh, you can play more easily now with pressure and temperature smoothing (on the Miscellaneous page). And the turbulence amplitude is adjustable by an INI parameter (but not in FSX whilst flying). I've turned it down by default to half what it was -- down to its value in 4.217. Looking forward to some really insightful analytical feedback, if you can manage it! Not pictures, please, I prefer words unless there really is no way to describe something. Thanks & Regards Pete

In the next update (4.232), probably later today, I have separated the directional variability from the turbulence, with its own suppression option defaulted ON. I'm anxious to learn if it is the +/-2-8 degree fluctuations in wind direction which are upsetting the 747X, or just the frequent small changes in turbulent conditions all round. I'd like to discuss this with PMDG when we have some conclusions. So, perhaps more tests with the 747X but with cloud and wind turbulence allowed, variance suppression left defaulted, will show us more. I've also raised both the QNH and OAT smoothing to more prominence, fitting them onto the "Miscellaneous" page. Not enough about these for a page to themselves! ;-) Later Pete

Yes. "Toggle" actions are less predictable, as the result depends on what went on before, so if you restart a flight or something the switch is then reversed. This is a problem with many of the FS controls which often don't have "on"/"off" counterparts, just "toggle". As a better example in FS, consider the Gear switch. In FS you use "G" which operates GEAR TOGGLE. It goes UP if DOWN and vice versa. If you only have a momentary button, that's what you use because you have no choice. But if you have a latching switch (i.e. a toggle switch as on the T8), you'd use the Gear Down and Gear Up controls instead. Such a choice isn't always there -- though in many cases you use use FSUIPC offsets instead. This principle applies to switches controlled by bits or values in FSUIPC Offsets just as it does to FS controls. Anyway, glad you got it all sussed! Regards Pete

Can you please double-check the name of the control you've assigned. There isn't one by that exact name, and there are several it could be. It the button does something when released you must have programmed the release action as well as the press action. No. Keys and buttons are separate things. They only do things when touched in any case. It's called the User Guide, and I'm afraid it's about as idiotic I can provide. If you need to check what is going on, please look at the Logging options in FSUIPC. On the left hand side enable Button and Event (non-axis) logging. Then operate your button and check the FSUIPC Log file (in the FS Modules folder) to see what happened. If you don't understand it, show it here. It's only a text file and you can cut and paste. Regards Pete

Okay. It was a bad SimConnect install problem, so you did the right thing. Thanks for letting us know. Regards pete

This is really a question for the Squawkbox folks. Those offsets are not known or understood by FSUIPC itself, but allocated to Squawkbox for their use as they wish. There is. Use the FSUIPC Logging facilities, or easier still Monitor the offsets on the FS screen in real time, to see them change. The monitor is on the right-hand side in the FSUIPC Logging page. Only if you've programmed it that way. If you take a look at the button assignments screen (or the picture of it in the manual) you will see that there's a place where you can specify what you want to happen when a button is "pressed" and another for when it is "released". As it carefully explains in the manual, for a toggle, switching from "off" to "on" is the same as a "press", and from "on" to "off" is a release. If you think about it a little you will see this is pretty obvious and makes sense. No, that just is not true. It will act on either change, depending on how you programmed it. The Buttons page, where you program it, only operates on the "Press" or "off to on", otherwise it would flip a bit with momentary buttons -- that is why there's a place to program both press and release at the same time. The manual goes into button programming in a lot of detail. I cannot program things I don't know about, like Squawkbox. If you want to show me what you've done and what you are trying to do I can possibly tell you where you've gone wrong, but as I said at the start, your correct port of call is Squawkbox support as they know their software. Regards Pete

Okay. Maybe my turbulence emulation needs toning down a little. ;-) Was this when cruising at one level, not climbing/descending? I can't control TAT, but you could see if enabling the OAT smoothing helps. The trouble is that it is more difficult to do and still allow the right amount of change for altitude . I'll think about it. But also, none of the reports (till I mentioned it) said anything about OAT problems. Pressure jumps were much more of a problem with someone reporting altimeter readings jumpinh by as much as 1000' sometimes! The more testing goes on the more confused I am getting, I must admit. Regards Pete

Yes, sounds like something got screwed up in translation. Probably a couupted weather report on the website itself. Okay. Meanwhile i think I'll add the option to suppress directional variance separately in any case, and default it on (i.e. suppressed). I'll also put the QNH smoothing into the on-line interface as I don't think it does any harm, even if it does no good. But I think I'll leave the temperature one out (of the on-line options, that is). I know you had something odd going on with that, but I suspect sudden changes in OAT are indeed possible and even normal when traversing loud layers and so on, and I've also got to allow them to change as fast as you are ascending or descending, so the whole area is peppered with problems. Regards Pete

Why would it do that? Sorry, I'm misunderstanding something here. For one hour you had no wind reported, then you had 356/0? That's no wind too!? Is it Simconnect receiving your wind data? Are you using an external weather source? Simconnect isn't involved in FSX's own weather downloads. I cannot see what you are doing from here. But certainly it is possible to have long periods without any wind. I'm not really in the business of supplying weather nor examining what others supply, so really you will have to check that yourself -- look at your sources. I'm only interested in what FSUIPC does with it when you've got it. 0 knots isn't a wind, so the direction is probably either 360 True (same as 000/00) or anything at all. If FSUIPC or FSX is trying to vary it, the triangles get vanishingly small and the sines and cosines go daft. FSUIPC has got no smoothing to do if the wind remains at zero knots, and it can't even provide artificial turbulence, so really there is not a lot of point reporting it. You will need to examine the source of your weather. Odd that there's been two successive reports here, one with crazy weather and enormous shifts and one with nothing. It sounds like you both used the same source for weather and that source has been going rather wild recently! Regards Pete

Gusts are only wind speed changes. It sounds like the PMDG aircraft doesn't like the frequest smaller changes caused by turbulence. I know, that's why I asked you to try it with the turbulence and gusts disabled! It is no use have only one side of the equation. Please remember that there's a turbulence for clouds as well. No no. Please change to 4.231. There were other problems in 4.224. I don't know what those are then. Sorry. [LATER] Good grief? Where are you getting your weather from? What with that and all the other odd things you mention it sounds like the data was rather, erscrambled! Regards Pete