opengc-devel Mailing List for Open-source Glass Cockpit (OpenGC) (Page 6)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

 a quick addendum regards windows; check out

http://www.beyondlogic.org/index.htm#DeviceDrivers

might be helpful if your building your own boards

JW

> Well remember, FlightGear does run in Windows. :)
>
Well, I don't want to get into a flame war, however FG runs on windows
because a few dedicated souls (like Curtis Olson) strive to make the program
cross-platform compliant, and it's not always easy or fun...

If you want to build a world-class simulator you need access to the OS
internals and the ability to control hardware other than through the
application layer. And peek and poke just don't cut it.

But from what I've seen, the market is for hardware and interfaces to work
with and in the windows environment so one either goes with the flow, sets
their own course, or does without.

Enjoyed the stories and pics on your website. These projects have a way of
consuming us, don't they?  ;-)

Regards
John W.

> >
> Not all that familiar with EPIC.
EPIC is a fairly high end solution due to the cost of the gear.  It's not
cheap. :)

> Sounds like you are using Windows.  And the software provided by phidget is
> windows based. so you either roll your own for Linux or make do with the
> stuff in sourceforge.
>
I'm using Windows for all my initial development work.  Once I've got all
the hardware done, I'll run both Windows & Linux.

> I still like my board that drives 16 digits and runs in Linux kernel space
> on an interrupt basis. I never liked windows as an OS for simulation. As an
> engineer I like to know ALL the details and I don't think MS is going to
> release source any time soon...
>
Well remember, FlightGear does run in Windows. :)

> Is your Eagle a C or E model? Still living with steam gauges... ;-)
>
It's a C model.  Everything with the exception of the MPCD, VSD and TEWS
is steam.  I got really lucky and nailed down a real HSI and a
built-for-simulation-use ADI.  All my hydraulic and engine guages are
scratch built by a friend of mine and the others will be gutted and
rebuilt, with the exception of the ADI and HSI.  Those will eventually be
driven "as designed".

g.

Hi Manuel,

> > Over the course of the last year I've been trying to find simulation
hardware (MCP,EFIS,EICAS,etc) that works with Linux and would support open
source programs like FlightGear and OpenGC. All I could find was Windows
stuff ( EPIC, FSUIPC, etc). And there did not seem to be a lot of interest
in developing stuff for open source software under Linux.
>
> Sadly, this is true. Maybe Flightgear will change this in the future.
> In the home cockpit building community, Linux and flightgear don't seem
> to be very well known and used.
>
I suspect if you surveyed the users you would find most are not deeply
involved in software, but rather the hardware aspects of building something
tangible so windows and windows-related hardware provide a nice comfort
zone.

> I think that flightgear is especially suited for that since its open
> source so you can get information in and out easily and dont have to
> rely on peek'ing and poke'ing the memory of the running simulator
> program.
>
Right, you need to get to the kernel and leave the application alone.

> I thing all other things except the analog inputs will not be driven by
> a kernel driver, but rather by a user mode program that can connect to
> flightgear. That way, I can specify mappings eg. for the switches
> without having to unload/reload the kernel module over and over.
>
Running is kernel space is both risky and very effective. In my case, the
driver works with the hardware and never bothers the application (FG and
OpenGC) which simple poll the driver. Displays, LEDs, switch states are all
updated based on hardware interrupts and the application never sees or hears
about it.

> Costwise, I estimate my currently "in-progress" circuit schematic would
> cost around $50-70 in components, depending on the prices of your
> suppliers.
>
There are some sites that provide circuit design, PCB layout software and
prices vary also as well with quantities purchased. Looks like my component
costs for the MCP are around $30 to $35 but then I've kept the interface
simple by using the parallel port so after you buy a PCI board ($40) it
turns out to be a wash... And the start-up costs for the PCB range from $50
to $80 for the first unit. Then throw in some sockets, connectors, and
you're over the century mark.The panel, produced by AGT, is excellent and
with all the lights and switches goes for $325. This can be an expensive
hobby...
>
> I'm glad I'm not alone doing things like that under linux.
>
I don't think there are a lot of us ;-)

> If you are interested, I can send you a png of the circuit I'm working
> on right now.
>
I would appreciate that; Don't have a schematic of the my circuit, just a
bunch of notes and scribbles which I need to turn into a finshed product
with a circuit design tool to do a PCB layup. There are some boards at
www.phdigit.com that you might take a look at, only drawback ( I think ) is
software is for windows. Still researching it.

