Archived

This topic is now archived and is closed to further replies.

Guest dko60202

Using NAV3 in XML gauge?

Recommended Posts

Is it possible to set up and use a third NAV radio in an XML (radio) gauge? I'm trying to model the BK KN64 DME radio which has it's own internal nav frequency. I was hoping that by adding the line:Nav.3 = 1, 1, 0to the aircraft.cfg file, I could do things like >(K:NAV3 RADIO SET) in my XML...so far no luck. So: 1) Is it possible to have more than 2 NAV radios? and 2) If so, can I access NAV3 frequency and DME info in an XML gauge?Thanks!

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

Hi,I think with NAV.3 it's not possible. However you can simulate the existence of a third NAV, even you can make your own ILS receiver, but of course this requires some XML coding.You would have to play with local variables to store switching values to be assigned to, ie, NAV2 receiver.I haven't tried it though, but guess it should work fine.Regards,Tom

Share this post


Link to post
Share on other sites

I don't think that will work. I still need to have a working NAV2 receiver/vor, hence the need for a NAV3. I guess I could temporarily take over NAV2, get the DME, and then reset it, but I'm thinking that's gonna mess up the NAV2/VOR displays, even momentarily, every frame...especially since it takes some time for the DME to 'lock in'.Anyone else?Douglas

Share this post


Link to post
Share on other sites

For this to work, you need to make the NAV2 take over kinda "clocked" and in the background; while the needles, digits,etc will show your own Lvar values; this way you can avoid the "flickering" efect and have total control of the process.I still believe it's worth to give it a try...Tom

Share this post


Link to post
Share on other sites

Tom, I appreciate your help. For my purposes, NAV3 would be required. If it can't be done, then it can't; that's what I needed to know, thanks!Douglas

Share this post


Link to post
Share on other sites

I am coding a Bendix King KDI572 DME and have run into the same problem I believe was expressed by Douglas: the apparent need of a third Nav in order to get the HOLD function to properly work without time sharing Nav2 between a localizer display on one frequency and a DME on another.I have in mind an approach that should work (below), but if anyone sees a simpler way, I

Share this post


Link to post
Share on other sites

Hi,You can try to make use of the MS GPS.There you can have as many NAVAIDS with the corresponsing DME as you wish.Jan"Beatus ille qui procul negotiis..."

Share this post


Link to post
Share on other sites

Possibly, but I am not sure how. The limitation, I believe, is not in having enough NAVAIDS on the ground, but in having enough NAVs available in the aircraft.Douglas had it right when he asked if a third NAV was possible. I think that's what the BK KDI572 does. One selects a DME/TACAN using NAV2 (or NAV1), it locks onto that DME in the HOLD mode using its internal transceiver, then the pilot is free to set NAV2 (or NAV1) back to another NAVAID while the KDI572 continues to measure distance to the previously locked-on DME. In MSFS terms, this would essentially require a third NAV to work but that is not allowed.As I see it, work-arounds that mimic having a third NAV for this purpose could be: 1) use polar coordinates and trig to compute the XYZ location of the locked-on DME and compare that to A:Vars PLANE LATITUDE, LONGITUDE and ALTITUDE, 2) knowing only the frequency of the locked-on DME, access the MS NAVAID database to retrieve the XYZ of that DME (this doesn't seem possible or practical), or 3) knowing only the frequency of the locked-on DME, somehow use MS GPS to compute distance to that DME. I am not sure if this is possible, and I don't have an idea how to approach coding it anyway.In my post above, I realize that I neglected the third dimension, altitude. This is critical since MSFS correctly measures slant range DME, so it makes my math more difficult or maybe impossible... not sure.You can see that I am approaching this with one train of thought, trigonometry, and if other solutions are out there, I am kind of blind to them at the moment.Thanks for the reply,Bob

Share this post


Link to post
Share on other sites

