NWI Winds Aloft

[pilotjohn]

Pete,

I think there's a bug in how you translate the NWI winds aloft structure to the extended METAR syntax.

See below:

  1233328 >NewSet:  Surface wind: to alt=3330ft AMSL, dir=42T, vel=8.00, gust=1.
0, turb=0, shear=1, var=4.2
  1233328 >NewSet:  Wind layer 1: to alt=6670ft AMSL, dir=43T, vel=15.0, gust=1.
0, turb=1, shear=1, var=2.8
  1233328 >NewSet:  Wind layer 2: to alt=10000ft AMSL, dir=44T, vel=23.0, gust=1
.0, turb=2, shear=0, var=5.1
  1233328 >NewSet:  Wind layer 3: to alt=13330ft AMSL, dir=45T, vel=30.0, gust=0
.0, turb=1, shear=0, var=4.8
  1233328 >NewSet:  Wind layer 4: to alt=16670ft AMSL, dir=47T, vel=36.0, gust=0
.0, turb=1, shear=1, var=0.6
  1233328 >NewSet:  Wind layer 5: to alt=20000ft AMSL, dir=48T, vel=41.0, gust=0
.0, turb=1, shear=1, var=3.4
  1233328 >NewSet:  Wind layer 6: to alt=23330ft AMSL, dir=49T, vel=41.0, gust=0
.0, turb=1, shear=1, var=0.7
  1233328 >NewSet:  Wind layer 7: to alt=26670ft AMSL, dir=50T, vel=49.0, gust=0
.0, turb=0, shear=0, var=4.1
  1233328 >NewSet:  Wind layer 8: to alt=30000ft AMSL, dir=52T, vel=54.0, gust=0
.0, turb=2, shear=1, var=8.7
  1233328 >NewSet:  Cloud[0]: type=9, from 3420ft to 5574ft (+/- 0ft), cover=1,
turb=2, topshape=0
  1233328 >NewSet:                      Precip=0, base=0ft, rate=0, icing=0
  1233328 >NewSet:  Cloud[1]: type=9, from 6780ft to 10476ft (+/- 0ft), cover=1,
 turb=2, topshape=0
  1233328 >NewSet:                      Precip=0, base=0ft, rate=0, icing=0
  1233328 >NewSet:  Cloud[2]: type=9, from 12960ft to 17700ft (+/- 0ft), cover=1
, turb=2, topshape=0
  1233328 >NewSet:                      Precip=0, base=0ft, rate=0, icing=0
  1233328 >NewSet:  **** End of New Weather details for ICAO=GLOB
  1233328 Setting Weather: "GLOB 141541Z 04208G09KT&D1016NM 039V044 04315G16KT&A
1016OM 04423G24KT&A2032LG 04530KT&A3048OG 04736KT&A4064OM 04841KT&A5080OM 04941K
T&A6096OM 05049KT&A7112NG 05254KT&A8128LM 32KM&B-1&D1 32KM&B1&D1015 38KM&B1016&D
1016 43KM&B2032&D1016 48KM&B3048&D1016 54KM&B4064&D1016 59KM&B5080&D1016 64KM&B6
096&D1016 70KM&B7112&D1016 75KM&B8128&D1016 1CU034&CU022FLVN000N 1CU068&CU037FLV
N000N 1CU130&CU047FLVN000N 25/16&A0 05/M09&A3048 M17/M26&A6096 M19/M32&A9144 Q10
25 "

The sections after the surface wind should contain the actual UpperAlt value for the winds aloft, but it looks like you're subtracting the surface wind depth from each (the first one should be 2032, and last one should be 9144, but they are all less by the depth of the surface layer). "The altitude of a WINDS ALOFT section specifies the top of the layer in which the given wind data is to apply. The bottom of the layer will be determined by the top of any lower layer, either another WINDS ALOFT entry, or the SURFACE WINDS entry." This is visible in FSX weather interface, as the first aloft layer is nearly on top of the surface layer. Can you fix this?

Also, I'm not sure if the SimConnect METAR documentation is in the correct order, but if it is, the surface wind variation should come after the winds aloft section, not after the surface winds. (http://msdn.microsof...y/cc526983.aspx)

Regards,

John

[Pete Dowson]

The sections after the surface wind should contain the actual UpperAlt value for the winds aloft, but it looks like you're subtracting the surface wind depth from each (the first one should be 2032, and last one should be 9144, but they are all less by the depth of the surface layer).