BTW, if your not familiar with Rubini's book on linux device drivers,
recommend it highly. Google on device drivers or go to the O'Reilly website.
Text and source are online and GPL'd

Thank you for your comments

Regards
John W.

Hi John,

On Thu, Sep 18, 2003 at 10:50:24AM -0700, John Wojnaroski wrote:
> Hi,
> 
> Over the course of the last year I've been trying to find simulation hardware (MCP,EFIS,EICAS,etc) that works with Linux and would support open source programs like FlightGear and OpenGC. All I could find was Windows stuff ( EPIC, FSUIPC, etc). And there did not seem to be a lot of interest in developing stuff for open source software under Linux.

Sadly, this is true. Maybe Flightgear will change this in the future.
In the home cockpit building community, Linux and flightgear don't seem
to be very well known and used. 

I think that flightgear is especially suited for that since its open
source so you can get information in and out easily and dont have to
rely on peek'ing and poke'ing the memory of the running simulator
program.

> Well, I never followed the herd and was not about to move over to Windows or FSxxxx.

That would be a step back, wouldn't it :-)

> So I sat down and designed an interface board for the MCP and EFIS as starters. Turns out, the board is somewhat generic in that it takes rotary enconder data and key scan circuits and along with the Linux driver stuffs the data into a small file that the application can read/write. Using the board goes like this:
> 
> The board has a standard parallel port interface (I wanted to use IEEE1284 EPP but opted for the most common, simplest for the moment). It will run either on your printer port or any additional parallel port board (ISA or PCI) you care to install or I've got a custom ISA board with three programmable ports I used for development and testing.

I've done something very similar. I'm using the serial port, however.
The whole thing is based on microchips PIC line of microcontrollers.
(Like someone else pointed out in this thread, these are very good for
our purposes)

Right now I'm tying things together to build a board that can take up to
1024 inputs (switches/rotaries/..), 35 analog input channels, 
and 64 digital 8 bit channel outputs for things like 7segment displays,
steppers, Digital to analog,...

I've written a joystick kernel driver for linux for a earlier 16 channel
analog to digital system. And its Flightgear tested :-)

I've made Panels myself for a 747-400 MCP and EFIS. 

I thing all other things except the analog inputs will not be driven by
a kernel driver, but rather by a user mode program that can connect to
flightgear. That way, I can specify mappings eg. for the switches
without having to unload/reload the kernel module over and over.

> So if you were running a MCP panel the data would be airspeed, mach, heading, vvi, and altitude. Plus the state of the pushbutton switches on the panel which would go to the FMC for the appropriate action and control of the system autopilot(s) and such. Or you could configure it as a NAV/RADIO panel and process the data as frequencies. Or whatever..... 
> 
> The board and driver run in kernel space and use an interrupt to process changes in the state of the connected panel
> 
> I'm still testing the board but getting close to a decision on moving from a breadboard to a PCB layout. Best guesstimate on cost is between $100 and $200. ( I have no idea on what the manufacturing costs beyond the production of the bare PCB look like, as always very dependent on size of the lot and quantity discounts for parts and amortization of start-up costs,etc,etc)

Costwise, I estimate my currently "in-progress" circuit schematic would
cost around $50-70 in components, depending on the prices of your
suppliers.

> Trying to gauge the interest in such an item and welcome any feedback, questions, etc.
> 
> For a look at some of the hardware panels I plan to use check out http://www.a-g-t.com

I'm glad I'm not alone doing things like that under linux.

Some older circuits and pics of my MCP/EFIS panels can be found at my
home cockpit site: http://cockpit.varxec.de/ 

If you are interested, I can send you a png of the circuit I'm working
on right now.

Oh, and - of course - everything is released under the GPL, including
the PIC assembly language firmware programs.

Regards, 
Manuel

Hi,

I apparently misunderstood the status of FSUIPC support within OpenGC. 
A new version of the FSUIPC library is _not_ needed to be compatible 
with FSUIPC 3.0+ (in fact, the library version in release 15 of the SDK 
dates back to 2000). Therefore:

a) If you're using FSUIPC 2.97 or less with FS2002 or earlier, OpenGC 
will continue to work (for free).

b) If you're using FSUIPC 3.0+ with FS2004, OpenGC will also work. Note 
that if you are using 3.0+, the registration information provided in 
the earlier emails is still accurate.

