FSUIPC 3.51 & Winds

[pilotcdc]

Hello,

I have posted a message in the ActiveSky forum regarding the following problem...I'm not sure with whom the problem lies...

I use PMDG aircraft and ActiveSky in FS9 and there seems to be a discrepancy with wind reporting - I have wind smoothing turned on in ActiveSky. I have posted a screenshot here for clarification. There are also more pictures on the ActiveSky forum.

The FMC shows a tailwind of 17 knots but the ND shows a GS of 402 and a TAS of 367 making a 35 knot tailwind.

I have also had a problem where there is a tailwind and the ND shows a headwind and vice versa. I read in the 3.51 release notes that that problem was resolved, but I seem to still have it! See:

http://forums.avsim.net/user_files/135350.jpg

Any advice is appreciated.

Thanks,

Christian

PS I created a weather log file of the above flight if you are interested.

[JSkorna]

Hi,

Pretty sure I asked this at AVSIM, but I'll ask here also: What does the Shift/Z winds show in FS04?

[pilotcdc]

Shift-Z shows the same winds as ND...variation in the area was 0

[Pete Dowson]

The FMC shows a tailwind of 17 knots but the ND shows a GS of 402 and a TAS of 367 making a 35 knot tailwind.

The FMC also shows a crosswind of 33 knots. You forget, your aircraft is not travelling over the ground in the direction its nose is pointing, so the tailwind isn't the only additive to the ground speed. According to my maths the wind vector affecting the aircraft is

square root ( 17 x 17 + 33 x 33)

i.e. simple pythagoras. The answer: 37 knots! Dont's forget, the wind is pushing you sideways twice as much as it is forwards! You have to take the resultant wind vector to derive GS!

I have also had a problem where there is a tailwind and the ND shows a headwind and vice versa. I read in the 3.51 release notes that that problem was resolved

No, there's no change in 3.51 in the winds reported, only, in very unusual and special circumstances, to the effective wind at the aircraft, which isn't actually readable.

Without knowing where your PMDG aircraft is getting its information and calculating its figures I've no way to advise you, sorry. But if it is like the example you gave here, I suspect the simple maths of the situation are confusing you.

Anyway, try checking the actual values reported by FS itself, just to see if its something wrong in the PMDG aircraft -- for instance, use a default aircraft.

Shift+Z will show the ambient wind at the aircraft, with the heading you can therefore work out your tail and crosswinds by simple trig. For FS reported GS and TAS, if not shown on the aircraft's ND use FSUIPC's monitor (on the Logging page) -- check the Adv Display option there, and display the values in offsets 02B4 (GS) and 02B8 (TAS), both as U32 types, don't check 'Hex'.

You'd need to pause to check the figures as the GS is given is metres per second x 65536 -- convert to knots -- and the TAS is in knots x 128.

Regards

Pete

[pilotcdc]

Yes, using Pythagorean Theorem, you get a total wind of 37 knots. But, if you break those up into vectors, you get a 17 knot tailwind and a 33 knot crosswind as the FMC shows.

The only wind affecting groundspeed will be the headwind or tailwind component of the total wind. In this case, 17 knots. To make sure I wasn't going crazy, I computed the winds both on a "regular" E6B and an electronic one. They both show a groundspeed of about 383 knots. That would make the FMC correct, a tailwind of 17 knots (GS minus TAS). But, the groundspeed on the ND shows 402 knots - when it should be about 383 based on E6B calculations.

You say, "the wind is pushing you sideways twice as much as it is forwards! You have to take the resultant wind vector to derive GS!"

Not quite, if you have a direct crosswind of 100 knots, your GS will not change by 100 knots. GS would be derived from the components of the total wind, not the total wind itself.

Anyway, this problem is not showing up in 3.50, so I will use that for now.

-Christian

[Pete Dowson]

The only wind affecting groundspeed will be the headwind or tailwind component of the total wind.

How do you work that out? The aircraft will move in the airmass. If that is sideways, it moves sideways -- relative to the ground. The actual groundspeed will be the resultant vector of the aircraft's TAS on its heading (NOT track) and the wind vector, not the TAS and just the tail or headwind. You seem to be thinking that crosswinds don't do anything to the path of the aircraft over the ground. Why?

