FSUIPC 4.236 - Wind smoothing feedback for you, Pete

[MELKOR]

Hey Pete, here is some feedback using 4.236 tonight.

Methodology

1) Winds page: Smooth wind changes near aircraft=on, with 1 deg/2 sec, Weather Interval=1, All three "supress"=on. Clouds Page: Supress all cloub turb=on

2) Used "Slew" mode to move up and down to make my observations (way faster then doing a "real-time" flight, and weather effects are still reported correctly).

3) Used WeatherSet2 to watch the wind layers in real-time.

4) Used a little C++ SimConnect tool I wrote to watch/log SimConnect weather variables in real-time (set at a 1hz sampling rate).

Observations

1) Via WeatherSet2, I can see that FSX is regularly making radical wind shifts in seemingly random wind layers (I presume this behavior is the root cause of our collective woe?).

2) If I sit steady at some particular wind layer, and the wind direction changes radically, the direction change seems to be properly smoothed.

3) If I descend through wind layers with a radical wind direction difference, the direction change seems to be properly smoothed.

4) If I ascend through wind layers with a radical wind direction difference, the direction will temporarily jump to radical values before settling down to a proper smoothing.

Conclusion

Smoothing is working quite well!! But, because of (4), it seems as if something is still not right...

Tomorrow, I am going to increase the sampling frequency of my real-time weather logging tool - I'm thinking that the radical shifts might really be there in (2) and (3), but are not showing up because of the low sample rate... if that turns out to be the case, perhaps increasing the rate at which your "overrides" are applied (controlled by the interval factor, right?) will fix this?

Thanks so much for your efforts here, Pete - you are close to nailing this!! :-)

- Bill

[Pete Dowson]

1) Via WeatherSet2, I can see that FSX is regularly making radical wind shifts in seemingly random wind layers (I presume this behavior is the root cause of our collective woe?).

Yes. FSX generates far too many "spurious" wind layers when it is updating the matrix of WX stations around the aircraft (part of the weather dynamics). These in turn make a mess of the interpolation it performs to derive the weather at the aircraft location.

As it performs these dynamic changes, the number of wind (and temperature) layers increases. In fact it can get so bad that the METAR strings it generates in its SimConnect reports can exceed the defined Maximum METAR string length (of 2048 bytes I think -- it's defined in the SimConnect header).

For some time now FSUIPC4 has tried to fight this by reading the surrounding WX station METARs, removing thin or duplicated wind and Temperature layers, and writing them back. But to avoid a noticeable performance it doesn't do this very often. It cycles through the 9 closest stations (in a 3 x 3 matrix) at the maximum rate of 1 per second (when the value bottom left on the Winds tab is set to 2 -- it would be 1 every 1/2 second if that was reduced to 1).

This keeps the number of layers in check, but doesn't prevent all those silly changes. Possibly it makes them a little worse, but I don't think so.

2) If I sit steady at some particular wind layer, and the wind direction changes radically, the direction change seems to be properly smoothed.

3) If I descend through wind layers with a radical wind direction difference, the direction change seems to be properly smoothed.

4) If I ascend through wind layers with a radical wind direction difference, the direction will temporarily jump to radical values before settling down to a proper smoothing.

That is mighty strange. FSUIPC4 doesn't check or care whether you are ascending or descending. I'll have to do similar tests myself -- I haven't tried doing anything directly like that as I thought the problems were related purely to changes being made from external sources, like ASX.

... perhaps increasing the rate at which your "overrides" are applied (controlled by the interval factor, right?) will fix this?

Unfortunately it isn't that simple. The overrides are made in two places in FSX's processing. One is when the Weather DLL is called by SIM1.DLL to provide the local weather. That's a straight-forward hook. That is when I learn the "target" value of the smoothing -- i.e. the value which I need to graduate towards. The same applies to the temperature and pressure (both ambient and sea level). This part I do in FSX RTM, SP1 and SP2.

The other is dirtier. I actually have to patch the WEATHER.DLL to perform what's known as a "blister" out to a little bit of my code which overwrites values just before it is about to use them. I only managed to find this in SP2's Weather DLL. The previous version is vastly different. Without this patch the smoothing, when operating to do its job, causes the ASI to "ratchet" (jump up and down) at a regular interval, about 1 sec normally. I suspect the same would happen to the QNH/Ambient pressure (causing the altimeter to "ratchet", and the temperature (causing blips in the engines), but I've not re-checked SP1 since adding those smoothing actions.

I have tried having a thread running overwriting these values every n mSecs (n various: tried 1, 5, 10, 20), not caring where in FSX's operations they were. That really didn't seem to help, and it gets very complicated trying to avoid crashes or corrupting other data. It is also then more complicated trying to discern the correct target values to be used.

You see, these values do not kindly sit in one place. They are in dynamically allocated structures belonging to a C++ class. They move about!

Regards

Pete

[Pete Dowson]

2) Used "Slew" mode to move up and down to make my observations (way faster then doing a "real-time" flight, and weather effects are still reported correctly).

I've been trying to make things go wrong doing this, but I can't seem to get the same results as you.

Tell me, what is your weather source when you do this? Are you manually setting up some nasty shifting layers?

perhaps increasing the rate at which your "overrides" are applied (controlled by the interval factor, right?) will fix this?