OpenGC 0.55 is now available for Windows (in addition to the Mac 
version mentioned in the email yesterday). Linux users should be able 
to roll their own release from source without running into compile 
problems.

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 hope that after I die, people will say of me: "That guy sure owed me 
a lot of money." 

I feel like I've been doing this a lot lately, but OpenGC 0.55 is out 
for Mac and should be available for Windows by tomorrow evening. It 
adds a few experimental features to the nav display (ground track 
information and zoom buttons), which will probably change dramatically 
by the time anything near the final release occurs. Also available is 
preliminary NMEA GPS string parsing for the EGyro folks.

0.55 will probably be the last release for a couple of weeks. I have a 
number of issues I'd like to address more completely before issuing 
another. The flurry of recent changes has primarily been to iron things 
out prior to the Avsim conference and take care of a few EGyro items I 
procrastinated on from earlier in the summer.

For developers: 0.55 is in sync with the CVS, which should be stable 
for at minimum the next five days, most likely until the beginning of 
October. At this point in time everything _should_ be building smoothly 
on all platforms.

Any questions or problems, don't hesitate to ask.

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 hope that after I die, people will say of me: "That guy sure owed me 
a lot of money." 

>
> > I do like that 0/256/0 prototyping kit. Will it handle static switches
and
> > momentary switches?
> >
> It works just like the EPIC does.  You can get it in a 16x16 matrix or an
> EPIC wiring-compatible 8x32 matrix.  You use diodes just like in EPIC to
> isolate the switches.  Both momentary and on/off switches can be used.
>
Not all that familiar with EPIC.
Sounds like you are using Windows.  And the software provided by phidget is
windows based. so you either roll your own for Linux or make do with the
stuff in sourceforge.

I still like my board that drives 16 digits and runs in Linux kernel space
on an interrupt basis. I never liked windows as an OS for simulation. As an
engineer I like to know ALL the details and I don't think MS is going to
release source any time soon...

Is your Eagle a C or E model? Still living with steam gauges... ;-)

Regards
John W.

> > There is a 7 segment controller that will drive 8 digits each.  I'm using
> > one of them to handle my VHF radio panel.  They're very easy to use and
> > since they're USB, you can use as many as you need. (up to the USB max of
> > course)
> >
> Looked and looked; could not find the above mentioned item. Is there a part
> number?
>
It's called the PhidgetLED.  I didn't spot it either - Chester may have
not begun to sell them yet.

> I do like that 0/256/0 prototyping kit. Will it handle static switches and
> momentary switches?
>
It works just like the EPIC does.  You can get it in a 16x16 matrix or an
EPIC wiring-compatible 8x32 matrix.  You use diodes just like in EPIC to
isolate the switches.  Both momentary and on/off switches can be used.

g.

Hi Gene,

> There is a 7 segment controller that will drive 8 digits each.  I'm using
> one of them to handle my VHF radio panel.  They're very easy to use and
> since they're USB, you can use as many as you need. (up to the USB max of
> course)
>
Looked and looked; could not find the above mentioned item. Is there a part
number?

I do like that 0/256/0 prototyping kit. Will it handle static switches and
momentary switches?

Thanks for the input.

Regards
John W.

> I looked at that site a while back, but again not convinced it meets the
> test. For example, how would you drive an array of 16 7-segment LEDs? OTH
> there are some items there that are interesting, but again did not see
> anything that would drive/interface to something like an MCP and EFIS panel
> as a single package.
>
There is a 7 segment controller that will drive 8 digits each.  I'm using
one of them to handle my VHF radio panel.  They're very easy to use and
since they're USB, you can use as many as you need. (up to the USB max of
course)

> Have you used these products in your sim? >

I currently use both EPIC and Phidgets in my sim.  I'm using 1 of the 7
segment controllers as I mentioned as well as 3 of the 32/32 I/O boards
and 1 of the 0/256/0 boards.  I'm also using 2 of the 8 servo boards and 1
of the 4 servo boards for driving custom built gauges.

The 7 segment controller can also be set up to drive 64 LEDs directly.

You might want to check out http://www.737flightsim.com - David is using
Phidgets exclusively with his project.

If you have any questions about Phidgets, I'd be more than happy to help.

g.

Hi Gene

I looked at that site a while back, but again not convinced it meets the
test. For example, how would you drive an array of 16 7-segment LEDs? OTH
there are some items there that are interesting, but again did not see
anything that would drive/interface to something like an MCP and EFIS panel
as a single package.

