Re: [Flightgear-devel] RFE for jsclient,js_server
On Fri, Jul 08, 2005 at 03:14:07PM +0100, Jim Campbell wrote: Hi, Can the jsclient and the js_server code be extended to allow up to eight joystick axis and the jsclient.cxx code enhanced to accept the button bits? It looks like the js_server.cxx code is encapsulating the button word as long integer but it is not being decoded on jsclient.cxx side. sure, why not. I originally wrote these two pieces on an afternoon. You are welcome to improve and extend it. Regards, Manuel ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New developer
On Mon, Jun 13, 2005 at 02:11:55AM +, Ampere K. Hardraade wrote: On June 13, 2005 12:42 am, Manuel Bessler wrote: The stuff is still here: 1. http://cockpit.varxec.de/fgfs/fgfs_717-200.tar.bz2 2. http://cockpit.varxec.de/fgfs/fgfs_717-200_71.blend.gz They are not there. Ooops, my bad. (My old server redirects to my new server, but the files are only on the old one...) I've put them on my new server: http://cockpit.varxec.net/fgfs/fgfs_717-200.tar.bz2 http://cockpit.varxec.net/fgfs/fgfs_717-200_71.blend.gz http://cockpit.varxec.net/fgfs/fgfs-screen-001.jpg ... http://cockpit.varxec.net/fgfs/fgfs-screen-005.jpg The screens show the state of the 3d model. Regards, Manuel ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New developer
On Sat, Jun 11, 2005 at 10:09:29PM +, Ampere K. Hardraade wrote: 1) Does someone is already working on that? I believe someone had been working on the Boeing 717/MD-82, but the author of Well, I had been working on a B717... the flightmodel seemed ok, but hasn't been updated to the newer JSBSim config file formats, so it will need some work in that area. that aircraft has some real life issues to take care of, and gave(?) the model to someone else to continue. There is no word regarding that particular aircraft ever since. Well, If you meant me, there were no special issues to take care of that I know of, but I've not been monitoring the lists as thoroughly in the past year. The 3D Model was in a very early (and probably sorry) state. I'm not much of a 3D artist at all. I still have the blender files, but maybe someone wants to start from scratch? Nobody really came forward back then, when I asked for help with the 3D model :( The stuff is still here: 1. http://cockpit.varxec.de/fgfs/fgfs_717-200.tar.bz2 2. http://cockpit.varxec.de/fgfs/fgfs_717-200_71.blend.gz #1 contains the JSBSim files #2 is the compressed blender file of the 3D model Regards, Manuel ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org 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.
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.
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.
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 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] 'Nother Newbie.
On Mon, 16 Aug 2004 19:11:40 -0700 (PDT) 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. I'm working on a hardware interface for flightgear. While the software part (interfaceing to flightgear) isn't very far yet, the actual hardware controller is near 'release'. I've been working on it for some time now. Soon I'll get to the point when I have to actually work in the interfacing to flightgear. Here's my cockpit building website with infos about the hardware I'm working on: http://cockpit.varxec.net/electronics/PHCC.html http://cockpit.varxec.net/ If you are interested in discussions about hardware interfacing to simulators, esp. for flightgear, consider joining the sim-hardware mailinglist: http://lists.varxec.net/ Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FMC
On Fri, Aug 06, 2004 at 09:20:25PM +0200, Boris Koenig wrote: I'd say that would not really that much depend on the availabilty of a FMC/CDU SDK but rather getting your hands on the right docs, as soon as these have been collected it should be much more realistic to that done, I think the idea is great - so, gathering all available information and determining what needs to be done is certainly something that could come in to actually develop the mentioned FMC SDK - because you could use a test implementation of a 737/747 FMS in order to determine the needs and architectural modifications required. http://www.fmcguide.com/ Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FMC
On Fri, Aug 06, 2004 at 09:17:21PM +0200, Boris Koenig wrote: I like the unix philosophy: for every task a seperate program that does only the one thing its designed for. ( make each program do one thing well) I know this is not always appliceable esp. for a flightsimulator, but it could be a good idea in this case. I don't even mention that this whole thread ultimately brings us back to the plugins discussion :-) I'm thinking more in terms of named pipes/fifo sockets... plugins just have two advantages here: they can be built later than the simulator and you can decide when to load what. But the costs are adding all the dlopen stuff. Not sure if the other platforms make it easier here. (I haven't followed the plugin thread) Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FMC
On Fri, Aug 06, 2004 at 09:27:02PM +0200, Boris Koenig wrote: Ususally, homebuilt CDUs consist of a small LCD w/ TV or VGA interface, the pushbuttons and a piece of plastic resembling the CDU panel. Use an older PC to drive the LCD with a CDU/FMC software running on it (or remotely if using X11) is the latter really an already established mechanism, I was really under the impression for it to be a spontaneous idea :-) No it wasn't an instantaneous idea. I have a prototype CDU panel (made from paper, overhead transparencies and transparent contact paper). http://cockpit.varxec.net/panels/img/cdu_panel1.jpg Check out X11GC, a x11-based glass cockpit software I'm working on. Thats whats gonna drive my CDU. But for the logic behind it, the FMC, it'd be nice to have a standalone program... :) the X11GC page: http://cockpit.varxec.net/software/x11gc.html two CDU screenshots: http://cockpit.varxec.net/tmp/acars_cdu_screenshot1.png http://cockpit.varxec.net/tmp/acars_cdu_screenshot2.png (The fonts for this demo are the Aerowinx CDU fonts. They are not GPL, but freely downloadable. I plan on making some under the GPL) but see my previous post: using SimGear as a backend for the calculations there would not be a reason to drop the mainly Nasal based approach for the actual implementation of the logics involved - which would then have many advantages talking of flexibility. Well, Nasal doesn't fit too well in my standalone concept. I already have a scripting language integrated into my X11GC/PHCC* programs (They share some classes, and can be built into one binary). I use LUA, an embedded scripting language. http://www.lua.org/ Easy to learn and easy to integrate into your own programs :-) Regards, Manuel *PHCC is my cockpit electronics interface solution: http://cockpit.varxec.net/electronics/PHCC.html ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FMC
On Fri, Aug 06, 2004 at 01:54:06AM +0200, Boris Koenig wrote: Of course, if there's running X11 on that other machine, FlightGear could still provide the graphics for such an externally displayed CDU via network without the need to explicitly be running on that machine :-) x11 yes, but what if not OpenGL capable. That would exclude running anthoer flightgear instance on that machine. (I'm thinking about old cheap computers. Often those you can get for free) professional users who are building their own cockpits or simply those users that are using those expensive external standalone CDU units. Or homebuilt cheap external CDUs :-) On the other hand I think one has to ponder about the pros cons, and certainly it would be more of an advantage for the AVERAGE user to have a GENERAL xml-configurable mechanism to add support for FMCs/CDUs to FlightGear than having merely a way to code your own stuff by accessing the property tree via network. Another idea I just had: Why not put all the general algorithms needed in an average FMC into a library (possibly as part of SimGear). Things like performance calculations, (access to) route databases, input validation (eg: airport code exists?, does this airport have a runway xxR?),routing calculations,... This library could then be used/linked to build an FMC, either withing fgfs our as a standalone program. Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FMC
On Fri, Aug 06, 2004 at 02:34:07PM -, Jim Wilson wrote: Maybe something like that could work. There are some good suggestions in this thread, but you know in the end these details are up to whoever takes the initiative to write the code. There will always be room for further contribution. Yes. (I wrote that in my other post in this thread) Which reminds me that I forgot to make it clear that I am very excited to hear of this proposal. This feature is something we really need, especially for the airliners. Yes, same here :-) ... waiting for a decent open source B744 FMC implementation :) Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FMC
On Fri, Aug 06, 2004 at 02:26:12PM +0200, Boris Koenig wrote: x11 yes, but what if not OpenGL capable. well, in that specific example I was referring to the case where a secondy machine would running dedicatedly for the purpose of displaying a CDU for a FMS - so GENERALLY I would I migth have misunderstood you. I thought you meant running the CDU in a slaved fgfs. I see - but even though this was mainly only a thought.I really think that there's no need for any OpenGL requirements in order to display something as trivial as a CDU. Yes. That was my point. Or homebuilt cheap external CDUs :-) don't know about these, if you've any experience with these it might be interesting, maybe just for the sake of adding well, I have some parts at home. Not finshed. Doing the electronics interface currently. (details: http://cockpit.varxec.net/electronics/PHCC.html) Ususally, homebuilt CDUs consist of a small LCD w/ TV or VGA interface, the pushbuttons and a piece of plastic resembling the CDU panel. Use an older PC to drive the LCD with a CDU/FMC software running on it (or remotely if using X11) support to deal with that stuff, there's probably some basic specification using RS232 or USB for data exchange, I'd guess ? both is possible. SimGear itself is rather meant to provide a generic framework for simulations - so, the things that you are mentioning would be rather specific to flight simulator applications hence it would certainly make more sense to directly integrate it into FG itself. If you look at some stuff in SimGear, you'll see that there are flightsim specific things... and if someone wanted to write a FMS procedure trainer, he could link simgeear in, but wouldn't need any flightgear stuff. AFAIR, Flightgear doesn't build any libs that are used by 3rd party programs. To me, SimGear seems the perfect for the kind of routines I mentioned. In order to really determine what data and functions to access it would be necessary, one would first need to look into a FMC manual and find out what data sources are being used to AFAIK FMCs (at least the ones used onboard Boeings) use airdata, IRS, and possibly GPS. They can control (nav-)radio tuning, ACARS... They interface with the autopilot, flight control computer and probably a bunch more. I also remember something about weightbalance. compute the stuff, OR what -flightgear based data- could ALTERNATIVELY be used for that purpose. Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FMC
On Sat, Aug 07, 2004 at 12:51:02PM -0400, Ampere K. Hardraade wrote: I think newer Airbus aircrafts have CDU's that have a more advanced GUI. http://www.flug-revue.rotor.com/FRheft/FRHeft04/FRH0401/FR0401c1.JPG looks like the A380. Is the overhead panel really a screen ? It looks like a big LC Display... Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FMC
On Thu, Aug 05, 2004 at 06:14:03PM -, Jim Wilson wrote: Harald said: - it's an external application because there is no need to put it in FG code and there would be some complication with the display and keyboard part ; I like the idea of a FMC system. :-) It would actually be very nice to have a FlightGear subsystem for this. Even nicer if it was possible to configure features via an xml config file (since not all FMCs are exactly the same). You can still manipulate data through the property system. I know that it would have some advantages if the FMC were part of flightgear, however I tend towards an seperate program like Harald is planning. It could be easily networked so you could use an older computer with a small monitor to put the FMC/CDU on. The FMC program wouldn't even have to provide a text/graphics output necessarily. Would it work to have one node in the property tree that would contain the text on the CDU display ? The 3D cockpit could listen for changes to this node and when one happens, update the CDU display in the 3D cockpit... It should be very easy to use the NewGUI feature (xml gui) to present a display with buttons as well as pc keyboard input. How about the setup in a B747-400 with 3 CDUs (and AFAIR also 3 FMCs). For those building cockpits at home, having more than one CDU, each displaying different pages would be nice :-) Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Linuxtag
On Fri, Jun 18, 2004 at 07:19:56PM +0200, Manuel Bessler wrote: Next week is the Linuxtag in Karlsruhe, Germany. It would be interesting to meet some flightgear folks. If I go, it'll probably be saturday, or maybe friday. I'll be there on Friday, so if anyone is there the same day, maybe we can meet for a small chat or so ? Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Linuxtag
On Fri, 18 Jun 2004 14:09:40 +0200 Mathias Fröhlich wrote: Hi, Next week is the Linuxtag in Karlsruhe, Germany. http://www.linuxtag.org/ Is Flightgear present this year? Or will somebody be there for an other project? I myself wondered if Flightgear is gonna be there. I might go to Linuxtag, but just as a visitor. It would be interesting to meet some flightgear folks. If I go, it'll probably be saturday, or maybe friday. Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MD-11 cockpit
Hi Innis, On Mon, 17 May 2004 10:13:25 +0800 Innis Cunningham wrote: When doing my B717, I used qcad to measure things from these drawings. Like engine placement, pilot viewpoint and also got me started with the 3D model (which isn't finished yet, so if someone wants to finish the 3D model... raise your hand :-) The jsbsim aero file should be quite flyable. so... any takers for the 3D model ? Its in Blender format. You can send it to me but I doubt I would get to it for a month or so till I am finished what I am currently working on. If you send it could you send it in AC3D(prefered) or DXF. Its available here: http://cockpit.varxec.de/fgfs/fgfs_717-200_71.blend.gz (just the blenderfile, gzipped) http://cockpit.varxec.de/fgfs/fgfs_717-200.tar.bz2 (fdm, engine config, and 3d model in .ac format) Note that I haven't touched the model since September... so the JSBSim configs will have to be converted to the new format. The directory layout may also have to be changed. I currently don't have a recent flightgear checkout (my computer needs updating in the hardware area as well to allow me to enjoy flightgear again), so I can't do much right now. Most of my free time is currently going into PHCC, my home cockpit interface project for flightgear: http://cockpit.varxec.de/PHCC.html (If you are more interested in this project, join the sim-hardware list: http://m18s17.vlinux.de/cgi-bin/mailman/listinfo/sim-hardware ) Innis and Ampere, thanks for taking a look at my model... Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MD-11 cockpit
On Sat, May 15, 2004 at 07:09:21PM -0400, Ampere K. Hardraade wrote: I have been doing some hunting lately; namely, looking for information regarding the MD-11's flightdeck: dimensions, layout, technical diagrams, etc. I have tried many search keywords on the Internet, my local library, as well as my university's library. So far, I have no luck. Have you checked this page: http://www.boeing.com/assocproducts/aircompat/3d_view.html It contains .dxf drawings of the different Boeings (and MD/DCs) When doing my B717, I used qcad to measure things from these drawings. Like engine placement, pilot viewpoint and also got me started with the 3D model (which isn't finished yet, so if someone wants to finish the 3D model... raise your hand :-) The jsbsim aero file should be quite flyable. so... any takers for the 3D model ? Its in Blender format. Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] flightgear and hardware: mailinglist created
On Fri, 30 Apr 2004 09:56:08 -0700 (PDT) Gene Buckle wrote: You could've saved yourself the effort and joined the simpits-tech mailing list at http://www.simpits.org. There's over 300 people on the list. I AM on that list :) I've even posted a few times. Since I now have my own server with full access, I thought I might as well set up mailman, might come in handy someday :) And then... simpits is not fgfs specific. Most discussions tend to be fighter pit based and mostly on MSFS or Falcon. Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] flightgear and hardware: mailinglist created
On Fri, 30 Apr 2004 19:03:53 +0100 Al West wrote: There's not a whole lot of FGFS discussion because it's not a drop and go solution like MSFS or Falcon (and soon to be Lock On: Modern Air Combat) is. If it was easier for non-programmer types to interface to, I'm sure more people would use it. Having a FlightGear cockpit evangelist wouldn't hurt either. :) The thing is though us FGFS guys would want to talk about things that programmer types like to talk about and I think it would potentially bore or confuse the current SimPits list group. IMHO one great thing Totally agree. The level on some other forums I also frequent is often not very high. There are a lot of non-tech people trying to build their own cockpit. For them it ususally starts out as a huge learning experience, esp. in the electronics field. about the net is the choice (either that you have, or your influence on others ;-)). So I think the more the better. Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Motion Base Simulator ?
On Thu, 22 Apr 2004 18:12:16 -0400 Ampere K. Hardraade wrote: That's because it isn't a 747-400, but a 747-200; which makes me think that that might once been an actual plane. Yes, it was an actual plane. AFAIR D-ABYM of the Lufthansa. Its part of a museum. Its staticly mounted, so no motion sim :( The guy who owns that museum also has a Concorde and a Tu-144 at his other museum (which happens to be in the same town that Stephen and I live in :-) http://www.airliners.net/open.file/535998/L/ Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] B747 flaps settings
On Sat, Jan 31, 2004 at 10:49:37AM -0600, David Culp wrote: I see the file Aircraft/747/747-yasim-set.xml contains a question: !-- These are complete fabrications. What are the real flap detent settings on a 747-400? -- Depending on where you look, I've seen [ 1, 5, 10, 20, 25, 30 ] or [ 5, 10, 15, 20, 30 ]. Hmmm, interesting. I've never seen the second config. Is there a picture on the net with this config ? Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Incorrect fog rendering
On Thu, Jan 22, 2004 at 09:35:23PM +0100, Avi Levy wrote: I'm new to this group, and would like to add that if there is any information needed on MD11 and B767 flight characteristics or systems, feel free to ask through this mailing list, I have a lot of flying hours on these types. A MD11 jsbsim model would be nice :-) AFAIR, the MD11 glass cockpit is very similar to the one used on the B717-200. Do you have detailed infos about that ? even screenshots of different situations, closups from cockpit photos... Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Trim position and speed to external hardware
Hi Matt, seems nobody answered (at least not on the list)... On Tue, Dec 23, 2003 at 12:08:54PM +, Matthew Law wrote: How do I export the trim position and IAS to a serial port? I'd like to use these values to drive some stepper motors which crudely simulate control load and trim effects. What do you have hooked up to the serial port ? some intelligent circuit, like a microcontroller ? If you can do a tiny bit of parsing inside a microcontroller, the generic output module might work for you. The generic output module that can output in ASCII format. It is configurable via XML (see the Protocols directory in the base package). That would allow you to define what properties you want and the format/seperators. something like: --generic=serial,out,10,/dev/ttyS0,9600,f1serial where f1serial is the XML configfile in the Protocol directory, but without .xml Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Serial device
On Tue, Dec 23, 2003 at 01:40:16AM -0500, Alan King wrote: I have worked on a protocol for my own stuff... it includes analog axis and button state support. I've put up a picture of my protocol spec: http://cockpit.varxec.de/fgfs/PHCC2HostProtocol.xfig.png Can't get there through the link. At any rate I am working more Sorry, wrote the email and forgot to upload the file... now its there. Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Serial device
Hi Alan, On Mon, Dec 22, 2003 at 02:48:02AM -0500, Alan King wrote: Anyone up for making a serial device? I only do a little programming you mean for the microcontroller side ? on the PC side of things, so am not currently up to the task I think. Needs sync bytes, something like this is common: FF FF 0 axis1 0 axis2 0 axis3 etc. Really just check the high bit, 2 set in a row is the sync, then a zero then axis etc. By just checking the high bit other things can be put in like this: F0 Fx 0y ax1 0y ax2 etc. I have worked on a protocol for my own stuff... it includes analog axis and button state support. I've put up a picture of my protocol spec: http://cockpit.varxec.de/fgfs/PHCC2HostProtocol.xfig.png Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] SR-71 Flight Manual
The SR-71 manual is available online for free: http://www.sr-71.org/ http://www.sr-71.org/blackbird/manual/index.htm Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-users] Slackware, USB, CH yoke
On Wed, Dec 17, 2003 at 09:59:51AM -0800, Andy Ross wrote: Alan King wrote: A keyboard can be interrogated. A mouse outputs constant data and/or can be interrogated. A standard joystick does.. nothing. A standard joystick* looks like an HID device, just like a mouse or [...] [* i.e. a USB one, like the ones you buy in stores these days and like A standard joystick port, old analog PC style (those that use the ns558.o) can also detect the number of axes connected, but not the number of buttons. It works by charging a capacitor through a resistor (RC circuit) and couting the time it takes. That time is dependent on the resistor, which in this case would be the potentiometer inside the connected joystick. If no joystick is present, the capacitor will never load, and this is what the software uses to determine whether a joystick is present. (this has given me some headaches with my homebuilt yoke... i had a loose wire so the driver never loaded :( :))) Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: Cockpit Hardware Building (was: Re: [Flightgear-devel] F-16 cockpit)
Hi Alan, On Thu, Dec 11, 2003 at 10:50:11PM -0500, Alan King wrote: Yep, here is a picture of my CNC/driller. I wanted mostly metal, all cheap hardware store components, and just drill hole assembly, no slotting etc. I have a large electronics inventory, and have about 400 stepper motors on hand and 2K mosfets and my own intelligent 4 and 5 phase stepper motor controller/driver board. Also while you're at it hit the beacon file, it looks good and I've now built much bigger one, note it's a 3 MB mpg.. http://home.nc.rr.com/alan69/FlightGear/CNC.jpg Do you have more pictures of your CNC ? Is the part that the steppers are mounted on some kind of plastic ? I'd like to see more pics of the details how you built your CNC :) It's just being built. But it did hit me looking at it last night that Windows handles 2 mice ok with both moving the pointer, just have it USB and plug it in and leave the normal mouse alone. Must have some scaling though, FlightGear is very touchy with my normal 400 dpi mouse. First dot over from center is a noticable jump, more than it should be. You can set the mouse resolution down in windows, or alternatively, you could change the scaling of the mouse axes in flightgear. (XML file) http://home.nc.rr.com/alan69/FlightGear/rudder.gif have. Bellcrank has bearing at center, and the little squares are where to put teflon pads from a mouse. The other short piece is cut from the Instead of teflon pads, you could use the material that those (usually white) bread cutting boards are made of. That material is relatively good to work with (sharp knife :) and are widely available. Its something that I've seen from one cockpitbuilder use and now others are using it as well, like me. ...and its not as tiny as the teflon pads from a mouse :-) bellcrank board, and is underneath the guide plates with teflon on top. Guide plates are captured and keep torque forces off the single rails. But, had far better idea. Move bellcrank to under the guide plates. Use the short piece on top, and have the 1/4-20 bellcrank axle screw into it from the bottom, and not penetrate it. That way all wood showing, crank and rods are hidden. Guide plates only have a 1/4 gap where the axle comes through to support the top bar. Stained, this should look way better than most homemade jobs easily, maybe better than the made ones. Oh yeah extra hole or holes near the end of bellcrank is through it, the guide plate, and partically through bottom plate. Drop in a peg and locks in place to make a less shifty footrest when not in use. These may look so good I'll have to start selling some on Ebay! :) Post some pictures of the rudder when you are getting there :-) http://home.nc.rr.com/alan69/FlightGear/yoke1.jpg http://home.nc.rr.com/alan69/FlightGear/yoke2.jpg Note in yoke1, that opening with tab for the clam is already there. Simply clamp the bearing. At the other bearing, see the wider screw slot? Two dremel cuts with a grinding wheel will make it a tab too for the other clamp. Note that you need 2 more dremel cuts to cut the corners of the bracket so it can rotate, corners are what's holding that bracket from falling over. Four cut mechanical solution. Mouse goes on bracket, control goes at end of threaded rod. This is upside down, and note that mouse will be the first thing to hit, so may need a metal bar across the bracket a bit wider than the mouse to hit first. Likely PVC tube heated, bent, and molded slightly to grip shape to make the control. Wrap in tennis grip etc, and hang it on a slope board with sides. Rest of the buttons and controls are easy after this, and relocate mouse wheel for other use like elevator trim. Do you plan on something like a centering mechanism, so that there is a force that'll push the controls into the center positions ? Electronics will be easy, but we really need a good simple serial format that FlightGear understands and can map to any controls. 19,200 serial with 16 axes and 4 or 8 bytes should be enough, then let me use XML config to tell which byte maps to which control. Everyone has a serial port, it works in XP, and it's easy to do the hardware. Heck have FG output on the serial too and run gagues etc. Haven't looked at that FG programming side of it too much yet though, but the micro side for the controls is simple.. The protocol and hooking it up to fgfs should be the easiest part compared to coming up and building the hardware. Thanks for the detailed descriptions :) Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: Cockpit Hardware Building (was: Re: [Flightgear-devel] F-16 cockpit)
On Wed, Dec 10, 2003 at 09:52:52PM +, David Luff wrote: mode joking=on Actually, we just want you to work on the flightgear core and not be sidetracked by drooling over hardware stuff others are building. Believe me, it can be addicting just looking at what others are building. :- /mode Ah, that reminds me, must give up programming for a bit and get those rudder pedals made :-) Mine are waiting for some good ideas. I'm not yet satisfied with them :-) Seriously though, I'd be quite happy to see a flightgear-hardware list, I'd be much more inclined to throw out PIC problems and general hardware musings to a dedicated list than to pollute the already busy FG list with Thats exactly what I am thinking. them. Having said that, I'm quite happy to see hardware-related discussions on this list whilst you don't have one. Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: Cockpit Hardware Building (was: Re: [Flightgear-devel] F-16 cockpit)
On Wed, Dec 10, 2003 at 03:40:54AM -0500, Alan King wrote: time. Just show those (mostly ignorant) MSFS crowds what flightgear can do :-) Just joined the list myself and this was one of only a few main reasons. I was drawing up homemade control system hardware this afternoon. Welcome Alan :) You showed up just at the right time. The hardware building thread started just a couple of days ago... :-) I think I have the rudder pedals down to the bare minimum for correct control, linear rudder and proportional toe brakes but only using 2 drawer slides for minimum cost and only drilled holes for easy assembly, no slots in a bellcrank etc. Yoke is just a sloped cabinet with a drawer slide underneath, two bearings mounted on this with a threaded drawer slides are pretty interesting for cockpit building. We used them for our XYZ table. http://cockpit.varxec.de/tools/ You can find them in any good home improvement store (or at home if you wanna get rid of some old funiture ;) rod running through with the yoke. Fixed to the rod is an angle bracket, 2.5 out then several over, with an optical mouse attached. Sectioned 4 pipe fixed concentric to the rod with a pattern attached to the outside. With 2 in and out travel and 120 deg for roll it should the 120 deg, is that 60 in each direction, or 120 in each dir ? My yoke (747 style) has 180 deg total, so 90 in each dir. I have a several minutes long cockpit video from the net of a LH 747-400 where you can see the flightcontrols check. There the yoke went from -90 to +90 deg. give about 4 by 4 mouse travel around the pipe, for 1600 points total resolution on each axis, scaled down to reasonable for output. $10 optical mouse is the only part not absolute minimum cost, but with high res and all optical and a wheel to relocate for other use I think it's an ok trade off. Throttle and the rest are no real problem after that. Do you use that mouse as the primary mouse for fgfs for mouse yoke mode (what you get when you right click once in fgfs) or did you write a joystick driver for it ? The nice thing about using the mouse is, that the resolution is much better than with a potentiometer. Will have a port to hook in my RC transmitter and multiple output formats, so I can fly either RC trans or yoke/pedals for Flightgear or FMS. Also since I need a slope cabinet for the yoke anyway, turn it around and the back side will be a dual joystick MAME controller for two players or dual joystick for Robotron 2084 etc. Trying to make it all in one so I only have ONE extra controller to have laying around! :) Should come in under $50-$60 for just the yoke/pedals part, I do PICs as well so that part's easy. The $200ish for the CH stuff really isn't that bad, but I'm going to make some for a couple friends as well. I'd rather have something that feels rock solid over a plastic game controller for myself anyway. Plus I can put it on the net and then Do you have any pics of your setup on the web yet ? anyone can go to the hardware store and then build their own cheap good flight controls. Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: Cockpit Hardware Building (was: Re: [Flightgear-devel] F-16 cockpit)
Hi John, On Tue, Dec 09, 2003 at 03:02:25PM -0800, John Wojnaroski wrote: Hi Manuel, I've also talked to John Wojnaroski, He is also building hardware. Maybe we're just a few doing flightgear, but that'll certainly change over time. Just show those (mostly ignorant) MSFS crowds what flightgear can do :-) Let's just say they suffer from invincible ingnorance ( a theological concept associated with the idea of sin ) Yeah, I know what you mean. If you want to talk off-list about hardware stuff, just email me. I'd be interested in what you are doing. If you would, please include me. With the holidays fast approaching, won't have much time, but starting '04 should be able to free up more time. Still waiting for some AML-22 switches to complete the MCP. OK, No problem. Maybe we should really consider a mailinglist for that as Al has mentioned. Even if it'll be very low traffic. The question would be whether this would/could be hosted officially along the other fgfs list, or if we should set up something independet of flightgear.org Curt? My idea would be something like this: flightgear-hardware -- discussions about hardware interfacing to flightgear, hardware design, and interface software Whadda'y'all think ? Jim Brennan might also be interested. Currently we have a lead on a 737 heading for the chopping block and trying to get our hands on the cockpit. Cool. Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: Cockpit Hardware Building (was: Re: [Flightgear-devel] F-16 cockpit)
Hi Curt, On Wed, Dec 10, 2003 at 10:24:36AM -0600, Curtis L. Olson wrote: It's not a ton of work to setup a new mailing list, however, you might consider just jumping on board with an existing home cockpit group such as simpits.org. That would make more sense to me since they've already gone to a lot of effort to collect like minded people. Well, like minded My idea would be something like this: flightgear-hardware -- discussions about hardware interfacing to flightgear, hardware design, and interface software Whadda'y'all think ? If there is some overwhelming desire to add a flightgear-hardware Its up to you, Curt. You'd have to set it up and stuff. I like the idea of having a list along flightgear-devel|user|flightmodel There are lots of lists for MSFS builders, maybe some for Xplane and a couple for the fighter people. I like the idea to have something that is tied to flightgear specifically. list, I can do that, but definitely consider jumping on board with the simpits.org group. They could benefit from your knowledge and resources and I'm sure you could benefit from theirs. I am on the simpits-tech list, but it is mostly fighter jet oriented. Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: Cockpit Hardware Building (was: Re: [Flightgear-devel] F-16 cockpit)
On Wed, Dec 10, 2003 at 10:38:48PM +0100, Manuel Bessler wrote: already gone to a lot of effort to collect like minded people. Well, like minded Ooops, didn't finish my sentence... this should not have been in my reply. I was going to write something like like minded in terms of building, but not like minded about the simulator to drive it (and open sourcing software for it). Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Cockpit Hardware Building (was: Re: [Flightgear-devel] F-16 cockpit)
Hi Al, On Mon, Dec 08, 2003 at 03:17:31AM -, Al West wrote: http://cockpit.varxec.de/electronics/PIC_homecockpit_control.html Wow, what you have done so far looks impressive. I've not even got off the Thanks :-) drawing board yet. At the moment I'm trying to work out the best trade off for hardware components vs. connectivity. However I'm getting drawn in to I've worked on my solution for quite some time. It really takes time designing stuff like that. The current solution grew out of several smaller things that I built. I just thought that I should put everything together and make one big solution out of it that can drive everything you might need in a cockpit. And I think its the cheapest solution out there. And since all the others don't support flightgear (the flightsim world is still so MSFS centered) I thought this is the best way. do a soft key panel using some a touchscreen 7 LCDs that I've just seen, £160 (UK Pounds) is quite tempting. But its so much more fun to actually flip switches and turn knobs :-) Really ;-) It would be interesting to have a place where the hardware people could talk. I'm not sure whether there are many people involved in hardware building around flightgear. So far you are the only person to respond saying you build hardware - not that doesn't mean there are more people there. Maybe it's something that the users would be more interested with. I've also talked to John Wojnaroski, He is also building hardware. Maybe we're just a few doing flightgear, but that'll certainly change over time. Just show those (mostly ignorant) MSFS crowds what flightgear can do :-) If you want to talk off-list about hardware stuff, just email me. I'd be interested in what you are doing. Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] NMEA *out* to a Garmin
On Sat, Dec 06, 2003 at 10:21:41AM -0600, Curtis L. Olson wrote: David Megginson writes: Does anyone know if it's possible for a Garmin GPS to take its position information from external NMEA input, rather than just broadcasting the position as NMEA output? I wanted to experiment with using my (brand-new) Garmin 196 slaved to FlightGear, but I have not had much luck yet. This works to slave FlightGear to the GPS: --nmea=serial,in,20,/dev/ttyS0,4800 This, however, does not work to slave the GPS to FlightGear: --nmea=serial,out,4,/dev/ttyS0,4800 I selected the NMEA IN/NMEA OUT in the 196 menu. I'd be interested in hearing from anyone who has used any Garmin receiver slaved to FlightGear (rather than the other way around). A while ago, I read something from the M$FS side of things about outputting GPS data from the sim to a GPS unit. Here's a link: http://forums.avsim.net/dcboard.php?az=show_topicforum=142topic_id=5559mesg_id=5559page=5 Mentioned was the Garmin GPSMap 196. Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] F-16 cockpit
Hi Al, On Thu, Dec 04, 2003 at 06:11:06AM +, [EMAIL PROTECTED] wrote: Hi, Very nice piece of kit - but a little costly. I've been toying with the idea of building my own generic single seat cockpit unit. I do MIDI, LCD, Serial and Keyboard interface controllers. Recently I've got hold of some USB chips and have been planning to make some control panels for FlightGear. I'm wondering how many people would be interested in developing some 'open-source' hardware for FlightGear? We have facilities here including precision CNC I'm currently working on my own hardware that I'm going to connect to flightgear. It has a RS-232 serial port with USB option. Currently I'm busy writing the firmware and host software. http://cockpit.varxec.de/electronics/PIC_homecockpit_control.html milling and drilling, circuit board fabrication and welding. I'd be quite happy to do general control panels at a price little over cost or provide the circuit board and chips. My prototype PCBs are home-made with the toner transfer method. (pics of that process are also available at my site) I don't know if this is the right place to be discussing this (is the devel mail-list intended for software development? If so could a hardware development mail-list be set up?). It would be interesting to have a place where the hardware people could talk. I'm not sure whether there are many people involved in hardware building around flightgear. I'd be happy to hear from anyone interested, even if it's only ideas at this point in time. Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] C++ Terror!
On Wed, Nov 12, 2003 at 11:07:48AM +0100, Erik Hofman wrote: Manuel Bessler wrote: I've thrown together something similar with the plib js and net examples and changed the joyclient on fgfs side. This allows you to use a joystick port on another machine via the network. One thing I'd like to change is to make it configurable via the property tree what is being controlled by the remote joystick. I'm not sure if that'll work. I imagine something like this: fgfs --jsclient=socket,in,10,192.168.1.2,16759,udp --prop:/jsclient/axis[0]/binding=/controls/engines/engine[0]/throttle --prop:/jsclient/axis[1]/binding=/controls/engines/engine[1]/throttle Currently the protocol assumes 4 axes, 4 buttons. If less than 4 axes are installed on the joystick server, the unused axes will read zero. No provision for endian-ness yet. Okay, this is committed to CVS. Changes and updates are always welcome. OK, thanks. I'll send you the stuff when I get back to work at it. Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Combat anti-flame
Hi Martin, On Tue, Nov 11, 2003 at 01:46:01PM +, Martin Spott wrote: At least, now that the Concorde fleet is retired. Oh my god, how could I forget the Concorde - and it's counterpart, the TU-144 !?! We have both here in static display at Sinsheim, I can't forget them... I see them every time I look out the window :-) Do you live somewhere in the area ? Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] C++ Terror!
On Mon, Nov 10, 2003 at 09:57:06PM -0600, Curtis L. Olson wrote: Gene Buckle writes: I'm going to talk to Peter Dowson about modifying WideFS for use with FlightGear now that I've got the barest inkling of what the generic network frame can handle. We'll see how it goes. As far as I understand WideFS, FlightGear can do all that already. You can set up one copy to be a master, and any number of additional copies to be slaves. For each display channel you can specify view offset direction and fov. You can set up anything from a simple 3 monitor display system to some huge convoluted mess if you want to gang up 20 machines. I think Gene meant FSUIPC... I may try building a small module that would direct joystick movement from my EPIC card into the sim and see how bad the latency is. I did something similar on an old agwagon sim I had access to once. Fancy old joystick ... I write a little program that could read the joystick and blast positions to flightgear via the net. Seemed to work ok. Latency wasn't too bad. I've thrown together something similar with the plib js and net examples and changed the joyclient on fgfs side. This allows you to use a joystick port on another machine via the network. One thing I'd like to change is to make it configurable via the property tree what is being controlled by the remote joystick. I'm not sure if that'll work. I imagine something like this: fgfs --jsclient=socket,in,10,192.168.1.2,16759,udp --prop:/jsclient/axis[0]/binding=/controls/engines/engine[0]/throttle --prop:/jsclient/axis[1]/binding=/controls/engines/engine[1]/throttle Currently the protocol assumes 4 axes, 4 buttons. If less than 4 axes are installed on the joystick server, the unused axes will read zero. No provision for endian-ness yet. Here's the source: ... wait a sec... uhhh, the floppy disk has read errors... I'll have to get it again from a friend where I wrote it... ... however the most important files that I had on another disk are here: http://cockpit.varxec.de/fgfs/jsclient.cxx (goes into fgfs's Network directory, the changes to Main/fg_io.cxx and Main/options.cxx were on the corrupted disk) http://cockpit.varxec.de/fgfs/js_server.cxx (plib based joystick server program) http://cockpit.varxec.de/fgfs/Makefile (for js_server.cxx) (tested with flightgear CVS from Sept. 10th) PS: This code is really the answer to one of my own questions, way back in Oct 2002 :-)) http://baron.me.umn.edu/pipermail/flightgear-devel/2002-October/012450.html Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] What is Everybody Doing
On Sat, Sep 20, 2003 at 07:35:02PM +0800, Innis Cunningham wrote: Hi All In an effort to see what 3D models might be in the pipeline and to save people working on the same model. Maybe people could say what A/C they have under development(not in your imagination though). Boeing 717-200 Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Opengc-devel] Linux Hardware
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 FS. 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 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Boeing 717-200 progress
On Tue, Sep 16, 2003 at 10:02:56PM -0400, David Megginson wrote: Manuel Bessler writes: Sure, if a model flies 'by the numbers' is a good start, but there are other properties that need to be simulated well for a good model, esp. outside of cruise (cruise is probably the simplest part). It's all numbers, of course: it's just that the numbers for the moments, etc., are not as easily available. Yes, exactly. How are these usually derived/calculated/guessed ? All I've found was a formula for approximation in a pdf document on MSFS SDK. I'm not even sure if it was an MS official document. I've reproduced this formula in my 717.xml jsbsim config. Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Boeing 717-200 progress
On Tue, Sep 16, 2003 at 09:53:50PM -0400, Nick wrote: Manuel, If you find errors in the MSFS let me know. I have a friend who is a developer there, on CFS but he talks to the MSFS guys too. Just for information he is a fully-trained (Kansas Univ.) engineer who used to do aero model development for Boeing. Also a great guy. I used to go to lunch with him once a month before I moved from Seattle to WV. Well, I really don't use MSFS. (and neither do I use Windows). Last time I had MSFS running myself was in the FS 4 days. On a 286 with hercules monochrome graphics :-) But I could never fly/land well back in those days. I was just comparing non-official 717-200 config files for MSFS. Even the best Aero engineer is limited by the simulation engine (MSFS). I myself don't know much about aero stuff, and all I know I've learned while doing the 717-200 for fgfs. learning-by-doing :-) Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Boeing 717-200 progress
On Wed, Sep 17, 2003 at 10:19:15AM +0200, Erik Hofman wrote: Manuel Bessler wrote: Could someone with that or a similar book please help out. If you can help with better numbers for the 717-200 flightmodel that would be highly appreciated. Did you see these pages: http://www.bh.com/companions/034074152X/appendices/data-a/table-2/table.htm http://www.bh.com/companions/034074152X/appendices/data-b/table-6/default.htm Yep. This is one of my sources for the model. But there are a lot of numbers where I * don't know if/how I could use them * or don't know what they are, eg. Sv/S, 1/4 Chord Sweep Also concerning the thrust issue, I don't know what to use. There's takeoff thrust, climb thrust,... what goes into the jsbsim config ? Or do I need to mess around w/ these numbers to get the right value ? Thanks for helping the blind and clueless :-), Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Boeing 717-200 progress
On Tue, Sep 16, 2003 at 05:08:15PM +0200, Matevz Jekovec wrote: The 3D model is not that far yet. I'm not very good when it comes to modelling. Its completely made in blender (2.27). No movable parts yet. I realized that the ac-export python script does not use the names for the meshes that are given in blender. Is anyone else using only blender to create the aircraft models for flightgear ? (ie. without ppe or AC3D) I modeled my J-22 completely in Blender (you can try it by running fgfs --aircraft=j22). I used v2.28 and exported it to .ac file format with the python script found on this page (FG wiki): http://www.seedwiki.com/page.cfm?doc=ModelerAndSceneryBuilderDocumentationwikiid=2418wpid=0 AFAIK *everything* work/worked as far as object names are conserned, animation connection, flight model etc. I had actually no problems and issues with bugs or anything else that wasn't my fault when modeling and implementing the model. Maybe the problem with object names does not exist in the export script for 2.28 (i've read that you need a newer version of the script starting w/ blender 2.28). That's my guess. BTW: your j22 looks very nice. :) I like the animations (gear and pilot head) :-) Now, if we could use the blender built-in animation tools for creating the fgfs model/animation .xml files, that would be very cool. ;-) btw. Your model looks good! Keep up the good work! :) - Matevz Thanks. But there are a lot of things not right yet. I'll probably redo the fuselage and the esp. the wings. I've started off with a lot of detail, so my model has probably serveral times as much vertices than the 747. How did you do the movable surfaces, eg ailerons or elevators. I made the whole wing as one mesh and plan to try to use boolean ops to split/cut out the movable parts. I'm interested how you did it. Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Boeing 717-200 progress
On Mon, Sep 15, 2003 at 10:19:45PM -0500, David Culp wrote: I'd like to hear what you think. (esp. concerning the flightmodel) Very nice! I took it around the pattern once, and it flies well. I'll fly it some more later. Off hand I'd say it needs a little more drag when fully configured, although the problem could also be excessive idle I really haven't messed with the drag coefficients. They are probably still the way they came out of Aero-Matic. Since I had to increase the lift quite a bit from what aeromatic gave me, I might have to increase drag as well if aeromatic assumes some L/D ratio. thrust. This is the kind of thing you'd need a 717 pilot's opinion on. It might also be that I have excessive thrust. I don't know. I've used the advertised value for the BR715 engines which is 21000lbs. I have no idea what the take-off thrust would be. I just used the 21000lbs figure in the engine config file (MAXMILTHRUST). Is the advertised figure of engine thrust the same as max static thrust at S.L thats used by jsbsim ? Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Boeing 717-200 progress
On Mon, Sep 15, 2003 at 11:33:44PM -0400, Nick wrote: Good evening, Just as a matter of professional technique, the pilot's opinion is the last place to go for verification. Do every possible thing you can to check your results objectively. Then tell the pilot you've done every possible objective test. THEN get the pilot's opinion. I agree partially. Often, esp. w/ M$FS, people claim their planes are 'as real as it gets'. They are especially proud if some professional pilot flies them and attests that the simulation flies as the real thing. I'm not a pilot. But I think there's a still a huge difference between sitting in a real cockpit and having 'full motion feedback' and sitting in front of a monitor. Sure, if a model flies 'by the numbers' is a good start, but there are other properties that need to be simulated well for a good model, esp. outside of cruise (cruise is probably the simplest part). While researching numbers for the 717, i looked at some M$FS aircraft.cfg files. Often, even basic values like wing area were off by 100% !!! Not to speak of some other numbers. And this was just comparing a couple of 717s from the M$FS world against each other. Enough M$ bashing for now. For objective data on the 717 engine see Jane's All the Worlds' Aircraft. Idle thrust may be listed, or you may be able to calculate it from numbers given there. For zero-lift drag of the 717 configuration I believe you should have a number somewhere around Cd = .02. As a reference point most airliners have an LD of 20 clean at cruise. Could someone with that or a similar book please help out. If you can help with better numbers for the 717-200 flightmodel that would be highly appreciated. CD0 is set to 0.02 in my 717 jsbsim config. I have some experience in this. I hope it helps. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Boeing 717-200 progress
Hi, my jsbsim 717-200 flies much nicer now. Maybe a little more fiddling w/ the elevator. For test flights, check out the plane at: http://cockpit.varxec.de/fgfs/fgfs_717-200.tar.bz2 (includes ac3d file of visual model, but no sounds) http://cockpit.varxec.de/fgfs/fgfs_717-200_71.blend.gz (the blender file used to create the ac3d file) The 3D model is not that far yet. I'm not very good when it comes to modelling. Its completely made in blender (2.27). No movable parts yet. I realized that the ac-export python script does not use the names for the meshes that are given in blender. Is anyone else using only blender to create the aircraft models for flightgear ? (ie. without ppe or AC3D) Here are some shots while taxiing at LIRF (Rome Fiumicino): http://cockpit.varxec.de/fgfs/fgfs-screen-001.jpg http://cockpit.varxec.de/fgfs/fgfs-screen-002.jpg http://cockpit.varxec.de/fgfs/fgfs-screen-003.jpg http://cockpit.varxec.de/fgfs/fgfs-screen-004.jpg http://cockpit.varxec.de/fgfs/fgfs-screen-005.jpg Nosewheelsteering doesn't work yet apparently.. By default, my model is tanked 100% which means that it is pretty heavy (MTOW actually) when you start. 13deg Flaps for takeoff (press ']' once) and accelerate to about 135 kts and rotate. Landing: Approach at about 140-145 kts w/ full flaps (40deg) I'd like to hear what you think. (esp. concerning the flightmodel) Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] 3dmodel - jsbsim gear question
I was wondering about one issue while messing with the UNDERCARRIAGE section of my 717 model: the dxf drawings from Boeing show the nose gear at a slightly higher ground level than the main gear. Thus, when the real aircraft is on ground, the fwd part of the fuselage will have less ground clearance than the rear part. I used those 3-view dxf drawings in blender to model the 3d model for my 717. My question is: do I have to rotate the model in blender so that both nose and main gear are on the same level, or will jsbsim place the 3d model inside fgfs such that both nose and main gear will have ground contact ? Of course given the correct numbers in the UNDERCARRIAGE section (ie. shorter z-axis lenghts for the nose gear compared to main gear (my model's origin is the a/c nose)) Is my description clear enough to understand what I'm asking ? Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3dmodel - jsbsim gear question
On Thu, Aug 28, 2003 at 03:03:40AM +0100, Lee Elliott wrote: I'm not very familiar with JSBSim so I don't know if it includes a gear compression factor. This could be important when you set the gear up because it might assume, or you might have to tell it, whether the gear z-axis is a loaded or unloaded figure. When I started animating u/c suspension I found that it's easier if you model the gear at it's unloaded extension i.e. it's position when the a/c is in the air and there's no weight on it. If you're not going to animate the suspension then you should model the gear in it's loaded position other wise it'll stick through the ground while it's landed. I'm not gonna animate suspension at the moment. i guess the dxfs i used are set up for the a/c sitting static on-ground. I was wondering about how jsbsim determines where to put the 3d model. All i can see in the config is the geometric refences of the different a/c parts like engines, gear, c.g., pilot eye pos'n,... but nothing referencing that coord-system with ground, except thru the gear pos'ns Two ways i can imagine jsbsim doing this: (imagine the gear, all with different lenghts) 1. it takes the AC_GEAR from UNDERCARRIAGE that would hit the ground first if the aircraft would be dropped down on the runway vertically. 2. it does 1. but for all three, but rotating/translating the 3d model so that all 3 gear of the 3d model will be on the ground like the real world (given that the 3d model and the fdm gear definitions correspond) Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Boeing 717-200 flightmodel
On Wed, Aug 20, 2003 at 08:53:39PM -0700, Tony Peden wrote: config with some others, like the F100, and they are the same although the F100 doesn't seem to suffer from the same problems. I've also used MoI values similar to those of the F100. Any suggestions for the fdm/aero beginner ? The problem is probably not in the flight controls, but in the aero. Try either reducing pitching moment due to elevator or increasing pitching moment due to alpha. I can be more specific if you e-mail me your config file. One note of caution: the keyboard increments are necessarily kind of big anyway. Yes, but you can still control most aircraft relatively OK with the keyboard. With my 717 config, even taking off is hard. Another problem (I think) is the lack of lift. I have only found something for the DC-9 (which is granddaddy of the 717): Clmax=2.0 Aero Matic guessed around 1.4 for my input. 1.4 is probably a skosh high for flaps up. For full landing flaps, it's going to be considerably higher. Do you have any stall speeds? No, I can't remember seeing anything like that for the 717 on the net. Even finding other speeds like V1, Vr, V2 was hard. I found one report from a test pilot who flew the 717. As far as I remember, Vr was around 120kts with flaps 13. I don't know what Clmax actually means... Max. Lift Coefficient at ? (i dont know) My model takes off at about 190kts with flaps up, and about 170 or so with first notch of flaps (ie. one keypress, ?1/3rd of full?) I don't know how the flaps stages in the jsbsim config correlate to the fgfs keyboard control (which seems to increase/decrease by 0.333 of the full value 1.0). Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Boeing 717-200 flightmodel
Hi all, I'm working on a Boeing 717-200 flightmodel (jsbsim) and the 3D visual model in blender. (I've uploaded it here for now: http://cockpit.varxec.de/fgfs/B717_model_1.tar.bz2 [180k]) This is my first attempt at a flight model. I've learned some stuff about aerodynamics in the process, but am still barely scratching the surface. Since the 717(aka MD-95) is still pretty new, there's not much information about it on the net. I've used some numbers from the tables at www.bh.com I got started with David Culp's Aero-Matic scripts but heavily modified the fdm config file afterwards. My biggest problem with the flightmodel is that elevator seems _very_ sensitive. (ie. when flying with the keyboard, pressing up/down _once_ will let the plane pitch about 10+ degrees up/down) I compared my values in the FLIGHT_CONTROL section of the config with some others, like the F100, and they are the same although the F100 doesn't seem to suffer from the same problems. I've also used MoI values similar to those of the F100. Any suggestions for the fdm/aero beginner ? Another problem (I think) is the lack of lift. I have only found something for the DC-9 (which is granddaddy of the 717): Clmax=2.0 Aero Matic guessed around 1.4 for my input. Now, I don't know how to correct that into the values in the fdm config. 3D Modelling: I've messed with blender a few times over a couple of years now. But I'm not a big artist and I am not very good with coming up with smart ways of how to model a certain thing. I was just wondering if there's a blender tutorial for modelling planes, esp. for flightgear. I googled for it but didn't find anything. The fuselage front and rear were the biggest problems for me. I ended up using nurbs circles along the length of the plane and then converting the nurbs circles into meshes. Then I manually created the faces (ie. marking 4 vertices, FKEY, until done) which was tedious work :) Is there a better way of doing this ? I've got the basic model finished, now I need to add(or seperate) the moving surfaces out of the wing and tail. Maybe cutting out using boolean ops. Is that how you do this ? It'd be nice if we had a tutorial (like those of the blender community) of how to make a visual model for flightgear using blender. Any help is appreciated. Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Boeing 717-200 flightmodel
On Thu, Aug 21, 2003 at 12:28:13AM +0200, Frederic Bouvier wrote: Manuel Bessler wrote: The fuselage front and rear were the biggest problems for me. I ended up using nurbs circles along the length of the plane and then converting the nurbs circles into meshes. Then I manually created the faces (ie. marking 4 vertices, FKEY, until done) which was tedious work :) Is there a better way of doing this ? I use extrusion of a circle and for each section, differentiated scaling with the help of the 3-view bitmap in the background (one view in each sub window ) well, I tried that too, but the differentiated scaling didn't yield the effects that I wanted. I also used a 3-view, but in DXF format (from the Boeing site). I posted the link to those on Jul 29th. Maybe I'm too much a perfectionist... I always want to get it as accurate as possible :-) Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] shared base package question
On Fri, Aug 15, 2003 at 01:50:36AM +0200, Arnt Karlsen wrote: ..if there are GPL'ed alternatives, we should link to them. 7-Zip is LGPL http://7-zip.org/ Supported formats: 7z, ZIP, CAB, RAR, ARJ, GZIP, BZIP2, TAR, CPIO, RPM and DEB. 7-Zip works in Windows 98/ME/NT/2000/XP. Command line version of 7-Zip can be used in Linux via Wine program. 7-Zip is a free software distributed under the GNU Lesser General Public License. Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightRecorder Help needed!!!
On Fri, Aug 15, 2003 at 03:42:58PM +0200, Carsten Hoefer wrote: Hi, I tried to write a small program to plot various flight information. For example height vs. time, speed vs. time, etc Unfortunately I am a programing novice. That's why I need your help now! A couple of weeks ago I programmed something similar. Its written using the wxWindows toolkit and it uses the CSV logging feature of fgfs. Since I hacked it together in a few hours, its not advanced or pretty and it does not have scaling, labeling of axes, tickmarks or any other nice things. If someone wants to take a look at it email me. Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Boeing 3D drawings
Hi Just found this site with dxf/dwg (Autocad) 3D Drawings from Boeing: http://www.boeing.com/assocproducts/aircompat/3d_view.html CAD 3 View Drawings for Airport Planning Purposes Just thought that this might come in handy for the modellers. Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 747 cockpit data
Hi Jim, On Thu, Jul 17, 2003 at 01:27:25PM -, Jim Wilson wrote: This was an outstanding find. I did have a main panel map that John sent me a while back, but this has the whole flight deck in one pdf. Now if I could only have (for free :-)) the pages that reference each of the balloon keys in the diagrams. The pages of this pdf have the NorthWest Airlines Logos on them (well, at least in xpdf, in acrobat it seems they have been painted over...) Maybe this is an excerpt of the well known NWA 744 Manual that is sold on the web, eg. at http://www.esscoaircraft.com/ (the 744 AOM is here: http://www.esscoaircraft.com/noname162.html ) Do you know Jerome Meriwether's site: http://www.meriweather.com/ There are the descriptions for nearly everything/every panel of a couple of cockpits (though I have looked only at the 747-400 :) Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Views
On Tue, Jul 15, 2003 at 03:04:11PM -, Jim Wilson wrote: Hmm, this makes me think we could use the Linux way of switching text consoles: alt+F1 ... alt+F8 - 8 different views! I know there's at least one flight simulator that toggles views with the function keys. Maybe it's ACM (I didn't use ACM for 7 years or so ). We must be careful not to intefere with Linux' console switching, As far as I remember, you need CTRL+ALT+Fx to switch console under X. Right. I don't think we're using any ALT key bindings. Are there compatibility issues here? Can we do ALT? I think many windowmanagers (and windows itself, Alt+F4) use Alt for their purposes. I'd like to have Alt free for System and Windowmanager stuff. I'm thinking along the lines of emacs: Control for most shortcuts, and Meta for others (which the user could map to Alt, or Windoze keys, or whatever) In blender eg. i can't use some Alt- shortcuts since i've have some Alt- mapped for my windowmanager (ion). Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Wiki
On Sat, Jun 28, 2003 at 06:24:19PM -0700, WillyB wrote: I have made a list of common acronyms for myself a while ago. Some definitions are adapted from the flightsim navigation tutorial at http://www.navfltsm.addr.com/ My list can be found at: http://cockpit.varxec.de/acronyms/ There are 74 entries right now. Would you mind if I posted that list on the Wiki? No, go ahead :) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Wiki
On Sat, Jun 28, 2003 at 12:35:35AM -0700, WillyB wrote: Something that someone who knows could add would be a page that has the definitions of all of the different acronyms (sp) used.. and what they are for / how to use them... I know these are covered in the links within fg docs, but a list w/ a short explination would be much easier to find, follow and digest IMHO. I have made a list of common acronyms for myself a while ago. Some definitions are adapted from the flightsim navigation tutorial at http://www.navfltsm.addr.com/ My list can be found at: http://cockpit.varxec.de/acronyms/ There are 74 entries right now. Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] boeing panel question
Hi Jim, On Fri, Jun 27, 2003 at 01:19:23AM -, Jim Wilson wrote: it is 22 degrees from the vertical. Thanks for the great link. Does that seem like too much of a slope to you? That's close to half of a 45. Well, I was a little surprised when I read that, but since I've been hearing about around 17degrees in general for airliners (might have originated from the airbus home cockpit builders), it seemed within reason. Esp. since in my home cockpit the sawing wasn't that exact, so it got to be around 22 degrees :-) There, it seems to look OK. One of the things that might throw us off visually could maybe the overhang of the glareshield. Have you seen this page?: http://www.simpit.de/ This guy has the cockpits of both a 767 and an A320 measured out.(in centimeters, if your brain is not 'compatible' with metrical units, be sure to have a calculator handy :-))) Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] boeing panel question
On Fri, Jun 27, 2003 at 02:11:26PM -, Jim Wilson wrote: Manuel Bessler [EMAIL PROTECTED] said: Have you seen this page?: http://www.simpit.de/ This guy has the cockpits of both a 767 and an A320 measured out.(in centimeters, if your brain is not 'compatible' with metrical units, be sure to have a calculator handy :-))) Actually I do well with metric. :-) With the flight gear modeling it is usually the other way around, converting from feet/inches to meters as the models are all done in metric. The photos at that link are incredible. I'd love to have the same thing for the 747-400. Perhaps someone will take the initiative to do a 3D cockpit for the A320. It seems that esp. the 747-400 dimensions are very hard to come by. I've searched the net for months and haven't found much good info. But I've been able to extrapolate the numbers for the MIP and the overhead of the 744 ... I _think_ I got at least the MIP numbers pretty near the original. But I have nothing to check them against. For a drawing of the 744 MIP with dimensions check this: http://cockpit.varxec.de/plans/ Its the webpage of me and a friend who *were* building a fgfs based home cockpit. Mostly for space and time constraints, we have to dismantle the cockpit itself. I hope to use some pieces for a scaled down version for the desktop. As for pics of the 744 cockpit, I did a recursive wget download of the old www.747cockpit.com site some months ago. There are many closeup shots of the different panels. I could make an archive and put it up on the web if that would help you with the modeling. Manuel PS: Thanks for working on the models, they are getting better every time I update my fgfs CVS snapshots. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] boeing panel question
On Wed, Jun 25, 2003 at 02:14:51PM -, Jim Wilson wrote: Does anyone know what the slope of the backplane on the 747-400 main panel is? It certainly isn't vertical. I might end up just using what looks correct, but it'd be nice to know what it is supposed to be. according to this: http://forums.avsim.com/dcboard.php?az=set_threaded_modeforum=137page=topic_id=16742prev_page=show_mesg it is 22 degrees from the vertical. Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] DC3 sound package
Hi, I found a sound package of DC-3 sounds (actually for 'that other simulator') which might license-wise be compatible with the GPL. http://www.dc3airways.com/ ... or direct link to the sounds: http://www.dc3airways.com/dc3sounds.zip quote from the readme hahaha !!! I have no legal stuff, use these DC-3 sounds how you want, when you want, change them, upload anywhere you feel like (it would help me if you do, please keep this text file with it though), use them as freeware, shareware or commercial, I really don't care, as long as you enjoy them and credit me as the original author of these sounds. I realize that by releasing these on the Internet, anything can happen and.. I accept that. /quote Meybe we should contact the author just to tell him if we include it in fgfs. Now... it would be nice if we had a tool to convert the MSFS sound.cfg to flightgears XML sound description format... :-) (this seems to include a description of the sound.cfg format: http://www.microsoft.com/games/flightsimulator/inc/fs2000/sdk/fs2000_aircraft_container_sdk.pdf) Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] cycling w/ right mouse button pause
On Sat, Mar 01, 2003 at 04:31:30PM -0500, David Megginson wrote: So it is. I've just checked in some changes, so that all a subsystem has to do is override FGSubsystem::is_suspended() to return false, and it will keep running during a pause. I've made the change to the input module, and the mouse now cycles again during pause. Thanks David. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] cycling w/ right mouse button pause
Since nobody posted anything about my first question/possible bug report I'll try it again: On Wed, Feb 19, 2003 at 02:57:40AM +0100, Manuel Bessler wrote: Hi I've noticed that cycling (right clicking) between mouse pointer mode, yoke mode, and view mode has no effect while paused. If you right click while paused it does not change mode until I hit 'p' again to unpause. It seems that it 'records' at most one right click in paused mode. It worked for me in 0.8.0, but in all 0.9.x and CVS versions I tried, it didn't. Flightgear and base CVS from Feb 17. Platform: Debian Woody, 2.4.16 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] cycling w/ right mouse button pause
Hi I've noticed that cycling (right clicking) between mouse pointer mode, yoke mode, and view mode has no effect while paused. If you right click while paused it does not change mode until I hit 'p' again to unpause. It seems that it 'records' at most one right click in paused mode. It worked for me in 0.8.0, but in all 0.9.x and CVS versions I tried, it didn't. Flightgear and base CVS from Monday. Platform: Debian Woody, 2.4.16 Another weird thing I've seen today: Taxiing at KSFO to the big building (the one on stakes :) with the 747... Halted, with engines on idle, the nose of the 747 slowly entered the building and a couple of seconds later the 747 makes a jump and freezes the simulation. This jump is the weird thing: The 747 just gets stuck in the building, same position, but a couple of feet above ground (nearly on top of the building). Could that be a tiling problem ? Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [more or less OT] Map Projection on Navigation Displays
On Thu, Feb 06, 2003 at 10:22:18PM -0600, Curtis L. Olson wrote: So, could the Lambert Conformal Conic be the projection I am looking for ? Any help or pointers are appreciated. You might be thinking too hard about this. Yeah, I guess. But then, I'm too often a perfectionist ;-) $x = $w/2 + ($lon - $center_lon) * $deg_to_nm * $scale * $xfact; $y = $h/2 - ($lat - $center_lat) * $deg_to_nm * $scale; ($x, $y) is the coordinates (in screen space) where you should draw the object. This is known to work pretty well over a local area (assuming my typing is correct, I didn't overlook something, and you can get past the pseudo-perl syntax.) :-) Thanks, this will at least for the testing phase a good start. I have been thinking about something like this, but the ironing out the formulas above ... I just didon't how to put it all together. perl's no problem. I've did quite a bit of perl hacking some time ago. Thanks again, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [more or less OT] Map Projection on Navigation Displays
I couldn't find any good info on what kind of map projection technique to use for the ND. ie. mapping lat/lon to x/y-screen coord. I took a look at the OpenGC source, and as far as I understand, it uses a technique which converts RijksDriehoeks to Hayford. I tried to google a bit on this, but couldn't find much. Basically, RijksDriehoeks seems to be a technique developed specifically for the Netherlands... Did a little more research... (blindly shooting some search requests at google) Something that came up was, the Lambert Conformal Conic Projection. I also had the chance to ask a real airliner pilot. He said that on A340 and B744, a line on the NDs represents the shortest path between two points, ie. a Great Circle route. He also said that on older NDs (A300 or A310, I forgot which he mentioned) the line is not a Great Circle Route. So, could the Lambert Conformal Conic be the projection I am looking for ? Any help or pointers are appreciated. Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [more or less OT] Map Projection on Navigation Displays
Hi Norman, I heard about this... this still doesn't help me with the specific projection technique used on NDs. the proj package can do the conversion for you I understand that, but my what I would like to know is: Is the RijksDriehoeks conversion to Hayford as used by OpenGC the method used in the real NDs by Honeywell(or whoever makes those in Boeings/Airbuses) ? Is there any info about this on the web ? References ? I am wondering about the RijksDriehoeks thing because it seems to be a method specifically designed for the use in Netherlands. [Do I make it harder than it actually is ? Am I missing something ?] Finding an algorithm is not the problem, but knowing which algorithm to use is. Any way here is a hint trf_nonpolynomial.csv: 19914,RD NewNetherlands - onshore.,9809,52.0922178,5.23155,,,0.079,155000.0,463000.0,9001,9110,8901,1995-12-02 00:00:00,Nederlandse Commissie voor Geodesie publication 30.,EPSG,,95.30 96.29 ??? I guess I don't understand... not enough hint for me :) Bye, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] [more or less OT] Map Projection on Navigation Displays
Hi I am working on something similar to OpenGC, but not OpenGL based, but rather xlib-based... (its supposed to run on lowlevel Pentiums w/ non-3D accel graphics cards, maybe even 486s) I couldn't find any good info on what kind of map projection technique to use for the ND. ie. mapping lat/lon to x/y-screen coord. I took a look at the OpenGC source, and as far as I understand, it uses a technique which converts RijksDriehoeks to Hayford. I tried to google a bit on this, but couldn't find much. Basically, RijksDriehoeks seems to be a technique developed specifically for the Netherlands... Does anyone have some tips for me? What do Honeywell/Boeing/Airbus type NDs use? Do I make it harder than it actually is ? Thanks, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [more or less OT] Map Projection on Navigation Displays
On Sat, Feb 01, 2003 at 06:04:21PM -0500, Norman Vine wrote: Manuel Bessler writes: I am working on something similar to OpenGC, but not OpenGL based, but rather xlib-based... (its supposed to run on lowlevel Pentiums w/ non-3D accel graphics cards, maybe even 486s) I couldn't find any good info on what kind of map projection technique to use for the ND. ie. mapping lat/lon to x/y-screen coord. I took a look at the OpenGC source, and as far as I understand, it uses a technique which converts RijksDriehoeks to Hayford. And how is this going to tie into FlightGear ??? I am not sure whether I'll use one of the existing interfaces (eg. the one for opengc,... probably I'll start testing w/ the telnet interface.) or I if write one (yeah, another one :-) right now, its not connected to anything yet, just keyboard input and joystick for easy test input. http://www.remotesensing.org/proj/ I heard about this... this still doesn't help me with the specific projection technique used on NDs. Also, I have only started digging into all this GIS and similar stuff (also for possible use for my day job) There's a lot of stuff to learn :( Thx, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 747-yasim Questions
On Tue, Nov 05, 2002 at 09:34:55PM -0800, Andy Ross wrote: Only by bugging Curt to make a new release. :) Is CVS relatively stable (near releasability) at this time ? To be fair, building FlightGear from CVS really is no harder than building the source tarballs. Its not really the building, but rather the download/keeping it synced. I still use a 56k Modem and pay by the minute. :( I was gonna try CVS, but I have to d/l it at work. Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 747-yasim Questions
On Mon, Nov 04, 2002 at 09:24:43AM -0800, Andy Ross wrote: Cool, someone's playing with the 747. This model hasn't had a lot of tweaking yet beyond the engine thrust bugs that Jim Wilson dealt with a few months back. Hey, the 747 is the queen of the sky :-) Does it model the thrust reversers ? What about Speedbrakes/Spoilers ? No, no, yes. The spoilers control is mapped to the /controls/spoilers property, which doesn't have a default input binding. I have it wired to one of the thumbwheels on my Saitek throttle. ok, thats cool. I'll just add a key mapping for the spoilers. I didn't even think of snooping around to see wether there is any 'functionality' that I could use and map it to a key. Thrust reversers and speedbrakes wouldn't be hard to support, I've just been lazy. The Boeing obviously doesn't have a speedbrake, but the A-4 and Harrier should. There are still some (much harder) issues with drag scaling that I'd like to get fixed first. None of the planes need a brake right now, since they all sit way behind the power curve during approach and dump speed really fast. BTW: What is the difference between Speedbrakes and Spoilers? Some stuff i was reading about the 747 made it seem to me that the speedbrake lever in the cockpit controls the spoiler surfaces. ... Actually on the cockpit photos I found on the web (eg www.airliners.net) there is a lever that is labeled 'speed brake'. Its the one right next to the #1 Throttle, on the pilots side. Bouncing: Part of this is due to a blindingly stupid bug with ground effect that I discovered this weekend. It should interpolate the effect from zero Is there a way I could apply this to 0.8.0 which I currently have? Another factor is the lack of automatic wing spoiler deployment, which helps a lot to keep the airplane from getting airborne again after a hard landing. This would require just a tiny amount of C++ code right now: watch the /gear[n]/wow properties and set the /controls/spoilers to 1.0 when they transition from false to true. This would be a great application for interactive scripting from the aircraft definition; a feature that has been long talked about but not yet moved on. I played around with the telnet interface and also with fgfsscript.pl I tried to use fgfsscript.pl to get the radio altimeter announcements during approach... but its hard to make this work right, since the polling nature of fgfsscript.pl and since the feet values change rather quickly. So I must allow for a certain 'window' of feet values around those I want announced. Tuning this just right is a lot of work. And finally, I agree. The default gear damping is a little too light. YASim computes a default damping coefficient automatically, based on the weight of the plane and the placement of the gear. But it's not going to work perfectly for all aircraft. There needs to be a per-gear tunable for spring and damping coefficients, but there isn't yet. This is like the reversers/speedbrakes issue -- something unimplemented only due to my laziness. Well, laziness is actually a good character 'flaw' for programmers. :-) Thats the same with me ;-) ... But, back on the topic... so ... when are you gonna implement these 'due to laziness' features Grin ;-) Well, pumping the brakes during the takeoff is hardly standard procedure; I'm not sure what the real aircraft would do. :) The Well, I was trying to 'emulate' the parking brakes by keeping 'b' pressed, advancing the throttle and wait a little for the thrust to develop. joystick trigger is mapped to the wheel brakes, by the way. You can Yeah, I know, but I don't use a joystick to fly. Mouse and keyboard work well (actually: better) for me. I like the mouse yoke. And esp. the mapping of the elev. trim to the mousewheel :-) The wheel bounce issue is real, though. In my copy, I got better results by changing the compression distance of the nose wheel strut from 2m to 1m in the Aircraft-yasim/747.xml file. This has the effect I'm gonna try this. thanks. (BTW: the parking brake doesn't seem to work w/ the 747) Uh, true. This is trivial to fix, just add a mapping from the parking brake property in the 747.xml file. Everywhere you see: I should have thought about this ... that was an easy one :-) I suppose I could wire up an eye candy starter, which spooled the engine up and down from zero while diddling the temperature and fuel flow variables in a vaguely plausible way. But features like realistic engine start aren't possible for this code; they'll need to wait for someone with the patience and dedication to model one specific engine (and electrical system, and APU, and...). :) From what I read on the list, Curt started adding support for electrical systems, and people talked also about pneumatic and hydraulic systems... This will hopefully provide a more 'realistic' way of starting procedures in the future. But a fake eye candy
Re: [Flightgear-devel] Networked Sound / Networked Input
On Mon, Oct 21, 2002 at 06:12:33AM -0700, ace project wrote: Our upcoming network module can support the network joystick input part. Just make a nice 'packet-layout' (max packet size 512bytes) that contains the info you need, a few functions to fill the variables in Flight Gear and a small program that implements my beta mpeClientHandler-module and you will be all set (not quit that easely, but easy enough). How much effort would this take ? Quick Hack or more like 'a couple days programming'? Networked sound is out of reach for now, I can not guarantee packet delivery yet and out-of-order is deadly for sound, you'll have to use the telnet interface, but even that is less that optimal. Unless! Ofcourse! If you only want to send what file(s) to play, then it can be supported without much difference from the above example. I should have stated that more clearly: It was my idea, just to send what to play, when, and at what volume and pitch. I had another idea: how about the Y Sound Server Library ? http://wolfpack.twu.net/YIFF/ I know that a few linux games make use of it. (I don't know whether it is multiplatform, though) Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Networked Sound / Networked Input
Hi having played around a little bit with flightgrear earlier this year, I got really hooked since 0.8.0 came out. Good work guys... :) A couple of questions have popped up in my mind about some things... (some are especially interesting for cockpit builders :-) Is it possible to have (or implement) Sound and also Input (mostly for analog joysticks -or pots- and keyboards) networked ? eg. if you have several machines networked, one could be used for engine and wind noise, another for gear, flap, touchdown-squeal,... that would allow placing speakers a different places and angles and it would also overcome the limitation of (i think) 3 simultaneous samples playing via plib. Networking Input could allow more than the 4 axes per gameport. And since most computers have soundcards and analog joystick ports anyway, this would allow them to be used. I know that I could add some more joystick ports to my machine but this often not that easy since the good old ISA slots disappear and ISA cards that contain only joystick ports are not easy to find nowadays. USB is not a good way of interfacing your home built stuff since it requires more circuitry than the plain ol'gameport. PS: anyone using OpenGC under unix ? After fixing some capitalization Issues, I got the 0.3 CVS version compiled (using cmake) 2 weeks ago. However it does not work w/ flightgear. Looking at the source I could see why: the fgfs stuff is just left out at some places. PPS: anyone heard of the A340 Glass Cockpit project: http://a340gc.iradis.org/ it uses something called Raw Distributed Data Protocol (RDDP) Happy flying, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