Anyway, this problem is not showing up in 3.50, so I will use that for now.

There should be no difference in 3.50, though that depends exactly what values are being compared between the two. Certainly, because of a correction in 3.51, the Aircraft Wind N and E values should be more accrate than they were before.

Perhaps you got used to incorrect reported values before and now don't like the better ones?

I think a lot more thought and research needs to be done on this before conclusions can be reached. You may need PMDGs help, to see what FS values they are using. I also mentioned how to check a few. If they are using others I can tell you about those too.

Regards

Pete

[Pete Dowson]

Further to my last reply, and actually working things out (for a change ;-)), the full way to compute that GS would be, again by pythagoras:

square root ((367 + 17)^2 + 33^2)

because the heading vector is the TAS + tailwind (367+17).

This actually gives 387, so the crosswind vector, in this case, does only add 3 knots. So there's something odd going on. But I need more data to know what that might be. Certainly comparative figures for the SAME situation exactly (i.e a paused saved one) with 3.50 and 3.51 might be useful. And as well as the GS and TAS offsets I mentioned already, the Aircraft wind X and Z values -- these are:

3470 FLT64 ambient X-axis wind (i.e. lateral), m/sec

3480 FLT64 ambient Z-axis wind (i.e. longitudinal), m/sec

There are two others which are relevant (unfortunately you can only monitor 4 values at a time, but if you are paused you could change over):

2DC8 FLT64 aircraft X-axis wind (i.e. lateral), ft/sec

2DD8 FLT64 aircraft Z-axis wind (i.e. longitudinal), ft/sec

If you could establish the situation as in your illustration, pause it and save it, then record the Shift+Z values, the ND values, the FMC values and the above 6 values, then do the same with FSUIPC 3.50, I will try to analyse them and see if I can work out what is happening. Don't worry about converting all these values, just write them down accurately please.

I'm wondering if PMDG have performed some extra computations to try to make up for something they may have found wrong in FSUIPC 3.50 and before, rather than reporting it for correction as one soul did. I don't use their aircraft so it isn't easy for me to work out what they are doing.

Oh, and can you derive anything different from default aircraft? If it is only the PMDG FMC which has these computations wrong I would certainly have to discuss it with them.

Regards,

Pete

[JSkorna]

Hi All,

The suggestion I made today at AVSIM is to try with a default plane and a default panel.

[pilotcdc]

Hi,

Ok, I did some testing and here it is...

In both tests (3.50 & 3.51) I turned off wind smoothing.

3.51

Wind: 277@35 on both ND and Shift-Z

TRK: 190

