okay. looks like i've got some homework to do... the more i get into this the more impressive this project seems.
i guess i need to try to start with the following two things: 1) is there a single set of classes i can look at to try to understand event processing as it relates to the main frmae painting loop? 2) if i started with a single switch tied into a serial or USB port as a means of beginning to understand the hardware/software interface, what parts of that "internal dynamics disabled" client versoin of FG would i look into. i'm kind of curious anbout the layout of the project too. if i had been setting it up, i'd have been tempted to create a directory for "Radios", at the same level as Instruments and Network. this is where i'd have parked stuff for Nav, Comm, GPS, and other radio sets. where is this info hiding (you can see i've just started skimming the direcctory structure at this point. martin --- "Curtis L. Olson" <[EMAIL PROTECTED]> wrote: > martin pardee wrote: > > >harald, > > > >thanks for the pointer. just one question though: what role does the FG > >client" play in the system? (if the answer is that i should go read the > code > >and find out then i'll go do that). > > > > > > Client, server, master, slave are overloaded buzzwords. :-) > > FlightGear can be configured to act like a telnet or even an http > "server". It can watch a port for incoming connections and respond > appropriately. > > FlightGear can also be configured to dump UDP or TCP data packets out > over the network at a high speed. Other copies of FG can be configured > to read these packets and use that data (and disable the internal > dynamics calculations.) In this case, depending on your command line > options, FG can be configured to be a telnet server, an http server, a > "dynamics" master/server, or a "dynamics" slave/client, and possibly > some combination of all of those simultaneously depending on the context > and what you are trying to accomplish. > > >it sounds like FG is set up to "talk" to another process over the net, > > > > Yes, with several approaches and mechanisms supported. Different > approaches are best suited for different uses. > > >treating that process as a netwrok client in the classic 2-tier > "client-server" model. > > > > > > Yes, we can do that. > > >if this is correct, then it suggests that my hardware interface software is > >going to place requests (via telnet) to the "server", e.g. FG, and ask for > the > >contents of member variables that hold frequency data, and submit "event > >notifications" when i've moved a control knob on my hardware. > > > >how am i doing so far? > > > > > > Yes we can do it that way. Using the telnet interface, your own custom > client software can request the value of any variable at any time. You > can also update the value of any other variable at any time. The > overall bandwidth of the telnet interface is not very high though so > it's not appropriate for blasting all the flight dynamics data at 60hz > for instance, but for your application it probably will work very well > ... and I can imagine ways to cheat that would make it look like it was > working even better than it actually was. (For instance, you might get > some delay if you turn the knob, send the data to FG, and then read the > new frequency back from FG, but if you know locally how far your knob > turned, you can update your local display immediately, and then sync up > with FG at a slower rate.) > > 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 > _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