I am going by this definition in the SDK:

"Format 1:

This repeats the surface wind data but instead of specifying a surface layer depth it specifies a base altitude. The extension format is &ANNNNTS. Note the A for altitude instead of D for depth, and that wind altitudes are above mean sea-level (MSL). The format is otherwise the same as for surface winds, including the extension giving the depth, turbulence and wind shear"

Notice that the entries contain 'A' not 'D' like the surface layer.

"The altitude of a WINDS ALOFT section specifies the top of the layer in which the given wind data is to apply. The bottom of the layer will be determined by the top of any lower layer, either another WINDS ALOFT entry, or the SURFACE WINDS entry." This is visible in FSX weather interface, as the first aloft layer is nearly on top of the surface layer. Can you fix this?

I agree this caused confusion in the first place -- that statement completely conflicts with the 'A' definition of the format. The correct method, as used in FSUIPC, was derived by experimentation and testing, and of course by reading back the weather so written.

I suggest you test this yourself. Set the weather at a station with several contrasting wind layers, then, instead of looking at the misleading graphics in the FSX dialogue (which are wrong, in fact -- they've never worked correctly), use slew to slew up into each layer in turn (use Shift+Z to check your altitude), pause and exit slew mode so the Shift+Z display shows the wind details (Mag, not True, but okay otherwise). You'll find that what is written not only accords with what is read back but also with what can be really observed in the sim, rather than in the dialogues. Remember whilst you are doing this that the wind speed and direction are both gradually changed towards the 'boundary point' to avoid a sudden transition (windshear).

Also, I'm not sure if the SimConnect METAR documentation is in the correct order, but if it is, the surface wind variation should come after the winds aloft section, not after the surface winds. (http://msdn.microsof...y/cc526983.aspx)

Again, derived from testing -- and observing the order on readback. It is correct, and obviously more sensible, to have the variance block immediately after the surface wind block. It doesn't work the way you suggest, it is ignored.

Try all this yourself. Use Weatherset2 to change wind values and add/delete layers at a WX station whilst reading back the resulting METAR in offset B800 and checking the actual simulated result.

I'm afraid the SimConnect WX documentation leaves a lot to be desired. By the time they came to write it up, Niniane Wang, who wrote the code, had left.the team. The reason the obvious bugs (the interpolation errors causing the exctreme wind shifts) were never fixed, even in ESP, was apparently because no one understood her code. They planned to re-write it all completely in FSXI.

Regards,

Pete

[pilotjohn]

I agree this caused confusion in the first place -- that statement completely conflicts with the 'A' definition of the format. The correct method, as used in FSUIPC, was derived by experimentation and testing, and of course by reading back the weather so written.

The read-back shows the same as that which was written (e.g. base altitude not the top of the layer, is this correct?). I'll take your word for this since slewing through layers seems to not show the correct wind, although everything in WeatherSet2 and FSX GUI, and read-backs show the correct settings. Only the surface wind read-out seems correct, regardless of the number of layers I create and where in the layer I am trying to slew/un-slew to check wind.

  1853479 >NewSet:  Surface wind: to alt=10000ft AMSL, dir=215T, vel=2.00, gust=
3.0, turb=0, shear=0, var=4.8
  1853479 >NewSet:  Wind layer 1: to alt=20000ft AMSL, dir=236T, vel=26.0, gust=
1.0, turb=1, shear=1, var=2.9
  1853479 >NewSet:  Wind layer 2: to alt=30000ft AMSL, dir=257T, vel=63.0, gust=
0.0, turb=0, shear=1, var=7.8
  1853479 >NewSet:  Cloud[0]: type=8, from 6170ft to 25410ft (+/- 0ft), cover=2,
 turb=1, topshape=0
  1853479 >NewSet:                      Precip=0, base=0ft, rate=0, icing=0
  1853479 >NewSet:  Cloud[1]: type=9, from 10690ft to 16710ft (+/- 0ft), cover=2
, turb=1, topshape=0
  1853479 >NewSet:                      Precip=0, base=0ft, rate=0, icing=0
  1853479 >NewSet:  **** End of New Weather details for ICAO=GLOB
  1853479 Setting Weather: "GLOB 141503Z 21502G05KT&D3048NG 213V217 23626G27KT&A
3048OM 25763KT&A6096NM 34KM&B-1&D1 34KM&B1&D1015 42KM&B1016&D1016 49KM&B2032&D10
16 57KM&B3048&D1016 65KM&B4064&D1016 73KM&B5080&D1016 80KM&B6096&D1016 88KM&B711
2&D1016 96KM&B8128&D1016 2ST062&ST192FOVN000N 2CU107&CU060FOVN000N 16/08&A0 09/M
06&A3048 M16/M24&A6096 M40/M53&A9144 Q1029 "
  1859875 WX Error: timed out, WX request type 5, Lat=41.0669, Lon=-74.5561, Alt
=0.0m
  1874882 Weather Read request (At Aircrft) to area 4: Lat=40.36, Lon=-74.56, Al
t=115.3, Req=2
  1874882 Weather Read request (Nr Station) to area 5: Lat=40.36, Lon=-73.63, Al
t=0.0, Req=1
  1874882 Weather Received (type 4 request, Interpolated): "GLOB&A0 141503Z 2150
2G05KT&D3048NG 213V217 23626G27KT&A3048LM 25763KT&A6096NM 34KM&B-1&D1 34KM&B1&D1
015 42KM&B1016&D1016 49KM&B2032&D1016 57KM&B3048&D1016 64KM&B4064&D1016 73KM&B50
80&D1016 80KM&B6096&D1016 88KM&B7112&D1016 96KM&B8128&D1016 2ST062&ST019FLVN000N
 2CU107&CU006FLVN000N 16/08 09/-6&A3048 -16/-24&A6096 -40/-53&A9144 Q1029 @@@ 10
0 9 236 26 | 200 -16 257 63 | "
  1874882 WX Received in 0 mSecs, WX request type 4, Lat=40.3567, Lon=-74.5567,
Alt=115.3m

[Pete Dowson]

The read-back shows the same as that which was written (e.g. base altitude not the top of the layer, is this correct?).

I am pretty sure it is correct for "A". If it is the top it would be a "D".

I'll take your word for this since slewing through layers seems to not show the correct wind

Really? I just did this at EGCC with the EGCC METAR string in front of me and, with the smoothing interpolation taken into account, it seems correct. You don't get a precise boundary between layers of course, but a gentle change.

Regards

Pete

[pilotjohn]

Really? I just did this at EGCC with the EGCC METAR string in front of me and, with the smoothing interpolation taken into account, it seems correct. You don't get a precise boundary between layers of course, but a gentle change.

Yep... for the sample above I was getting 5-6 KTS at 18000 feet during the slew read-out. I'll finish up my weather generator as is, and see how it feels with the limitations FSX imposes.

[Pete Dowson]

Yep... for the sample above I was getting 5-6 KTS at 18000 feet during the slew read-out. I'll finish up my weather generator as is, and see how it feels with the limitations FSX imposes.

I notice you are setting GLOB weather, not station weather. Are you definitely in Global weather mode, and did you clear weather first? I'm wondering if your weather might still be in transition (forming, so to speak). Do the clouds get drawn correctly?

I've really not done much testing in Global mode myself, but it is used by several Flight Instructor programs, and of course by ASE in its DWC mode. It might be instructive to see what METAR strings it sends and what results it gets. this would have to be done with Simconnect logging, of course.

Regards

Pete

[pilotjohn]

I notice you are setting GLOB weather, not station weather. Are you definitely in Global weather mode, and did you clear weather first? I'm wondering if your weather might still be in transition (forming, so to speak). Do the clouds get drawn correctly?

I've really not done much testing in Global mode myself, but it is used by several Flight Instructor programs, and of course by ASE in its DWC mode. It might be instructive to see what METAR strings it sends and what results it gets. this would have to be done with Simconnect logging, of course.

Regards

Pete

Yes, definitely in global mode (FSUIPC logs show this, weather cleared) and clouds(at least what works)/visibility/temperature are set correctly. The logs above are the METAR sent and received, correct? Or is there additional logging available?

[Pete Dowson]

Yes, definitely in global mode (FSUIPC logs show this, weather cleared) and clouds(at least what works)/visibility/temperature are set correctly. The logs above are the METAR sent and received, correct? Or is there additional logging available?

FSUIPC logs them, as you see, and so does SimConnect if you enable its logging. ASE for FSX doesn't use FSUIPC, which is why I suggested it for comparison, but looking at SimConnect logging.

I'll try and find time to do some comparisons in global mode. It won't be today though. You could also experiment with your own METAR strings. You can write them via offset B000 -- FSUIPC doesn't interfere with those, it just sends them on to SimConnect.

Regards

Pete

[pilotjohn]

I'll try and find time to do some comparisons in global mode. It won't be today though.

Thanks... I'll keep poking.

Both write and read look good in terms of winds aloft, they show up correctly in the FSX weather GUI, and WeatherSet2, but I'm not getting the results in flight.

I used the B offset to write some METARs directly (now that it works - thanks again for fixing that BTW) but it seems to have no affect either (wrote GLOB 000000Z 36010KT&D1000NG 27050KT&A3000NG 15/10&A0) which again looks good in FSX GUI but doesn't get simulated. If I view it in the GUI and click "OK" it starts to work.

The same thing happens if I use WeatherSet2 to add a layer. It shows up but doesn't appear to be simulated.

You said doing this on a per-station basis works?

[Pete Dowson]

I used the B offset to write some METARs directly (now that it works - thanks again for fixing that BTW) but it seems to have no affect either (wrote GLOB 000000Z 36010KT&D1000NG 27050KT&A3000NG 15/10&A0) which again looks good in FSX GUI but doesn't get simulated. If I view it in the GUI and click "OK" it starts to work.

Weird, as all you are doing is bypassing the FSUIPC encoding of binary tabulated data to METAR string, so it should be no different.

You said doing this on a per-station basis works?

Well it works here with WeatherSet2, and Active Sky 6.5 also uses it and works fine in FSX. Also you can actually set ASE into FS9 mode so it uses FSUIPC and the NWI, and it works too that way.

Global weather mode must work, as it is used by ASE in DWC mode. Maybe it just isn't using layers, only controling the weather at the aircraft, but I wouldn't hasve thought so. When I get time I'll do some SimConnect logging with ASE and see.

Regards

Pete

[pilotjohn]

If global turns out not to work...

Would you be able to add facilities for evaluating the nearest or adding "virtual" stations? As it is I can't determine what the nearby stations are if I have to use station-based weather settings since I don't see any facility for that except <??> which sets weather for THE nearest station.

Perhaps if a lat/long is given, FSUIPC should create a virtual station at that location using the ID given in the ICAO field and then set the provided weather for it. That way I could create a grid of stations.

If I don't enter global mode and set GLOB weather will it set all stations to that weather? What is that mode called? Theme?

[Pete Dowson]

If global turns out not to work...

But it must work. Programs, like ASE, use it! You ARE using a fully updated version of FSX aren't you? It wasn't in the original release. I think it was added in SP2, though it might have been SP1.

Sorry, I just don't have time to do an investigation for you at present. I suggest getting ASE working in DWC mode and seeing what that does by examining the SimConnect logs.

Would you be able to add facilities for evaluating the nearest or adding "virtual" stations? As it is I can't determine what the nearby stations are if I have to use station-based weather settings since I don't see any facility for that except <??> which sets weather for THE nearest station.

I've no way of doing that any better than you can, i.e. by reading the WXStationList.bin file and using the Lat/Lons there to determine their distance. You'll find that file in the same folder as your FSX.CFG I don't really think such an action falls within the FSUIPC remit.

Perhaps if a lat/long is given, FSUIPC should create a virtual station at that location using the ID given in the ICAO field and then set the provided weather for it. That way I could create a grid of stations.

No, I won't be doing that, sorry. And in any case it would only work in places where there are no already existing weather stations, like in the Oceans. Otherwise the weather at the existing ones would interfere and cause all sorts of weird problems because of FSX's interpolation errors.

If I don't enter global mode and set GLOB weather will it set all stations to that weather?

Only if the weather is definitely clear to begin with. Then, gradually, each weather station's weather would change, differently. That occurs even with the dynamics slider at minimum, simply because the weather is moving, it is not static (unless there are no clouds and no wind -- but i don't think it can even stay that way for all that long).

