martin pardee wrote:

folks:

i just joined your mailing list. and i've probably jumped into the wrong one.

(and i'm about to start rambling, so if you're impatient,  delete this now...)

i am looking for some pointers on hardware interface.

after running the FlightGear sim on my box, i'd say it's a pretty mature
product at this point, and i'm not sure my C++ is well-oiled enough to make a
contribution.


i started looking at flight gear hoping that there would be a way to get at
system internals from "outside the box" so that i could build my own "simulated
radio stack" and hook it up.

after searching the web site, i came to the conclusion that the developers
mailing list was a close as i was going to get to discovering internals without
downloading the CVS tree and reading sorce code for 6 months.

can anyone tell me if there is already a part of your project devoted to this, or if you think it's even worth trying? i don't want to drive your project
members crazy reading email from someone who has an interest that your (really
cool by the way) project doesn't support, or plan to.



As I understand it, you'd like to build a hardware radio stack and interface it to FG. There are a couple of ways you could attack this.


1. Add a module (i.e. some code) inside FG that runs every frame. Your code would read all your hardware switches through whatever mechanism you have devised and update the FG internals. It would also send things like frequencies (probably cooked up in the best flavor for your hardware) so that the radio stack can display the frequencies.

2. You could go for total separation and create an external application that talks directly to your hardware. That application could then communicate with FG via the "telnet" interface to read the necessary FG property values to update your hardware display, and write the switch/knob values back to FG as input to it's radio models.

There are probably a variety of other ways you could get this done, but these two approaches are the ones that jump to the front of my list. The first approach would require a bit more digging into the FG internals, the 2nd approach could have potentially sluggish performance. The "telnet" interface is the ultimate in flexibility, but is not anywhere close to high bandwidth.

Regards,

Curt.

--
Curtis Olson http://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/
FlightGear Project http://www.flightgear.org
Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d



_______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d

Reply via email to