GS: 335 (should've been around 363)

TAS: 367

FMC showed: Headwind 2 kts; crosswind 35 kts

02B4 (U32): 11288222

02B8 (U32): 46967

3470 (FLT64): -3.9446

3480: (FLT64): 17.53*

2DC8: -22.66*

2DD8: 54.60*

The values followed with a * mean that during pause, the values were flashing rapidly between two different numbers, so I took the number while unpaused. Also, during the pause the TAT shifted quickly between -5 to +1 continuously. And, the mach number was changing from .481-.588 because of the temp change. Keep in mind, this was with ASVE running. When ASVE was off, the flashing/changing values did not occur. They also did not occur with ASVE running with 3.50.

3.50

Wind: 277@35 on both ND & Shift-Z

TRK: 190

GS: 362

TAS: 365

FMC: headwind 2 kts; crosswind 35 kts

02B4: 12304589

02B8: 46729

3470: 17.9213

3480: -1.8836

2DC8: 59.0321

2DD8: 3.2350

From my point of view, there seems to be a problem with ASVE running with 3.51. I loaded the default 737 with ASVE & 3.51 and had the same problems of the values changing rapidly.

Someone in the ActiveSky forum also did some testing. They said with ASVE & 3.50 they had no problems, but with ASVE & 3.51 they had some issues (TAS & GS), and they noted that when using 3.51 & FS weather those issues were no longer seen.

Hope this helps,

Christian

[Pete Dowson]

The values followed with a * mean that during pause, the values were flashing rapidly between two different numbers, so I took the number while unpaused.

Strange. I don't suppose you could read either of them? If you checked the "normal log" option in the Monitor page they would be written to the FSUIPC log file -- probably making it quite big quite quickly by the sound of it, so only do it whilst its paused, the stop it again.

Also, during the pause the TAT shifted quickly between -5 to +1 continuously. And, the mach number was changing from .481-.588 because of the temp change. Keep in mind, this was with ASVE running. When ASVE was off, the flashing/changing values did not occur. They also did not occur with ASVE running with 3.50.

Is that over many tests, or just one of each? Because there's really been no changed in FSUIPC in areas like temperature setting. That's really puzzling. Of course the TAT would be affected slightly by the wind direction changes, because of the different pressure on the body, but compared to the airspeed I would have thought that effect to be negligible.

It is also odd that there's any wind difference, because by switching wind smoothing off (I assume you did than in FSUIPC and in ASV? Because ASV can override that and does, by default I think) you actually bypass all of the FSUIPC "interference" in all the values listed, including the only difference in the weather between 3.50 and 3.51.

There's one very important value missing from the list. Unfortunately you omitted the heading. The "track" is no use because the tail and crosswinds, and the X and Z wind values, are relative to the aircraft body, which is the heading orientation. I also assume this was in level flight, otherwise some of the figures cannot be related.

The values for GS and TAS shown by the ND are certainly correct in that they match the values FS is using in both cases. The FMC must be computing crosswind and tailwing from the given wind rather than reading the aircraft X and Z values -- in the 3.51 case above the FS-computed crosswind (X) from 2DC8 is 13 knots and the headwind (Z) from 2DD8 is 32 knots. The 3.50 values are 35 knots and 2 knots respectively, agreeing with the FMC.

One thought has just struck me. I'm wondering if ASV tries to control the winds at the aircraft directly -- by writing to offsets 2DE0 and 2DE8. The correction in 3.51 was made in applying values written to 2DE0, for the wind direction. It was found that the value FSUIPC was actually writing was 180 degrees opposite to what should have been written. I fixed this, but perhaps, experimentally, Damien found the error, didn't tell me about it, and "fixed" it by writing 180 degree-different wind directions here.

This would certainly cause some havoc, even if the wind smoothing was turned off. And it presents a quandary if so. Do I, in FSUIPC, maintain an error because programs have been changed to "correct" for it, or expect the programs to be fixed? Really, if indeed, this is what has happened, then the ASV team should have sorted out the discrepancy with me when it was frst noticed.

To check for this, do you think you could run your test once again, but this time Monitor just 2DE0 and 2DE8, both as FLT64. If you like, check the "normal log" option below so the values get written to the log. then you can show me that.

Sorry for all the hassle. This is indeed a puzzle.

If this is the problem, I can provide an interim version of FSUIPC which will have an INI parameter to revert to the incorrect wind setting -- or, rather, do the 180 degree reversal when the value is written to 2DE0. Then, if it is ASV, the parameter can be removed when and if it is ever fixed.

I do have ASV installed in my cockpit (but not on my test machines unfortunately), and I'll try to do some checks myself tomorrow as well. In case it is ASV build dependent, can you tell me the exact version/build you are using, please. I'm not even sure I am up to date.

Thanks,

Pete

[pilotcdc]

Ok, I did some more testing, and here are the results.

With 3.51...

Wind: 277@35

HDG: 181 (can't be right, wind's coming from other direction)

TRK: 184

FMC: 4 kt tailwind; 35 kt crosswind

2DE0 (FLT64): 276.0000

2DE8 (FLT64): 36.0000

I forgot to write down the TAS & GS! But, the TAS was 367 and the GS was showing around 335.

And, on pause, the TAT was shifting back and forth from -5 to +1 and the mach was changing from M0.483-0.588 as before. I then quit ASVE and the wind shifted to 321@35 and the TAS/GS/HDG/TRK/FMC all showed correct values.

With 3.50...

Wind: 277@35

HDG: 189

TRK: 184

TAS: 367

GS: 367

FMC: 1 kt headwind; 35 kt crosswind

2DE0: 276.0000

2DE8: 36.0000

All seems to be correct in 3.50

Thanks,

Christian

PS Using ActiveSky V Enhanced Build 367.

[dave_paige]

Hi;

Just to reinforce that I also believe that there is a significant change between FSUIPC 3.50 and 3.51. Here are my 3 posts from the AVSIM Active Sky forum.

post #1

I want to add that I'm also getting some very strange wind behavior with ASVE since I upgraded to FSUIPC 3.51. I had a direct headwind of 98 knots, but with a true airspeed of 450 my ground speed was 398 knots, not right. With FSUIPC 3.50 everything was find. With FS weather themes the numbers came out right.

I'm about to do a test flight with FS real world weather to see what that does. I'll report back in a few.

post #2

Ok, I've done a bit more testing and the descrepancy on the ND of the PMDG 737 concerning wind,TAS, and GS is only when running ASVE and FSUIPC 3.51.

FSUIPC 3.51 with FS real world weather, or an FS weather theme shows the correct TAS vs. GS based on the winds.

FSUIPC 3.50 with ASVE, FS real world weather, or an FS weather theme shows correct TAS vs. GS based on the winds.

post #3

Hi Jim;

Ok just complete the test you suggested. Used the default 737-400 cruising at FL320 with ASVE weather and FSUIPC 3.51.

heading: 259

wind: 259 at 46kts

true airspeed: 436kts

ground speed: 467kts

Still not correct.

[Pete Dowson]

I also believe that there is a significant change between FSUIPC 3.50 and 3.51.

I'm still checking this, but I have only just discovered that there is a new version of ASV called ASVE. All my tests have been with Build 325, which seems to before this "E" was added. I had no knowledge of the later versions. B325 certainly behaves impeccably here.

The change between 3.50 and 3.51 is significant here because it CORRECTS an error (originally due to a misunderstanding about certain internal FS variables) which has been in all versions of FSUIPC 3 before 3.51 (or rather 3.507, which was available here for testing for 5 or 6 weeks -- apparently no one using ASVE bothered to try it and tell me these things).

It is looking like ASVE was changed to try to allow for this error in pre 3.51 versions -- instead of someone talking to me and arranging for it to be fixed. When it was reported (not by ASV sources) I fixed it, so the counter-measures which may have been taken in ASVE are now incorrect.

This is the way it is looking, but I am working on it now to compare ASV 325 and ASVE 367 to prove to myself whether this is the reason or not.

Please see previous messages in this thread too.

Regards,

Pete

[Pete Dowson]

Okay. I've now downloaded and installed ASVE, build 367. It does no different from my older ASV build 325 as far as the direct control of winds is concerned. however, they both do actually use the feature which I thought I fixed in 3.51. (ASV must be one of the very few programs which do use it).

What I cannot understand is how 325 seemed to be perfectly okay with FSUIPC versions 3.507-3.51 here.

The problem with the way the direct wind application (through offsets 2DE0 and 2DE8) works is that it appears to give the reverse wind effect on the aircraft itself -- for instance, as measured with the ASI on an aircraft static on the ground, nose to wind. In other words, setting a 30 knot wind from 270 via those offsets, with FSUIPC 3.50 and before you'd need to point the aircraft's nose to 90 to measure the 30 knots on the ASI. That can't be right!

Probably the fix for this which I added in 3.507-3.51 was wrong, but it most certainly did correct this anomaly, which was the intention. Maybe that was a fluke and in fact there's another fix which will do the job without the incorrect side effects on the crosswind and headwind values you've been getting with ASV.

So, I am working on an interim release, 3.511, which by default does the same as 3.50 did for these offsets, but which also contains an INI file parameter ("AircraftWindRev") which, if set to "Yes" will reverse the direction applied sent to offset 2DE0 before applying it to FS. (This is different to the previous "fix").

Please look out for this in the Interim Versions announcement, top of this forum, and try it with the same sorts of tests you have been doing already -- they have been very helpful, thanks. Please try 3.511 as it comes, and then with AircraftWindRev=Yes in the INI, with the exact same weather if possible, and reporting the same variables, please.

I'm going to try to do the same here, but I badly need corroboration as these things have not appeared wrong here at all so far.

Thanks,

Pete

[Pete Dowson]

I've just noticed that, in ASVE at least (it may have been there in ASV too, but I've installed ASVE over it now) there's an Option setting to diasable "direct wind control". Maybe I had it disabled? I don't know.