What is that mode called? Theme?

No, theme sets weather from a theme definition. User-defined or "custom". FSUIPC automatically sets Custom mode when you try to set a WX station's weather.

Regards

Pete

[pilotjohn]

But it must work. Programs, like ASE, use it! You ARE using a fully updated version of FSX aren't you? It wasn't in the original release. I think it was added in SP2, though it might have been SP1.

Well winds aloft in global mode definitely don't work, no matter what I do.

How can I use the FSUIPC facilities to set the weather mode to "Custom" so that individual stations can be set?

There's GLOBAL mode, and I can clear weather which reverts to "Theme" mode (according to logs).

But it seems "custom" needs to be used if I want to set all stations and use "GLOB" to propagate to unset stations.

[Pete Dowson]

Well winds aloft in global mode definitely don't work, no matter what I do.

That actually may be so -- I would hazard a guess that because Global mode was intended for direct easy control of the weather AT the aircraft (for training applications really), it was not necessary to implement layers. A quick log with ASE in DWC mode would show.

All you need to do, really, is change the wind according to the aircraft's altitude, probably as ASE does.

How can I use the FSUIPC facilities to set the weather mode to "Custom" so that individual stations can be set?

As I just said, it does that automatically when you try to set a station.

There's GLOBAL mode, and I can clear weather which reverts to "Theme" mode (according to logs).