Hi,Options 1) and 2) are feasible for sure.But, like I stated in this thread before, the simplest solution is to model a "swaping" radio between two frequencies based on a single COM.Again,there is no need for a NAV3 whatsoever.A *very rough* pseudocode would be something like: (LNAVcontrol) 6 == if{ (ANAV(1/2)Bearing) (>LMyNav3Bearing) (ANAV(1/2)Distance) (>LMyNav3Distance) 1 (>LNAVcontrol) }(LNAVcontrol) 5 == if{ 6 (>LNAVcontrol) }(LNAVcontrol) 4 == if{ Freq (>K:NAV(1/2)_SET) 5 (>LNAVcontrol) }(LNAVcontrol) 3 == if{ (ANAV(1/2)Bearing) (>LMyNav2Bearing) (ANAV(1/2)Distance) (>LMyNav2Distance) 4 (>LNAVcontrol) }(LNAVcontrol) 2 == if{ 3 (>LNAVcontrol) }(LNAVcontrol) 1 == if{ Freq (>K:NAV(1/2)_SET) 2 (>LNAVcontrol) }Then instead of using Avars in your RMI/VOR/ILS course/rose/dme indicators, use your own LVars (like (LMyNav3Bearing)).The real update will happen at least 6 times/second per each NAV, I believe an acceptable rate. Tom

Share this post


Link to post
Share on other sites

Hi Tom,I am remiss for neglecting to acknowledge that you suggested Nav swapping as the work-around in your 2005 response, above. So, I add my thanks to that from Douglas.I jumped to the conclusion that I didn

Share this post


Link to post
Share on other sites

Tom,I think I get it. Thats a great solution to the problem.Many thanksBob

Share this post


Link to post
Share on other sites

Here's what I have so far (FS9 XML). It yields only zero values:C:fs9gpsC:fs9gps(L:Async,bool) if{ (@c:WaypointVorElevation,feet) (>L:My_VOR_Elev,number) (@c:WaypointVorICAO) (>L:My_VOR_ICAO,string) 0 (>L:Async,bool) }%((@c:WaypointVorICAO))%!3s!%((@c:WaypointVorElevation,feet))%!4d!(L:KDI572Knob,number) -- 0 max (>L:KDI572Knob,number) (L:KDI572Knob,number) 2 == if{ (A:NAV2 IDENT,string) (>@c:WaypointVorICAO) 2 (>L:HoldingNav,number) 1 (>L:Async,bool) } (L:KDI572Knob,number) ++ 3 min (>L:KDI572Knob,number) (L:KDI572Knob,number) 2 == if{ (A:NAV1 IDENT,string) (>@c:WaypointVorICAO) 1 (>L:HoldingNav,number) 1 (>L:Async,bool) } The were put in hoping that I could see that correct information was retrieved from the gps.dll. Didn't work; just zero values. Same for L Vars -- My_VOR_Elev and My_VOR_ICAO. These are also "0". I can confirm that the other L Vars -- Async, HoldingNav and KDI572Knob work as intended. As well, there is an active 3 letter NAV IDENT. The VOR / Waypoint is not part of an active flight plan, and for the purposes of the KDI572 gauge, I would rather it was not. That is, I hope to access info about the VOR without requiring an active flight plan or altering an active flight plan.Rgds,Bob

Share this post


Link to post
Share on other sites

Bob,It can be done using the GPS vars. I made a VHF (voice) Homing indicator (Becker ZVG2002) for a project. The gauge can be found in this project --http://library.avsim.net/esearch.php?DLID=...&CatID=fs2004acThere are many points to consider when using the GPS-- The HOLD dme station must be searched/located in GPS data on every gauge read so...- Frequency must be used for finding station as Strings are not saveable in L:Vars.- Line of site for radio must be used for reception "in/out/back in range" in searching for station- Once correct station is found it must have DME capabilities- If found and it has DME then a geo calc can be performed for level Distance- Once Level Distance is found som trig is needed for Slant Distance. - Once Slant Distance is found DME speed can be computed.-Then display it :-) There probably are more points to consider but these are the main ones.If you would like me to recode the the ZVG2002 for your purpose drop me a PM. RomanProud "TEAM AVSIM" RTW race member.

Share this post


Link to post
Share on other sites

Thanks for the response, Roman. I appreciate it.As for my L Vars and strings, I removed that part of my code. My mistake for trying to combine L Vars and strings.I think I understand your points, but it might help for me to reiterate my problem:Regarding the HOLD dme, what I need to do is access that VOR one time, one cycle, only. And then, I do not actually need dme information returned. Rather, I want to know the lat, lon and elevation of that VOR. If I am able to retrieve lat, lon and elev, I can store those as L Vars and make use of them in the KDI572 gauge I am trying to write.I haven

