Board index FlightGear Support Flying

RNAV with KNS80 trouble (SOLVED)

Controlling your aircraft, using the autopilot etc.

RNAV with KNS80 trouble (SOLVED)

Postby jogois » Thu Jul 19, 2018 8:08 pm

Trying to get KNS80 to work in ENR/RNV mode flying the Patten's version of PAF's Piper Aerostar 700 (http://pattenflightgear.wifeo.com/aerostar700.php ), and also with the original model of Syd Adams, but haven't got it. I've followed the steps given in the KNS80 Pilot's guide (http://www.montereynavyflyingclub.org/O ... /kns80.pdf) by reproducing the same flight from Kansas City to Memphis with the same VORTACs, (after checking that they are still operative in FG since the KNS80 Pilot's Guide is quite old), but there is no way. I've been searching the forum and haven't found much about it other than the KNS80 modeled in FG is supposed to work properly.

Am I missing something?
Last edited by jogois on Sun Jul 25, 2021 7:32 pm, edited 2 times in total.
jogois
 
Posts: 25
Joined: Thu Dec 25, 2008 5:41 pm
Location: Europe
OS: Ubuntu-Mate 18.04

Re: RNAV with KNS80 trouble (PARTIALLY SOLVED)

Postby jogois » Sun Jul 22, 2018 3:26 pm

After rechecking the issue I posted, I've found that there is an error in the kns80.nas file included in Patten's Aerostar. The error is on line 194 where is says:

if(!me.NAV1_IN_RANGE.getValue()) {

and should be: if(me.NAV1_IN_RANGE.getValue()) {

Note that the original kns80.nas file has a '!' before the 'me.' in the condition. This mistake is also present in the kns80.nas file in /usr/share/games/flightgear/Aircraft/Instruments-3d/kns80 (FlightGear 2018.2.1 in Ubuntu) so I assume it is a bug of the kns80.nas included in the main program so that the condition is wrongly programmed since, according to Nasal conditionals "If you wish to execute code only if a condition is not true, use the ! operator:...", and in this case one wants to execute the condition when it is true,i.e. when RNAV/ENR is selected.

Any way to report the issue?

On the other hand, although now the DME field shows the correct distance to the waypoints programmed in the KNS80 panel, still the slave HSI doesn't work together with the KNS80 in RNAV mode and keeps showing the red NAV flag warning. Any suggestion?

Jogois
jogois
 
Posts: 25
Joined: Thu Dec 25, 2008 5:41 pm
Location: Europe
OS: Ubuntu-Mate 18.04

Re: RNAV with KNS80 trouble (PARTIALLY SOLVED)

Postby wkitty42 » Sun Jul 22, 2018 6:26 pm

have you tested and does it work properly if you remove the "!"? if so, a patch can be built and submitted to the bug tracker or to the developers' mailing list (found here)...

what other craft are using the kns80.nas file? are they negatively affected by this change? if they are, another solution needs to be found...

[time passes]

here's a list of craft that contain "kns80" in any of their xml files...

Code: Select all
cd ~/flightgear-dev/fgaddon-ng
$ find . -type f -name *.xml -exec egrep -Hin -e "kns80" {} \; | cut -d "/" -f 2 | sort | uniq

Aerostar-700
Cessna-421-Golden-Eagle
Grob-Gf200
Lancair-235
Long-EZ
PC-6
Piaggio-P166
Ryan-Navion
SIAI-Marchetti-S.205R
SIAI-Marchetti-SF.260
Socata-ST10
Tecnam-P2006T
Velocity-XL
ZLT-NT
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 9146
Joined: Fri Feb 20, 2015 4:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 20.04

Re: RNAV with KNS80 trouble (PARTIALLY SOLVED)

Postby jogois » Sun Jul 22, 2018 9:47 pm

Hi wkitty42,

The approach for kns80.nas in the other airplanes I've tested (Ryan-Navion, Tecnam-P200-6T, Lancair-235) after your reply is different. They all use the kns80.nas file from the original (I think) Aerostar-700 as it can be read in the header:

"
#<PropertyList><module>Aerostar-700</module><script><![CDATA[
#### King KNS-80 Integrated Navigation System ####
#### Syd Adams ####
#### Ron Jensen ####
####
#### Must be included in the Set file to run the KNS80 radio
####
#### Nav Modes 0 = VOR ; 1 = VOR/PAR ; 2 = RNAV/ENR ; 3 = RNAV/APR ;
####

"

RNAV mode doesn't work either in these cases. The DME distance to the he waypoints in the KNS80 doesn't work, instead it shows a "frozen" number that corresponds to the DME distance to the VORTAC station (not the programmed waypoint) that appears in VOR mode. That value updates, and freezes again, in the DME field of the KNS80 panel if switching from RNAV to VOR mode and then back to RNAV.

Have repeated the flight with Patten's Aerostar with the modification I suggested and the KNS80 panel seems to work fine up to a certain point. The DME shows distances that I assume are the ones of the programmed waypoints in RNAV mode. If switching to VOR mode while in flight, the DME shows a different distance that could be the one corresponding to the VORTAC that is active in the KNS80 at the moment. Switching back again to RNAV mode, the DME field displays a different value, but not allways since sometimes it freezes again with the VOR mode value.

Is there a way to check if those distances are correct? I mean, the distances to the programmed waypoints in the RNAV mode and the distance to the active VORTAC in the KNS80 panel.

It would help to check the RNAV behavoir if someone else reproduced the same flight described in the KNS80 Pilot's Guide with both the original and the modified (without the '!') kns80.nas files, with the Aerostar and with the the planes suggested by wkitty42.

Haven't checked the PAR and APP modes yet.

Again, the slave HSI shows the red NAV flag warning.


Jogois
jogois
 
Posts: 25
Joined: Thu Dec 25, 2008 5:41 pm
Location: Europe
OS: Ubuntu-Mate 18.04

Re: RNAV with KNS80 trouble (PARTIALLY SOLVED)

Postby wkitty42 » Sun Jul 22, 2018 10:27 pm

jogois wrote in Sun Jul 22, 2018 9:47 pm:Hi wkitty42,

The approach for kns80.nas in the other airplanes I've tested (Ryan-Navion, Tecnam-P200-6T, Lancair-235) after your reply is different. They all use the kns80.nas file from the original (I think) Aerostar-700 as it can be read in the header:

ok, so that would appear to mean that your craft has its own implementation of this device... if that's the case and your changes work, it is probably ok to make your fix and not worry about the others... as i mentioned above, a patch can be done and submitted to the given links OR you might be able to do it and submit it to the repository directly if you are of a mind to go that far...

i can't answer your other questions... their details are outside my pay grade ;)
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 9146
Joined: Fri Feb 20, 2015 4:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 20.04

Re: RNAV with KNS80 trouble (PARTIALLY SOLVED)

Postby jogois » Mon Jul 23, 2018 6:45 pm

Hi again. Thanks for your reply.

When I pointed out to the different approach of those airplanes using the kns80.nas file in contrast to Patten's and the up-to-date Syd Adams' Aerostar, I did it based on the fact that the KNS80 in Patten's one is called from line 489 of 'aerostar700-set.xml' (line 489):

<file>Aircraft/Aerostar-700/Models/Instruments/kns80/KNS80.nas</file>

and the current (as per FlightGear Addon page) Sys Adams' Aerostar calls it from 'aerostar700-set.xml' (line 444):

<file>Aircraft/Instruments-3d/kns80/KNS80.nas</file>


and both of those KNS80.nas files have the following heather:

"
#### King KNS-80 Integrated Navigation System ####
#### Syd Adams ####
#### Ron Jensen ####
####
#### Must be included in the Set file to run the KNS80 radio
####
#### Nav Modes 0 = VOR ; 1 = VOR/PAR ; 2 = RNAV/ENR ; 3 = RNAV/APR ;
####

"
and therefore, are different files from the ones called from the Ryan-Navion, Lancair-235, etc as mentioned in my previous post (note the name of the .nas file is not in capital letters). In particular the Lancair-235 calls the kns80.nas from line 181 of lancair235-base.xml:

<file>Aircraft/Lancair-235/Models/Interior/Panel/Instruments/kns80/kns80.nas</file>


and the Ryan-Navion does the same from line 171 of navion-base.xml:

<file>Aircraft/Ryan-Navion/Models/Interior/Panel/Instruments/kns80/kns80.nas</file>

and so on. But other than that, they, and here it comes, show different code. I said that they use different approach to manage the KNS80 because of their different Nasal code to model the same instrument. In fact, the kns80.nas they use has the RNAV condition well (I think) programmed from line 131:

"
var updateRNAV = func{
# check to see if we are in-range
if( NAV1_IN_RANGE.getValue()==0) {
return;
"

which would be in accordance with my modification of KNS80.nas codition from line 194 that I mentioned in my second post of this topic (or should I say that mine is in accordance to them). However, in spite of it, the KNS80 of these other airplanes with the kns80.nas file simply doesn't work (please bear in mind I'm only talking about the RNAV -and probaly PAR, APP- mode since the VOR mode works just great). I don't have a clue why, so I will stick to the newer (I think) KNS80.nas of Patten's and Syd Adams' Aerostar. If it finally works we can just substitute de kns80.nas for the KNS80.nas and modify the whatever-airplane-base.xml to point to it.

Having said that, yes, I have tested it again, and with the modification of the condition in the two .nas files (the one in 'Aircraft/Aerostar-700/Models/Instruments/kns80/KNS80.nas' and the one in 'Aircraft/Instruments-3d/kns80/KNS80.nas'), both Aerostars (Patten's and the current one of Syd Adams' from FlightGear Addons page) show the DME distance to the programmed waypoints.

To test it again, I have picked an airport (can be any one) and its corresponding approach and departures charts, STAR's, and SID's, etc, to choose a runway to take off from. What we need here is 4 fixes related to the VORTAC used by this whatever airport's runway, so that the KNS80 would be programmed with these 4 fixes as our waypoints, being the first one the one used first in the chart for our chosen procedural departure. This way, while we are on the ground, the DME display of the KNS80 panel -in RNAV mode- should show the distance from our airplane to our first programmed waypoint that, in turn, would be the distance from our airplane to the relevant DME station plus or minus (depending on the position of that DME facility with respect to us in our chosen runway) the distance from that DME station to the actual chosen fix. The good part is that it initially works (allways speaking of KNS80.nas without the '!' in the condition) and shows the expected distance to the programmed waypoint, so that would fix it.

After taking off, the DME distance starts changing (decreasing in my case, as I fly to the waypoint) and showing good values according to the fix I programmed. It even agrees with the moving map picture of the situation. So yes, modifying the condition works!.

Once over the fix (allways with the moving map open) the distance shows little discrepancy although I don't know if it mimics the error behavoir mentioned in the KNS80 Pilot's Guide. Anyway, after overflying the fix, switching to VOR mode causes the DME to display the distance to the VORTAC station, everything fine, but switching back to RNAV mode has no effect unless switching back to VOR mode, and back to RNAV mode again when it displays once more the distance to our waypoint (in our case the fix of interest). I think that this behavoir has to do with the refresh of the simulation. Still no clue about it though.

Also, if after the above, while in flight we select our second waypoint, remember in RNAV mode, the DME displays the distance to it more or less correctly according to the moving map, so we are moving fordward. I forgot to say that while checking all this I had selected the fix on the moving map with the right button of the mouse in order to cross check the distance between the blue star and our plane with the displayed value in the DME field of the KNS80 (that's why i said "more or less correctly" above). As said, the slave HSI is not linked to RNAV mode and keeps showing the red NAV flag.

I wonder if I am the only one having experienced RNAV problems with the KNS80, or simply if I am the only one trying RNAV the good old way. However, I'm gonna try to find where the rest of the problem is, and in any case I'll try to inform Patten (have to see if his website has contact info) about this topic before reporting to the bug tracker. Just wanna be sure.


Sorry for the length of this post. Thanks for reading.


Jogois



UPDATE --july 26, 2018: All of the above is true if taking off in RNAV/ENR mode, following the KNS80 Pilot's Guide, but seeing the strange 'freezing' behavoir of DME distances in VOR mode when RNAV is working fine, I decided to take off in VOR mode like allways WITH the modified KNS80.nas. Well, changing the condition (removing '!') solves the RNAV trouble displaying the correct distance to waypoints, etc., but it makes VOR mode INOPERATIVE. So the fix solves one bug, but causes other. It is not a definitive solution.

Having been reading the code of KNS80.nas (and kns80.nas as well, just in case) I don't find the obvious conflict between the two modes.

Any one else willing to try?
Last edited by jogois on Sun Jul 29, 2018 9:33 am, edited 1 time in total.
jogois
 
Posts: 25
Joined: Thu Dec 25, 2008 5:41 pm
Location: Europe
OS: Ubuntu-Mate 18.04

Re: RNAV with KNS80 trouble (NOT SO - PARTIALLY SOLVED)

Postby jogois » Sat Jul 28, 2018 4:25 pm

Well, this time I did modify th kns80.nas file of the other airplanes. Since the RNAV/ENR mode in those airplanes with the kns80.nas file din't work either, and as I said the condition affecting RNAV from line 131 doesn't have the '!' in it, I just included it (as below) to see what happened:

"
var updateRNAV = func{
# check to see if we are in-range
if(!NAV1_IN_RANGE.getValue()==0) {
return;
"

The funny part is that now the RNAV/ENR mode works in these airplanes too, displaying the distance to the programmed waypoints, any of the 4, with no problem, but now the DME distance in VOR mode becomes a frozen value in the KNS80 display. What? RNAV/ENR mode works without '!' in the condition of the KNS80.nas file, just where kns80.nas doesn't work (again RNAV/ENR mode) without it. Wait a minute... now RNAV/ENR works with kns80.nas if adding '!' to the condition, the same as if we delete it from KNS80.nas file.

Although both KNS80.nas and kns80.nas are supposed to be just versions (with hashes, temporary objects, and all those neat ways to make the code cleaner and more readable -different approach-) of the same file, they work just the opposite to each other speaking of RNAV/ENR mode availability. I am not able to find where the problem is. I think it is like finding a stone on a mountain of stones, it is there but where...

In both cases when RNAV/ENR works (in the KNS80 panel), the CDI for any mode (other than VOR) is unusable because the HSI keeps showing the red NAV flag as I said. Besides, if changing to VOR/PAR mode, although, according to the KNS80 Pilot's Guide, the KNS80 should display the distance to the VORTAC station as in VOR mode, being this operative, it displays the distance to the programmed waypoint!!!. That would be an easy fix though.

Jogois
Last edited by jogois on Sun Jul 29, 2018 9:34 am, edited 1 time in total.
jogois
 
Posts: 25
Joined: Thu Dec 25, 2008 5:41 pm
Location: Europe
OS: Ubuntu-Mate 18.04

Re: RNAV with KNS80 trouble (NOT SO - PARTIALLY SOLVED)

Postby jogois » Sat Jul 28, 2018 9:29 pm

UPDATE-EDITED-->>: The above has given me a clue of another error in the KNS80.nas file: the variables 'D2R' and 'R2D' are used in KNS80.nas BUT ARE NOT DECLARED!!!: EDITED---->>>My mistake, YES, THEY ARE ALREADY DECLARED IN NASAL (in globals.nas) as explained in http://wiki.flightgear.org/Nasal_library#Variables.

In KNS80.nas R2D is used in line 214, and D2R is used in lines 208,209,210, 211, 225, 229, and 233. Why removing '!' from KNS80.nas file not having the variables declared made the RNAV/ENR mode to work remains a mistery to me--EDITED-->>Not any more, see above!. That fix still works, but in any case the variables --EDITED-->>could<<--EDITED-- be declared in KNS80.nas as they are in kns80.nas, i.e.:

"
var PI=3.14159265;
var D2R=PI/180;
var R2D=180/PI;
"
On the other hand, the kns80.nas file has to include '!' in the condition for the same mode to work, but, we can also make RNAV/ENR work in KNS80.nas without removing the '!' providing that we add '==0' at the end of the condition (same way as shown in kns80.nas):

if(!me.NAV1_IN_RANGE.getValue()==0) {
return;
}


It could even be nonsense in Nasal, but it works.


VOR mode is a different matter.


However speaking of KNS80.nas, VOR/PAR mode's DME distance will work if we add the line "range = distance;" to the mode condition. This way DME distance to the DME station acts as per indicated in KNS80 Pilot's Guide (point 3 of "Controls" section) that is showing the same DME distance as displayed in VOR mode. The modification should be:

"
if ( mode == 1){
fangle = math.abs(selected_radial - radial);
needle_deflection = math.sin((selected_radial - radial) * D2R) * distance * 2;
range = distance;
}
"

Now we need to fix the red NAV flag warning in order to see if the FG's KNS80's CDI acts as the real one and we can fix the rest of the modes, but first we need to find the error there. Next time..., now enough for today.

NOTE: the quotation marks are NOT par of the code modifications and MUST NOT be included.

Jogois
Last edited by jogois on Sun Aug 05, 2018 9:49 am, edited 1 time in total.
jogois
 
Posts: 25
Joined: Thu Dec 25, 2008 5:41 pm
Location: Europe
OS: Ubuntu-Mate 18.04

Re: RNAV with KNS80 trouble (NOT SO - PARTIALLY SOLVED)

Postby wkitty42 » Mon Jul 30, 2018 1:30 pm

just a few more hints...

the "!" means "not"... eg: if (!myproperty == 0) says "if (not myproperty) is equal to zero"... "(not myproperty)" means the opposite of (myproperty)...

myproperty = false (set the property to false)
print myproperty (prints 0 or false)
print !myproperty (prints 1 or true)

generally any non-zero number is seen as true. zero is false.


then, for your code blocks, use the forum's code tags like so...

Code: Select all
[code]
    if ( mode == 1){
        fangle = math.abs(selected_radial - radial);
        needle_deflection = math.sin((selected_radial - radial) * D2R) * distance * 2;
        range = distance;
    }
[/code]


yes, i used code tags to show you how to use code tags :mrgreen:
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 9146
Joined: Fri Feb 20, 2015 4:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 20.04

Re: RNAV with KNS80 trouble (NOT SO - PARTIALLY SOLVED)

Postby jogois » Mon Jul 30, 2018 3:33 pm

Thanks wkitty42. I'll use code tags from now on.

Anyway, what I can see then is that adding '!' to the kns80.nas (that has the ==0) and delete it from KNS80.nas (that hasn't) basically makes those conditionals being the same. That's why adding the '!' to the kns80.nas made it work. I found it just by trial and error, but it is good to know why.

So far, I find no way to link KNS80 to NAV1 to show what it is supposed to do in RNAV (VOR mode apart, and only in case RNAV is not working). That link would lead to the solution.

Thanks again.

Jogois
jogois
 
Posts: 25
Joined: Thu Dec 25, 2008 5:41 pm
Location: Europe
OS: Ubuntu-Mate 18.04

Re: RNAV with KNS80 trouble (NOT SO - PARTIALLY SOLVED)

Postby wkitty42 » Mon Jul 30, 2018 4:01 pm

just to make sure that i'm being clear... let's take the following from your code above and break it down...

if(!me.NAV1_IN_RANGE.getValue()==0)


let's say that time X, me.NAV1_IN_RANGE.getValue() returns 0 (zero)... in this case the code is then

if(!0==0)

which is false because zero does equals zero... now, at time Y, that function returns 1 (one)... now the code is

if(!1==0)

which is true because one does not equals zero...


some might say that the code is using negative logic... this because of "!myvar"... these following two are the same...

if(!me.NAV1_IN_RANGE.getValue()==0)
if(me.NAV1_IN_RANGE.getValue()==1)

notice that there's two differences between them... the '!' and the '1'...


most of the time, in other languages, you'd see something like this, instead... i'm not sure about in this code, though... i've been here 3 years and i'm still learning stuff ;)

if(me.NAV1_IN_RANGE.getValue() != 0)


does that help?
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 9146
Joined: Fri Feb 20, 2015 4:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 20.04

Re: RNAV with KNS80 trouble (NOT SO - PARTIALLY SOLVED)

Postby jogois » Wed Aug 01, 2018 8:14 pm

It really helps, thank you again wkitty42.

In my opinion, little examples like those are more than useful for everyone to understand complex situations. As you can see in my second post in this topic, I did check the Nasal Conditionals Wiki before even considering to remove the '!' in the first place, but in any case focusing only in KNS80.nas at that moment I hadn't checked the condition in kns80.nas file yet. Its somehow more complex logic comes really understandable with clear explanations like yours.

On the other hand, as you can see in almost all my posts of this topic, I've been complaining about a conflict causing VOR mode NOT working properly once the RNAV/ENR (and VOR/PAR) mode is fixed because, instead of getting the actual -real time- DME distance to the station, the KNS80 kept displaying a fixed value that was only refreshed by another fixed one only if switching between modes in the KNS80. The really weird thing is that after the fix, VOR/PAR mode actually gets the real distance to the DME station when adding 'range=distance' expression inside the condition that defines such mode. However, although it is the same expression that is inside the VOR mode condition originally, this one (speaking of KNS80's display) simply doesn't work.

Since the condition that is supposed to check if NAV1 is in range has been proven (in my opinion) to be somehow problematic for the RNAV/ENR and VOR/PAR modes to work properly (again, speaking of the KNS80's display), I just thought WHAT IF the condition ITSELF is the problem, and not the way it was programmed in the first place? After all, no matter how we can change it, the problem still persists. Well, considering this I've commented out the condition, and guess what, YES, now VOR mode ALSO WORKS and gets the correct -real time- DME distance to the station in the KNS80 display, being the rest of the aspects of the mode unaffected and working. I've checked it with the moving map open (also checking the distances against the blue star), and yes it works!!!

The red NAV flag is still there in every mode but in pure VOR.

That condition has been actually conflicting with the updateRNAV function definition, so definitely there is a problem there. Nevertheless, I still think that NAV1_IN_RANGE has to be checked somehow.

More next time.


Jogois
jogois
 
Posts: 25
Joined: Thu Dec 25, 2008 5:41 pm
Location: Europe
OS: Ubuntu-Mate 18.04

Re: RNAV with KNS80 trouble (NOT SO - PARTIALLY SOLVED)

Postby wkitty42 » Wed Aug 01, 2018 9:47 pm

i'm glad that my explanations help you to understand what's going on... not everyone is a programmer but some can pick up some things in relatively simple languages... you're doing good! keep up the good work! :)
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 9146
Joined: Fri Feb 20, 2015 4:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 20.04

Re: RNAV with KNS80 trouble (NOT SO - PARTIALLY SOLVED)

Postby jogois » Fri Aug 03, 2018 11:26 pm

Hi there.

Finally the red NAV flag in RNAV mode is gone!

The conflict was in some other place, but the truth is that the problem with NAV1_IN_RANGE condition has led me to pinpoint where the problem was. Diving into the KNS80.nas file, I couldn't find any other reason that caused the red NAV flag being there every time the RNAV mode was activated, so I reviewed again the other file defining the KNS80 (kns80.xml).

There, in the kns80.xml (in Patten’s Aerostar is in /wherever you have your additional aircraft folder/Aerostar-700/Models/Instruments/kns80”) I saw that in the the Nasal script governing the RNAV.btn object there was a ‘}’ that was closing the (test!=2) condition before setting the property to slave the NAV to the GPS and, therefore, executing this every time and thus making the RNAV of the KNS80 to ALWAYS be slaved to the GPS. That‘s a bug, isn’t it?

The same applies for the kns80.xml in the other affected airplanes’ trees (Ryan-Navion, Lancair-235,etc.), and for the kns80.xml in the MAIN FG INSTALLATION DIRECTORY (in my version – Ubuntu PPA FG 2018.2.1): /usr/share/games/flightgear/Aircraft/Instruments-3d/kns80.

The solution is simple. First KEEP the condition affecting NAV1_IN RANGE in its original form inside KNS80.nas (IT HAS TO BE WHERE IT WAS). The same goes for kns80.nas as well in ITS ORIGINAL form. I just reproduce the one in KNS80.nas here:

Code: Select all
 updateRNAV : func{

   if(!me.NAV1_IN_RANGE.getValue()) {
        return;
    }


then, in kns80.xml, just move the curly bracket to make the property that slaves the NAV to the GPS be INSIDE the conditional:

There it is:

--For the RNAV mode--

Original WRONG kns80.xml (RNAV.btn):

Code: Select all
    <animation>
        <type>pick</type>
        <object-name>RNAV.btn</object-name>
        <action>
            <button>0</button>
            <repeatable>false</repeatable>
            <binding>
                <command>nasal</command>
                <script>
                var test = getprop("/instrumentation/kns-80/nav-mode");
                if(test != 2){setprop("/instrumentation/kns-80/nav-mode",2);
                }else{setprop("/instrumentation/kns-80/nav-mode",3);}<!-------problem here-->
                setprop("/instrumentation/nav/slaved-to-gps", 1);
                </script>
            </binding>
        </action>
    </animation>


Corrected kns80.xml (RNAV.btn):

Code: Select all
    <animation>
        <type>pick</type>
        <object-name>RNAV.btn</object-name>
        <action>
            <button>0</button>
            <repeatable>false</repeatable>
            <binding>
                <command>nasal</command>
                <script>
                var test = getprop("/instrumentation/kns-80/nav-mode");
                if(test != 2){
                    setprop("/instrumentation/kns-80/nav-mode",2);
                }else{
                    setprop("/instrumentation/kns-80/nav-mode",3);
                    setprop("/instrumentation/nav/slaved-to-gps", 1);
                }
                </script>
            </binding>
        </action>
    </animation>



However, the VOR/PAR mode still needs to be corrected since the red NAV flag keeps coming alive there.
Haven’t found the solution yet, but if the property to slave nav to gps is commented out in the VOR.btn object the problem is gone, so it must be over there as well. Any one sees something?

Original xml80.xml (VOR.btn):

Code: Select all
    <animation>
        <type>pick</type>
        <object-name>VOR.btn</object-name>
        <action>
            <button>0</button>
            <repeatable>false</repeatable>
            <binding>
                <command>nasal</command>
                <script>
                var test = getprop("/instrumentation/kns-80/nav-mode");
                if(test != 0){
                    setprop("/instrumentation/kns-80/nav-mode",0);
                    setprop("/instrumentation/nav/slaved-to-gps", 0);
                }else{
                    setprop("/instrumentation/kns-80/nav-mode",1);
                    setprop("/instrumentation/nav/slaved-to-gps", 1);
                }
                </script>
            </binding>
        </action>
    </animation>



UPDATE: if the slaved-to-gps property affecting mode 1 (VOR/PAR) is either commented out or edited to be 0, the red NAV flag also dissapears in VOR/PAR mode. Don't know if is a solution though. It just behaves like that. Below is the edited code for VOR.btn in kns80.xml:

Code: Select all
    <animation>
        <type>pick</type>
        <object-name>VOR.btn</object-name>
        <action>
            <button>0</button>
            <repeatable>false</repeatable>
            <binding>
                <command>nasal</command>
                <script>
                var test = getprop("/instrumentation/kns-80/nav-mode");
                if(test != 0){
                    setprop("/instrumentation/kns-80/nav-mode",0);
                    setprop("/instrumentation/nav/slaved-to-gps", 0);
                }else{
                    setprop("/instrumentation/kns-80/nav-mode",1);
                    setprop("/instrumentation/nav/slaved-to-gps", 0);
                }
                </script>
            </binding>
        </action>
    </animation>





Anyway, as a temporary solution, if someone doesn’t want to slave nav to GPS at all, simply comment out any reference to that property both in VOR.btn and RNAV.btn, and the problem with the red NAV flag would be gone for good.

Corrected kns80.xml -slaved-to-gps- commented out:

Code: Select all
    <animation>
        <type>pick</type>
        <object-name>VOR.btn</object-name>
        <action>
            <button>0</button>
            <repeatable>false</repeatable>
            <binding>
                <command>nasal</command>
                <script>
                var test = getprop("/instrumentation/kns-80/nav-mode");
                if(test != 0){
                    setprop("/instrumentation/kns-80/nav-mode",0);
<!--              setprop("/instrumentation/nav/slaved-to-gps", 0);-->
                }else{
                    setprop("/instrumentation/kns-80/nav-mode",1);
<!--              setprop("/instrumentation/nav/slaved-to-gps", 1);-->
                }
                </script>
            </binding>
        </action>
    </animation>

    <animation>
        <type>pick</type>
        <object-name>RNAV.btn</object-name>
        <action>
            <button>0</button>
            <repeatable>false</repeatable>
            <binding>
                <command>nasal</command>
                <script>
                var test = getprop("/instrumentation/kns-80/nav-mode");
                if(test != 2){
                    setprop("/instrumentation/kns-80/nav-mode",2);
                }else{
                    setprop("/instrumentation/kns-80/nav-mode",3);
<!--              setprop("/instrumentation/nav/slaved-to-gps", 1);-->
                }
                </script>
            </binding>
        </action>
    </animation>


NOTE: because of the ‘slaved-to-gps’ property, if anyone tried the KNS80 Pilot’s Guide flight from KMCI to KMEM planning the flight in the route manager AND with the flightplan ACTIVATED, the perception would have been that the KNS80 was working properly, without being so.

I‘ll keep trying to solve the VOR/PAR mode NAV flag anyway.

However, now that the red NAV flag is not there anymore in RNAV mode, there are some -until now- hidden problems that have aroused and that need to be solved. Just to mention one of them for the moment: the CDI doesn't point to the phantom station (waypoint) but to the actual DME station as in VOR mode--EDITED--> so there is no way to know when we are passing over our waypoint, since the TO-FROM flags will be linked to the real VORTAC station, nor our linear deviation from the waypoint.

More next time.


Jogois
jogois
 
Posts: 25
Joined: Thu Dec 25, 2008 5:41 pm
Location: Europe
OS: Ubuntu-Mate 18.04

Re: RNAV with KNS80 trouble (NOT SO - PARTIALLY SOLVED)

Postby jogois » Sun Sep 02, 2018 7:14 pm

After some time thinking about how I could make the CDI point to the waypoint in RNAV/ENR and RNAV/APP modes I opted to slave the nav property to the KNS-80 so we could fool the nav governed systems (HSI's CDI in particular) to finally get a realistically simulated KNS-80 in FG (I mean without faking its functionality under the GPS). The only values we need for the CDI to point to our phantom station (waypoint) would be (I think) the actual-deg, reciprocal-radial-deg, and heading-needle-deflection (for the course indicator) being the rest of the nodes in the "./instrumentation/nav/radials" path irrelevant. I don't worry about the to-from flag for the moment.

Well, based on that, in addition to the modifications I made to the kns80.xml that I mentioned in my previous post, I commented out ALL references to the GPS in KNS80.nas, and started to consider some options. One was using "listeners", being the other to use "aliases", to “slave” the "/instrumentation/nav/radials/whatever-needed-nodes" (actual-deg, reciprocal-radial-deg, and heading-needle-deflection) to "/instrumentation/kns-80/rnav/whichever-needed-nodes". Then I started playing with the Nasal console.

The problem with the listeners option was that, though it seemed to work (i.e. the CDI pointed to the waypoint) the CDI (just the CDI) blinks between the RNAV and VOR. To get it right I had to speed up the simulation 16x so that the needle would stay where it was supposed to be, that is showing only the RNAV subject. However, since the simulation speed is not affected by those listeners (only the CDI needle display is), after including the proposed listeners into probably the KNS80.nas (or kns80.nas) and/or the kns80.xml, I think that one solution could be to increase the animation speed of the CDI in RNAV mode ONLY (up to 16x I presume), but that is way out of my reach for the moment.


The code (in the Nasal console) for the listeners option:

Code: Select all
setlistener(("/instrumentation/kns-80/rnav/actual-deg"), func(node){
  setprop(("/instrumentation/nav/radials/actual-deg"), node.getValue());
   } ,0,1);
setlistener(("/instrumentation/kns-80/rnav/reciprocal-radial-deg"),func(node){
    setprop(("/instrumentation/nav/radials/reciprocal-radial-deg"), node.getValue());
   } ,0,1);
setlistener(("/instrumentation/kns-80/rnav/heading-needle-deflection"),func(node){
    setprop(("/instrumentation/nav/heading-needle-deflection"), node.getValue());
  } ,0,1);


As I've said, the other option was using alias to pass the values from ../kns-80/rnav/whatever-node to ../nav/radials/whichever-node, and the results were the same as above.

The code (in the Nasal console) for the alias option:

Code: Select all
props.globals.getNode("/instrumentation/nav/radials/actual-deg").alias("/instrumentation/kns-80/rnav/actual-deg");
props.globals.getNode("/instrumentation/nav/radials/reciprocal-radial-deg").alias("/instrumentation/kns-80/rnav/reciprocal-radial-deg");
props.globals.getNode("/instrumentation/nav/heading-needle-deflection").alias("/instrumentation/kns-80/rnav/heading-needle-deflection");


Any ideas?


Well, I'll keep on trying anyway.

More next time.

Jogois
jogois
 
Posts: 25
Joined: Thu Dec 25, 2008 5:41 pm
Location: Europe
OS: Ubuntu-Mate 18.04

Next

Return to Flying

Who is online

Users browsing this forum: No registered users and 3 guests