That's because the only sure way I have to clear all weather is to tell FSX to set the "clear weather" theme.

Regards

Pete

[pilotjohn]

Ok.

I just tested, and not setting global mode (setting dynamics to 0, clearing weather, then setting GLOB METAR) works for winds aloft. I now have to re-test all the other stuff I generate (temp/visibilty/clouds).

[pilotjohn]

Pete,

In this non-global custom mode, my original "bug" report stands. The winds aloft altitude after the &A should be the upper altitude, not the upper altitude less surface wind depth. I just tested this with the two following METARs and the described results which show that &A should have the layer top, not base.

GLOB 000000Z 36010KT&D1000NG 27060KT&A3000NG 15/10&A0

At the surface the wind was shown as 10 KTS. Slewed to 5000 feet the wind read-out was 24 KTS (which is about correct for interpolation using 10000-3300=6700, 60-10=50, 5000-3300=1700, 1700/6700*50=13, 10+13=23).

GLOB 000000Z 36010KT&D1000NG 27060KT&A1100NG 15/10&A0

At the surface the wind was shown as 10 KTS. Slewed to 5000 feet the wind read-out was 60 KTS (no interpolation since above the layer top), and at 3500 feet the wind read-out was 37 KTS (which again is correct for interpolation, 3700-3300=400, 60-10=50, 3500-3300=200, 200/400*50=25, 10+25=35).