Share this post


Link to post
Share on other sites

Maybe try this because I believe in previous testing that when querying the GPS it must be done in the same gauge read so change # #(L:Async,bool) #if{ #(@c:WaypointVorElevation,feet) (>L:My_VOR_Elev,feet) #(@c:WaypointVorLatitude,radians) (>L:My_VOR_Lat,radians) #(@c:WaypointVorLongitude,radians) (>L:My_VOR_Lon,radians) #0 (>L:Async,bool) #}#Change to - (L:Async,bool) 1 ==if{ 0 (A:NAV1 IDENT,string) (A:NAV2 IDENT,string) 3 (L:HoldingNav,number) case (>@c:WaypointVorICAO) (@c:WaypointVorElevation,feet) (>L:My_VOR_Elev,feet) (@c:WaypointVorLatitude,radians) (>L:My_VOR_Lat,radians) (@c:WaypointVorLongitude,radians) (>L:My_VOR_Lon,radians) 0 (>L:Async,bool) }And change mouse to this -(L:TestGPSKnob,number) -- 0 max (>L:TestGPSKnob,number) (L:TestGPSKnob,number) 2 == if{ 2 (>L:HoldingNav,number) 1 (>L:Async,bool) } (L:TestGPSKnob,number) ++ 3 min (>L:TestGPSKnob,number) (L:TestGPSKnob,number) 2 == if{ 1 (>L:HoldingNav,number) 1 (>L:Async,bool) } Doing this will do the full query / store on the "next" gauge read only and only once. The problem remains if there are more than 1 of the same VOR idents.. Even if it does work ????? Good luckRomanProud "TEAM AVSIM" RTW race member.

Share this post


Link to post
Share on other sites

DISREGARD ABOVE POST !!! I remember now how to get data from GPS, you cannot directly set (>@c:WaypointVorICAO) because it's not a string that is readable but more so a hashcode or database ID designator ( contains facility areas and such), the reason is there could be more than one. The only way is through "NameSearch", "IcaoSearch" or "Nearest",(just like using the GPS) then select the correct one to send to (>@c:WaypointVorICAO). Then you can get the data.Working on an example now using the "Nearest" way. Roman

Share this post


Link to post
Share on other sites

This works --- EXCEPT it will only pick up VORs no ILSs, didn't try TACANs or DMEs. The ICAO search solution would be the best way as ILSs are included ( will work on it ). Caution!!! The display elements are different than yours.C:fs9gps 0 (>G:Var1) 0 (>G:Var2) 0 (>L:My_VOR_Lat,radians) 0 (>L:My_VOR_Lon,radians) 0 (>L:My_VOR_Elev,feet)(A:GPS POSITION LAT, Radians) (>@c:NearestVorCurrentLatitude, Radians) (A:GPS POSITION LON, Radians) (>@c:NearestVorCurrentLongitude, Radians) 289 (>@c:NearestVorMaximumDistance, NMiles) 150 (>@c:NearestVorMaximumItems) @nearestVor (@c:NearestVorItemsNumber) 0 != if{ (G:Var1) (>@c:NearestVorCurrentLine) (@c:NearestVorCurrentICAO) (>@c:WaypointVorICAO) 1 (>G:Var2) @identVor } els{ @reset } 0 (>G:Var2) (G:Var1) ++ s1 (>G:Var1) l1 (@c:NearestVorItemsNumber) 1 - > if{ @reset }(@c:WaypointVorIdent) slen 0 != (G:Var2) 1 == and if{ (L:HoldingNav,number) 1 == if{ (A:NAV1 IDENT,String) } els{ (A:NAV2 IDENT,String) } (@c:WaypointVorIdent) scmp 0 == if{ @set } els{ @increment } }0 (>L:Async,bool) 0 (>G:Var1) 0 (>G:Var2) (@c:WaypointVorLatitude, radians) (>L:My_VOR_Lat,radians) (@c:WaypointVorLongitude, radians) (>L:My_VOR_Lon,radians) (@c:WaypointVorElevation, feet) (>L:My_VOR_Elev,feet)(L:Async,bool) if{ @initialSearch }(L:TestGPSKnob,number) 0 !=Ident = %((C:fs9gps:WaypointVorIdent) )%!s!Lon. = %((L:My_VOR_Lon,radians) )%!9.6f!Lat. = %((L:My_VOR_Lat,radians) )%!9.6f!Alt. = %((L:My_VOR_Elev,feet) )%!9.2f!(L:TestGPSKnob,number) -- 0 max (>L:TestGPSKnob,number) (L:TestGPSKnob,number) 2 == if{ 2 (>L:HoldingNav,number) 1 (>L:Async,bool) } (L:TestGPSKnob,number) ++ 3 min (>L:TestGPSKnob,number) (L:TestGPSKnob,number) 2 == if{ 1 (>L:HoldingNav,number) 1 (>L:Async,bool) } Roman

