Using NAV3 in XML gauge?

[Guest dko60202]

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!

[taguilo 33]

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

[Guest dko60202]

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

[taguilo 33]

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

[Guest dko60202]

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

[Guest rpmc]

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

[phjvh 0]

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..."

[Guest rpmc]

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

[taguilo 33]

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

[Guest rpmc]

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

[taguilo 33]

>>You indicate that Option 2) is feasible. That

[Guest rpmc]

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

[Guest rpmc]

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

[spokes2112 179]

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.

[Guest rpmc]

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