Can you fix this please?

Regards,

John

[Pete Dowson]

Can you fix this please?

I don't know if I can, if it's an FSX bug. The point is, the weather actually being set IS being read back with the same altitudes in the METAR strings. Correct? If I manipulate the input, contrary to the SDK documentation, and it reads back differently to what is written, I'm going to get much more flak for it being wrong than keeping it how it is and has been for 5 years.

It will have to wait until i have time to do a full investigation. If it is really wrong the way it is I might need to just document it, or add another, alternative, facility to "NW_SET" like "NW_SETDIFFERENTLY".

Meanwhile, can you just do a test at a weather station, not GLOB. please? Position yourself at the actual station, so there is no or little interpolation. Possibly this bug in FSX only affects the GLOB settings, not all of them. If that is the case I wouldn't really have such a worry "fixing" it ("fiddling" it is probably a more apt description).

Regards

Pete

[pilotjohn]

I don't know if I can, if it's an FSX bug. The point is, the weather actually being set IS being read back with the same altitudes in the METAR strings. Correct? If I manipulate the input, contrary to the SDK documentation, and it reads back differently to what is written, I'm going to get much more flak for it being wrong than keeping it how it is and has been for 5 years.

No, I don't think it's an FSX bug. If you write X and read back and get X than FSX is not altering anything, thus there's no bug (only if it behaves differently than written, but it doesn't, you write X as the layer top, you read back X, and FSX is using that as the layer top). It's just that the &A should be the layer top, and that's how FSX interprets it (per "option B" in the documentation). If you were writing X and getting X+Y or getting X but FSX behaving like X+Y than I would concur that it's an FSX bug and you're "fixing" it. But that's not the case here.

Meanwhile, can you just do a test at a weather station, not GLOB. please? Position yourself at the actual station, so there is no or little interpolation. Possibly this bug in FSX only affects the GLOB settings, not all of them. If that is the case I wouldn't really have such a worry "fixing" it ("fiddling" it is probably a more apt description).