But it sounds like that is the facility which is driving the bit of FSUIPC which chabged from 3.50 to 3.51, so another possible test, to verify this, would be to change that ASVE option.

This isn't in place of the previous tests I suggested with 3.551, but another possible work-around and confirmation.

I'll put 3.551 up in an hour or so. Just doing some final checks here to make sure I haven't broken anything. ;-)

Regards,

Pete

[dave_paige]

Just a preliminary report;

Just as you thought, with version 3.5.1.1 of FSUIPC, ASVE (build 367), PMDG 737NG or default 737-400;

AircraftWindRev=No = correct TAS vs. GS behavior

AircraftWindRev=Yes = incorrect (reversed) TAS vs. GS behavior

BTW I do all of these test flights by climbing to a cruise of FL360 and then flying directly into the wind to eliminate the need for a trig calc.

I didn't include the specific because I'm going to do some more testing including your mention of the ASVE parameter regarding 'direct wind control'.

[dave_paige]

Second prelim report;

Also as you thought, turning off ASVE 'direct wind control' while using FSUIPC 3.5.1, also resolves the TAS vs. GS reverse effect issue. I'm off to read the ASVE docs on what that control was originally intended for.

I think I like the option you've put in the .ini file of 3.5.1.1. So hopefully you'll go with that.

