kterz

Hi, wake turbulence encounters are logged by ASN (providing also some useful details). So you can find details in the log file coming up from the session you need to clarify what happened. In addition, watching the ASN map (zoomed in significantly), you can see if any wake trails are present in the aircraft path. Remember that wake trails tend to "live" longer when wind is calm (they may reach 120 seconds or more). They also drift with the wind, so you may find them in places not expected. ASN creates wake trails by reading the data of other aircraft. If these data are not correct (e.g. the speed or whether the aircraft is on the ground), then erroneous wake turbulence may come up. We've extensively tested this with the default FSX AIs and some multiplayer clients, but I have seen reports of issues coming more often in relation to multiplayer. Keeping an eye on ASN map will help clarify all this (if any data are wrong). Please provide to us all these details, so that we can figure out if something is wrong and fix it. Thanks,

Hi, I have to jump in here because we've had several reports of this happening with ASN (due to the way ASN reduces visibility in cloud). As already discussed, this is not ASN related (or any wx engine or aircraft specific) and it is coming up only in low visibility conditions. In most cases this was due to the use of custom shaders (like custom Bojote's shaders 3.0). Reverting to stock shaders (and/or clearing the shaders cache after that) has resolved the problem in all cases I've been aware of. Hope this helps.

Hi, where is your dll.xml file located? It should be placed in: \\DRAGON-PC\AppData\Roaming\Lockheed Martin\Prepar3D v2 If it's there, can you upload it (or open it with Notepad and copy paste its contents)? Of course, I'd prefer all this to be made through our support system (please open up a support ticket on http://support.hifitechinc.com/) Thanks,

Hi, This is a known issue and has been (partially) resolved for some users. Please follow this thread on our forums: http://www.hifitechinc.com/forums/showthread.php?2823-ASN-P3Dv2-1-Simconnect-doesn-t for more information Thanks, EDIT: Correction. The issue reported here doesn't seem to be related to SimConnect. It seems like a file access issue. How have you verified that access is granted to: '\\DRAGON-PC\AppData\Roaming\Lockheed Martin\Prepar3D v2\dll.xml.ASbackup' from your client PC. Have you actually tried to access the folder through explorer (on the client machine) and you have tried to delete/rename/edit any file there?

Hi Gary, Subscribing to a navdata provider is not in our current plans. I don't say we will not in the future, but it's not within the current scope of the application. The easiest thing in your case would be to suggest to PFPX devs to export a flight plan version that will include SID/STAR points. AFAIK FsBuild for example already does this and its usefulness might go beyond just using the plans with ASN.

Hi all, this is a very interesting discussion. What is noticeable from the 2 videos is the constant changes in the angle of attack (due to the turbulence obviously). It might be worth rechecking the same scenario with the option "enhance turbulence" unchecked in ASN options. Second, at least in the second video there was a storm and depending on precipitation rate (and winds and terrain etc), ASN constantly adjusts the updraft downdraft ratio. It seems to me that in this approach you may have been in a constant 300 to 400 fpm downdraft situation. You can also check this using ASN debug window (look for a negative VS there). I am not talking about windshear here. Just pure precip related downdraft. You can set the max downdraft rate to zero in ASN settings and retest this scenario. One other thing I've noticed is that several aircrafts behave differently in the case of a downdraft, but in most cases you get a pitch up attitude change (it's part of the aircraft "self balance" design). I don't know if this is related to the response of the AT in the T7, but it makes sense that the aircraft may try to compensate for restoring stability and balance, while ASN tries to "destroy" it in the first place

