Kostas,

 

 I appreciate your response, but you still left me with questions.

 

What is the beam width in degrees that ASN outputs to Roland's Radar and or others if it is a variable. (Although I saw nothing in your API documentation that sets beam width.) That would be more helpful when looking at various "types" of radars.

 

I am also confused why you would not want me to use your NexRAD output when comparing to a display. I would think your internal NexRAD would be the more accurate display of what is really happening. Your documentation also leads me to believe this is so. Also where are the distances measured from. When I set the range in your software where does it determine that range if from / to. 

 

Thank you,

 

Hi Ken,

 

Our wxr radar (airborne mode, not to be confused with the NexRad functionality) is designed around the Collins WXR 2100 model with a beam width of 3.5 degrees and multi scan support if needed (but I think Roland is not using it). I think there was a misunderstanding (blame me for that). I really like the comparisons you made between the airborne and the NexRad images. I was specifically making a comment about this phrase:

"I agree lots more testing is needed and I think there are some limitations to either ASN or even FS. Mostly with very large thunderstorms fail to represent as large columns filled with precipitation"

 

This just gave me the impression that you didn't really understand specifically how our external api works (the one feeding e.g. Roland's gauge with data), But now re-reading it, I think you're correct. The basic limitation is that the thunderstorms in the default fsx/p3d cloud models are just too small. This has been improved with the new t-storm cloud structures included in ASCA, but still needs improvement and we're working towards this goal. The main compromise in these cases is always performance. One of the most performance intensive depictions in FSX/P3D is hurricanes. I don't know if you had any chance to fly through a hurricane with ASN. The radar image you'll get will be nice, but It certainly is tough for performance. In any case, there are still things we can do to improve it and we're working hard to get there.

 

 

 

 

Actually, what you've said above is extremely facile... Think about it.... The WXA (Advantage) uses what it SEES in FSX/P3D in terms of weather generated without ANY regard to what's actually making the weather. It doesn't care. What does that mean? It means that we can see and forewarn in ANY conditions as a WXR is supposed to do and we do it, again, in all WX engines. We're not before the WX... we're AFTER it's been generated. As well, if the WX engine can cause the situations you imply, then they would still happen, no matter what WX engine is being used... We don't change the weather (we do put the precip where it's supposed to go except in the case of ASN), we're just showing where it is.

 

As well, I have my doubts as to weather (PUN!) or not you could make a WXR that worked in all WX engines... it took us a huge amount of effort and time (not to mention money) to do so and I am SURE that if you could have, you would have. It would make no sense to not make money just because you're "stuck" in ASN's WX engine...

 

I know what you've been through, I've been there too Many times...  Believe me it was not technical reasons that made us select this path. I don't think the community needs any proof as to what we are able to achieve as far as overcoming technical limits and raising the bar higher (the latest one being enabling dynamic cloud texture and sky color changing).  And we could actually release a gauge that could work with any weather engine within 15 days. The code is in there, it's just disabled. Yes, working with the weather AFTER it has been generated.

 

It's just a different business approach (and philosophy) we're talking about. And while I respect the approach you took (and the effort you made to get there), the final judge is always the community that has to answer a very simple question: Do they consider the experience they get from your simulation but without ASN/AS16 installed and running adequate?

The key here is the term "adequate". If just varying the precipitation intensity is enough, then I am sure it will be perfect for them. If they want however an actual simulation of a weather related aviation hazard (which is the single reason they bother to install these units in real life), then I am not sure how this can be achieved without proper synchronization with the weather engine itself.

Sorry to disagree (again).... The WXR we made will do EXACTLY as you say yours does in ASN/AS16 as well as in ALL other WX engines... so again, you're being facile and misleading.  We don't CHANGE or MAKE the weather.  We take it from FSX/P3D after it's been created and display the results.  The ONLY change we make is to the precip and again, we don't do that for ASN.  So, again, you're either making assumptions about how our product works, you're deliberately misleading the people reading this or you don't understand what we're doing.  

 

To that end, let me be clear:  No matter what your (or anyone else's) WX engine does, we will ALWAYS display the WX properly.  ALWAYS.  And we do not make ANY changes to what happens to your aircraft in that WX.  If the weather (engine) is creating a system wherein you would break up if you go into the WX and the programming allows for that, then it will break up.  We don't stop or modify the WX, we only display it.  Our product is not just adequate (in fact, I never used that term... you did)... it does exactly what it's supposed to do:  display the WX in the sim.  No more and no less.  It does it accurately and in all sims, all aircraft and finally, all WX engines.  Including yours.  No other WXR does that.  No other.  I'd hardly call that "adequate'.  I'd call that pretty darned amazing.