kterz

Hi Mike, Sorry my mistake there. FSBuild uses the wx_station_list.txt, not the snapshot. Check this file. There have been some reports that in Windows with a locale that uses "," instead of "." as a comma delimeter, there are some issues between fsbuild and ase communication Kostas Terzides

Hi, 2 things: - What's your windows locale set to? (Can you paste here a single line, whichever you like from current_wx_snapshot?) - import the fsbuild plan to ASE (export as fsx xml from fsbuild first) and let it process the data. Use ASE winds aloft data in your FMC, because these are what you will encounter during your flight. Close fsbuild, then reopen the same plan and the aloft should be there (they will not match exactly the ones in ASE because fsb uses the method of copying the closest to the waypoint station data, while ASE uses advanced interpolation). Use fsbuild winds etsimates only for initial fuel calculation. Kostas Terzides

In my case it uses NZAA as a southwest interpolation source station (at 44nm). All the others are irrelevant. I think we dont have an issue here (at least on my machine). However, I've actually managed to get an interpolation details screen such as one in your first screen shot using NZPH. NZPH is an airport with no associated weather station. I've been wondering if this happens when ASE tries to interpolate the weather for an airport (not a weather station) (Look at the name in Report page, if it just says "airport" instead of a name). Can you confirm this? May be we'll get somewhere here. Kostas Terzides

OK if this is happening constantly, please tell me what's your maximum surface wind option set to? NZWT even though interpolated too with only one close source station gives me ATM (252217Z) surface winds 205/03 (while NZWR gives me 18000 as you say) Kostas Terzides

Well, that's how interpolation works (and this situation is also very common outside New Zealand). Interpolation doesn't mean just copying the data from the closest station. Do you think it's realistic to have the exact same conditions in NZWR as in NZAA (that's ~70nm away)? Interpolation is used in many places (even FSX itself uses interpolation from 3 stations to calculate the ambient wind direction and speed- even though not very successfully). If you think this should be improved in any way, I am sure Damian will be glad to listen to any suggestion Kostas Terzides

The last screen shot you provided demostrates that ASE is working as it should. The only actual station significantly affecting the weather at NZWR is NZAA. The other ones are just there for reporting reasons (and these reports could be easily removed if we ask Damian, if that's what's bothering you). What is the ICAO of the station of the first screen shot? Is it NZPI, Parakai you mentioned on the other thread IIRC? This station is neither in the FS station's database nor in the internal station db ASE maintains. May be that's the reason you're getting these erroneous interpolation information. If that's the issue, then you could insert it manually (if you know lat,lon etc) until the station database is updated Kostas Terzides

VoxATC will not give us a STAR when the final waypoint of the flightplan (the beginning of the STAR) is within a certain radius from the destination airport (~ 40-50nm). This way we are passed to the approach controller before reaching this point and the approach controller always vectors us (by default- unless we select another option). He is not able of assigning us a STAR. Only the previous enroute controller may do this.

When in DWC mode, as you know the weather is set globally. That means the winds at destination are constantly updated to the current surface winds of the station closest to the aicraft coordinates. That's why when we usually go get the ATIS (usually before ~50nm out) it's wrong. All ATC programs I know of read the fs destination weather to report the ATIS. And at the moment we get it (in DWC mode always) it is expected to be wrong (if it is correct then this might be by pure lack). ASE on the other hand gives a chance to ATC programs to get the "real" destination weather conditions indireclty (through windows messaging). AFAIK, only Pete has taken advantage of this (the infamous USEAseWeather option that is on by default when DWC is on). AFAIK only RC uses FSUIPC to get the destination weatherBut there is another problem there: AI aircraft. Even though, RC may report a correct ATIS, the true winds at destination are not set yet to match the ASE destination metar (they will be eventually as we get closer). RC may decide on the active runway soon enough by observing the AI and the runway we may get will possibly be wrong.Pete has explained all this much better than I do:http://forum.simflig...post__p__404290All the above are the reasons I always use force weather to destination when DWC is on. This way the weather at destination is set early enough to allow both AI and ATIS reporting programs to use "real" conditions. It is a good compromise given the advantages of DWC and I think it should always be checked when DWC is on and a flight plan is set. Some inconistencies may persist in cases of variable winds at destination, that's why now the team is investigating the LockWind option as you know. Some other problems may exist with ATC programs such as VoxATC, that calculate the active runway based on destination weather directly before the TOD. And this may be prior to the 80nm threshold ASE uses for forcing the destination weather, leading to incosistencies. Kostas