Checked at KTTN (same METAR but KTTN instead of GLOB). Same result (writing, reading, behavior, GUI all agree as layer top). See log below:

   176874 NW_CLEAR weather command received
   176874 NWI weather clear actioned
   176874 External weather discarded
   176936 Weather Mode now = Theme
   176936 Weather Mode now = Custom
   177872 Setting Metar: "KTTN 000000Z 36010KT&D1000NG 27060KT&A3000NG 15/10&A0"

   178059 Weather Read request (At Aircrft) to area 4: Lat=40.27, Lon=-74.81, Alt=66.8, Req=2
   178059 Weather Received (type 4 request, Interpolated): "????&A0 151734Z 36010KT&D1000NG 100KM&B-1500&D2021 CLR 14/09 Q1013 "
   178059 WX Received in 0 mSecs, WX request type 4, Lat=40.2730, Lon=-74.8084,Alt=66.8m
   181226 Weather Read request (Nr Station) to area 5: Lat=40.27, Lon=-74.81, Alt=0.0, Req=1
   181226 Weather Received (type 5 request, Nearest): "KTTN&A64 000000Z 36010KT&D1000NG 27060KT&A3000NG 100KM&B-1564&D2021 CLR 15/10 Q1013 @@@ 101 15 270 60 | "

Aside from the "feature" in global mode of ignoring winds aloft, in custom mode all signs point to the fact that &A should be the layer top, not base: in writing and reading the METAR, in behavior, and in FSX weather GUI. How about "NWI_SETCORRECTLY" instead? :)

[Pete Dowson]

No, I don't think it's an FSX bug.

Actually, nor do I. I think it works as it is. I'm simply not getting the same results as you report. I'm not setting weather, only reading it, but I'm judging by the METARs being read and the observations at the aircraft.

Try, for example, the "developing storms" theme. Log the weather to find the reported Metar string at your WX station. Make a note of it then stop the weather logging as it will go on and on.

In FSUIPC's logging, monitor these offsets:

0E90 U16

0E92 UA16

6020 FLT64

Check "FS Window" below.

