Help - ASE SP2 ATIS delay to RC

[jordanal]

Pete,

I would like to refer you to a discussion and my analysis over in the AVSIM Radar Contact forum - regarding the new FSUIPC functionality of getting RC to use ASE weather - it takes too long to parse and is causing RC voice response delays in the critical approach and landing phases of the flight. A moment of your time reading the analysis would be greatly apprciated.

Happy Holidays to you and yours...

http://forum.avsim.net/topic/321640-leave-freq-for-wx/page__view__findpost__p__1897432

[Pete Dowson]

I would like to refer you to a discussion and my analysis over in the AVSIM Radar Contact forum - regarding the new FSUIPC functionality of getting RC to use ASE weather - it takes too long to parse and is causing RC voice response delays in the critical approach and landing phases of the flight. A moment of your time reading the analysis would be greatly apprciated.

I'd rather do support for my products here.

I'm not sure where your delay is coming from, but I have both RC and ASE on a separate WidClient PC and there's no noticeable difference now from before. When RC asks for the weather for a particular location, FSUIPC asks ASE for it, and updates it in FSUIPC offsets withing a second or two.

Altogether that's 4 transfers over the network for each request. But they never amount to more than a couple of seconds. Since RC is supposed to allow at least 10 seconds to answer any request I'd be amazed if that timeout was ever exceeded. It would mean that your ASE program was simply not getting adequate processor time.

What RC sees is EXACTLY the same as it always has been. The DWC/ASE linkup in entirely a matter between FSUIPC and ASE. FSUIPC would otherwise read the weather from SimConnect -- and depending on how busy FSX is, that can take a second or so too. You are way off beam in your speculation about some sort of "weather parsing". If you have delays on your system it is because something isn't being able to run adequately and/or, if networked, your network is running badly.

I seem to recall that BEFORE the new facilities, allowing use of DWC with correct weather, folks were saying use of DWC slowed RC down intolerably, and the advice I saw on the RC forum was to turn DWC off. Maybe this is what you are seeing, not the result of any new facilities! You could easily check by setting the UseASEweather parameter to 'No'. Didn't you think of that?

From other reports I've seen, ASE SP2 along with these new facilities have made things for most RC users more responsive, not less. So something would seem to be wrong on your set-up.

Regards

Pete

[jordanal]

What I've been able to figure out is, if I use the ASE "Standard" mode without the new "UseASEWeather" switch (UseASEWeather=No) in the FSUIPC.ini file, then all is well and RC acts as before SP2 (including poor arrival ATIS reports for RC). But, if I change the switch to "UseASEWeather=Yes" while still in ASE Standard mode, then I get the exact same delayed responses in RC that we had all seen while using ASE in DWC mode. So, using Standard mode with the new switch causes RC (slow response) delays as well. This is with ASE running on my Simconnect-Client/WideClient PC and I get the same slow responses from Radar Contact whether I run it on the Client or directly on the FSX PC. I have also tried reinstalling ASE with the original ASE full installer and just the SP2 update to no avail - same symptoms.

From what I have seen, DWC mode looks good and I'd really like to use it with RC like others seem to be - but, I'm racking my brain trying to figure out why I might be seeing the opposite results.

I have two zips of ASE, FSUIPC, and WideFS logs, one for each Standard scenario (with and without the new FSUIPC UseASEWeather switch). As you can see in the logs, FSX and simmconnect work fine, just as they always have - I just can't figure out why the the new UseASEWeather switch would give me slow DWC-like RC symptoms.

Al Jordan - ASE Standard Mode with UseASEWeather.zip

Al Jordan - ASE Standard Mode without UseASEWeather.zip

[Pete Dowson]

What I've been able to figure out is, if I use the ASE "Standard" mode without the new "UseASEWeather" switch (UseASEWeather=No) in the FSUIPC.ini file, then all is well and RC acts as before SP2 (including poor arrival ATIS reports for RC). But, if I change the switch to "UseASEWeather=Yes" while still in ASE Standard mode, then I get the exact same delayed responses in RC that we had all seen while using ASE in DWC mode. So, using Standard mode with the new switch causes RC (slow response) delays as well.

It is bound to be the same as forcing it on with "UseASEWeather=Yes" makes it operate in both DWC and standard modes. Omit the parameter to only have it working in DWC mode.

I have two zips of ASE, FSUIPC, and WideFS logs, one for each Standard scenario (with and without the new FSUIPC UseASEWeather switch). As you can see in the logs, FSX and simmconnect work fine, just as they always have - I just can't figure out why the the new UseASEWeather switch would give me slow DWC-like RC symptoms.