Hi, As far as I understand this, the issue is that during the export PFPX doesn't include in the exported file the way points included in the SID/STAR. IMO, this is the correct thing to do. AFAIK, a flight plan most of the times is designed with the SID or STAR excluded, because these are in RL assigned by the controller depending on the weather, active runway etc. Then the actual SID/STAR can directly be inserted to the aircraft CDU once the clearance is given, but it isn't needed for them to be part of the flight plan per se. ASN is not a dedicated flight planner tool, nor you gain anything in particular by manually adding the SID/STAR waypoints one by one to it. ASN is a weather tool designed to provide and calculate an approximation of the winds and weather conditions along the route. And that's the main use of loading a flight plan to ASN (in addition to improving weather accuracy on the main stations selected and affected, that is the dep/dest/alternate airports). Having said that I recognize that in some cases some STARs are more than 200 nm long and having ASN drawing a direct line between the airport and the first transition point is suboptimal. We'll think about ways of improving this moving forward. Thanks,

Hi, I may have missed the issue here, but why didn't you just enter "FL380" (or 380 or 38000) in the cruising altitude text box in ASN and then click refresh? I mean after loading the original plan you mentioned in the OP. Can you also attach the pln file exported by PPFX? (or open it with notepad and paste here in a code section the text) Thanks,

Hi Max, let's clarify some things: - 75SM is the maximum default allowable surface visibility. It doesn't mean that it will be 75 on the ground all them time (with a metar saying '9999' or '10SM'). It will be at least 10SM and at most 75SM. How much the visibility actually extends (I repeat when on ground or close to the ground), is calculated based on atmospheric conditions, the presence of temperature inversion layers, winds etc to approximate what happens in real life as closely as possible. The same thing happened with AS2012, the algorithms however used for this were different (now they are more sophisticated). - Your problem is when at altitude (like in your screenshot). In this case the upper visibility is in effect. By default this is 150 and maxes out to 200. Checking the auto calculate upper visibility option, will make attempt ASN to vary this according to current conditions (creating a more hazy environment during summer, when the temperatures are higher, the atmosphere is more stable etc). So it's the upper visibility option you should experiment with. Try setting this to 200 (and uncheck the "auto adjust upper visibility" option), then set it to 100, then to 60, in order to get a balanced acceptable depiction (on what is clearly caused by a LOD issue).