Now slew up from ground through all the layers (there'll only be about three). Compare the winds at the aircraft (0E90/0E92) at the altitude (you have it now in metres in the message window and feet in the Shift-Z display from slew mode. See how the winds change.

Here they change as I would expect with A altitudes treated as bases, most certainly NOT with those treated as tops -- that would be way out. Only D (for "Depth" I think) is a "tops" measure, and that's from the ground altitude.

Best if you do all this testing at a sea level airport in case your discrepancy is thinking AGL as opposed to AMSL -- though I don't think that can be it, as KTTN is only about 200 feet in any case.

(Incidentally, KTTN doesn't appear to be a WX station on my system. It gives an error return from SimConnect if I try to read the weather at that station. Odd?).

Regards

Pete

[pilotjohn]

Actually, nor do I. I think it works as it is. I'm simply not getting the same results as you report. I'm not setting weather, only reading it, but I'm judging by the METARs being read and the observations at the aircraft.

Try, for example, the "developing storms" theme. Log the weather to find the reported Metar string at your WX station. Make a note of it then stop the weather logging as it will go on and on.

In FSUIPC's logging, monitor these offsets:

0E90 U16

0E92 UA16

6020 FLT64

Check "FS Window" below.

Now slew up from ground through all the layers (there'll only be about three). Compare the winds at the aircraft (0E90/0E92) at the altitude (you have it now in metres in the message window and feet in the Shift-Z display from slew mode. See how the winds change.

Here they change as I would expect with A altitudes treated as bases, most certainly NOT with those treated as tops -- that would be way out. Only D (for "Depth" I think) is a "tops" measure, and that's from the ground altitude.

Best if you do all this testing at a sea level airport in case your discrepancy is thinking AGL as opposed to AMSL -- though I don't think that can be it, as KTTN is only about 200 feet in any case.

(Incidentally, KTTN doesn't appear to be a WX station on my system. It gives an error return from SimConnect if I try to read the weather at that station. Odd?).

Regards

Pete

Odd... I'm getting different results. Using FSX Acceleration KTTN is definitely a station and has an ATIS (screenshot attached).

1. I put the plane at KTTN.

2. I loaded Developing Storms theme

3. I launched WeatherSet2 and looked the request return for KTTN

The METAR from KTTN is:

   295919 Weather Received (type 3 request, AtStation): "KTTN&A64 151850Z 22805K
T&D1057LM 227V229 22805KT&A1000LM 227V229 23206KT&A1000LG 231V234 22805KT&A1064L
M 227V229 23206KT&A1121LG 231V233 23306KT&A1124LG 231V234 23306KT&A1128LG 231V23
4 23407KT&A1188LG 233V235 23407KT&A1192LG 233V235 25015G26KT&A2000LG 249V250 250
15G26KT&A2000LG 249V250 24416G28KT&A2064LG 244V245 24416G28KT&A2128LG 244V245 32
KM&B-257&D30736 2CU048&CU004FMVN000N 8CI301&CI000FNVN000L 2CI390&CI000FMVN000N 2
4/24 24/24&A0 23/23&A1300 23/23&A1300 23/23&A1364 23/23&A1428 23/23&A1492 23/23&
A1556 22/22&A1620 22/22&A1684 22/22&A1748 21/21&A1812 21/21&A1876 Q0989 @@@ 35 2
3 228 5 | 35 23 232 6 | 37 23 228 5 | 39 23 232 6 | 39 23 233 6 | 39 23 233 6 |
41 23 234 7 | 41 23 234 7 | 68 21 250 15 | 68 21 250 15 | 70 21 244 16 | 72 21 2
44 16 | "

Let's assume they're layer tops as depicted in the FSX GUI. Then...

At 4000 feet there's a 7KT layer, and at 6600 feet, a 15KT layer, with the highest layer of 16KT at about 6800 feet.

4. I slewed to 5500 feet, and there's 11KT wind there (about right for interpolation between 4000/7 and 6600/15)

5. I slewed to 7500 feet, and there's 15KT wind there (about right for above any interpolation layer)

These wind speeds are too close together for clear testing (screenshots attached) which is why I tested with pretty obvious layers and speeds. It's odd that winds aloft would behave differently than all the other weather parameters (visibility etc.) which use upper altitude to delineate a layer. In my case and testing winds aloft behave similar to visibility layers.

[Pete Dowson]

Odd... I'm getting different results.

Looks right to me using my interpretation. these are the encoded winds in the area of your two "spot tests":

23407KT&A1192LG 233V235 5500ft = 1676 m, layer base 3900 ft = wind 233-235 at 07

25015G26KT&A2000LG 249V250 layer top is this base = 6560 feet

25015G26KT&A2000LG 249V250 two identical entries?

24416G28KT&A2064LG 244V245

24416G28KT&A2128LG 244V245 7500ft = 2286 m, 244-245 at 16-28

4. I slewed to 5500 feet, and there's 11KT wind there (about right form interpolation between 4000/7 and 6600/15)

5. I slewed to 7500 feet, and there's 15KT wind there (about right for above any interpolation layer)

Correct within normal variation, assuming the A values are bases. You should take note of wind directions too, though -- the wind speeds will be varying a lot more than the direction, even at one altitude..

That METAR you've got is like those you get when something has been setting weather via SimConnect. None of the normal weather downloads or themes ever has that many layers, and certainly not such close and even identical layers. But that certainly happens when trying to set layers -- one of the main bugs in FSX weather. If allowed to write FS weather, FSUIPC tries to rationalise and remove close and duplicate layers, because they can build up so that the METAR string exceeds its FSX limit of 2048 characters and FSX crashes.

Regards

Pete

PS why all those pix? I never doubted you had such a weather station, I just don't know why I haven;t.

[pilotjohn]

Looks right to me using my interpretation. these are the encoded winds in the area of your two "spot tests":

23407KT&A1192LG 233V235 5500ft = 1676 m, layer base 3900 ft = wind 233-235 at 07

25015G26KT&A2000LG 249V250 layer top is this base = 6560 feet

25015G26KT&A2000LG 249V250 two identical entries?

24416G28KT&A2064LG 244V245

24416G28KT&A2128LG 244V245 7500ft = 2286 m, 244-245 at 16-28

Correct within normal variation, assuming the A values are bases. You should take note of wind directions too, though -- the wind speeds will be varying a lot more than the direction, even at one altitude..

That METAR you've got is like those you get when something has been setting weather via SimConnect. None of the normal weather downloads or themes ever has that many layers, and certainly not such close and even identical layers. But that certainly happens when trying to set layers -- one of the main bugs in FSX weather. If allowed to write FS weather, FSUIPC tries to rationalise and remove close and duplicate layers, because they can build up so that the METAR string exceeds its FSX limit of 2048 characters and FSX crashes.

Regards

Pete

PS why all those pix? I never doubted you had such a weather station, I just don't know why I haven;t.

All I did was start FSX, load my default flight with KTTN set, and select the weather theme. As the flight got progressively along, the layers got more and more confusing. That's the one I grabbed after about 5-10 minutes of slewing and checking the GUI, when I finally launched WeatherSet2. Another 5-10 minutes later it was looking nastier (dynamics?). Initially they looked a little cleaner but I didn't have KTTN which is why I asked for it specifically. I included the image to make sure we're talking about the same thing when talking about a station (something that has an ATIS and shows in the weather GUI).

Well, I did some additional testing. I set the shear level to instantenous. This stopped interpolating and only provided the required wind when the altitude provided in &A is passed. This would indicate a "base" as you suggested. I'm trying to figure out the need for a surface depth then. It seems using a simple &D1 (&D0 doesn't work) for the surface layer is probably the correct approach for me as then all wind is interpolated to whatever wind aloft is at the airport elevation without having a "fixed" layer.

Thanks for sticking with my investigation.

[Pete Dowson]

Well, I did some additional testing. I set the shear level to instantenous.

Where do you do that? (Forgive me, it's actually several years since I was involved in all this weather stuff).

This stopped interpolating and only provided the required wind when the altitude provided in &A is passed. This would indicate a "base" as you suggested. I'm trying to figure out the need for a surface depth then.

Yes, I was always puzzled by that.

It seems using a simple &D1 (&D0 doesn't work) for the surface layer is probably the correct approach for me as then all wind is interpolated to whatever wind aloft is at the airport elevation without having a "fixed" layer.

Interesting that &D0 doesn't work -- it can actually be reported back in a METAR from SimConnect. But then the read-back format and write formats are different in any case, with the documentation a bit of a mish-mash of both.

Regards

Pete

[pilotjohn]

Where do you do that? (Forgive me, it's actually several years since I was involved in all this weather stuff).

The two letters at the end of a wind group provide turbulence and shear, so instead of 27060KT&A3000NG I put NI (no turbulence, instantaneous shear). I believe some of this is actually missing in your struct-to-METAR code as occasionally I've seen things like A3000G or A3000N etc. I believe two letters might be required.

Did you also notice that variance information was being sent after each wind group in that whacky KTTN METAR from the theme? You only send one, correct, even if I include variance information in other layers? Is this because it doesn't work?

[Pete Dowson]

The two letters at the end of a wind group provide turbulence and shear, so instead of 27060KT&A3000NG I put NI (no turbulence, instantaneous shear).

Oh, yes. Of course, corresponding to the shear field in the NewWind structure.

I believe some of this is actually missing in your struct-to-METAR code as occasionally I've seen things like A3000G or A3000N etc. I believe two letters might be required.

Hmm. I've never seen that -- in fact the code contains this:

n += sprintf_s(&szMetarToWrite[n], MAX_METAR_LENGTH - n, "%03d%02d%sKT%s%c%c ",
					dir, p->Wind[i].Speed, szGust, szAlt, chTurbulence[t], chShear[s]);[/CODE]

where chShear is "GMSI", and the s value is constrained to be in the range 0-3 inclusive. Can you show me any examples? Are you sure you aren't mixing the METARs being read with the ones being written?

Did you also notice that variance information was being sent after each wind group in that whacky KTTN METAR from the theme? You only send one, correct, even if I include variance information in other layers? Is this because it doesn't work?

Well, I think because it didn't work -- this is according to comments in my code, so I obviously did try it. However, we are talking about 5 years ago, and I cannot recall now whether I only tried with the RTM version or SP1 or SP2. I think SP2 because a lot of things got fixed then, but maybe, even if it worked by then, maybe I never changed it because it meant having even more messy code testing the version in use.

If you'd like to try it via the string mechanism and let me know, it would be easy enough to fix. I do have quite a lot of SP1 and SP2 only checks in these days (as well as ESP and Prepar3D versions 1, 1.1 and 1.2 -- so it's messy anyway!

Regards

Pete