opengc-devel

[Opengc-devel] NavTestGauge

[Wendell T. <we...@ad...>]

When using OpenGC with FlightGear, and displaying the
NavTestGauge, I can't get the vor or adf needles to
move.  Is that porting working with fgfs?  Are the
needles on OpenGC supposed to track/mimic the ones on
the fgfs panel?  I've tuned the radios in fgfs, but
the needles on the NavTestGauge don't move.  (Maybe
that is why it is called 'Test'?)

Is there a better way to turn off the navaids
and smaller airports other than to edit apt.dat?

Wendell

Re: [Opengc-devel] NavTestGauge

[Damion S. <be...@cs...>]

> When using OpenGC with FlightGear, and displaying the
> NavTestGauge, I can't get the vor or adf needles to
> move.  Is that porting working with fgfs?

There are actually two issues here.

1) Back when the FlightGear data source was designed, FlightGear did 
not support sending nav deflections to external software. OpenGC did 
all of these computations internally, based on its own model of the 
world. For simplicity (and to enforce conformance to the rest of the 
data sources) OpenGC no longer allows the data source to do that. So, 
no, I don't believe that FlightGear is currently capable of sending 
that data to OpenGC. This may/should be a fairly simple matter of 
updating the data output format in FlightGear, but to be honest I 
haven't done much work in that regards. Your best bet may be to get 
someone in FlightGear to volunteer to maintain the data source. The 
rewrite that I did a while back changed the networking behavior but did 
not update the data format in any way.

2) I didn't write the needle code on the nav display, so I can't 
guarantee that it would work even if FlightGear supported the 
appropriate data output. This issue is one I can handle pretty easily, 
and is on my list of things to do already (since it affects all of the 
data sources).

> Is there a better way to turn off the navaids
> and smaller airports other than to edit apt.dat?

Not at this time, no. That's also on the short list of things to do. I 
added zoomin/zoomout buttons last night (which are in the CVS now) 
along with a ground track heading and speed indicator. Thresholding 
airports by runway length is one of the next things I'll be adding.

For the time being, the nav display is not meant to mimic any 
particular aircraft model, merely to provide a platform for developing 
the core functionality (hence "test"). Any suggestions for nice things 
to have would be appreciated. Things which are already on my list 
include:

1) Verify needle and CDI functionality.
2) Range scale (to indicate approximate distances).
3) Better rendering of airports and navaids.
4) More complete data on airports and navaids (particularly runways and 
extended runway centerlines for airports).
5) More control over nav rendering (turn airports/navaids/etc. on/off)
6) Thresholding airports by max runway length

Cheers,
-Damion-

---------
Damion Shelton
Carnegie Mellon University, Robotics Institute
A408-o Newell Simon Hall
412.268.3866 (office)
412.818.8829 (cell)
412.268.6436 (fax)
http://www.cs.cmu.edu/~beowulf
---------
I remember how my great-uncle Jerry would sit on the porch and whittle 
all day long. Once he whittled me a toy boat out of a larger toy boat I 
had. It was almost as good as the first one, except now it had bumpy 
whittle marks all over it. And no paint, because he had whittled off 
the paint.

Re: [Opengc-devel] NavTestGauge

[John W. <ca...@mm...>]

Hi,

The question is one of philosophy and division of labor...

IMO the FG side should do the flying (EOM), scenery, and systems modeling.
The glass displays should act like the flightdeck receiving data from the
aircraft systems. So in that world the display code gets a lat and lon from
the FG side and nav/radio data from the FG receivers. Given that setup, the
display side needs a panel to tune radios and send the frequencies to the FG
side receivers who search the nav world for in-range stations and return the
appropriate data. There should be NO panel displayed on the FG side except
perhaps for thr HUD

Having said that I then turned around and violated my own reasoning and
built a clone of the FG nav data base on the display side and modified the
FG nav/radio code to support situations present in glass displays like
multiple tuned in-range stations for MAP modes, auto-search/tuning when
flying in LNAV mode, etc.  The FG/OpenGC interface gets a bit complicated
with all the hand-shaking required to do this and somewhat
non-deterministic; i.e, the FMC auto-searches for in-range/tunable stations
and may select several to perform a nav calculation or use an INS (lat/lon)
as raw data or correlate with identified stations, especially when flying
great circle routes.

To mitigate the network traffic and the complexity inherent in a variable
length data packet I again felt the clone approach was a reasonable
compromise. So, yes one could allow the FG side to input VOR/Radio
frequencies by then you need to have some sort of signal/semaphore to
exchange to decide who has control.

One advantage of using OpenGC is to reduce the CPU and GPU workload on the
FG side. You can expect around a 15 to 20% inprovement in frame rate by
spreading out the work.

Again, I've not kept pace with the lastest CVS, there may be some legacy
code (circa 2001) that might still work with fgfs... Peraps Damion could
address that better than I.

Regards
John W.


----- Original Message -----
From: "Wendell Turner" <we...@ad...>
To: <ope...@li...>
Sent: Tuesday, September 16, 2003 2:02 PM
Subject: [Opengc-devel] NavTestGauge


> When using OpenGC with FlightGear, and displaying the
> NavTestGauge, I can't get the vor or adf needles to
> move.  Is that porting working with fgfs?  Are the
> needles on OpenGC supposed to track/mimic the ones on
> the fgfs panel?  I've tuned the radios in fgfs, but
> the needles on the NavTestGauge don't move.  (Maybe
> that is why it is called 'Test'?)
>
> Is there a better way to turn off the navaids
> and smaller airports other than to edit apt.dat?
>
> Wendell
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Opengc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengc-devel

Re: [Opengc-devel] NavTestGauge

[Damion S. <be...@cs...>]

> IMO the FG side should do the flying (EOM), scenery, and systems 
> modeling.
> The glass displays should act like the flightdeck receiving data from 
> the
> aircraft systems.

I agree with that setup.

> So, yes one could allow the FG side to input VOR/Radio
> frequencies by then you need to have some sort of signal/semaphore to
> exchange to decide who has control.

Actually, I don't think it's necessarily all that complicated. It 
depends on the data scheme, but as long as you assume that the sim is 
holding the "master copy" of things there's no problem. For each data 
cycle, OpenGC reads the state of the sim, displays the relevant stuff, 
and then writes whatever changes the user requests back to the sim 
(which I suppose would have the option of rejecting the input).

> One advantage of using OpenGC is to reduce the CPU and GPU workload on 
> the
> FG side. You can expect around a 15 to 20% inprovement in frame rate by
> spreading out the work.

Perhaps in regards to the cockpit displays, but I don't think the nav 
stuff requires all that much CPU.

> Again, I've not kept pace with the lastest CVS, there may be some 
> legacy
> code (circa 2001) that might still work with fgfs... Peraps Damion 
> could
> address that better than I.

Well, yes and no. I removed most of the bidirectional stuff when I 
converted to plib networking for flightgear. The old flightgear 
interface didn't work on Windows, whereas the new one does. I think the 
main issue now is exporting the nav needle positions correctly, which I 
don't think should be _that_ big of a deal.

Cheers,
-Damion-

---------
Damion Shelton
Carnegie Mellon University, Robotics Institute
A408-o Newell Simon Hall
412.268.3866 (office)
412.818.8829 (cell)
412.268.6436 (fax)
http://www.cs.cmu.edu/~beowulf
---------
I remember how my great-uncle Jerry would sit on the porch and whittle 
all day long. Once he whittled me a toy boat out of a larger toy boat I 
had. It was almost as good as the first one, except now it had bumpy 
whittle marks all over it. And no paint, because he had whittled off 
the paint.