Thanks so much for a great piece of software and being so responsive, and yes, I'm a proud, registered, user.

[Pete Dowson]

I think I like the option you've put in the .ini file of 3.5.1.1. So hopefully you'll go with that.

Well, I will for now. But there's a problem to solve still. With that set to its default "No", the wind at the aircraft as measured by the ASI is 180 degrees out. That must mean something. That is the 'bug' I set out to fix in the first place, and I've had to allow it back.

You can only really see this measurement easily on the ground, because when flying the larger TAS and complex vectors mask what is going on, and particularly makes it difficult to relate the instrument readings directly. More experiments, in scientific conditions, are going to be needed to get to the bottom of it.

I'm not sure when I'm going to have such time to investigate further, so the option stays. I just don't like it.

Regards,

Pete

[pilotcdc]

Hello all,

I did a quick test flight. I had the same results as Dave reported above. Correct when AircraftWindRev=No and incorrect with AircraftWindRev=Yes.

Seems like a problem with ASVE Direct Wind Control...but I like to keep that on becuase there are more reporting stations with ActiveSky than with default FS weather -- especially over water.

Thanks Pete & Dave for the testing and temporary fix.

-Christian

[JRBarrett]

I think I like the option you've put in the .ini file of 3.5.1.1. So hopefully you'll go with that.

Well, I will for now. But there's a problem to solve still. With that set to its default "No", the wind at the aircraft as measured by the ASI is 180 degrees out. That must mean something. That is the 'bug' I set out to fix in the first place, and I've had to allow it back.

You can only really see this measurement easily on the ground, because when flying the larger TAS and complex vectors mask what is going on, and particularly makes it difficult to relate the instrument readings directly. More experiments, in scientific conditions, are going to be needed to get to the bottom of it.

Ah Ha! This answers a question which has puzzled me since the release of FS2004... i.e. the fact that when one taxis into the wind with the FS parameters displayed on screen via Shift-Z, the displayed ground speed increases, and decreases when taxiing with a tailwind. Exactly the opposite of what one would expect.

Thanks for the insight...

Jim Barrett

[dave_paige]

Hi Pete;

It might not be that bad. Here's a quote from the ASVE user's guide:

Disable Direct Wind Control – Disables the DWC wind system in ASV. This system, when not disabled, corrects for FS9’s erroneous wind direction changes by forcing wx as computed by ASV at all times. Depends on ASV running for correct wind depiction.

