Re: [Flightgear-devel] Radio Hardware.
that last phrase caught me off guard. very funny! just hope she never reads this... --- Gene Buckle <[EMAIL PROTECTED]> wrote: > > the prize (or title, or whatever) if there is one. if you don't mind my > > asking, though, are you a single guy? or do you have the ability to > > filter out high decibel audio??? > ...forgot this bit.. :) > > I am in fact married. She's a very good and understanding woman. > Besides, she knows the alternative is beer and strip clubs. :) > > g. > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > __ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Radio Hardware.
> > The HUD for the F-15 is a real one. Only the combining glasses are "home > > made". The HUD optics came out on the short end of the stick in the > > crash of the jet it was in. The original combiners are made of .250" > > quartz glass with some kind of semi-reflective coating. I've been told > > that the coating is gold. > > Have you checked places that sell laser stuff ? > You might be able to get mirrors with semi-reflective coating. Those > mirrors I've seen might be gold coated, the color looks like it could be > gold. > The main problem is cost. Even if I could afford to have a new set of combining glass made, the main reflection mirror needs to be replaced to. That little gem is a front-surface mirror that definately uses gold. It's just too costly for me to worry about right now. I've got a ton of other things that will nickel and dime me to death long before I get to rebuilding the HUD. I may end up stealing parts out of the working A7 HUD I have. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Radio Hardware.
On Tue, Sep 07, 2004 at 06:52:36PM -0700, Gene Buckle wrote: > > you win! anyone who's willing to fabricate their own HUD i think should > > take the prize (or title, or whatever) if there is one. if you don't > > mind my asking, though, are you a single guy? or do you have the > > ability to filter out high decibel audio??? > > > > The HUD for the F-15 is a real one. Only the combining glasses are "home > made". The HUD optics came out on the short end of the stick in the > crash of the jet it was in. The original combiners are made of .250" > quartz glass with some kind of semi-reflective coating. I've been told > that the coating is gold. Have you checked places that sell laser stuff ? You might be able to get mirrors with semi-reflective coating. Those mirrors I've seen might be gold coated, the color looks like it could be gold. Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Radio Hardware.
Hi Matin, On Mon, Sep 06, 2004 at 05:33:58PM -0700, martin pardee wrote: > it would make sense for the sim to support a "pub-sub" framework. centralizing > the messaging would be a way of 1) makeing sure that this wheel doesn't get > re-invented too often and 2) make sure that the performance hit takes place > only once as well. yes I agree. Thats the reason I have my own prop tree where further processing takes place. Eg. take the AP altitude and push it out on the assigned 7segment displays, decoding the number to the way the 7segment displays are hooked up. > i'd think that somewhere inside here there's a orimary loop that controls when > stuff gets rendered onscreen, which seems like it would have been a good place > to manage other real-time like things. somewhere in here it might be nice to > place a trigger for messaging. > > would you know of something like this hiding in the code somewhere? no. my idea is to be based mostly around the property tree. when some subscribed-to value changes, push out the notice with the new value. Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Radio Hardware.
> the prize (or title, or whatever) if there is one. if you don't mind my > asking, though, are you a single guy? or do you have the ability to > filter out high decibel audio??? ...forgot this bit.. :) I am in fact married. She's a very good and understanding woman. Besides, she knows the alternative is beer and strip clubs. :) g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Radio Hardware.
> you win! anyone who's willing to fabricate their own HUD i think should > take the prize (or title, or whatever) if there is one. if you don't > mind my asking, though, are you a single guy? or do you have the > ability to filter out high decibel audio??? > The HUD for the F-15 is a real one. Only the combining glasses are "home made". The HUD optics came out on the short end of the stick in the crash of the jet it was in. The original combiners are made of .250" quartz glass with some kind of semi-reflective coating. I've been told that the coating is gold. I haven't been keeping a close eye on the hardware discussion, but interfacing to FG is very easy. I hope to be able to do some work with interfacing Manuel's (sp?) hardware for a how-to I've been picking at for the past few months. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Radio Hardware.
Gene, you win! anyone who's willing to fabricate their own HUD i think should take the prize (or title, or whatever) if there is one. if you don't mind my asking, though, are you a single guy? or do you have the ability to filter out high decibel audio??? martin :) --- Gene Buckle <[EMAIL PROTECTED]> wrote: > > others engaged in this activity. i fell a little less like a reclusive > > nut case :) > > > Heh. Someone mentions nutcases, and I feel obligated to speak up. :) > See http://www/f15sim.com for the precise definition of "nutcase". See > www.737simguy.com, www.737sim.com, 737flightsim.com and www.simpits.org > for further examples. *grin* > > FG is the easiest of the lot to interface to, but like most it requires > programming a bit to do. > > g. > > > ___ > 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
Re: [Flightgear-devel] Radio Hardware.
manuel, it would make sense for the sim to support a "pub-sub" framework. centralizing the messaging would be a way of 1) makeing sure that this wheel doesn't get re-invented too often and 2) make sure that the performance hit takes place only once as well. i STILL haven't dug into the code too deeply (because i STILL haven't finished setting up Kdevelop because i STILL haven't installed alll of the packages it needs...). but... i'd think that somewhere inside here there's a orimary loop that controls when stuff gets rendered onscreen, which seems like it would have been a good place to manage other real-time like things. somewhere in here it might be nice to place a trigger for messaging. would you know of something like this hiding in the code somewhere? martin --- Manuel Bessler <[EMAIL PROTECTED]> wrote: > On Wed, Sep 01, 2004 at 05:46:27PM -0700, martin pardee wrote: > > manuel, > > > > it's good of you to answer me. i take some conmfort from knowing that there > are > > others engaged in this activity. i fell a little less like a reclusive nut > case > > :) > > > > i was wondering if you had an approach to interfacing to the FG sim. since > it's > > obvious that you and Stephen are pretty deep into this, it seems that you > must > > also have tackled the interface work as well. i am guessing that you are > NOT > > using a telnet connection to the sim. > > No, I'm not. But I haven't written much of the stuff I have in my mind, > and nothing on the fg side at all. > > The software that talks to the hardware side uses a property tree > similar to the one flightgear uses internally. I plan on making a > "bridge" between those two. > The basic idea is to have my prop tree to update fg's prop tree if eg. > switches get flipped,... and have something like a "subscription" to > certain fg prop tree nodes which get propagated from fg to my > prop tree whenever fg makes changes to the value of the subscribed node. > Eg. airspeed increases by 1 knot: fg tells my prop tree that the > airspeed node has changed to x knots, to which my software can respond, > eg tell the real hardware airspeed gauge to move to the new value. > > > Regards, > Manuel > > ___ > 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
Re: [Flightgear-devel] Radio Hardware.
Gene Buckle wrote: Gene Buckle wrote: others engaged in this activity. i fell a little less like a reclusive nut case :) Heh. Someone mentions nutcases, and I feel obligated to speak up. :) See http://www/f15sim.com for the precise definition of "nutcase". See www.737simguy.com, www.737sim.com, 737flightsim.com and www.simpits.org for further examples. *grin* Gene, in case you were wondering, www.nut-case.com looks like an open domain right now. You might want to consider jumping on it before someone else beats you to it. :-) Naw, if I did that, what would you sane people have to aspire to? :) I don't know about anyone else, but I'm looking into "nutgear.org" right now ... Curt. -- Curtis Olsonhttp://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
Re: [Flightgear-devel] Radio Hardware.
Curtis L. Olson wrote: I don't know about anyone else, but I'm looking into "nutgear.org" right now ... You're thinking of writing a meccano simulator? ;-) -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Radio Hardware.
> Gene Buckle wrote: > > >>others engaged in this activity. i fell a little less like a reclusive > >>nut case :) > >> > >> > >> > >Heh. Someone mentions nutcases, and I feel obligated to speak up. :) > >See http://www/f15sim.com for the precise definition of "nutcase". See > >www.737simguy.com, www.737sim.com, 737flightsim.com and www.simpits.org > >for further examples. *grin* > > > > > > Gene, in case you were wondering, www.nut-case.com looks like an open > domain right now. You might want to consider jumping on it before > someone else beats you to it. :-) > Naw, if I did that, what would you sane people have to aspire to? :) g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Radio Hardware.
Gene Buckle wrote: others engaged in this activity. i fell a little less like a reclusive nut case :) Heh. Someone mentions nutcases, and I feel obligated to speak up. :) See http://www/f15sim.com for the precise definition of "nutcase". See www.737simguy.com, www.737sim.com, 737flightsim.com and www.simpits.org for further examples. *grin* Gene, in case you were wondering, www.nut-case.com looks like an open domain right now. You might want to consider jumping on it before someone else beats you to it. :-) Curt. -- Curtis Olsonhttp://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
Re: [Flightgear-devel] Radio Hardware.
Manuel Bessler wrote: On Sun, Aug 29, 2004 at 07:23:21AM -0700, martin pardee wrote: manuel, my (original) primary motivation was to obtain (buy) enough hardware that i could have a Fsim that closely resembled the cockpit of the plane i fly ( a piper cherokee 180). the costs on this approach would easily cover the amount i spend on the anual inspection for the airplane. not a good choice. so... that left me with building my own. after examining (and purchasing) 2 other comnmercially avaialable flight sims, i decided that the only practical solution was to work with a sim that permitted me access to internals. that's how i ended up pestering all of you... :) martin For the hardware part, there's a whole (heavily MSFS biased) community of "home cockpit builders". There are a few forums where we 'hang out' and exchange tips and ideas. If anyone's interested there'll be a collection of simulators (from a link trainer through to more modern military sims, as well as PC based stuff at the South Yorkshire air museum this Sunday. Details here: http://www.aeroventure.org.uk/index.php I'll be dragging a machine along to show off flightgear, and will hopefully have some 0.9.5 cds to give away (is there a 0.9.5 mac build available yet?) -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Radio Hardware.
> others engaged in this activity. i fell a little less like a reclusive > nut case :) > Heh. Someone mentions nutcases, and I feel obligated to speak up. :) See http://www/f15sim.com for the precise definition of "nutcase". See www.737simguy.com, www.737sim.com, 737flightsim.com and www.simpits.org for further examples. *grin* FG is the easiest of the lot to interface to, but like most it requires programming a bit to do. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Radio Hardware.
On Wed, Sep 01, 2004 at 05:46:27PM -0700, martin pardee wrote: > manuel, > > it's good of you to answer me. i take some conmfort from knowing that there are > others engaged in this activity. i fell a little less like a reclusive nut case > :) > > i was wondering if you had an approach to interfacing to the FG sim. since it's > obvious that you and Stephen are pretty deep into this, it seems that you must > also have tackled the interface work as well. i am guessing that you are NOT > using a telnet connection to the sim. No, I'm not. But I haven't written much of the stuff I have in my mind, and nothing on the fg side at all. The software that talks to the hardware side uses a property tree similar to the one flightgear uses internally. I plan on making a "bridge" between those two. The basic idea is to have my prop tree to update fg's prop tree if eg. switches get flipped,... and have something like a "subscription" to certain fg prop tree nodes which get propagated from fg to my prop tree whenever fg makes changes to the value of the subscribed node. Eg. airspeed increases by 1 knot: fg tells my prop tree that the airspeed node has changed to x knots, to which my software can respond, eg tell the real hardware airspeed gauge to move to the new value. Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Radio Hardware.
manuel, it's good of you to answer me. i take some conmfort from knowing that there are others engaged in this activity. i fell a little less like a reclusive nut case :) i was wondering if you had an approach to interfacing to the FG sim. since it's obvious that you and Stephen are pretty deep into this, it seems that you must also have tackled the interface work as well. i am guessing that you are NOT using a telnet connection to the sim. martin --- Manuel Bessler <[EMAIL PROTECTED]> wrote: > On Sun, Aug 29, 2004 at 07:23:21AM -0700, martin pardee wrote: > > manuel, > > > > my > > (original) primary motivation was to obtain (buy) enough hardware that i > could > > have a Fsim that closely resembled the cockpit of the plane i fly ( a piper > > cherokee 180). > > > > > > the costs on this approach would easily cover the amount i spend on the > anual > > inspection for the airplane. not a good choice. so... > > that left me with building my own. after examining (and purchasing) 2 > other > > comnmercially avaialable flight sims, i decided that the only practical > > solution was to work with a sim that permitted me access to internals. > > > > that's how i ended up pestering all of you... > > > > :) > > martin > > For the hardware part, there's a whole (heavily MSFS biased) community > of "home cockpit builders". There are a few forums where we 'hang out' > and exchange tips and ideas. > We've also setup a wiki for that kind of stuff: > http://wiki.varxec.net > > My co-builder Stephen is currently working on his C172 radio replicas: > http://cockpit.varxec.net/stephen/gal/xpdr_galleryidx.html > > Believe me, the way he builds the stuff is one of the cheapest possible :-) > > > Regards, > Manuel > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > __ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Radio Hardware.
On Sun, Aug 29, 2004 at 07:23:21AM -0700, martin pardee wrote: > manuel, > > my > (original) primary motivation was to obtain (buy) enough hardware that i could > have a Fsim that closely resembled the cockpit of the plane i fly ( a piper > cherokee 180). > > > the costs on this approach would easily cover the amount i spend on the anual > inspection for the airplane. not a good choice. so... > that left me with building my own. after examining (and purchasing) 2 other > comnmercially avaialable flight sims, i decided that the only practical > solution was to work with a sim that permitted me access to internals. > > that's how i ended up pestering all of you... > > :) > martin For the hardware part, there's a whole (heavily MSFS biased) community of "home cockpit builders". There are a few forums where we 'hang out' and exchange tips and ideas. We've also setup a wiki for that kind of stuff: http://wiki.varxec.net My co-builder Stephen is currently working on his C172 radio replicas: http://cockpit.varxec.net/stephen/gal/xpdr_galleryidx.html Believe me, the way he builds the stuff is one of the cheapest possible :-) Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Radio Hardware.
On Tue, Aug 31, 2004 at 05:23:29PM -0700, martin pardee wrote: > 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. Why do you want to run an fg instance with dynamics disabled ? For the easiest start, I'd use a single fg instance, with the telnet server enabled, and write a little (eg. perl) script that reads the parallel port where you have your switch connected, and changes a property via the telnet interface when the switch gets opened/closed. Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Radio Hardware.
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 Olsonhttp://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
Re: [Flightgear-devel] Radio Hardware.
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 Olsonhttp://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
Re: [Flightgear-devel] Radio Hardware.
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). it sounds like FG is set up to "talk" to another process over the net, trating that process as a netwrok client in the classic 2-tier "client-server" model. 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? martin --- Harald JOHNSEN <[EMAIL PROTECTED]> wrote: > martin pardee wrote: > > >folks: > > > >i''d like to offer my (bleated) thanks to curtis olson, john wojnaroski and > >manuel bessler for taking the time to respond to "yet another newbie". > > > >i've received some good pointers from you all. > > > >it looks as if there are several approaches i could take to interfacing a > stack > >of simulated radios to the FG sim. i guess i'm going to have to roll up my > >sleeves and dive into the code base. > > > >one additional approach has occurred to me though, and i wonder if you all > can > >offer an opinion. > > > >it's been said that there are two approcahes to my problem: > > > >1) write a module that will run once per frame and handle control inputs and > >display outputs on my hardware. > > > > > > > I don't think it is possible to have a reliable data flow, and doing > things every frame will slow the whole thing. > > >2) write a network client that is "telnet based" and send packets over the > net. > > > >it occurrs to me that if FG supports telnet, that there must be a class > >somewhere that handles socket based communication. since sockets also make a > >fairly elegant for of IPC on a unix system, i was thinking that developing a > >class (or subclass) for this purpose might work out well with minimum impact > to > >the existing code. > > > > > > > Well, if you use the "telnet" protocol there is no impact on FG code and > it can work today. > > >could anyone commenton this idea please? > > > > > >in closing, i'd also like to ask if there is any sort of technical reference > >dosumentation that would allow a new coder to begin exploring the project. > > > > > > > You should have a look at fgfsclient.cxx in the FG/script/exmaple > subtree (on the cvs). The script/python subtree has also good examples > of what can be done using the telnet protocol. > The server side of the "telnet" protocol can be found in the > src/Natwork/props.* files. > Also FG must be lauched with --props=5501 to activate the server side. > Now you juste have to find the properties that you need and the property > browser is handy for that. > > >thanks to all, and best regards, > > > >martin pardee > > > > > > > > > > > > > > > > > >___ > >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 > > > > > > > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > __ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Radio Hardware.
manuel,
my
(original) primary motivation was to obtain (buy) enough hardware that i could
have a Fsim that closely resembled the cockpit of the plane i fly ( a piper
cherokee 180).
the costs on this approach would easily cover the amount i spend on the anual
inspection for the airplane. not a good choice. so...
that left me with building my own. after examining (and purchasing) 2 other
comnmercially avaialable flight sims, i decided that the only practical
solution was to work with a sim that permitted me access to internals.
that's how i ended up pestering all of you...
:)
martin
--- Manuel Bessler <[EMAIL PROTECTED]> wrote:
> On Sat, Aug 28, 2004 at 07:25:29AM -0700, martin pardee wrote:
> > it occurrs to me that if FG supports telnet, that there must be a class
> > somewhere that handles socket based communication. since sockets also make
> a
> > fairly elegant for of IPC on a unix system, i was thinking that developing
> a
> > class (or subclass) for this purpose might work out well with minimum
> impact to
> > the existing code.
>
> Not sure if the existing code can do it, but it shouldn't be too hard to
> add support for unix sockets/fifos.
>
> the README.IO in the source distribution under docs-mini says (in mine
> anyways, my CVS is several months old):
> "medium = { serial, socket, file, etc. }"
>
> ... it should be possible to add if its not there yet.
>
> The only problem could be that file-based sockets/fifos might not be
> portable across all OSs.
>
>
> > in closing, i'd also like to ask if there is any sort of technical
> reference
> > dosumentation that would allow a new coder to begin exploring the project.
>
> I'm primarily interested in the hardware side of your project...
> Are you building the radio stack yourself or are you buying some ?
>
>
>
> Regards,
> Manuel
>
> ___
> Flightgear-devel mailing list
> [EMAIL PROTECTED]
> http://mail.flightgear.org/mailman/listinfo/flightgear-devel
> 2f585eeea02e2c79d7b1d8c4963bae2d
>
__
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Radio Hardware.
On Sat, Aug 28, 2004 at 07:25:29AM -0700, martin pardee wrote:
> it occurrs to me that if FG supports telnet, that there must be a class
> somewhere that handles socket based communication. since sockets also make a
> fairly elegant for of IPC on a unix system, i was thinking that developing a
> class (or subclass) for this purpose might work out well with minimum impact to
> the existing code.
Not sure if the existing code can do it, but it shouldn't be too hard to
add support for unix sockets/fifos.
the README.IO in the source distribution under docs-mini says (in mine
anyways, my CVS is several months old):
"medium = { serial, socket, file, etc. }"
... it should be possible to add if its not there yet.
The only problem could be that file-based sockets/fifos might not be
portable across all OSs.
> in closing, i'd also like to ask if there is any sort of technical reference
> dosumentation that would allow a new coder to begin exploring the project.
I'm primarily interested in the hardware side of your project...
Are you building the radio stack yourself or are you buying some ?
Regards,
Manuel
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Radio Hardware.
martin pardee wrote: folks: i''d like to offer my (bleated) thanks to curtis olson, john wojnaroski and manuel bessler for taking the time to respond to "yet another newbie". i've received some good pointers from you all. it looks as if there are several approaches i could take to interfacing a stack of simulated radios to the FG sim. i guess i'm going to have to roll up my sleeves and dive into the code base. one additional approach has occurred to me though, and i wonder if you all can offer an opinion. it's been said that there are two approcahes to my problem: 1) write a module that will run once per frame and handle control inputs and display outputs on my hardware. I don't think it is possible to have a reliable data flow, and doing things every frame will slow the whole thing. 2) write a network client that is "telnet based" and send packets over the net. it occurrs to me that if FG supports telnet, that there must be a class somewhere that handles socket based communication. since sockets also make a fairly elegant for of IPC on a unix system, i was thinking that developing a class (or subclass) for this purpose might work out well with minimum impact to the existing code. Well, if you use the "telnet" protocol there is no impact on FG code and it can work today. could anyone commenton this idea please? in closing, i'd also like to ask if there is any sort of technical reference dosumentation that would allow a new coder to begin exploring the project. You should have a look at fgfsclient.cxx in the FG/script/exmaple subtree (on the cvs). The script/python subtree has also good examples of what can be done using the telnet protocol. The server side of the "telnet" protocol can be found in the src/Natwork/props.* files. Also FG must be lauched with --props=5501 to activate the server side. Now you juste have to find the properties that you need and the property browser is handy for that. thanks to all, and best regards, martin pardee ___ 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 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Radio Hardware.
folks: i''d like to offer my (bleated) thanks to curtis olson, john wojnaroski and manuel bessler for taking the time to respond to "yet another newbie". i've received some good pointers from you all. it looks as if there are several approaches i could take to interfacing a stack of simulated radios to the FG sim. i guess i'm going to have to roll up my sleeves and dive into the code base. one additional approach has occurred to me though, and i wonder if you all can offer an opinion. it's been said that there are two approcahes to my problem: 1) write a module that will run once per frame and handle control inputs and display outputs on my hardware. 2) write a network client that is "telnet based" and send packets over the net. it occurrs to me that if FG supports telnet, that there must be a class somewhere that handles socket based communication. since sockets also make a fairly elegant for of IPC on a unix system, i was thinking that developing a class (or subclass) for this purpose might work out well with minimum impact to the existing code. could anyone commenton this idea please? in closing, i'd also like to ask if there is any sort of technical reference dosumentation that would allow a new coder to begin exploring the project. thanks to all, and best regards, martin pardee ___ 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