Have you used these products in your sim?

Regards
John W.

----- Original Message -----
From: "Gene Buckle" <ge...@de...>
To: <ope...@li...>
Sent: Thursday, September 18, 2003 11:16 AM
Subject: Re: [Opengc-devel] Linux Hardware

>
>
> On Thu, 18 Sep 2003, John Wojnaroski wrote:
>
> > Hi,
> >
> > Over the course of the last year I've been trying to find simulation
> > hardware (MCP,EFIS,EICAS,etc) that works with Linux and would support
> > open source programs like FlightGear and OpenGC. All I could find was
> > Windows stuff ( EPIC, FSUIPC, etc). And there did not seem to be a lot
> > of interest in developing stuff for open source software under Linux.
>
>
> John, you missed out on the Phidget (httpd://www.phidgets.com).  There is
> a Linux driver available on SourceForge and someone has also done work on
> a Mac OSX version.  It works very similar to EPIC, but is _vastly_ cheaper
> to use and more oriented to software developers.
>
> g.
>
> --
> Proud Owner of 80-0007
> http://www.f15sim.com
>
>
>
>
> -------------------------------------------------------
> 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

On Thu, 18 Sep 2003, John Wojnaroski wrote:

> Hi,
>
> Over the course of the last year I've been trying to find simulation
> hardware (MCP,EFIS,EICAS,etc) that works with Linux and would support
> open source programs like FlightGear and OpenGC. All I could find was
> Windows stuff ( EPIC, FSUIPC, etc). And there did not seem to be a lot
> of interest in developing stuff for open source software under Linux.

John, you missed out on the Phidget (httpd://www.phidgets.com).  There is
a Linux driver available on SourceForge and someone has also done work on
a Mac OSX version.  It works very similar to EPIC, but is _vastly_ cheaper
to use and more oriented to software developers.

g.

-- 
Proud Owner of 80-0007
http://www.f15sim.com

Hi,

Over the course of the last year I've been trying to find simulation =
hardware (MCP,EFIS,EICAS,etc) that works with Linux and would support =
open source programs like FlightGear and OpenGC. All I could find was =
Windows stuff ( EPIC, FSUIPC, etc). And there did not seem to be a lot =
of interest in developing stuff for open source software under Linux.

Well, I never followed the herd and was not about to move over to =
Windows or FSxxxx.

So I sat down and designed an interface board for the MCP and EFIS as =
starters. Turns out, the board is somewhat generic in that it takes =
rotary enconder data and key scan circuits and along with the Linux =
driver stuffs the data into a small file that the application can =
read/write. Using the board goes like this:

The board has a standard parallel port interface (I wanted to use =
IEEE1284 EPP but opted for the most common, simplest for the moment). It =
will run either on your printer port or any additional parallel port =
board (ISA or PCI) you care to install or I've got a custom ISA board =
with three programmable ports I used for development and testing.

Installing/using the board is standard Linux.

Compile the module driver -- source and makefiles will be provided

Create the device -> mknod /dev/mcp u 254 0

Install the modules -> insmod mcp.o

Create you application -> something like this
/**********************
main()
{
:
fd =3D open( "/dev/mcp",  O_RDWR);

int result =3D read(fd, mesg, sizeof mcp_data);
// Convert from char string to data types
memcpy( char * &mcp_data, char * &mesg, sizeof mcp_data );
// Now do your application stuff whatever
:
:
close(fd);=20
}
*******************/
So if you were running a MCP panel the data would be airspeed, mach, =
heading, vvi, and altitude. Plus the state of the pushbutton switches on =
the panel which would go to the FMC for the appropriate action and =
control of the system autopilot(s) and such. Or you could configure it =
as a NAV/RADIO panel and process the data as frequencies. Or =
whatever.....=20

The board and driver run in kernel space and use an interrupt to process =
changes in the state of the connected panel

I'm still testing the board but getting close to a decision on moving =
from a breadboard to a PCB layout. Best guesstimate on cost is between =
$100 and $200. ( I have no idea on what the manufacturing costs beyond =
the production of the bare PCB look like, as always very dependent on =
size of the lot and quantity discounts for parts and amortization of =
start-up costs,etc,etc)

Trying to gauge the interest in such an item and welcome any feedback, =
questions, etc.

For a look at some of the hardware panels I plan to use check out =
http://www.a-g-t.com

Regards
John W.

That's a great idea, thanks. It was bothering me a bit that people 
would have to pay money to use free software...

As soon as it's released I'll give it a try. For maximum compatibility 
we may keep dual interfaces for a while (since it doesn't sound like 
that would be extra work), although if both FS2002 and 4 are supported 
there's probably not any reason to.

Your project looks great by the way! Seems that not attempting to 
support everything under the sun has allowed you to progress quite a 
bit further in other areas. I'll be sure to give you a plug in the 
presentation I'm giving at the Avsim conference.

Cheers,
-Damion-

On Wednesday, September 17, 2003, at 04:20 PM, 
Mic...@ai... wrote:

> Hi Damion,
>
> This was an announcement made a few days ago on our new site
> (www.flightdecksoftware.com)
>>
> FDS is proud to report that FDSConnect is now as good as ready and 
> will be
> released within a few days. FDSConnect is a FSUIPC-like interface 
> towards
> FS2004/2002. Much like FSUIPC, FDSConnect makes FS2004/2002 look like 
> FS98.
> FS2004/2002 variables can be found at the same offsets they were in 
> FS98
> and currently are in FSUIPC. Unlike FSUIPC, FDSConnect is and WILL 
> REMAIN
> freeware. For (freeware) developers who are, like us, very unpleased 
> with
> the fact that FSUIPC/WideFS is now payware, switching to FDSConnect is 
> just
> a matter replacing a few function calls. The first release of 
> FDSConnect
> will be FS2004-only but as there are still numerous people flying 
> FS2002
> users we will work hard to get a FS2002 version ready within a few 
> Weeks.
> Off course we are already working on FDSWideConnect, and FDSWideView 
> which
> will both be released within a few weeks.
> <
> After reading your mail I thought this might interrest you.
> Cheers,
> Michael De Feyter

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

Hi Damion,

This was an announcement made a few days ago on our new site
(www.flightdecksoftware.com)
>
FDS is proud to report that FDSConnect is now as good as ready and will be
released within a few days. FDSConnect is a FSUIPC-like interface towards
FS2004/2002. Much like FSUIPC, FDSConnect makes FS2004/2002 look like FS98.
FS2004/2002 variables can be found at the same offsets they were in FS98
and currently are in FSUIPC. Unlike FSUIPC, FDSConnect is and WILL REMAIN
freeware. For (freeware) developers who are, like us, very unpleased with
the fact that FSUIPC/WideFS is now payware, switching to FDSConnect is just
a matter replacing a few function calls. The first release of FDSConnect
will be FS2004-only but as there are still numerous people flying FS2002
users we will work hard to get a FS2002 version ready within a few Weeks.
Off course we are already working on FDSWideConnect, and FDSWideView which
will both be released within a few weeks.
<
After reading your mail I thought this might interrest you.
Cheers,
Michael De Feyter

Hi,

I talked to Pete Dowson, developer of FSUIPC, yesterday and verified 
where OpenGC stands in regards to working with the new payware version 
of FSUIPC. Basically, OpenGC will work fine without any special 
registration provided the user already has a registered copy of WideFS. 
A registered copy of FSUIPC is _not_ required, unless you want to run 
OpenGC on the same machine as the sim (which I discourage for 
performance reasons).

This means that if you are using OpenGC with the FSUIPC data source, 
you should purchase your 3.0+ copy now to avoid problems when we make 
the switch (probably soon). I would like to have the switch 
accomplished before the Avsim conference next week, and will be out of 
town from Friday through the beginning of the conference, so this will 
likely happen tomorrow evening.

Once the switch occurs, we will no longer support earlier (i.e. 
freeware) versions of FSUIPC. The payware version of FSUIPC will, 
however, work with older versions of Flight Simulator, so OpenGC will 
support those as well as the latest and greatest.

Cheers,
-Damion-

---------
Damion Shelton
The Open Source Glass Cockpit Project (OpenGC)
Carnegie Mellon University, Robotics Institute
http://www.opengc.org
da...@op...

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

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

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

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

As you may be aware, the FSUIPC software that OpenGC uses to access the 
Microsoft Flight Simulator line has recently shifted to a payware 
model. I had explored getting OpenGC free access to FSUIPC through the 
author's freeware accreditation process, but it looks like the need to 
use the WideFS program will complicate this.

Right now it appears that users will be required to register WideFS 
regardless of the status of OpenGC as accredited freeware or not. This 
means that going through the accreditation process, which would make 
the builds more complicated, is only worthwhile if we want to run on 
the same computer as FS2000x without WideFS. I have tended to 
discourage people from doing this because of the performance hit 
incurred, so it looks like the build process will be the same but users 
(and developers) will be required to register WideFS in order to use 
OpenGC with FS200x.

This does NOT affect the use of OpenGC on Windows for data sources 
other than FSUIPC - it will still build and run the same, the only 
difference being that if you attempt to connect with an unregistered 
copy of WideFS it won't work. Because of library differences, we will 
no longer support versions of FSUIPC < 3.0. I'm still verifying with 
the author what exactly will need to be registered - just WideFS, or 
both WideFS and FSUIPC - in order to keep things running as they are, 
and will pass this info on once I know.

For reference, current costs are $20 for either WideFS or FSUIPC, or 
$30 for both.

Cheers,
-Damion-

---------
Damion Shelton
The Open Source Glass Cockpit Project (OpenGC)
Carnegie Mellon University, Robotics Institute
http://www.opengc.org
da...@op...

On Tue, Sep 16, 2003 at 01:23:51PM -0400, Damion Shelton wrote:

> I would suggest that in general you try and stick with the versions of 
> the libraries that are included in the OpenGC repository

Duh!  I was just going off of the build web page, now I see that
ExternalLibraries contains the 'right' versions of things.

> So my understanding is that it's not even in alpha yet.

I guess I should have read the fine print first!

Thanks,

Wendell

Hi,

I would suggest that in general you try and stick with the versions of 
the libraries that are included in the OpenGC repository (unless of 
course, I screw something up and those don't work either). I only 
switch to newer versions of the libraries if there's something new that 
they offer that's really compelling, because of problems like you 
encountered.

> -- fltk-2.0.x bad; fltk-1.1.3-source.tar.gz good

I think the FLTK problem deserves particular discussion - version 2.0 
is _dramatically_ different than 1.x. The current CVS of 2.0 doesn't 
even build on the Mac, nor is it particularly stable on other platforms 
either. From the FLTK web page:

"FLTK 1.1.x is the current stable release branch. FLTK 2.0 is currently 
in development and available via CVS. Please see the software page for 
details. The first 2.0 alpha releases will likely appear mid-2003, with 
a final release around the end of 2003."

So my understanding is that it's not even in alpha yet. I'd really like 
to see 2.0 out and working, because we have some problems at work that 
are FLTK related and are unlikely to be resolved in the 1.x branch. 
Until then, I would suggest using a 1.1 release.

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 hope that after I die, people will say of me: "That guy sure owed me 
a lot of money."

Thanks again for all of the work in OpenGC.  A month or so
ago I downloaded everything (onto RedHat Linux) and got it
running.  I tried it yesterday, getting the latest versions
of everything, and things didn't go well.

-- freetype-2.1.5 bad; freetype-2.1.4 good

The latest FTGL references FT_Open_Flags, which is not in
2.1.5, but is in 2.1.4.

-- fltk-2.0.x bad; fltk-1.1.3-source.tar.gz good

In OpenGC, ogcRenderWindow.cpp includes FL/Fl.h, which isn't
in 2.0.x.

However, using earlier versions of those may have caused
this error:

  Source/Base/main.o(.text+0x45): undefined reference to
  `fltk::repeat_timeout(float, void (*)(void*), void*)'

I went back to the previous version from a month ago, and it
works fine.

Wendell

2001	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct (22)	Nov (3)	Dec
2002	Jan	Feb	Mar (3)	Apr	May	Jun	Jul (2)	Aug (3)	Sep (12)	Oct (31)	Nov (6)	Dec (2)
2003	Jan (1)	Feb	Mar (5)	Apr (9)	May (18)	Jun	Jul	Aug (7)	Sep (56)	Oct (23)	Nov (7)	Dec (7)
2004	Jan (2)	Feb (2)	Mar (7)	Apr (26)	May (3)	Jun	Jul (2)	Aug	Sep	Oct (6)	Nov (5)	Dec
2005	Jan	Feb (2)	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov (1)	Dec
2006	Jan	Feb	Mar	Apr (2)	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2007	Jan	Feb	Mar	Apr	May	Jun	Jul (1)	Aug	Sep	Oct	Nov	Dec

opengc-devel Mailing List for Open-source Glass Cockpit (OpenGC) (Page 6)

opengc-devel — Developer's discussion list