After thinking about that for a while, I've made two further changes to try to nail this:

1. I've resurrected my "wind smoothing thread", which I didn't think would be needed now that I am hooking into what I thought was the right place in WEATHER.DLL. This thread attempts to re-write the desired winds up to 200 times per second. I want to see if this stops these directional swings.

2. I am now automatically doubling the WX station METAR reads and corrective writes during times when the number of temperature or wind layers at the aircraft exceeds 15. I am hoping this will avoid a build up of such layers, many of which are spurious and unwanted.

The problem with both of these changes is that they may impact performance, and I really can't have that happen, at least not noticeably. The thread one may even be a little dangerous, although again I've taken steps to prevent it accessing stuff when it shouldn't. I can't make it crash at all here.

I am testing FSUIPC 4.237 right now and will upload it soon.

Thanks

Pete

[MELKOR]

2) Used "Slew" mode to move up and down to make my observations (way faster then doing a "real-time" flight, and weather effects are still reported correctly).

I've been trying to make things go wrong doing this, but I can't seem to get the same results as you.

Be sure that the layers you're moving through have radical wind direction differences. Also, I used keys mapped to "down quickly" and "up quickly" to slew through the layers.

Tell me, what is your weather source when you do this? Are you manually setting up some nasty shifting layers?

Just FSX's own "real weather with 15 minute updates", and the "download winds aloft" option turned on in the weather display settings. No manual changes. FSX seems to create nasty shifting layers, happily, all on its own. :-)

I am testing FSUIPC 4.237 right now and will upload it soon.

Will test this when I get home tonight, and post results (What I plan on doing: increase the frequency of my weather sampling, retest 4.236, test 4.237, and compare).

Thanks!

- Bill

[Richard McDonald Woods]

Hi Peter,

FSUIPC4.236 was initially ( first 2 hrs) a great improvement with Vista, PMDG 747-400X and ASX. The only problem was the jumping speed tape (up and down by up to 400 feet around every 3 or 4 minutes).

However, I then realised I had no wind vector on the ND, so I restarted ASX, but that made no difference. So I saved the situation and restarted ASX then FSX. Commanded speed was then M.841 but aircraft stuck at M.783. Still no wind vector. But now I can't engage LNAV - just get the FMS message NOT ON INTERCEPT HEADING. Then the aircraft gradually veered to the left without my being able to correct it. Eventually got stick shaker so I ended the flight.

I know that not all of my symptom may be the target of your most valuable work, but I shall not fly again for a couple of days, so if you want any of my files just shout.

Regards, Richard McDonald Woods

Winchester, UK

[Pete Dowson]

FSUIPC4.236 was initially ( first 2 hrs) a great improvement with Vista, PMDG 747-400X and ASX. The only problem was the jumping speed tape (up and down by up to 400 feet around every 3 or 4 minutes).

Are you using FSX + SP2/Acceleration? What FSUIPC Wind options are you setting? How does a "speed tape" measure "400 feet"? Do you mean the altitude tape?

If you are using FSX without SP2 or Acceleration then the main result of any of the smoothing options is "jumping" of the values at regular intervals -- the intervals are probably dependent upon the smoothing values, but most usually, for the ASI / Wind speed, they would be every second.

However, I then realised I had no wind vector on the ND, so I restarted ASX, but that made no difference. So I saved the situation and restarted ASX then FSX. Commanded speed was then M.841 but aircraft stuck at M.783. Still no wind vector. But now I can't engage LNAV - just get the FMS message NOT ON INTERCEPT HEADING. Then the aircraft gradually veered to the left without my being able to correct it. Eventually got stick shaker so I ended the flight.

Sorry, but there really is no way what FSUIPC is doing can cause the PMDG that much confusion, not unless it really has some serious bugs. To start with its ND's wind vector is derived from exactly the same values which would be displayed when you press Shift+Z. No wind vector means no wind. Did you check?

if you want any of my files just shout.

Thanks for the offer, but without more information I wouldn't know what to look for. If you are not using SP2 / Acceleration, as it sounds from your report, then I suggest that you disable all the smoothing options. If you are using SP2 / Acceleration then perhaps I need to investigate the "400 foot jumping on the speed tape" (), but maybe we should clarify that first, please?

Thanks,

Pete

[Pete Dowson]

Be sure that the layers you're moving through have radical wind direction differences. Also, I used keys mapped to "down quickly" and "up quickly" to slew through the layers.

Well, yes, I did have such layers, though often they changed before I got there. I finally realised I had the Options setting for weather changes one notch off the "no changes" mark. Even so it was uncanny how most of the winds "sorted" themselves into more reasonable setting before I got there.

Maybe it is related to where in the workld I am. I'm inclined to put the aircraft mid-Ocean and create weather using the user-defined global facilities.

However, I did actually managed to slew up and down fast enough through some very large changes in wind direction, and the smoothing still worked, so I'm puzzled.

Just FSX's own "real weather with 15 minute updates", and the "download winds aloft" option turned on in the weather display settings. No manual changes. FSX seems to create nasty shifting layers, happily, all on its own. :-)

Evidently not so bad where I am. Can you give me an airport ICAO ID for such reliable misfortune, please? ;-)

The first report (see the other recent threads) on 4.237 seems to say that these shifts may be fixed, but I'm not holding my breath.

Thanks for your help!

Regards

Pete