No idea why it affects your system differently, but, as I pointed out, the ASE route to get whether involved FSUIPC receiving the request from RC, sending it to ASE, getting the data back (as a SimConnect-style METAR string, decoding it, and then indicating its availability to RC (or anyone else). In all tests here this takes less than 1 or 2 seconds. When ASE is not being asked, FSUIPC requests it direct from SimConnect, which is bound to be a little faster. But since RC should be allowing up to 10 seconds to get an answer. Since you should be getting your destination weather 70-80 nm out. I really don't see why such a small delay should be a problem affecting anything to do with your approach.

What am I supposed to be looking for in all that stuff you uploaded, by the way? Isn't is RC's logging you need, for analysing by JD instead?

Regards

Pete

[jordanal]

It is bound to be the same as forcing it on with "UseASEWeather=Yes" makes it operate in both DWC and standard modes. Omit the parameter to only have it working in DWC mode.

No idea why it affects your system differently, but, as I pointed out, the ASE route to get whether involved FSUIPC receiving the request from RC, sending it to ASE, getting the data back (as a SimConnect-style METAR string, decoding it, and then indicating its availability to RC (or anyone else). In all tests here this takes less than 1 or 2 seconds. When ASE is not being asked, FSUIPC requests it direct from SimConnect, which is bound to be a little faster. But since RC should be allowing up to 10 seconds to get an answer. Since you should be getting your destination weather 70-80 nm out. I really don't see why such a small delay should be a problem affecting anything to do with your approach.

What am I supposed to be looking for in all that stuff you uploaded, by the way? Isn't is RC's logging you need, for analysing by JD instead?

Regards

Pete

Hi Pete,

I had some further analysis and e-mail conversations with JD at Radar Contact yesterday involving RC logs, and some different ASE scenarios. It turns out, I not only get the controller response delay (slows) during approach and landing, but also when I contact the ground-controller for my departure runway assignment (another weather related response within RC). Having a saved RC flight (saved just pior to contacting ground), with ASE in standard mode and UseASEweather=no, requesting and receiving a departure runway takes less than 2 seconds. If ASE is running in DWC mode (Global), or in any other mode with UseASEweather=yes in the FSUIPC.ini file, then that sequence of contacting ground and getting a runway now takes almost 12 seconds. It seems that when communication between RC & FSUIPC involves any whether related decision, the response time becomes much more lengthy if ASE is involved. Again, this becomes critical when on final approach and instead of getting the cleared to land 5nm from touchdown, you don't get cleared until you're 50ft over the threashold, or even later after you've already touched down. The other weather related 'slow' response is when the approach controller is determinig the best approach at about 50nm out. So you see, it is during all three weather related reponses in RC, that it becomes 'slow'. Again, this is with ASE in global mode or with the UseASEwhether=yes switch.

I tried to take a 'weather' log in FSUPC yesteday to see if there was any hint of this delay between RC, FSUIPC, and ASE when contacting ground (during a weather related controller call). But it didn't reveal much of anthing besides weather stations.

How can I log what FSUIPC is doing once it receives a weather request from RC?

[Pete Dowson]

Having a saved RC flight (saved just pior to contacting ground), with ASE in standard mode and UseASEweather=no, requesting and receiving a departure runway takes less than 2 seconds. If ASE is running in DWC mode (Global), or in any other mode with UseASEweather=yes in the FSUIPC.ini file, then that sequence of contacting ground and getting a runway now takes almost 12 seconds. It seems that when communication between RC & FSUIPC involves any whether related decision, the response time becomes much more lengthy if ASE is involved.

I would expect the time to double -- 2 secs to, sa,y 4, because there are twice as many interactions involved. But to get to as long as 12 seconds it sounds like something in your specific setup is stopping one of the several processes involved actually running for several seconds at a time, or at least denying it processor time for such a time.

Again, this becomes critical when on final approach and instead of getting the cleared to land 5nm from touchdown

What on Earth are you doing asking for ATIS on final approach? You should get that 60-80 miles out!!!

you don't get cleared until you're 50ft over the threashold, or even later after you've already touched down. The other weather related 'slow' response is when the approach controller is determinig the best approach at about 50nm out. So you see, it is during all three weather related reponses in RC, that it becomes 'slow'. Again, this is with ASE in global mode or with the UseASEwhether=yes switch.

Once FSUIPC has got the weather for the destination is simply keeps it updated automatically unless someone requests weather for someplace different. THAT would certainly cause a longer delay, especially if the other requester was keeping RC locked out for the timeout (12 seconds!). If you have something else running which is asking FSUIPC for weather for a different location that would most certainly explain delays no matter what ASE was doing.

Otherwise, once the weather has been requested by RC for a specific place there is no difference to RC whether FSUIPC is getting it from ASE or where, because RC will just retrieve the weather FSUIPC last obtained at any time before.

RC does NOT need to get the METAR weather for an airport except to answer ATIS requests (which you don't do on finals), and possibly to determine runway in use should its requests for runway data being used by AI traffic not provide that data. It will certainly NEVER EVER need to get the METAR weather for the airport you are on final approach to. All it is reading then is current wind and pressure data which is available to read directly in standard offsets which have been the same since FS98 days.

How can I log what FSUIPC is doing once it receives a weather request from RC?

Add lines to the [General] section of the INI file:

LogExtras=x8000

TestOptions=x2000

Debug=Please

The first line will log all the requests for weather at a station and at Lat/Lons, and the results. The initial request is logged with a line starting ### NWIR ### Weather Read Req.

The second line will also log the exchanges with ASE.

Regards

Pete