You are right about this. We as users expect everything to always work as it should and easily blame what seems to be the most obvious reason for our problem. However, consider the following scenario:You have a program that has a Server part ("S") and a client part ("C"). C downloads periodically some piece of data (I'll name it "DT") from S and they both work in harmony. DT may be in a proprietary format (no one should complain). S happens to be on a server in the US and bring down data that have the US -locale. S doesn't know in what country C is (all the server programs are and should be client agnostic for performance reasons). C decodes the downloaded data correctly and C is a time critical applicaiton.Now, let's consider a third application ("X) that claims to support and decodes DT for some functionality. X runs on the client machine and it is not time critical (at least not at the level C is). X may run on a machine with a different locale than S and in that case it cannot decode correctly DT. That's the situation we have here. Possible solutions:1) X changes a line or two of code to decode DT correctly, by knowing that DT has a US locale. In dotNet it's as simple as using NumberFormatInfo.InvariantInfo.NumberDecimalSeparator instead of NumberFormatInfo.CurrentInfo.NumberDecimalSeparator 2) Change C, so that when DT gets downloaded, it reformats it to use the local format AND change the parsing code to accomodate the changes. That means 2 changes are needed for a time critical application such as C, that this way MAY slow down.What do you think is the better solution?Afterall, FSbuild claims to support AS weather, not the other way around.Regards, Kostas

Take a look at thisAlso note that when hitting the Interpolation details button, it is sometimes necessary to leave the report page go to some other page (eg briefing) and then back to report, so that the interpolation details have a chance to get initialised.

Hello to all and thanks for the update,May I ask something: Is the 80nm distance hardcoded? What I've been thinking is that some ATC programs (not RC by the way) calculate the STAR procedure that we will be assgned to, while still enroute (before TOD) based on the active runway. And in RW I believe that ATIS info is obtained before initial descend, IIRC. Haven't tried it yet, but why "80nm" and not 120nm or something like that (or make it adjustable)? Is this fix only for Radar Contact users?Regards, Kostas

Can you post here, the Err.log file (open it with notepad) inside %appdata%\Intenal Workings\VoxATC (Start-> Run->Type: %appdata% and then goto Internal Workings-> VoxATC). I remember having a similar problem (it was related to the folder my flight plans are saved, because my user name uses Unicode chars... anyway, I changed the .pln location to something like c:\blah.pln and it solved it. May be in your case it is something different) If the file is very large, then rename it to something else, try to start a new flight until the error comes up and then post the contents of the newly created err.log. Kostas

You are right that <RoutePositions> is not a proper name. My thought is that this XML file gives the user an opportunity to override the default way of setting up a vectored approach and possibly these positions (with their altitude constraints) may represent a "user-defined" vectored approach route. And the highest of these positions may represent the MSA for the program. In fact, I found out tonight that the value I set there is relevant only to the initial descend from cruise altitute and it is not respected when vectored for an approach subsequently. It seems that "Full ILS" is the only suitable option for high terrain approaches, at least for now.

They obviously know it. I think we are in the middle of something here (not yet fully implemented), that's why this is undocumented for now. We'll have to wait. I'm glad they seem to actively (even though silently) work.