So it looks as if Damian Clark of HiFi software may have been trying to fix the same problem. So now the double fix recreates the problem. So it looks as if users should just disable his or yours when running ASVE and FSUIPC together.

I've tried it both ways, ASVE 'direct wind control' disable with FSUIPC 'aircraftwindrev' set to 'Yes' = works fine,

ASVE 'direct wind control' enabled with FSUIPC 'aircraftwindrev' set to 'No' = works fine.

I'll continue testing and see if either method works better.

[Pete Dowson]

Hi,

I've posted two updates to FSUIPC in the top announcement here as part of an attempt to get the wind smoothing system working correctly (again). Please try them out and let me know what you think. I've reproduced the notes about them here, below, so you can see what is going on.

Best regards

Pete

===============================================

FSUIPC.DLL Versions 3.511 and 3.512

I've posted two test versions at the same time in an attempt to find out if they both behave the same, wind-wise, or if one is better than the other. I am testing here, but wider usage is needed, please.

The 3.51 fix in the wind smoothing algorithm which additionally makes the wind direction written to offset 2DE0 have the correct effect at the aircraft, now appears to be in error. The direct wind control facilities at offsets 2DE0 and 2DE8 are used by ASV (optionally, but defaulted). The fix applied to get the apparently correct effect at the aircraft via these offsets has the unfortunate side effect of making FS set incorrect crosswind and head/tail wind components.

Worse, even weithout anything using direct wind control, with Wind Smoothing is enabled, the same, "corrected" algorithm is used and again applies the incorrect wind components -- although then these don't appear to be read as such by navigational instruments.

I cannot make a lot of sense of all this at present, though after a couple of days of investigation it does appear to me that FS's wind simulation is rather different when the aircraft is on the ground than when it is in the air. I can 'fix' things on the ground, and in the air, but with different algorithms. Although I can detect the difference ("aircraft on ground") I cannot actually implement both fixes because the wind changes have a delayed effect on the aircraft. I've tried, but no matter what I do, things get screwed up for a while just after take-off, i.e. at the worst possible time.

So I'm abandoning the attempts to get the wind control working on the ground. Hopefully I'll be able to do better with the next version of FS, as and when.

Just by way of explanation of what the original change in 3.51 was all about: the problem in 3.50 and before with the wind direction written to 2DE0 was that the effect actually implemented in FS at the aircraft was a wind 180 degrees opposite, as could be found by turning a static ground aircraft into wind as measured on its ASI. The fix in 3.51 certainly fixed that, and quite a bit of exposure here (as 3.507) failed to detect the airborne inconsistencies which arose.

The differences between 3.511 and 3.512 are in how much "fiddling" FSUIPC does with the winds inside FS when smoothing or providing direct control. Over the last two days I think I've proven to myself that some of the things I was changing don't matter, and may make things worse, so 3.512 eliminates that part of the code.

Please try both 3.511 (without "AircraftWindRev=Yes") and 3.512 (it doesn't have that parameter), and let me know which you find better, if you notice any difference at all. Thanks!

Regards

Pete

[dave_paige]

Only had time for two flights tonight. But my initial reaction is that 3.512 seems to work very well for me. I'll do more extensive testing probably over the weekend. Thanks again for all of your efforts and attention to this.

[tstewart]

Hi Pete,

3.511 works fine with ASV and Direct Wind Control on. I will check 3.512 tonight.

[Pete Dowson]

Hi Pete,

3.511 works fine with ASV and Direct Wind Control on. I will check 3.512 tonight.

Thanks. It should be the same, but I am testing a slight modification (which will be 3.513). It suppresses the direct wind control whilst you are on the ground. Since the wind direction set by direct control is 180 degrees out when on the ground, yet okay when airborne, it actually presents a bigger change or risk on takeoff, so, since I cannot fix the ground problem I will prevent it instead. There will be a parameter to undo this if needed, but I hope it won't be.

I'll put 3.513 up as soon as I'm happy with it, maybe tonight.

Regards,

Pete