Share this post


Link to post
Share on other sites

Oh. I think I know what's wrong...Roman,I copied your VORRetrieveTEST gauge into my aircraft. No success. I just get null values, the same result I have been getting for months each and every time I attempt gps associated code. Frustrating as h___.You said your code works and I believed you. So, I put your gauge in the default Baron, and... well, now both of us know your code works just fine...The difference? Maybe it's this: I have Reality-XP GNS 530 & 430 (FS9 vintage) installed in my a/c and I'd guess that the MSFS gps.dll is either deactivated when using these RXP gauges, or the RXP configuration needs editing to make the gps code work.I don't know, but I'll search through the SimForums RXP site to see if there is anything to learn there.Thanks a million for the help. I really appreciate it.BobTom: thanks very, very much for your assistance, too. Looks like your Nav swapping has always been the right solution for the DME HOLD problem!!

Share this post


Link to post
Share on other sites

All:Apologies for the false alarm. There appears to be no conflict with RXP GNS gauges.Roman's code works, but in my a/c there must be another issue that I'll need to track down.

Share this post


Link to post
Share on other sites

It's turning out well.. Got the ILS part working well.. Tried ICAO search ( about 23 hours worth, no hair left ), so going back to nearest search.The ICAO code format for VORs is'VK5 GRB' -or-'VK5 KGRBIGRB' -or-'V KGRBMNO' etc...The result can be different due to basically a poorly executed AFCAD2 modification.. But the ICAO search only does the last characters during the search. I just could't get the search routine to spawn.. I got the inputs in though. RomanProud "TEAM AVSIM" RTW race member.

Share this post


Link to post
Share on other sites

Hi Bob,If you still want to use the gps functions to retrieve NAV coordinates and altitude, it's very simple :-)1) Do an ICAOSearch using Avar nav info: 0 (>L:ICAO Found,number) 0 (>L:ICAO NoMatch,bool)'V' (>@c:IcaoSearchStartCursor)31 (>@g:enteringInput)0 (>@c:IcaoSearchMatchedIcao)(A:NAV1 Ident,string) (>C:fs9gps:IcaoSearchEnterChar)(@c:IcaoSearchMatchedIcaosNumber) 0 > if{ (@c:IcaoSearchCurrentIcao) (>@c:FacilityICAO) 1 (>L:ICAO Found,number) } els{ 0 (>L:ICAO Found,number) } (@c:FacilityICAO) (>@c:WaypointVorICAO)(@c:WaypointVorLatitude,degrees) (>L:YOurLat,degrees)(@c:WaypointVorLongitude,degrees) (>L:YOurLon,degrees)(@c:WaypointVorElevation,feet) (>L:YourAlt,feet)Then, somewhere on the code ..NAV1 changedif{ @SearchICAO }(L:ICAO Found,number) 1 == if{ 2 (>L:ICAO Found,number) }(L:ICAO Found,number) 2 == if{ @RetrieveVOR }etc etcNow you can use those Lat/Lon/Alt vars combined with Plane Lat, Plane Lon and Plane alt via geocalc functions to find the proper distance to the VOR at any moment.Good luck! :-)Tom

Share this post


Link to post
Share on other sites

Tom, Thanx alot!! I barked up the same tree, almost exact. But it never worked. Since you made it work, I thought I'd give it another try. It didn't work again !! But found the problem --- I had constantly firing Vars inside looping macros -- BAD, BAD, BAD!!! Got rid of both and voila ;-) Got rid of a boatload of code!:-beerchug Thanx,RomanProud "TEAM AVSIM" RTW race member.

Share this post


Link to post
Share on other sites