Hi Tom, I said that your comment is inaccurate because it was only partially correct. You present ASN as just using themes. But, ASN in addition to the themes, knows the exact cloud sprite positions inside a theme cell (even if they are few- scattered or broken) and that's the main difference. The video I linked above using ASN provided cloud/precip data for their radar clearly demonstrates that. What also proves this statement is using our map (in detail mode) and zooming closely to 20 miles range for example. You'll see the exact cloud sprite positions with a resolution much higher than that of a single "cell", even if the clouds are few or scattered in this case. The accuracy of knowing the exact cloud sprites inside a theme cell is what makes adjusting various ambient parameters much more accurate. For example completely avoiding the rain out of nowhere issue, or adjusting the precipitation rate, downdrafts/updrafts (since these are also directly controlled) based on the exact thickness and precipitation load of the cloud sprites directly above the aircraft. (see this draft video I made back in September where the increase in precipitation rate is demonstrated while the clouds move with the wind to the SE and the storm cell enters the area above the aircraft like in real life) What you noticed (about turbulence close to CBs but also outside of them), is done in purpose, because this is what happens in real life and we simulate t-storm avoidance procedures extremely accurately (including the rules about the overflying safety altitude margin). Tom, there are no miracles in computer science. If you see the data (clouds in this case) inside your sim, then it's somewhere in memory and it can be read. It's just a matter of having the technical competence and giving yourself enough time (months) and patience being dedicated to your goal. So, once again I invite you to take a (closer this time) look at ASN and what it offers This thread is not of course about ASN or about weather engines in general. It's about a realistic weather radar and what is required to achieve this in fsx. Using "wx theme cell" resolution is simply not enough for this. A combination of accurate precip load localization with a combination of direct ambient precip/turbulence/shear control is needed so that a realistic wx radar (including predictive wind shear functionality) can be realized. And that's exactly what ASN offers right now out of the box. Kostas PS: A small (technical) correction. You repeat yourself that a cell is 16x16 km. This is not true. The cloud model used to "fill" the cell is 16x16 km and then it scales up or down. The length of the cell in the latitude axis is about 19500 meters, while in the longitude axis varies according to the present aircraft latitude and may be as large as ~26000 meters in the equator while shrinking as latitudes become more extreme. This is one of the known fsx 2d-3d conversion restrictions. This will become evident if you move to the southern pole (since it's day now) and load up the weather (whatever weather you like). The results will be simply... funny. And... no, ASN can't fix this too

Hi Ed, I agree with you in general. it depends on the depth of simulation you want to achieve and the definition of "accurate weather radar". If you want to simulate all features included in modern on board radar equipments (like setting tilt values, multiscanning, predictive windshear systems, turbulence etc), then no it's not possible. At least without the help of a weather engine behaving as an intermediate layer between fsx and the aircraft itself. This is the case with the way fsx is coded. The weather radar is tightly coupled to the weather itself (and this is the way it should be, if we want to elevate realism to a level where it actually makes sense for the simmer to use it). ASN already provides all this and actually exposes API functionality for aircraft (or other) developers to take advantage of this (and this is already in progress by some of them, e.g. look at this). And yes this required low level code techniques to achieve ("hacking" to use your words) and months of work to reach to this level.

Hi Tom, your linked post contains some inaccuracies (the information about how ASN works). You're welcomed to give our trial a go in order to see in action how ASN behaves in relation to CBs, radar depiction, cloud tops, hail simulation, cloud turbulence, t-storm related drafts, precip localization etc. Or watch the various videos demonstrating ASN achieving now what you consider impossible. Thanks!

Hi, take a look at this: http://www.hifitechinc.com/forums/showthread.php?2525-Disappearing-Clouds-seems-to-be-solved

Hi, Can you reproduce this without ASN running? I mean using fsx manual weather, set up an overcast layer, then slew up to 20000 feet or more and see if the clouds disappear. This issue happens some times when the shaders are not properly cleaned up, or if you use custom shaders that your graphics card doesn't like. BTW: ASN overrides the cloud draw distance value set to fsx.cfg. Set it through the ASN app (gives you more options). But do this after performing the no-ASN check I propose above. Thanks,

Hello to all, First of all read the forum rules here: http://forum.avsim.net/topic/384751-forum-rules/ I'd like to clarify that we're finalizing some changes in the way ASN handles radar data communication, minimizing disk access among other things. These changes have been included in the upcoming hotfix we're preparing and will be released in the following days. Just FYI, this had only partial success as to the freezes/stutters issues for certain users, since this problem is multifactorial and not only related to the way ASN works. Any user experiencing such issues, is welcome to open up a support ticket and we'll provide to him early releases. This way helps us keep track of the feedback and provide personalized support in a better way Thanks for your support! Kostas PS: Selecting to go public posting here (multiple times) directly hurting the product's reputation, instead of using our own support ticket system (that will most probably solve the issue), not signing with a real name, hmmm... interesting... Let's make a poll: When is the exact point where it's ethical for a moderator to start... moderating forum posts?

Hi David, May I ask why do you want to remove it? Do you have any issues with it? as_audio.exe as explained is needed for ASN audio functionality. It starts up when fsx starts up and just stays there waiting for a signal from the main ASN application (consuming zero CPU cycles in between). If no signal is given it just stays there and "kills itself" upon fsx exit. You may ask yourself why this has been designed as a separate executable. The reason is that this way it has its own process address space and this way does not affect in any way fsx VAS. We could incorporate this functionality inside our "in process" modules and then you wouldn't even be able to notice it (and it would adversely affect fsx VAS). As for not using it, I'd suggest you leave it there and leave the wind shear aural alert on, otherwise you will not use ASN at its full potential (and next time you fly an approach into a thunderstorm you will wonder why "my airspeed increased on approach" and/or "why I have wind shifts"). Thanks,

Hi Mark, t-storm cells in the tropical zone are the ones with the tendency to go up to extreme flight levels. ASN simulates just this: The "tops" of the cells in tropical zones (and depending on how unstable the atmosphere is) go higher. Also please note, that the actual "echo tops" in the non detailed map view (if the aircraft is not close) is an approximation of what you'll find ahead of you, when you actually fly into this area. You have to get there to see the actual depiction (both in map detail view and in the sim). Finally, a thunderstorm may have "cores" that go up to extreme levels (ASN can make the tops go up to ~55000 feet), but the "bulk" of the clouds will be much lower (at about 30-35000 feet). That doesn't mean that overflying (at let's say 37000 feet) such a cloud is a safe procedure. There are rules followed in these situations in RL and ASN has modelled all the related aviation hazards, if someone does not follow these rules. In particular, you'll notice (especially if you have your download set to <= 10 minutes) how these t-storm cells become "alive". How the various cells build themselves moving around and while you may have planned to go through an alley, by the time you reach there, you may find yourself in the middle of the thunderstorm. As always, we are open to suggestions on how to make this even more engaging. Thanks for your feedback,

Hi, open up a support ticket (using your trial licence key) and we can figure things out (resetting the trial period if needed). Thanks,

Hi, sorry for the inconvenience. What language is your win7 version? We've identified a possible issue with international versions of Windows leading to the issue you have. What's your support ticket number? We can follow this there (I can give you a test build that probably solves the issue you have). Thanks,

Don't forget, that ASE adds at 200 feet an overcast layer when conditions are foggy and the relative option is checked ("Enable fog layer simulation" IIRC).

Hi, the "cannot control ambient weather" message is the result of an fsx crash (whatever the initial reason may have been), as ASN detects it can't control the weather. It doesn't necessarily mean it's ASN that caused the crash. Having said that, obviously we're investigating and working towards a solution to the freezes and crashes some of you have and the extend of ASN involvement in this. But, as I said, not all fsx crashes are due to ASN (even though you'll see this message coming up in all of these cases). Hope this is clear.

Hi, first, no you shouldn't make this assumption. The registry values are different. Please take a look at: HKEY_CURRENT_USER\Software\HiFi\ASNFSX See if the values there are stored ok. Alternatively, you can check this through ASN itself in the settings page. If the registry values are actually ok, then may be the issue is the following: ASN looks inside fsx app data path for the file wxstationlist.BIN. Is it there? Is it there when AS2012 is running/not running? Is it there when fsx is running/not running? This has caused issues to at least one more user (for some reason the file was removed only when fsx was running). Thanks,

Hi, the data are provided in raw binary format (for both moisture/precipitation signals and wind shear information), using (at the moment) a specific SimConnect function. The documentation for this is included in ASN download (it should be at least). The actual imagery/interpretation of the raw binary data we provide is up to the aircraft developer. Thanks,

Hi Luc, for which folder does this happen? fsx installation folder or fsx app data path folder (or both)? You said the registry values are set correctly?

OK thanks for this You understand that ASN is still new and reports that it doesn't work "as expected" are more or less to be... expected Yet, from my point of view as a developer I will always insist on these reports being as specific as possible so that we can pin the issue down and fix it. So thanks for this. I'll give the "EGLL 240150Z" a try to see how it behaves (whenever I find some time). There may be some adjustments needed there (for example in the rate of windshear generation in relation to reported winds gusting, or in the level of smoothing while the wind speed increases during a gust). @Claus: I'd like to repeat that SIGMETS don't apply to historical (at the moment). So there may have been other factors generating turbulence in your case. As for fsx option "disable turbulence and thermal effects", ASN bypasses it and directly controls both themals, up/down drafts and turbulence, so it will not matter. Cheers, Kostas