Re: [Flightgear-devel] Questions about IO system
Mike, Have a look at docs-mini/README.IO for the specific command line syntax, but yes, for task #1 you can setup FG to expect control inputs to come in via an FGNetCtrls packet (which you can send from your remote java application.) You can specify the rate at which FG checks for incoming packets, but you can send the packets whenever you like and FG won't complain. Similarly you can setup FG to export the primary flight dynamics data via the FGNetFDM structure. The details of doing sockets in Java I'll have to leave up to others. :-) There is also the generic protocol which I haven't used as much so I'm less familiar with it. I believe you can set it up for both input and output, but be aware that it sends data out in ascii rather than binary, so you will have a small parsing task on the remote end if you use the generic protocol. The generic protocol is really good for things like exporting to a delimited ascii file for import into excel for instance. Regards, Curt. Mike Kopack wrote: Hey gang, I'm trying to write some Java code to interface with FlightGear's IO system via sockets. I'm running on Windows (don't know if that matters or not.) Anyhow, I need to do two things: 1) Have one socket sending flight commands (like changing the rudder position, or turning on/off the autopilot, setting throttle, etc.) These can come in at any time. 2) Have another socket that my code listens for periodic updates in status information from FlightGear (position, attitude, engine temp, fuel flow rates, etc.) From what I see in the documentation, it shows that you can do this. I'm a bit confused by it though. To do task #1 above, do I just open a socket to Flightgear on the specified port, then send a XML doc with just the 1 command element I want to specify? To do task #2 above, as I understand it, I have to set up a XML file on the machine running FG that basically tells FG what data I want sent back over the socket. Does it come across the wire as an XML doc every x.x seconds (I see that there's a Hz setting when specifying the socket connection in FG), or does it come across as comma delimited or something like that? Any help with this is greatly appreciated. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Questions about IO system
Hi Mike, there's an example in the scripts folder (or utils folder) of the sourcecode (I think) on how to interface in Java. I haven't used it yet due to lack of time :(. Greets, Steven Citeren Mike Kopack [EMAIL PROTECTED]: Hey gang, I'm trying to write some Java code to interface with FlightGear's IO system via sockets. I'm running on Windows (don't know if that matters or not.) Anyhow, I need to do two things: 1) Have one socket sending flight commands (like changing the rudder position, or turning on/off the autopilot, setting throttle, etc.) These can come in at any time. 2) Have another socket that my code listens for periodic updates in status information from FlightGear (position, attitude, engine temp, fuel flow rates, etc.) From what I see in the documentation, it shows that you can do this. I'm a bit confused by it though. To do task #1 above, do I just open a socket to Flightgear on the specified port, then send a XML doc with just the 1 command element I want to specify? To do task #2 above, as I understand it, I have to set up a XML file on the machine running FG that basically tells FG what data I want sent back over the socket. Does it come across the wire as an XML doc every x.x seconds (I see that there's a Hz setting when specifying the socket connection in FG), or does it come across as comma delimited or something like that? Any help with this is greatly appreciated. Thanks! --Mike Mike Kopack ISX Corporation 1800 Parkway Place Suite 900 Marietta, GA 30067 678-581-2025 [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Questions about IO system
Steven Beeckman wrote: Hi Mike, there's an example in the scripts folder (or utils folder) of the sourcecode (I think) on how to interface in Java. I haven't used it yet due to lack of time :(. Greets, Steven Citeren Mike Kopack [EMAIL PROTECTED]: Hey gang, I'm trying to write some Java code to interface with FlightGear's IO system via sockets. I'm running on Windows (don't know if that matters or not.) Anyhow, I need to do two things: 1) Have one socket sending flight commands (like changing the rudder position, or turning on/off the autopilot, setting throttle, etc.) These can come in at any time. 2) Have another socket that my code listens for periodic updates in status information from FlightGear (position, attitude, engine temp, fuel flow rates, etc.) From what I see in the documentation, it shows that you can do this. I'm a bit confused by it though. To do task #1 above, do I just open a socket to Flightgear on the specified port, then send a XML doc with just the 1 command element I want to specify? To do task #2 above, as I understand it, I have to set up a XML file on the machine running FG that basically tells FG what data I want sent back over the socket. Does it come across the wire as an XML doc every x.x seconds (I see that there's a Hz setting when specifying the socket connection in FG), or does it come across as comma delimited or something like that? Any help with this is greatly appreciated. Thanks! --Mike Mike Kopack ISX Corporation 1800 Parkway Place Suite 900 Marietta, GA 30067 678-581-2025 [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d You don't need XML, all you want to do is read and write the property tree. As Steven said, check FGFSConnection.java in the scripts subdir for access via props/telnet protocol. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Questions
Hi Mostyn mostyn.gale writes ARGH My email server has been playing up. I can't send mail with outlook so I have to send it through the browser, but then it sends the mail from another address so I can't get onto the lists. Get Mozilla I am trying to put gauges in the virtual cockpits of my R22, Pawnee and C152 but I am having trouble understanding the data format. I can get a gauge to appear but I would like to do some gauges with covers, so the needle appears from under it. I can't find the information in the readme.xmlpanel file. Could someone point me in the right direction? On the same matter is there a way of setting coulours on a gauge to be transperent? Are they 3D guages if so just make a layer that is higer than the needle with the area you want to see the needle removed.Just like in real life were the face of the guage is on the bottom then the needle and then the layer that hides the needle at zero then the glass. Making something transparent can take two forms make the material transparent or make the texture you are using transparent Is it possible to animate *.mdl files? No With windows you may need a program called PPE(Pretty Poly Editor)to convert aircraft. Note this will not convert Gmax produced aircraft. Lastly are there any decent freeware/open source XML editors out there? At the moment I am just using wordpad to edit the XML files. What is wrong with wordpad I use it for all my FG XML files. Quick question are you Australian if so where?.I live in Perth Cheers, Mostyn Cheers Innis ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Questions
Le mardi 17 mai 2005 08:57 +1000, mostyn.gale a crit : ARGH My email server has been playing up. I can't send mail with outlook so I have to send it through the browser, but then it sends the mail from another address so I can't get onto the lists. Anyway I have a bit of a backlog of questions. I am trying to put gauges in the virtual cockpits of my R22, Pawnee and C152 but I am having trouble understanding the data format. I can get a gauge to appear but I would like to do some gauges with covers, so the needle appears from under it. I can't find the information in the readme.xmlpanel file. Could someone point me in the right direction? On the same matter is there a way of setting coulours on a gauge to be transperent? Is it possible to animate *.mdl files? I have been trying to animate my R22 which is in .mdl format and made by Abacus FSDS. Here is an example of the code in the /Models/r22.xml file. Cheers, Mostyn I could never animate mdl, BUT you can try to translate your model.mdl to model.ac .dxf ... with threedconvert which is in your source/util/Modeller directory I use threedconvert to convert from mdl format to ac format or dxf format. Sometime the result is bad, sometime very good, sometime threedconvert give a segmentation error. If the result is good you could manipulate your model with a CAD application (Blender,AC3D). And give a name to each part you want animate. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Questions about problems with the particle system
Luca Masera wrote: Hi, I've done some work on the particle system using the primitives of PLIB. I've however some problems. The first and the second screenshots are made with the simulator freezed and the only difference is the position of the head of the pilot. Why the object change their color? (The right texture is the white green). This is doe to the reflection of the sun on the particles. To change that you will have to set the reflective color of the vertex to 0.0 and the ambient and diffuse colors very close to each other (say 0.49 for ambient and 0.51 for diffuse). Another problem is the billboarding, I think. When the particle system is created there's a boolean used to make it a billboard. I've set it to true but seems that the particles appears only when the POW is directly afore them. I've seen the base code of the particle system and I've found that to create a billboard it's used the matrix GL_MODELVIEW_MATRIX defined into the OpenGL header. This could be the problem or this matrix is updated with the current point of view (maybe this question is for the PLIB develepers, but I make it anyvay)? There are multiple ways for a billboard to behave, most common are spherical (the object always faces the viewer with the same side up) and cylindrical (the object always faces the viewer but the upward pointer is aligned with the scenery all the time, useful for trees for example). For particles you will need to make sure it behaves spherical. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Questions about scenery objects
Josh Babcock wrote: What would be good poly counts and texture sizes for low and high LOD models of individual objects? Same for autogen objects? Most of the time, buildings on the screen use up only a tiny number of pixels. I often do buildings with 5 quads and a 64x64 texture, but even that much texture is too much sometimes. A city with a lot of simple buildings will look much more realistic than a city with only a few highly-detailed buildings. I don't think there's any consumer hardware out there yet that could handle, say 300,000 or more buildings for a big city, so the same point applies no matter what you're running. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Questions about scenery objects
David Megginson wrote: Josh Babcock wrote: What would be good poly counts and texture sizes for low and high LOD models of individual objects? Same for autogen objects? Most of the time, buildings on the screen use up only a tiny number of pixels. I often do buildings with 5 quads and a 64x64 texture, but even that much texture is too much sometimes. A city with a lot of simple buildings will look much more realistic than a city with only a few highly-detailed buildings. I don't think there's any consumer hardware out there yet that could handle, say 300,000 or more buildings for a big city, so the same point applies no matter what you're running. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel Hmm, well, I think I'll concentrate on landmarks first anyway, for VFR. Looking at the Models/Buildings directory though I can see that I would have to add lots of little 5 poly buildings. It also occurs to me that there should be a shared texture directory for the Models directory. Lots of call for stuff like light-concrete.rgb or red-brick.rgb or dark-grey-shingle.rgb. There's already some pretty generic sounding texture files in there. Sharing will save disk space as well as texture memory. Also, when one populates an area with purposely placed buildings, how do they turn off autogen for that area? Is this something that can be done without editing a .btg file? Is FG smart enough to not place autogen objects next to defined ones? Josh ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Questions about scenery objects
On Mon, 07 Jun 2004 16:41:21 -0400 David Megginson [EMAIL PROTECTED] wrote: Most of the time, buildings on the screen use up only a tiny number of pixels. I often do buildings with 5 quads and a 64x64 texture, but even that much texture is too much sometimes. A city with a lot of simple buildings will look much more realistic than a city with only a few highly-detailed buildings. I don't think there's any consumer hardware out there yet that could handle, say 300,000 or more buildings for a big city, so the same point applies no matter what you're running. Is there the ability to give a distance-dependancy to the textures used on a model? Or, alternately, to have the specific model/texture set used be distance-dependent? I'm aware that one can apply distance-dependent effects to the xml file, but I haven't yet found any docs about how that works (none in data/Docs, for instance). If possible, then I might think that one could use a very very small texture (little more than color) tiled over the face of an object at large distances, then switch to something more detailed once closer. -c -- Chris Metzler [EMAIL PROTECTED] (remove snip-me. to email) As a child I understood how to give; I have forgotten this grace since I have become civilized. - Chief Luther Standing Bear pgp6iDGaQ4qmx.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Questions about scenery objects
Chris Metzler wrote: Is there the ability to give a distance-dependancy to the textures used on a model? Or, alternately, to have the specific model/texture set used be distance-dependent? I'm aware that one can apply distance-dependent effects to the xml file, but I haven't yet found any docs about how that works (none in data/Docs, for instance). If possible, then I might think that one could use a very very small texture (little more than color) tiled over the face of an object at large distances, then switch to something more detailed once closer. Mipmapping does this for you automatically. The system stores several versions of the texture at reduced resolution. If the original texture is 256x256, then the system will also build a 128x128 version, 64x64, 32x32, 16x16, etc. Then the driver selects the texture resolution that best matches the screen resolution of each polygon it renders. There are cases where this doesn't work as well as you'd like (nearly edge on polygons get a much lower res texture than you'd hope for) but there are often work arounds such as anisotropic texture filtering (which is probably a driver option for most cards/drivers.) Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Questions about scenery objects
On June 7, 2004 09:56 pm, Curtis L. Olson wrote: Mipmapping does this for you automatically. The system stores several versions of the texture at reduced resolution. If the original texture is 256x256, then the system will also build a 128x128 version, 64x64, 32x32, 16x16, etc. Then the driver selects the texture resolution that best matches the screen resolution of each polygon it renders. This is great news. There are cases where this doesn't work as well as you'd like (nearly edge on polygons get a much lower res texture than you'd hope for) but there are often work arounds such as anisotropic texture filtering (which is probably a driver option for most cards/drivers.) Curt. Would you mind explaining what anisotropic texture means? Thanks, Ampere ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Questions about scenery objects
Ampere K. Hardraade wrote: On June 7, 2004 09:56 pm, Curtis L. Olson wrote: Mipmapping does this for you automatically. The system stores several versions of the texture at reduced resolution. If the original texture is 256x256, then the system will also build a 128x128 version, 64x64, 32x32, 16x16, etc. Then the driver selects the texture resolution that best matches the screen resolution of each polygon it renders. This is great news. There are cases where this doesn't work as well as you'd like (nearly edge on polygons get a much lower res texture than you'd hope for) but there are often work arounds such as anisotropic texture filtering (which is probably a driver option for most cards/drivers.) Curt. Would you mind explaining what anisotropic texture means? Hold on, I'm right in the middle of ripping off all my toe nails and dipping my feet in paint thinner. This is a slightly complicated thing to explain and I don't have the energy to really go into detail. I don't claim to be an expert here so my explanation is probably half fantasy and half my own imagination, but here is how I understand it at a conceptual level. Imagine some triangle (part of the scene) that when drawn on your screen consumes about 4 pixels across and 4 pixels high. The opengl system will pick the best square texture that fits the smaller of the two axes so it will probably pick the 4x4 pixel texture. This is a perfect match for the onscreen size of the triangle and gives you great visual results and minimizes any sort of texture aliasing. (Remember the horrible pixel swimming of MSFS 5.x and other early 3d video games? This is what mipmapping fixes.) Now imagine some triangle (part of the scene) that when drawn on your screen consumes about 40 pixels across and 4 pixels high. The opengl system will pick the best square texture that fits the smaller of the two axes so it will probably again pick the 4x4 pixel texture. But, this means that 4 pixels of your texture get stretched across 40 pixels of your screen which makes the result look really blurry. I doubt this is how anisotropic texture filtering is specifically implimented in the driver, but conceptually, anisotropic texture filtering makes additional versions of your texture that are wide and short as well as tall and narrow. This way it can often find a much better match for most/many situations. Now observe that when you view a runway it is almost always as you take off or land or taxi. This means it is almost always nearly edge on. These runway triangles end up being drawn short and wide on your screen which makes the runway texture blur out really quickly. Try turning on anisotropic texture filtering in your driver (under linux/nvidia there is an environment variable to set.) You will find that your runway textures look *much* sharper and nicer ... you can probably now pick out the markings at the opposite end where as before they were probably a big blurry mess. Here's a link, but it angles towards the technical side of it: http://www.opengl.org/resources/tutorials/sig99/advanced99/notes/node67.html Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Questions about scenery objects
Curtis L. Olson wrote: Ampere K. Hardraade wrote: On June 7, 2004 09:56 pm, Curtis L. Olson wrote: Mipmapping does this for you automatically. The system stores several versions of the texture at reduced resolution. If the original texture is 256x256, then the system will also build a 128x128 version, 64x64, 32x32, 16x16, etc. Then the driver selects the texture resolution that best matches the screen resolution of each polygon it renders. This is great news. There are cases where this doesn't work as well as you'd like (nearly edge on polygons get a much lower res texture than you'd hope for) but there are often work arounds such as anisotropic texture filtering (which is probably a driver option for most cards/drivers.) Curt. Would you mind explaining what anisotropic texture means? Hold on, I'm right in the middle of ripping off all my toe nails and dipping my feet in paint thinner. This is a slightly complicated thing to explain and I don't have the energy to really go into detail. I don't claim to be an expert here so my explanation is probably half fantasy and half my own imagination, but here is how I understand it at a conceptual level. Imagine some triangle (part of the scene) that when drawn on your screen consumes about 4 pixels across and 4 pixels high. The opengl system will pick the best square texture that fits the smaller of the two axes so it will probably pick the 4x4 pixel texture. This is a perfect match for the onscreen size of the triangle and gives you great visual results and minimizes any sort of texture aliasing. (Remember the horrible pixel swimming of MSFS 5.x and other early 3d video games? This is what mipmapping fixes.) Now imagine some triangle (part of the scene) that when drawn on your screen consumes about 40 pixels across and 4 pixels high. The opengl system will pick the best square texture that fits the smaller of the two axes so it will probably again pick the 4x4 pixel texture. But, this means that 4 pixels of your texture get stretched across 40 pixels of your screen which makes the result look really blurry. I doubt this is how anisotropic texture filtering is specifically implimented in the driver, but conceptually, anisotropic texture filtering makes additional versions of your texture that are wide and short as well as tall and narrow. This way it can often find a much better match for most/many situations. Now observe that when you view a runway it is almost always as you take off or land or taxi. This means it is almost always nearly edge on. These runway triangles end up being drawn short and wide on your screen which makes the runway texture blur out really quickly. Try turning on anisotropic texture filtering in your driver (under linux/nvidia there is an environment variable to set.) You will find that your runway textures look *much* sharper and nicer ... you can probably now pick out the markings at the opposite end where as before they were probably a big blurry mess. Here's a link, but it angles towards the technical side of it: http://www.opengl.org/resources/tutorials/sig99/advanced99/notes/node67.html Regards, Curt. Here's another: http://www.extremetech.com/article2/0,1558,1152380,00.asp Josh ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Questions about flight model
The Merlin is a rotary engine, isn't it? A rotary engine ? As in http://travel.howstuffworks.com/rotary-engine.htm ? Most people probably will agree that it's a V-12 piston engine ;-) Details about the engine oil pressure might be documented in some sort of engine manual: http://www.yellowairplane.com/Book_Reviews/Mustang_Manual/Mustang_Manual_Cover.html Regards, Hermann In any case, a pump attached to the engine accessory drive (along with the vacuum pump, etc.) is standard on a horizontally-opposed engine. The O-320 in my Warrior does have a relief valve, as well as a breather in the accessory housing to avoid excess pressure buildup in the crankcase. Oil pressure is usually pretty constant at anything other than idle RPM once the engine's warmed up, suggesting that the relief valve kicks in pretty early, as with the vacuum pump -- I'll try to pay more attention next time I'm up (rather than just checking that it's in the green). All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Questions about flight model
Hermann Schiffer wrote: The Merlin is a rotary engine, isn't it? A rotary engine ? As in http://travel.howstuffworks.com/rotary-engine.htm ? He meant radial, of course, which was true of most WWII era aircraft engines other than the Merlin. And if you really want to nit, what you describe is best called a Wankel engine. A rotary engine in aviation context is an ancient design where the pistons were arranged radially, but were fixed to the propeller and spun with the engine. The early propellers weren't large enough and the early engines not smooth enough to idle successfully without a flywheel. This was a trick to turn the whole engine into a flywheel. :) http://en.wikipedia.org/wiki/Rotary_engine Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Questions about flight model
On Fri, 23 Apr 2004 17:43:59 +0200 Luca Masera [EMAIL PROTECTED] wrote: Hi everyone, about JSBBim: the airplane has three tanks, but the flight model uses only the first. In other words, if I start FlightGear with the first tank empty, the engine is off and doesn't starts. This happens even if the first tank is plenty or with few fuel (I've tried with 1gal and when it's all consumed, the engine shuts off, even if the other two tanks are full). How I can solve this problems? There's someone that could helps me? We'll look at that. Tanks, Tanks, Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Questions about flight model
Luca Masera wrote Hi everyone, I'm creating the 3d instruments for the mb339 using JSBSim and YASim as flight dynamics models. The questions are: about YASim: in which units is measured the oil pressure? In JSBSim the value is holded by oil-pressure-psi and it's measured in psi; in YASim is holded by epr but the units are missing. Epr is exhaust pressure ratio. AFAIK, oil pressure is not modelled. Regards Vivian Meazza ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Questions about flight model
Luca Masera wrote: about YASim: in which units is measured the oil pressure? In JSBSim the value is holded by oil-pressure-psi and it's measured in psi; in YASim is holded by epr but the units are missing. Er, that's an Engine Pressure Ratio , which is a thrust metric used in early jets in lieu of N1 RPM. YASim doesn't model oil pressure right now, because I'm not aware of a good basis on which to do so. If you have numbers you want to match for this particular aircraft, I could write you up some Nasal in just a few minutes which would do the job. But the idea behind YASim is to produce plausible results for all possible engines; oil pressure is one of those values that is (AFAIK) just too engine-specific. The units are missing, btw, because there aren't any. It's a ratio. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Questions about flight model
Andy Ross wrote: Er, that's an Engine Pressure Ratio , which is a thrust metric used in early jets in lieu of N1 RPM. YASim doesn't model oil pressure right now, because I'm not aware of a good basis on which to do so. If you have numbers you want to match for this particular aircraft, I could write you up some Nasal in just a few minutes which would do the job. But the idea behind YASim is to produce plausible results for all possible engines; oil pressure is one of those values that is (AFAIK) just too engine-specific. How about allowing the config to contain a couple of sample values and then interpolating (taking into account outside temperature, engine temperature, and power setting)? All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Questions about flight model
Andy Ross wrote: But the idea behind YASim is to produce plausible results for all possible engines; oil pressure is one of those values that is (AFAIK) just too engine-specific. Further to the point, here is some information from the Lycoming O-320 Operator's manual; it would make a good starting point for horizontally-opposed piston engines. Oil Temperature: 180 degF desired, 245 degF maximum [down to 160 degF and 210 degF below 10 degF OAT] Oil Pressure: Normal: 90 psi maximum, 60 psi minimum, 25 psi idling Start and warm up: 100 psi maximum All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Questions about flight model
--- Andy Ross [EMAIL PROTECTED] wrote: Luca Masera wrote: about YASim: in which units is measured the oil pressure? In JSBSim the value is holded by oil-pressure-psi and it's measured in psi; in YASim is holded by epr but the units are missing. Er, that's an Engine Pressure Ratio , which is a thrust metric used in early jets in lieu of N1 RPM. FWIW, PW still prefers EPR over N1. YASim doesn't model oil pressure right now, because I'm not aware of a good basis on which to do so. If you have numbers you want to match for this particular aircraft, I could write you up some Nasal in just a few minutes which would do the job. But the idea behind YASim is to produce plausible results for all possible engines; oil pressure is one of those values that is (AFAIK) just too engine-specific. The units are missing, btw, because there aren't any. It's a ratio. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel __ Do you Yahoo!? Yahoo! Photos: High-quality 4x6 digital prints for 25ยข http://photos.yahoo.com/ph/print_splash ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Questions about flight model
David Megginson wrote: How about allowing the config to contain a couple of sample values and then interpolating (taking into account outside temperature, engine temperature, and power setting)? Sure. That was the idea with the Nasal script, actually. Set it to poll every second or so and compute a target for the next second's interpolation. It would be really easy to make this general, so every aircraft/engine could specify a property tree for configuring it, along the lines of the existing flaps detents settings, etc... And if an aircraft wants its own handling, it just writes its own script. But I'm open to suggestions. I'm mildly resistant to putting this in YASim only because table lookup isn't really its thing, and I'm doubtful that such a (fixed, in-FDM-configuration) scheme would really be generic enough for most aircraft anyway. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Questions about flight model
David Megginson wrote Andy Ross wrote: But the idea behind YASim is to produce plausible results for all possible engines; oil pressure is one of those values that is (AFAIK) just too engine-specific. Further to the point, here is some information from the Lycoming O-320 Operator's manual; it would make a good starting point for horizontally-opposed piston engines. Oil Temperature: 180 degF desired, 245 degF maximum [down to 160 degF and 210 degF below 10 degF OAT] Oil Pressure: Normal: 90 psi maximum, 60 psi minimum, 25 psi idling Start and warm up: 100 psi maximum All the best, The Merlin has a gear-driven oil pump and, I assume, a pressure relief valve. I was going to assume that oil pressure was a function of rpm with max and min values. Of course, it is also a function of oil temperature, which is a function of engine temperature. We already know egt. Are most of the building blocks in place already? If we don't want or need a sophisticated answer, then a function of rpm would be enough for an instrument, and that can easily be done in XML. Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Questions about flight model
Vivian Meazza wrote: The Merlin has a gear-driven oil pump and, I assume, a pressure relief valve. I was going to assume that oil pressure was a function of rpm with max and min values. The Merlin is a rotary engine, isn't it? In any case, a pump attached to the engine accessory drive (along with the vacuum pump, etc.) is standard on a horizontally-opposed engine. The O-320 in my Warrior does have a relief valve, as well as a breather in the accessory housing to avoid excess pressure buildup in the crankcase. Oil pressure is usually pretty constant at anything other than idle RPM once the engine's warmed up, suggesting that the relief valve kicks in pretty early, as with the vacuum pump -- I'll try to pay more attention next time I'm up (rather than just checking that it's in the green). All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