Hello all,I think I may have found an undocumented feature of VoxATC, giving us a manual way of defining the MSA for a particular airport. Create in %appdata%\Internal Workings\VoxATC\apdata a new xml file using as the name the airport code (e.g. LOWI.xml). In this xml file write these (this comes from LOWI.xml): <?xml version="1.0" encoding="utf-8"?><Airport ReplaceUnits="True"> <RoutePositions> <Position Latitude="N47*15.37'" Longitude="E11*20.38'" Altitude="2896" /> </RoutePositions></Airport> Notes:- I don't know if ReplaceUnits is needed- You can get the Latitude and Longitude by opening the .pln file (assuming the destination airport is LOWI) with a text editor and getting the DestinationLLA. Just don't forget to format the value like this: "N47°15'37.00" --> "N47*15.37' ". In these attributes I set the coordinates of LOWI airport.- The Altitude is in meters, thus for a supposed MSA in LOWI of 9500 ft we write 9500/3.28=2896 approximately.Of course, gettings MSA correct is not that simple. The approach plates (at least these I have) for LOWI LLZ East Procedure 26, give us an MSA of 9500ft only when north of RTT NDB and of course in the west approach (through KTI) the MSA are a lot higher. That means that a "generic" MSA value is of course not accurate enough and that the ATC system has to take into account the actual aircraft position. I don't know if adding in the above xml various Position elements having the coordinates of high terrain and the respective "MSAs" around LOWI would make VoxATC behave differently, though I doubt it.Anyway, having a way of (at least manually) instructing VoxATC for a "generic" MSA of a particular region is IMHO an addition to the way we've been vectored until now. I could automate the procedure (writing a simple dot net program manipulating the xmls as I could do the same thing for the transition altitudes I referred to in another thread), but I will not since, this might probably violate the EULA.I'm also sure that at some point the developer(s) of VoxATC will figure out a much more advanced way of handling the MSA issue. I am certain about this (I admire his/their programming skills), I only wish they could communicate a little bit more through this (or other) forums about their plans-intentions for the future of this brilliant pice of software. Kostas

You're right, getting fixated from time to time :-) I know this would be fantastic, it seems a lot of work from the developer perspective though. I just suggested a quick and easy way of programming this(so that would get this sooner :-) )

Hello all,May I suggest something to the devs (it is relevant only to users flying in Europe where trans levels differ from place to place signifiacantly).Since, VoxATC does use the concept of regional transition altitudes (in %appdata%\Internal Workings\VoxATC X\VASettings.xml) then it might be possible to expose through flight planner extra three text boxes to let the user insert the transition altitude for the departure, destination and alternate. Three separate Regional sections could be formed inside the xml for each place (differing in the TransitionAltitude attribute, being identical to UK/EU otherwise). The boundaries of these sections could be calculated based on the airport coordinates and a 40nm radius for instance or something similar. Further customization of the regional features could also be added if needed in the future. This would add to realism significantly (for instance when I fly LGTS-LGAV, the transAlt in LGTS is 6000ft and 9000ft in LGAV). Thanks, KostasPS: Don't forget to add a MSA in the future (though I know this requires some extra coding)

Oh! I must have been stupid or something! I just realized that the FS2Crew control panel MDA text box accepts inputs > 1000! I used to enter there i.e. 580 (the "calculated" value I would set in the orange bug) instead of 1580 for a published MDA of 1530 and TDZE=1157 and nothing happened! It's all clear now, thanks for this Bryan,Cheers,Kostas

Keep it coming! OK, thanks. I just haven't figured out the logic (as regards FS2Crew's internal perspective) behind the 3 ways of settings MDA/DH (CATI, CATII or III and NonPrec/Circling). It has to do with "Decide" call out? Is it not possible for your code to directly "read" the orange bug setting? Sorry, for being so pedantic, but I really like your product and I would like to know every single detail :-) You are probably right there I am ok with that.I have it assigned to a joystick button anyway. Thanks Kostas

Hello to all,Great product Bryan, congratulaions! I have a couple of questions1) The manual says that when a non precision approach (VOR, circling etc) is performed, then the MDA should be set to the text box in the control panel. In this case should the MDA orange bug in the altimeter be left to zero? I did that in a specific approach (with FMC fully progammed) and nothing happened. What is different when setting the MDA in control panel?2) In the manual, you provide a couple of flows, including a non precision approach. "Beacon inbound" or "VOR inbound" should trigger some kind of response from the FO? Should the FO (PNF) say "Check ___ feet" when crossing the fix, or is this not modelled?3) In case of a go around, when I say "go around" and it is recognised, should the FO respond by pressing the GO button below EICAS, or is that left to me?In any case, this product really excels in the case of a go around. I just fly the plane and almost everything else is just spoken. I can almost feel the teamwork required in this difficult maneuver in the RW.Thanks in advance for any replies,Kostas