Clear Weather - How long to wait?

[JarangMandi]

Pete,

Following on from this thread, development is well under way and I'm (almost) happily writing weather to both FS9 and FSX from the same program.

Something I've come across where the behaviour in FS9 and FSX appears to be quite different though is the behaviour in response to a "CLEAR WEATHER" command. The SDK suggests leaving a "a little delay afterwards" and whilst FS9 always seems happy with a 2 second delay (I've not tried shorter) the behaviour I'm seeing in FSX by examining the FSUIPC weather logs suggests that the time taken to complete the command (on my system at least) is on average around 1.5 seconds but has been seen to reach in excess of 4 seconds with the result the desired weather that has been set at specific stations in the meantime is being overwritten.

Do you know of a hard and fast rule that says how long I should wait? Is there something in the FSUIPC interface that says that processing of a clear weather command has completed (as opposed to having been written to FS as indicated by offset 0xC824)?

As an aside, to be able to distribute this program (when it's complete), is the process still to e-mail you for a code so that it will work with unregistered versions of FSUIPC?

Thanks,

Andy

[Pete Dowson]

I'm seeing in FSX by examining the FSUIPC weather logs suggests that the time taken to complete the command (on my system at least) is on average around 1.5 seconds but has been seen to reach in excess of 4 seconds ...

There is actually no way to clear the weather directly in FSX. FSUIPC does it by selecting the "clear weather" theme, as you can in the Weather menu, and also setting a default clear weather Metar as the default "global" weather. How long it then takes FSX to alter all the weather stations which have currently got local weather is a variable, I have no idea how long that would take. however, it should start from the local ones, so it shouldn't be a long long time.

with the result the desired weather that has been set at specific stations in the meantime is being overwritten.

Eroverwritten with what, exactly? The sequence sent to FSX would be in the correct order. I don't see how or why it should disregard later weather settings in favour of, what, "CLEAR WEATHER"?

Do you know of a hard and fast rule that says how long I should wait? Is there something in the FSUIPC interface that says that processing of a clear weather command has completed (as opposed to having been written to FS as indicated by offset 0xC824)?

FSUIPC merely sends the commands to FSX. It has no way of knowing what FSX is then doing. SimConnect must be processing the commands it receives in the order they arrive. I've no idea how stuff from an earlier command can take precedence over a later one. I've never seen that.

As an aside, to be able to distribute this program (when it's complete), is the process still to e-mail you for a code so that it will work with unregistered versions of FSUIPC?

You should email me, yes. Is it freeware?

Regards

Pete

[JarangMandi]

Thanks (again) for the quick reply Pete.

Eroverwritten with what, exactly? The sequence sent to FSX would be in the correct order. I don't see how or why it should disregard later weather settings in favour of, what, "CLEAR WEATHER"?

Yes - clear weather! In fact, depending on how long it takes to process the "clear weather" command, I'm seeing the commanded weather, albeit fleetingly. The FSUIPC log snippet below seems to support this - although you're obviously in a much better position to interpret it than I.

   455766 NW_DYNAMICS command, setting weather dynamics = 0
   455922 NW_CLEAR weather command received
   457078 Weather Read request (At Aircrft) to area 4: Lat=47.44, Lon=-122.31, Alt=133.1, Req=2
   457094 Weather Received (type 4 request, Interpolated): "????&A0 071952Z 24805G06KT&D1000NG 16KM&B-318&D3500 8ST012&ST000FLMR000N 6CU027&CU000FMLR000N 5CI299&CI000FNVN000N 11/10 Q1009 "
   457094 WX Received in 16 mSecs, WX request type 4, Lat=47.4382, Lon=-122.3112, Alt=133.1m
   458000 NW_SETEXACT weather command received, ICAO=GLOB
   458000 >NewSet:  **** New Weather being set: ICAO=GLOB (Dyn=0)
   458000 >NewSet:  Pressure=1013.0, Drift=0.0
   458000 >NewSet:  Visibility[0]: range=62.5sm (100584m), from=-1040ft, to=8960ft
   458000 >NewSet:  Temperature[0]: alt=430ft, Day=14 C, NightVar=0 C, DewPt=4 C
   458000 >NewSet:  Surface wind: to alt=6990ft AMSL, dir=0T, vel=0.00, gust=0.0, turb=0, shear=0, var=0.0
   458000 >NewSet:  Wind layer 1: to alt=20115ft AMSL, dir=270T, vel=20.0, gust=0.0, turb=0, shear=0, var=0.0
   458000 >NewSet:  Wind layer 2: to alt=23114ft AMSL, dir=270T, vel=25.0, gust=0.0, turb=0, shear=0, var=0.0
   458000 >NewSet:  Cloud[0]: type=9, from 6000ft to 0ft (+/- 0ft), cover=2, turb=0, topshape=0
   458000 >NewSet:                      Precip=0, base=0ft, rate=2, icing=0
   458000 >NewSet:  Cloud[1]: type=1, from 39700ft to 0ft (+/- 0ft), cover=6, turb=0, topshape=0
   458000 >NewSet:                      Precip=0, base=0ft, rate=2, icing=0
   458000 >NewSet:  **** End of New Weather details for ICAO=GLOB
   458000 Setting Weather: "GLOB 071952Z 00000KT&D2131NG 27020KT&A2131NG 27025KT&A6131NG 101KM&B-318&D3048 2CU060&CU-59FNMN000N 6CI397&CI-396FNMN000N 14/04&A131 Q1013 "
   458219 NW_SETEXACT weather command received, ICAO=KSEA
   458219 >NewSet:  **** New Weather being set: ICAO=KSEA (Dyn=0)
   458219 >NewSet:  Pressure=1009.0, Drift=0.0
   458219 >NewSet:  Visibility[0]: range=10.0sm (16093m), from=-1040ft, to=10440ft
   458219 >NewSet:  Temperature[0]: alt=430ft, Day=12 C, NightVar=0 C, DewPt=11 C
   458219 >NewSet:  Temperature[1]: alt=3710ft, Day=7 C, NightVar=0 C, DewPt=5 C
   458219 >NewSet:  Surface wind: to alt=3710ft AMSL, dir=248T, vel=5.00, gust=1.0, turb=0, shear=0, var=0.0
   458219 >NewSet:  Wind layer 1: to alt=6710ft AMSL, dir=135T, vel=20.0, gust=0.0, turb=0, shear=0, var=0.0
   458219 >NewSet:  Cloud[0]: type=8, from 1200ft to 0ft (+/- 0ft), cover=8, turb=0, topshape=0
   458219 >NewSet:                      Precip=1, base=0ft, rate=2, icing=0
   458219 >NewSet:  Cloud[1]: type=9, from 2700ft to 0ft (+/- 0ft), cover=6, turb=0, topshape=0
   458219 >NewSet:                      Precip=1, base=0ft, rate=1, icing=0
   458219 >NewSet:  Cloud[2]: type=1, from 29900ft to 0ft (+/- 0ft), cover=5, turb=0, topshape=0
   458219 >NewSet:                      Precip=0, base=0ft, rate=0, icing=0
   458219 >NewSet:  **** End of New Weather details for ICAO=KSEA
   458219 Setting Weather: "KSEA 071952Z 24805G06KT&D1000NG 13520KT&A1000NG 16KM&B-449&D3500 8ST008&ST-11FNMR000N 6CU023&CU-26FNLR000N 5CI295&CI-298FNVN000N 12/11&A0 07/05&A1000 Q1009 "
   459391 Weather Read request (Nr Station) to area 5: Lat=47.44, Lon=-122.31, Alt=0.0, Req=1
   459391 Weather Received (type 5 request, Nearest): "KSEA&A131 071952Z 24805G06KT&D1000NG 13520KT&A1000NG 16KM&B-449&D3500 8ST008&ST000FLMR000N 6CU023&CU000FMLR000N 5CI295&CI000FNVN000N 12/11 07/05&A1000 Q1009 @@@ 37 7 135 20 | "
   459391 WX Received in 0 mSecs, WX request type 5, Lat=47.4382, Lon=-122.3112, Alt=0.0m
   459391 NWI weather clear actioned

My interpretation of this is that the NW_CLEAR command issued at timestamp 455922 completes at timestamp 459391; when it is actually issued to FSX is unclear from this. In the meantime, I've waited for the timestamp at 0xC824 to change per the SDK, and issued a set for "GLOB" and "KSEA" weather stations which appear to be being sent to FSX at timestamps 458000 and 458219 respectively. The unfortunate effect of the NWI weather clear being actioned at 459391 is that it wipes out the effects of those two writes.

The corresponding section of the SimConnect log reads as follows...

> 456.50588 [65, 2566]WeatherSetDynamicUpdateRate:dwRate=1
> 456.64784 [65, 2567]RequestSystemState:RequestID=1, szState="Sim"
> 457.81453 [65, 2568]WeatherRequestInterpolatedObservation:RequestID=-1073741785, lat=47.438221, lon=-122.311234, alt=133.113525
> 458.73672 [65, 2569]WeatherSetObservation:Seconds=0, szMETAR="GLOB 071952Z 00000KT&D2131NG 27020KT&A2131NG 27025KT&A6131NG 101KM&B-318&D3048 2CU060&CU-59FNMN000N 6CI397&CI-396FNMN000N 14/04&A131 Q1013 "
> 458.94958 [65, 2570]WeatherSetObservation:Seconds=0, szMETAR="KSEA 071952Z 24805G06KT&D1000NG 13520KT&A1000NG 16KM&B-449&D3500 8ST008&ST-11FNMR000N 6CU023&CU-26FNLR000N 5CI295&CI-298FNVN000N 12/11&A0 07/05&A1000 Q1009 "
> 459.21395 [65, 2571]RequestSystemState:RequestID=1, szState="Sim"
> 460.12344 [65, 2572]WeatherRequestObservationAtNearestStation:RequestID=-805306328, lat=47.438221, lon=-122.311234
> 460.12697 [65, 2573]WeatherSetModeTheme:szThemeName=""
> 460.16783 [65, 2574]WeatherSetModeCustom:

This would appear to suggest that the clear weather theme is being commanded after the weather has been set. Is my interpretation correct?

Is it freeware?

It will be, yes - distributed to members of the Bristol Flight Simulator Group. I'll e-mail you offline about this.

Regards

Andy

[Pete Dowson]

   455922 NW_CLEAR weather command received
  ...
   459391 NWI weather clear actioned

Ah! Now i understand ...

... all this is very complicated, and a lot of it is, i think, a hangover from FS9 which may not be needed now.

Currently the NW_CLEAR request merely sets a flag which is actioned on the next interpolated weather scan. And that is partially determined by a user parameter and partly by things like frame rates. The implementation was a necessity on FSUIPC3 because trying to call the "clear weather" routine in the Weather DLL asynchronously could ceash FS9.

The "NWI weather clear actioned" message is in fact the time where the flag is noticed and the clear action undertaken.

I've checked, and what has changed in some recent version (several months ago at least -- early this year in fact) is that, unless you actually opt to have FSUIPC try to filter FSX's weather, the interpolated weather scanning is quite infrequent -- the 3-5 seconds you see in this log is quite typical in fact with the default options.

Sorry, when i reduced the frequency this side effect never occurred to me. In fact I don't really think all this delay / flag setting / action later is needed in FSX. I shall have a look at that code and see if i can sort it out. It's just never come up before as being a problem, it seems. I'll get back to you tomorrow or at least before the end of the week.

Regards

Pete

[Pete Dowson]

... the 3-5 seconds you see in this log is quite typical in fact with the default options.

After checking, in fact the cycle time, default, appears to be 8 seconds, so on average there would be a 4 second delay, but it could be as much as 8 seconds.

However, having looked at it now i am reasonably sure there is no reason at all that it needs to be delayed to the next local weather update (scan to populate the offsets). so, I've made some small changes and tested them, and i can get an instant clear weather response now. i don't think there are likely to be any unwanted consequences, but the version of FSUIPC4 I'm working on has a lot of other changes which I'm still testing and which are completely undocumented, so I'm not going to make a general release yet. However, by all means download and try 4.311 using the following link:

http://fsuipc.simflight.com/beta/FSUIPC4311.zip

Let me know.

Regards

Pete

[JarangMandi]

Thanks Pete,

I'll try it out when I get home from the day job.

Andy

[JarangMandi]

Pete,

I've just spotted when you made those posts... don't you ever sleep?! The level of support you provide is second to none. Thank you.

I've tried the new version that you posted the link to, and it all seems to work fine for me with no apparent side effects other than being able to set the weather much more quickly now. The logs are reporting that the clear weather command is being actioned on receipt too so all seems well.

Thanks again,

Andy

[Pete Dowson]

I've tried the new version that you posted the link to, and it all seems to work fine for me with no apparent side effects other than being able to set the weather much more quickly now. The logs are reporting that the clear weather command is being actioned on receipt too so all seems well.

Good.

I'll not be making a full new User release till something like mid-October, but i'll try to post a version with this change up on the "FSX Downloads" announcement within the next week or so, before I'm off on a short break! ;-)

Regards

Pete

[JarangMandi]

Pete,

Just to make sure... I'm assuming that the changes you made in the 4311 file have made it into the latest beta - which at present stands at 4322 if I'm understanding things correctly. I just don't recognise the changes in the text description that accompanies the 4322 file.

Also, I think I've come across a problem where there's a difference between the way that precipitation intensity is returned from FS9 and FSX versions of FSUIPC. FS9 appears to return a number between 0 and 5 - with 0 for "no precipitation" in conjunction with the same setting in precipitation type, whereas FSX seems to return a number between 0 and 4 - with 0 for "very light". I'm not 100% sure of this yet and plan to investigate further this week, but is it something you can take a quick look at?

Thanks,

Andy

[Pete Dowson]

Just to make sure... I'm assuming that the changes you made in the 4311 file have made it into the latest beta - which at present stands at 4322 if I'm understanding things correctly.

I don't take changes out once they're in unless they don't work or are not required. anything in and working in 4.311 will be in and working in any version > 4.311 too.

I just don't recognise the changes in the text description that accompanies the 4322 file.

Ah, sorry. I might have forgotten to mention it. It was a pretty trivial change and didn't change the way things worked for anyone else.

Also, I think I've come across a problem where there's a difference between the way that precipitation intensity is returned from FS9 and FSX versions of FSUIPC. FS9 appears to return a number between 0 and 5 - with 0 for "no precipitation" in conjunction with the same setting in precipitation type, whereas FSX seems to return a number between 0 and 4 - with 0 for "very light". I'm not 100% sure of this yet and plan to investigate further this week, but is it something you can take a quick look at?

I'm really not sure what either of them do in this area without ploughing through the code. Are you saying you want FSUIPC4 to add 1 to this is the precipitation type is set for rain or snow? What about setting the rain or snow? Is that consistent?

I have to decode/encode the METAR reports for FSX, so it isn't a simple matter for me to look at without more data. Nevertheless i will take a look. It might help if you have so METAR strings (from the relevant FSUIPC4 offset) and the corresponding Cloud records to compare. A weather log extract (Weather logging in FSUIPC's Logging page) would be adequate.

[LATER]

Okay, forget the logging. I see what you mean. It IS actually consistent reading and writing, which is what matters most, and why it's done no harm to date.

The problem arises from the fact that the FSX METAR extension coding for Clouds has a 5 precipitation level sequence starting with "V" for "very light", but no rate value for "none". Weird. Here:

P - Precipitation, one of: V (very light), L (light), M (moderate), H (heavy) D (dense)

Q - Type of precipitation, one of: N (none), R (rain), F (freezing rain), H (hail), S (snow)

The precipitation type encoding does have "N" for none, so I'll use that to re-encode/decode the zero precipitation case, moving the real ones up one.

Note that the type encoding goes up to 4, but for FS9 compatibility i encode N= 0, R = 1, S = 2, F = 3 and H = 4, rather than the order FSX gives them.

The rate value will be fixed in 4.323, uploading later today.

Regards

Pete

[Pete Dowson]

The rate value will be fixed in 4.323, uploading later today.

Okay, it is there now.

Pete

[JarangMandi]

Okay, it is there now.

Pete

Got it Pete, and it appears to have resolved the inconsistency between the FS9 and FSX interface.

Thanks!