[Flightgear-devel] initializing /environment/clouds/layer variables is broken
For the last couple of weeks, cvs fgfs does not allow initialization by --prop:/environment/clouds/layer[0]/elevation-ft= --prop:/environment/clouds/layer[0]/thickness-ft= --prop:/environment/clouds/layer[0]/coverage= either using fgrun or from the command line. What I am getting is two layers layer 0 is scattered at 4100 ft and 600 ft thick, and layer 1 is cirrus at 2 ft and 65 ft thick. Also, the alt (in Hg) = 29.9729 This is clearly a recently introduced bug. I am running from a cvs update from Jan. 1, 2009. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] initializing /environment/clouds/layer variables is broken
Stuart Buchanan wrote: Dave Perry wrote: For the last couple of weeks, cvs fgfs does not allow initialization by --prop:/environment/clouds/layer[0]/elevation-ft= --prop:/environment/clouds/layer[0]/thickness-ft= --prop:/environment/clouds/layer[0]/coverage= either using fgrun or from the command line. What I am getting is two layers layer 0 is scattered at 4100 ft and 600 ft thick, and layer 1 is cirrus at 2 ft and 65 ft thick. Also, the alt (in Hg) = 29.9729 This is clearly a recently introduced bug. I am running from a cvs update from Jan. 1, 2009. Are you running with /environment/weather-scenario set to Fair Weather by any chance? If so, try changing /environment/weather-scenario to none. I was not setting /environment/weather-scenario to anything, but it defaults to fair weather. If I reset it to none in the gui, nothing changes. If I restart fgfs after changing it to none and applying this change, it restarts with fair weather. It seems to me that the default should be /environment/weather-scenario=none. One should not have to include --prop:/environment/weather-scenario=none. I tested with this property set and it does allow my other /environment/clouds/layer selections to be implemented. Thanks for the help, Dave P. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] new side affect of recent change to camera-group
Hi All and Happy New Year, After updating SimGear and fgfs source from cvs yesterday, I noticed that at low throttle near or on the ground, there is a vertical plane in the field of view such that all the view beyond the prop disc and beyond this plane is darker. This is in the pa24-250 which changes the transparency of the prop disc based on the rpm. I can move this plane by changing /sim[0]/rendering/camera-group/near-field value using the property browser. - Dave P. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Supply (voltage) for instruments: True, 1.0, 12.0, !=0 ?
John Denker wrote: Hi -- On 01/01/2009 01:17 PM, Torsten Dreyer wrote: Please find attached a patch as a proof of concept that has been in my head for a while now. Here is a short description of what it does: Check if /systems/electrical/outputs/dme exists (but don't create) If yes: use this node's value for guessing if power is available (for b.c.) If not: check if /instrumentation/dme/supply-voltage-norm exists If yes: check if this node's value is greater than the value of /instrumentation/dme/supply-voltage-min If no: assume power is available. It's now the responsibility of the electrical system (or the aircraft config file) to provide a value to the /instrumentation/dme/supply-voltage-norm node. It is independent of the absolute voltage of the system itself or the operating voltage of the instrument. I'd be happy to refine this concept and provide a patch for the Instruments using the old /systems/electrical/output properties if the community agrees on that idea. Possible refinements to consider: a) Define dme/supply-voltage-norm so that 1.0 is _nominal_. On a typical aircraft with a 24-volt electrical system 24 real volts would correspond to dme/supply-voltage-norm = 1.0 and this is about what we expect to see with the engine off. We would see normed voltage = 1.17 with the engine on. Just to be clear, this is a significant change from what is suggested in the Subject: line, because most RW instruments operate OK from voltages far less than nominal. I reckon if the SW instrument is making a yes/no decision, it should check for supply-voltage-norm 0.8 or even 0.5. Tangential remark: In Real Life, if the voltage gets low, the DME effective range might go down, due to a lack of transmitter power ... but I am not suggesting that we model that level of detail, not now anyway. There are far more serious issues that need attention. The property should be analog, but using it in a nontrivially analog way should be reserved for the future. b) If the most important thing is compatibility with old features, the second-most important thing is to have a good introduction strategy for the new features. It is equally necessary to have an outroduction strategy for the old stuff; otherwise we wind up dragging around a huge legacy tail, forever. There's a network effect here: There's no advantage to upgrading the instruments until at least some important aircraft are updated, and vice versa. Therefore I suggest flipping the order of the check mentioned above: Instruments should check for the new thing first, and if it exists, they should ignore the old thing. The reason is simple: This allows aircraft implementors to get out in front if they want. They can implement both properties, with 100% confidence that a hitherto unknown property will not cause old instruments to fail. Then the aircraft implementor can go do something else, with the expectation that his aircraft will automatically improve as the library instruments improve. We can even provide a nasal script that automatically and systematically clones old-style voltage to make new-style properties. The converse is unchanged: From an instrument implementor's point of view, checking for both properties (in either order!) allows the instrument to get out ahead. The only reason for checking the new thing first is because it works better from the aircraft perspective. Is this really different that what Torsten is suggesting? From the instrument authors pont of view, he has to allow the instrument to operate if either condition is true. c) There is a good outroduction strategy which we can discuss later. There is a 2nd issue that leads to local copies of the instruments for various AC. That is emulating instrument lights via material animations. One of the reasons I made local copies of the radios for the pa24 is that the lighting for the instruments in the RW AC is from the red light in the ceiling panel, so it is really just illumination from between the heads of the front seat passengers. That means the bodies of the radios are also illuminated. But I doubt that having such illumination would not be desirable for some other AC like the seneca. Once we have better light simulation from osg, this issue will not reside in the instrument model any more. - Dave P. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Supply (voltage) for instruments: True, 1.0,
John Denker wrote: On 01/01/2009 05:05 PM, Martin Spott wrote: Different aircraft are equippped with electrical systems of different nominal voltage. You can buy most of the common instruments for at least two different voltages, I have no objection to standardizing on real volts so long as we standardize on something. In the RW they only make one kind of instrument. Some instruments like my GPS have a fancy regulator so they work fine on any voltage from 6 V to 32 V; otherwise there is a jumper on the back of the instrument. Putting a jumper in the SW instrument is super-easy and seems entirely reasonable if one wants this degree of realism. What is not reasonable is having a menagerie of incompatible un-jumperable 1 V instruments, 12 V instruments, 28 V instruments, and instruments that don't check the power state at all. John, I agree completely with pursuing such a standard. Having a documented standard would make both AC and instrument modeling easier. Either approach could work and I could live with either. With the jumper approach, we should also have a fraction required such as 0.8 or 0.5 used in the power test as you suggested. In the pa24, with out the engine running and current being drawn, the battery actually discharges and w/o such a fraction required, the instrument would immediately fail with just the battery power which would be very unrealistic. - Dave P. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] the garden of forking xml
John Denker wrote: Question: In the current CVS, why are there five inequivalent copies (six copies total) of kr87.xml? Similarly, why are there four inequivalent copies of kx165*1.xml? And other examples Other things being equal, such lack of modularity might be somewhat suboptimal from the point of view of reliability, testability, maintainability, extensibility, et cetera. But not suboptimal from the point of view of realism. At least for the pa24-250, adding the following: 1. Check for radio power and 2. Adding material animation to simulate radio illumination from the red light source in the overhead panel required making modified local to the AC changes to the xml files from Aircraft/Instruments-3d. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] fgfs lock up that is repeatable
This may have already been reported. This is with cvs fgfs and SimGear and osg from svn all updated last Monday and plib-1.8.5 running with up-to-date f9 on a amd athlon XP 3200+ with 2 GB ram and a GeForce 7800 SG OC with 256 MB GDDR3 from BFG. I took off in the pa24-250 from Dare CO KMQI and flew Victor airways to Roanoke ROA vor on my way to Charleston Yeager KCRW. Shortly after passing ROA vor, fgfs ground to a halt. System Monitor showed normal 99 to 100% CPU, normal Memory and swap and occasional small Network ( I was running terrasync also). The Log Window was spewing warnings. I saved a portion below. Since this had been more than a 2 hr flight, I tried just departing from Roanoke Rgnl (KROA) and picking up v260 at ROA vor on the 321 radial. Same think happened almost immediately. Here is a Log Window initial capture: FGMultiplayMgr - No receiver port, Multiplayermode disabled KI266 dme indicator #0 initialized Nasal Electrical System Initialized power up Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..) nan nan nan nan nan nan segment ignored.. Warning:: Picked up error in TriangleIntersect (0.032565 0.026345 0.032594,-0.05076 0.022405 0.028615, 0.027754 0.026345 0.024356) (nan,nan,nan) Warning:: Picked up error in TriangleIntersect (-0.05076 -0.022405 0.028615,0.032565 -0.026345 0.032594, 0.027754 -0.026345 0.024356) (nan,nan,nan) Warning:: Picked up error in TriangleIntersect (0.034332 0.013173 0.035063,0.034332 -0.013173 0.035063, -0.05076 -0.011202 0.031085) (nan,nan,nan) Warning:: Picked up error in TriangleIntersect (0.034332 0.013173 0.035063,-0.05076 -0.011202 0.031085, -0.05076 0.011202 0.031085) (nan,nan,nan) Warning:: Picked up error in TriangleIntersect (-0.05076 0.022405 0.028615,0.032565 0.026345 0.032594, 0.034332 0.013173 0.035063) (nan,nan,nan) Warning:: Picked up error in TriangleIntersect (-0.05076 0.022405 0.028615,0.034332 0.013173 0.035063, -0.05076 0.011202 0.031085) (nan,nan,nan) Warning:: Picked up error in TriangleIntersect (-0.05076 -0.022405 0.028615,-0.05076 -0.011202 0.031085, 0.034332 -0.013173 0.035063) (nan,nan,nan) Warning:: Picked up error in TriangleIntersect (-0.05076 -0.022405 0.028615,0.034332 -0.013173 0.035063, 0.032565 -0.026345 0.032594) (nan,nan,nan) Warning:: Picked up error in TriangleIntersect (-0.05076 0.022405 0.028615,-0.05076 0.022405 0.00034, 0.027754 0.026345 0.00034) (nan,nan,nan) Happy Christmas eve, Dave P. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] default trim at startup
Typically, the bendable trim tabs on aileron and rudder are used in real life to get near hands off performance at typical cruise with the ball centered. So a modeller will use the property browser and adjust the values to achieve this so the ball is centred with wings level and no aileron input and then put those values in the set.xml file. I just noticed that when I start with fgrun, all the trim values are set to 0.0 but when I start from the command line, the values in the set.xml are used to initialize the trims. The problem with starting with all trims 0.0 is that there is then no way in an aircraft that only has elevator trim adjust (and even rudder trim adjust) to get non slip/skid cruise with no aileron input. I cannot find what to edit to get rid of the trims being initialized to all being 0.0 when using fgrun. What am I missing? Dave P. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Final (?) 3D clouds patch
Stuart Buchanan wrote: dave perry wrote: You were correct. I had not set the weather scenario to METAR. I ran fgfs once with 3D clouds and once w/o 3D clouds, both with real-weather-fetch and scenario METAR. I only got 1 fps with the 3D clouds. Earlier with 3D clouds, I got about 21 fps. I assume you mean Earlier with 2D clouds, I got about 21fps ? No, that was with 3D clouds. But not via real weather fetch. That's very low. I'd expect a drop of about 10fps. What graphics card are you using? My graphics card: BFG GeForce 7800 GS OC which is an AGP 8x 256MB GDDR3 My system is an AMD Athlon XP 3200+ with 2G of ram. I typically get 70 to 80 fps with 2 D clouds and I had the frame rate throttled to 30 fps when I got the 1 fps with the latest 3D clouds. But I just tried running with 3D clouds and real weather fetch at KLMO and got 16 to 21 fps. Also for both 2D and 3D clouds, the field elevation is not accounted for in applying the cloud base MSL height. The METAR for these 2 runs showed broken at 011 (translates to 1,100 ft AGL) but leaving KDSM field elevation of 957 ft MSL, I was in the clouds by 1100 ft MSL or only about 150 ft AGL. Are we not applying the metar field elevation + metar AGL to get the cloud level? This sounds like a bug, though I thought I saw something adding the field elevation. I'll check. Thanks for pointing it out. -Stuart -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Final (?) 3D clouds patch
gerard robin wrote: On lundi 08 décembre 2008, Stuart Buchanan wrote: Heiko wrote: The clouds looking great now- the order problem is 99% solved so much as I can see! Yes - I think we're pretty much done. I see only some few problems still: -against a second 3d-clouds layer, the problem with z-drawing appears again I don't know how to solve this at the moment. Sorry :( -setting thunderstorm: the clouds has this transparency problem again, perfomance is weak, no lightning and thunder back (o.k. missing feature) maybe (just an idea) we can create a special set of a thunderstorm which is loaded instead the usual set which seems to be changed for fitting. The Thuderstorm scenario has a very specific METAR. We could easily change this to something that looks better. You answer to my previous question ( with the snapshot) on that topic . The blue edges are not on purpose :) One of the enhancements I'd like to make after the release is to allow the scenario METAR strings to be defined in a properties file, so a user can save METARs they want to fly in the future. SNIP -Stuart Cheers The 3D cloud appearance is much improved. Thanks to all involved! Several questions and comments. 1. At night, the emmissive seems very very bright. 2. Are you intending that the 3D cloud base should match the lowest level in the current METAR? I just flew with a KDSM METAR using real weather fetch (current METAR copied from ADDS:* KDSM 081954Z 10007KT 10SM BKN130 OVC160 01/M03 A2964 RMK AO2 SLP047 T00111033. * ) This gives a broken layer at 13000 ft AGL but the 3D clouds started at 2000 AGL. 3. When I took off, the outside view showed the clouds flickering. -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] c172p pitch at cruise question
Jon S. Berndt wrote: The JSBSim C172 FDM assumes the thrust line is the X axis. I'm not sure what the angle of incidence of the wing is, but it seems that at rest on the runway the pitch of the C172 should be 5 degrees, according to the picture you attached. Jon But as others have pointed out, this attitude should be determined by the modeling of the main gear flex and nose strut compression. The 3D model should be such such that when the FDM calls for 0 degrees pitch, the 3D model does not need any pitch rotation. If the modeller tries to achieve the attitude that a taxiing AC would have (e.g. 5 degrees pitch) in blender or ac3d, then the AC will have that 5 degrees pitch when the FDM is calling for 0 degrees. Dave P. -Original Message- From: Heiko Schulz [mailto:[EMAIL PROTECTED] Sent: Monday, December 08, 2008 12:16 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] c172p pitch at cruise question Hi, I had today a closer look into this issue. I got a drawing of the OM of a c172 which shows the the pitch angle with compressed nose gear. I tried to rotate the model but then I found something which shows me that the problem lies on the fdm: at cruise speed about 100kias I got a pitch about 0.3- 0.55 degres. Myself and some others in IRC-Chat noticed that the model is hardly to steer on the ground and lift of itself without touching the controls or the trim. I don't know, but could it be that the cg of the aircraft isn't right which makes all these? Attached the drawing from the OM. Cheers HHS -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Final (?) 3D clouds patch
Stuart Buchanan wrote: Dave Perry wrote: The 3D cloud appearance is much improved. Thanks to all involved! Several questions and comments. 1. At night, the emmissive seems very very bright. 2. Are you intending that the 3D cloud base should match the lowest level in the current METAR? I just flew with a KDSM METAR using real weather fetch (current METAR copied from ADDS:* KDSM 081954Z 10007KT 10SM BKN130 OVC160 01/M03 A2964 RMK AO2 SLP047 T00111033. * ) This gives a broken layer at 13000 ft AGL but the 3D clouds started at 2000 AGL. Was the weather scenario set to METAR as well - one of the bugs I fixed with the latest patch was that previously --enable-real-weather-fetch over-wrote the various scenarios. Now, you will only get METAR if you have METAR as the scenario, as well as --enable-real-weather-fetch. -Stuart You were correct. I had not set the weather scenario to METAR. I ran fgfs once with 3D clouds and once w/o 3D clouds, both with real-weather-fetch and scenario METAR. I only got 1 fps with the 3D clouds. Earlier with 3D clouds, I got about 21 fps. Also for both 2D and 3D clouds, the field elevation is not accounted for in applying the cloud base MSL height. The METAR for these 2 runs showed broken at 011 (translates to 1,100 ft AGL) but leaving KDSM field elevation of 957 ft MSL, I was in the clouds by 1100 ft MSL or only about 150 ft AGL. Are we not applying the metar field elevation + metar AGL to get the cloud level? Dave P. -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] c172p radio order?
Is there a reason that com1 and nav1 are the lower kx165 while the nav1 vor head is on top? -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] c172p pitch at cruise question
dave perry wrote: Hi All, snip Would it not be more realistic to rotate the 3D model about -3 or -4 degrees about the ac3d z-axis. I did not make myself clear in the initial questiion. The video link only detracted from my point. The model in the .ac file is just a rigid body that gets displayed when the fdm says the pitch is zero degrees (or perhaps zero incidence). The fdm then rotates this rigid model for other flight conditions. So if the model starts 3 or 4 degrees too nose high for realistic cruise, it will remain 3 or 4 degrees too high in pitch for all other rotations from the fdm. In particular, it will be 3 or 4 degrees higher than a realistic stall at touch down, burying the tail cone in the runway. To make this clear, I opened the c172p.ac in ac3d, made a screen capture of the side view, then rotated the model by - 4 degrees and made a 2nd screen capture of the side view and then scaled and combined these into one small .png which is attached. My only point is that I think the rotated side view pitch (bottom image) looks like a c172p at cruise and the original side view (top image) looks like a c172p in level no flap slow flight. Compare the wing and horizontal stab incidence angles in the two images. In the rotated side view, the horizontal stab is at zero incidence while the non rotated side view shows a noticeable positive incidence for the horizontal stab which would normally require significant up elevator to maintain. Making this change will be a lot of work since the panel will be messed up. I know because I made a similar rigid rotation correction about a month after I first submitted the pa24-250. Dave P. inline: c172p-4deg-pitch.png-- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] stall horn sound
Curtis Olson wrote: Hi Dave, I just commited a tweak to FlightGear cvs that relaxes the check for a stationary versus moving view point to account for the moving view offset as the aircraft flies by. See if things work any better for your now. Thanks Curt, This fixed it so the doppler effect is back with the YASim set files unchanged from cvs. I will do more testing with several AC later. - Dave P. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] stall horn sound
Curtis Olson wrote: I've done some work on the sound system in main.cxx and have attached a patch for folks to review if they want to look at what I did. I made a simplifying assumption that the listener is either stationary (stationary enough) or it is tracking with the aircraft model position. ... SNIP Then I used my simplifying assumption to set the listener velocity vector to (a) zero if the listener is stationary or (b) the model_vel if the listener is moving. This seems to really help clean up the stall horn sound (and hopefully the marker beacon sounds which suffered the same effect.) But at the same time, the doppler effects are maintained as they were. Curt, I am not sure this change is the cause, but there is now no doppler effect for yasim models that have non zero target-z-offset-m's for views 1 through 6. I noticed that the j3 cub, the pittss1c, and the yasim A6M2 all have doppler effects. They all also have no view n=j /view for j=1, 2, ... , 6. But the pa24-250, pa26-161, p51d, and bo105 have no doppler effect. They do have non zero target-z-offset-m in view n=j/view for j=1, 2, ... , 6. I also noticed that if I change the target-z-offset to 0.0, the doppler effect returns but the center of the views is then not what the model author intended. Dave P. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] stall horn sound
Curtis Olson wrote: Hmmm, I don't see anything obvious in the code that would cause this. Actually, you should only get the doppler effect in stationary views. Chase views will inherit the model velocity. But you should get doppler effect in the fly-by view and tower views ... is this not the case? No, unless I comment out view 3 and view 6, I don't get any doppler effect for the tower vew or the fly-by view. This is with yesterday's cvs for SimGear and fgfs source. Dave P. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] dramatic drop in frame rate with either osg from svn or osg-2.7.5
Hi all, Over the weekend, I compiled osg from svn update, SimGear from cvs update, and FlightGear source from cvs update. My frame rate is now less than 10 fps and it was a solid 31 fps with --prop:/sim/frame-rate-throttle-hz=30 and 50 to 70 fps w/o the frame-rate-throttle. The before compile was for both fgfs and SimGear from cvs a week ago, but osg from svn at least a month old. I also tried recompiling against osg-2.7.5 and got similar low fps. The reason I updated osg from svn was to avoid the Z-near problem. I do have boost-1.34.1-15.fc9.i386 installed. Are others seeing a dramatic fps drop with recent updates or did I miss something required for the recent updates? - Dave P. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] dramatic drop in frame rate with either osg from svn or osg-2.7.5
dave perry wrote: Hi all, Over the weekend, I compiled osg from svn update, SimGear from cvs update, and FlightGear source from cvs update. My frame rate is now less than 10 fps and it was a solid 31 fps with --prop:/sim/frame-rate-throttle-hz=30 and 50 to 70 fps w/o the frame-rate-throttle. Never mind. Problem went away when I opened the NVIDIA X Server Settings and then closed it w/o changing any settings. - Dave P. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] eyecandy: landing lights
Heiko Schulz wrote: The Noratlas Landing light is crude, not perfect. Versus the snapshots from Torsten which is smooth and more realistic :) Smooth? The lightcircles could need a bit more segments, but for me it looks like your approach. Nethertheless- fine that you both work on that- better some maybe crude ones than noones! :-) I like both! :) Cheers HHS - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel I used the idea from the Noratlas to make landing lights for both the pa28-161 and the pa24-250. In both cases I used material animation to tone them down and make the surface illumination go away smoothly in a matter of feet above the runway. I am anxious to see whether Torsten's approach is an extension of these efforts or a completely new approach perhaps using osg features. - Dave P. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] 3D instruments vanished with today's cvs
After updating SimGear and fgfs source from cvs this morning, the 3D instruments in the pa24-250 and pa28-161 disappear and reappear depending on the the viewing angle. This was not the case with cvs from a week ago. After seeing this anomaly, I updated OpenSceneGraph from today's svn and recompiled all three. The 3D instruments were still not visible. - Dave Perry - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FG menu bar small and no text?
Hi, I just rebuilt fgfs with plib-1.8.5, OpenSceneGraph-2.4.0, and cvs SimGear and FG source. The menu bar is now very small and has no text. Has something changed so I need something else? - Dave Perry - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG build fails with plib 1.8.5 and SLD
Alasdair Campbell wrote: So all is OK now except for the hotspots on my c172 radio stack which have gone haywire. Clicking on the COM2 swap button switches COM1 radio, Clicking the ADF buttons change the COM2 radio, the Autopilot buttons are ineffective, etc.etc. Can anyone confirm this behaviour? Try resizing the window. I pointed this out more that a month ago, but Tim Moore (who is maintaining osgviewer) was unable to reproduce the problem on his system. The resize can be dragging a side of the window or minimize/maximize the window. The mouse coordinates are not properly initialized (I speculate) until this is done. - Dave Perry - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] electrical updates to kt70.xml break it
Ron Jensen wrote: On Sat, 2008-03-01 at 20:37 -0700, dave perry wrote: I just noticed that the recent electrical updates to the kt170.xml submitted by Ron Jenson make the kt70 bright white if the instrument lights are turned on in the pa24-250 and the pa28-161. This is because the material animation factor should be between 0 and 1 and this change makes it equal to the output voltage from the buss (usually either 14 or 28 volts in most light AC). factor-propsystems/electrical/outputs/instrument-lights/factor-prop This saturates the material red, green, blue values. snip Ron, is there a reason this needed to be changed for the kt70? Hi Dave, The change was to make the KT-70 only work when the electrical system was turned on. The old setting of /controls/lighting/panel-norm was wrong, and needed to be changed to something based on the electical system. In all the electrical systems I have done, bus_volts is always the voltage that results when a switch connects the item to a bus. That way I can model the impact of the loads when the bus is supplied only by the battery. That is, if the pilot sits on the ramp with all the lights on and the radios on, etc., then the battery will slowly discharge and the voltage on the bus will slowly drop. If I need to have a normalized value for a material animation, I normalize it in nasal and do a setprop for the normalized value. Before your change, that was setprop(/controls/lighting/panel-norm, bus_volts * 0.071428571 * (1.0 - factor)); where the term (1.0-factor) implements the dimmer. That was so I would not have to change the kt70.xml file. All the other panel objects illuminated by the instrument lights have their material factor controlled by setprop(/sim/model/material/instruments/factor, bus_volts * 0.071428571 * (1.0 - factor)); Notice that, either way, this means that the instrument lights will also slowly get dimmer as the loads discharges the battery. The number 0.071428571 is 1/14 and normalizes for the maximum voltage. The electrical systems I use normalize the property systems/electrical/outputs/instrument-lights. By normalizing the /system/electrical/output/... property, the battery discharge is no longer going to dim the instrument lights. I didn't realize you were using the KT70 or I would have verifed it worked on your planes, too. I don't like the property /sim/model/material/instruments/factor. I feel its in the wrong place, and isn't well named, and using both systems/electrical/outputs/instrument-lights and sim/model/material/instruments/factor is redundant. It is not redundant if you are trying to model a battery that can discharge which is the nature of real batteries. The fact that we need to normalize is an artifact of the material animation implementation, not a property of the electrical system. Using two properties here lets the battery, switches, load impact, and dimmers all be realistically taken into account. The artifact created by our implementation of material animation is then accommodated by the sim/model/material/instruments/factor. Normalizing /system/electrical/outputs/instrument-lights to a number between 0 and 1 means is is no longer an electrical output. It is in fact a model material factor. A grep thru CVS show there are only 5 aircraft using /sim/model/material/instruments/factor now. Most aircraft are using some variant of systems/electrical/outputs/instrument-lights. I'd like to use that as a normalized value to allow instruments to just work regardless of the system voltage modelled. What should be the standard for instrument lighting properties? Ron Ron, I am not sure what the standard should be. I just went through the Instruments-3d sub folders and (if I counted correctly) 24 of them use sim/model/material/instruments/factor while 10 use systems/electrical/outputs/instrument-lights to change the emission material properties. The remainder do not adjust the material properties. I gave my reasons for having a factor that represents the voltage separate from the normalized factor for the emission material property. I just looked at pa24-electrical.nas and I believe I can model the desired switch, dimmer, and battery discharge dimming using either approach. But I find it distasteful to assign a material factor between 0 and 1 to a property in /systems/electrical/output/... . What do the rest of the team think? Am I just being pedantic? - Dave - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] electrical updates to kt70.xml break it
I just noticed that the recent electrical updates to the kt170.xml submitted by Ron Jenson make the kt70 bright white if the instrument light are turned on in the pa24-250 and the pa28-161. This is because the material animation factor should be between 0 and 1 and this change makes it equal to the output voltage from the buss (usually either 14 or 28 volts in most light AC). factor-propsystems/electrical/outputs/instrument-lights/factor-prop This saturates the material red, green, blue values. Several of the aircraft are expecting this to be controlled by factor-propsystems/electrical/outputs/instrument-lights/factor-prop since they are assuming a rotating dimmer controls the intensity, not the bus voltage turned on by the switch. Many other objects in Instruments-3d have a material animation tied to factor-propsystems/electrical/outputs/instrument-lights/factor-prop to simulate variable instrument light intensity. Ron, is there a reason this needed to be changed for the kt70? - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flying over an island
LeeE wrote: On Monday 11 February 2008 13:59, Melchior FRANZ wrote: * Thomas Förster -- Monday 11 February 2008: At least I think conservative is the right term. Oh, I didn't think that it was wrongly used. It's just that the decision was meant to be reasonable for the case based on logical considerations, and not the least on whether it would be (seen as) conservative. And I found the fact that a clear rendering bug is blamed on METAR or a conservative decision there annoying. But I like the idea to make an educated guess based on other METAR values, and I plan to implement that later today. I'll use a large set of stored METAR messages with specified (i.e. non- or M*) visibility to see which elements (other than humidity) have a correlation with the visibility. BTW: the biggest numbers that I found were 110 miles (KMWN Mount Washington -- not in our DB -- but there's a KHIE Mount Washington Rgnl!?). (That's assuming that the 9000 km from HAAB were a mistake. ;-) m. 9000km - lol:) I think I'd suspect the 110 miles figure (if that's a ground level value) as well, not only because that's a lot of atmosphere to see through but also because of curvature. I work at the Longmont CO Seagate Technology development center which is located adjacent to the Longmont, CO Vance Brand field (KLMO). It is a typical clear Colorado day that I can clearly see Pikes Peak 80 nautical miles (148 km) to the south from high spots on the road or as I lift off from KLMO in the pa24. By typical, mean about half of the time in the winter and less in the summer due to haze or afternoon showers. This is high desert country and the humidity is usually very low (10 to 20 %). I can never get fgfs visibility that models what I usually experience when I fly here. -Dave - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] making a garmin 496 respond to fgfs serial port
Curtis Olson wrote: On Feb 13, 2008 2:59 PM, dave perry wrote: I have the thread from 2006-08-26 between Curt Olson and Frederic Bouvier on this subject. The connection to the 496 is via a db-9 to super small usb cable I got from garmin as suggested in the garmin user's guide. From a dmesg, I expect that com1 is /dev/ttyS0 on my f7 system. I use the following option when launching fgfs: --AV400=serial,out,5,/dev/ttyS0,9600 and I have the garmin in Simulation, Aviation modes and Interface serial Data Format is Aviation In (before I launch fgfs). When I launch fgfs, I get Cannot open /dev/ttyS0 for serial I/O Error opening device: /dev/ttyS0 Error opening channel communication layer. I/O Channel config failed. Segmentation fault These are the lines from a grep of the dmesg. Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A which makes me think that com1 corresponds to /dev/ttyS0 and com2 corresponds to /dev/ttyS1. I also tried under WinXP with com1 replacing /dev/ttyS0 and C:\ mode com1 data=8 parity=n per the thread. fgfs did ran with no errors but the gps did not respond. Any suggestions? I would really like to use fgfs to get me familar with the gps before I am in the clouds and being vectored by Denver center. First thing I would check would be the permissions on the serial ports. You may need to add yourself to the uucp group for instance in order to be able to use them. Thanks Curt, I just did this after a google found a script file to put in /etc/security/console.perms.d/ttyS0.perms. fgfs now launches with no errors but the 496 still just sits there with no change. Here is what I get from setserial: [EMAIL PROTECTED] ~]$ setserial /dev/ttyS0 -a /dev/ttyS0, Line 0, UART: 16550A, Port: 0x03f8, IRQ: 4 Baud_base: 115200, close_delay: 50, divisor: 0 closing_wait: 3000 Flags: spd_normal skip_test Do I need to set the divisor so 9600 = Baud_base/divisor? Regards, Dave Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ http://baron.flightgear.org/%7Ecurt/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] making a garmin 496 respond to fgfs serial port
I have the thread from 2006-08-26 between Curt Olson and Frederic Bouvier on this subject. The connection to the 496 is via a db-9 to super small usb cable I got from garmin as suggested in the garmin user's guide. From a dmesg, I expect that com1 is /dev/ttyS0 on my f7 system. I use the following option when launching fgfs: --AV400=serial,out,5,/dev/ttyS0,9600 and I have the garmin in Simulation, Aviation modes and Interface serial Data Format is Aviation In (before I launch fgfs). When I launch fgfs, I get Cannot open /dev/ttyS0 for serial I/O Error opening device: /dev/ttyS0 Error opening channel communication layer. I/O Channel config failed. Segmentation fault These are the lines from a grep of the dmesg. Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A which makes me think that com1 corresponds to /dev/ttyS0 and com2 corresponds to /dev/ttyS1. I also tried under WinXP with com1 replacing /dev/ttyS0 and C:\ mode com1 data=8 parity=n per the thread. fgfs did ran with no errors but the gps did not respond. Any suggestions? I would really like to use fgfs to get me familar with the gps before I am in the clouds and being vectored by Denver center. -Dave - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Garmin Series 400 Aviation In data format
Hi Curt and Frederic, My wife gave me a Garmin GPSmap 496 for Christmas. Nice wife, huh! Anyway, I recalled this thread and want to confirm whether either of you have had success with the --AV400 beyond what was reported in this thread. Did you get FlightGear to drive the Garmin GPS III Pilot from Linux? I have ordered the serial interface cable from Garmin and will be trying to drive the 496 in simulation mode from FlightGear when it arrives in about 7 to 10 days. Besides the fun, this would be a great way to become very comfortable with the 496 and all its features w/o the pressure of using it in a real flight plan. I cannot pause the real pa24 to figure out what I did wrong with the GPS keypad. -Dave Frederic Bouvier wrote: Curt, Frederic Bouvier wrote : What option do you use to make it working ? I tried --AV400=serial,out,5,com1,9600 and --AV400=serial,out,5,com1,4800 without luck. Assuming the GPS unit interface is set to Aviation In, and not GARMIN I managed to make it work under Windows with my Garmin GPS III Pilot. For that, I had to restore the \r you removed from each sub messages. I don't understand why you removed them because the CVS comment implies they are needed, or the stream is opened in text mode under Linux, adding an undesired one. Under Windows the stream is opened in binary mode so \r is needed in the code. I won't commit my change before knowing your thought about that. When the line ending issue is cleared, transmission has to be done at 9600 bauds, 8 data bits, no parity. The channel parameters only set the baud rate, so one has to enter the following command at the window command prompt before starting fg : c:\ mode com1 data=8 parity=n that should display the new parameters. This command doesn't work when the port is already opened. Then the GPS Unit has to be put in simulation mode ( menu in the satellite page ), and the 'Aviation In' protocol must be activated in the Interface page of the system setup. Finally start fgfs with the option --AV400=serial,out,5,com1,9600 There is a handy freeware under windows to monitor serial ports : http://www.sysinternals.com/Utilities/Portmon.html -Fred - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] clearer patch to renderer.*xx - accomodates non 4:3 aspect ratios with osg
Tim Moore wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 dave perry wrote: | Tim Moore wrote: | -BEGIN PGP SIGNED MESSAGE- | Hash: SHA1 | | dave perry wrote: | | Tim Moore wrote: | | -BEGIN PGP SIGNED MESSAGE- | | Hash: SHA1 | | | | I've checked in a fix that addresses the non 4:3 problem and also fixes the osgviewer | | distortion issue. It turned out to be pretty hairy. Please give the patch a try. | | | | | | | | Thanks Tim, | | | | With today's SimGear and source cvs, I compiled with --enable-osgviewer | | and the distortions with resizing are gone. Another issue I had | | documented remains. If I don't resize, the hot spot | | vertical-coordinates are too low. Once I resize or maximize the screen, | | the hot spots are correct. It appears the mouse vertical is initially | | off until you resize. | I did check this and it seemed to work for me, but I'm probably used to hunting around | for the hotspots when I click on stuff. Can you give me a precise example that doesn't | work? Also, what's the magic for displaying the hot spots? | | When I start fgfs in the pa24 with the Century IIb, and try and switch | the autopilot on (lower left on the panel), clicking from the lower 1/3 | of this switch to about 2/3 of the height of the switch below the switch | is hot. In other words, the active hot spot is about 2/3 of the height | of this switch too low. To display the hot spots, type ctrl-C. All the | hot spots are the same distance too low. | | If you maximize the window, or just resize the window, the active area | of the hot spot will be moved up to the right location. I'm not seeing this at all with --enable-osgviewer. Perhaps it's a weird interaction with your window manager? Are you running Windows or Linux? Here are my configure options: ./configure --build=i686 --enable-osgviewer --prefix=/usr/local/FlightGear/data I am running a regularly updated Fedora 7 which is gnome based on two machines. I see this on both my desktop (nvidia GeForce 7800 GS OC) with a 1680x1050 TFT LCD monitor and on a Dell Latitude D810 notebook (ATI X600 mobile) with a 1920x1200 screen. Another issue I keep forgetting to mention; the tower views are broken with --enable-osgviewer. They seem to have a wrong near by longitude and latitude with a way too low altitude (usually below ground). - Dave - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] clearer patch to renderer.*xx - accomodates non 4:3 aspect ratios with osg
Tim Moore wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 dave perry wrote: | Tim Moore wrote: | -BEGIN PGP SIGNED MESSAGE- | Hash: SHA1 | | I've checked in a fix that addresses the non 4:3 problem and also fixes the osgviewer | distortion issue. It turned out to be pretty hairy. Please give the patch a try. | | | | Thanks Tim, | | With today's SimGear and source cvs, I compiled with --enable-osgviewer | and the distortions with resizing are gone. Another issue I had | documented remains. If I don't resize, the hot spot | vertical-coordinates are too low. Once I resize or maximize the screen, | the hot spots are correct. It appears the mouse vertical is initially | off until you resize. I did check this and it seemed to work for me, but I'm probably used to hunting around for the hotspots when I click on stuff. Can you give me a precise example that doesn't work? Also, what's the magic for displaying the hot spots? When I start fgfs in the pa24 with the Century IIb, and try and switch the autopilot on (lower left on the panel), clicking from the lower 1/3 of this switch to about 2/3 of the height of the switch below the switch is hot. In other words, the active hot spot is about 2/3 of the height of this switch too low. To display the hot spots, type ctrl-C. All the hot spots are the same distance too low. If you maximize the window, or just resize the window, the active area of the hot spot will be moved up to the right location. Hope this was clear. - Dave Perry - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] clearer patch to renderer.*xx - accomodates non 4:3 aspect ratios with osg
dave perry wrote: Tim Moore wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 dave perry wrote: | Patch adds a member function to FGRenderer class that returns the | current aspect ratio. Uses this in place of 4.0/3.0 in setFOV and | setNearFar. | | The diff follows: | This seems a little confusing / confused. In setFOV, why would you ignore the w argument? Now, I happen to know that /sim/startup/xsize is set to the value of w somewhere in one of the callers, but this is not clear at all. Can we untangle this a bit? In setFOV, you can use w/h for the aspect ratio. But in setNearFar just below this, w and h are not defined in that context, so you need to get the real current aspect ratio from some where. Hi Tim, The following patch uses w/h for the aspect ratio in setFOV and then uses xsize/ysize (from /sim/startup) for the aspect ratio in setNearFar. This accomplishes using the actual aspect ratio in place of 4.0/3.0 without having to add a new member function to the FGRenderer class. Please commit this patch. It fixes the same issue as the last patch and the behavior is the same as described on my last note. renderer.cxx patch follows: Index: renderer.cxx === RCS file: /var/cvs/FlightGear-0.9/source/src/Main/renderer.cxx,v retrieving revision 1.100 diff -p -u -r1.100 renderer.cxx --- renderer.cxx6 Jan 2008 23:03:20 -1.100 +++ renderer.cxx21 Jan 2008 15:48:33 - @@ -872,7 +872,7 @@ void FGRenderer::setFOV( float w, float fov_width = w; fov_height = h; osgViewer::Viewer* viewer = globals-get_renderer()-getViewer(); -viewer-getCamera()-setProjectionMatrixAsPerspective(fov_height, 4.0/3.0, +viewer-getCamera()-setProjectionMatrixAsPerspective(fov_height, w/h, fov_near, fov_far); } @@ -885,8 +885,10 @@ void FGRenderer::setNearFar( float n, fl n = 0.1; fov_near = n; fov_far = f; +float xsize = fgGetInt(/sim/startup/xsize); +float ysize = fgGetInt(/sim/startup/ysize); osgViewer::Viewer* viewer = globals-get_renderer()-getViewer(); -viewer-getCamera()-setProjectionMatrixAsPerspective(fov_height, 4.0/3.0, +viewer-getCamera()-setProjectionMatrixAsPerspective(fov_height, xsize/ysize, fov_near, fov_far); } Thanks, Dave - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] clearer patch to renderer.*xx - accomodates non 4:3 aspect ratios with osg
Tim Moore wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
dave perry wrote:
| Patch adds a member function to FGRenderer class that returns the
| current aspect ratio. Uses this in place of 4.0/3.0 in setFOV and
| setNearFar.
|
| The diff follows:
|
This seems a little confusing / confused. In setFOV, why would you ignore the
w argument?
Now, I happen to know that /sim/startup/xsize is set to the value of w
somewhere in
one of the callers, but this is not clear at all. Can we untangle this a bit?
In setFOV, you can use w/h for the aspect ratio. But in setNearFar just
below this, w and h are not defined in that context, so you need to get
the real current aspect ratio from some where. I noticed that
/sim/startup/xsize and /sim/startup/ysize we being updated as I changed
the window, so it seemed most clear to define a getAspectRatio() member
function in this class that was available to both setFOV and
setNearFar. This is certainly more correct than assuming an aspect
ratio of 4.0/3.0 in both calls.
Thanks for the bug fix all the same. I think we've blown off this problem
because it
was unclear how to deal with multiple cameras (monitors / graphics cards),
but now we're
only coding to the osgViewer interface, so it will be easier to arrive at a
coherent
solution.
It is interesting that with this patch, the osg branch behavior still
depends on the fgfs configure switches. There are still 3 cases:
case 1: Don't enable either SDL or osgviewer (in this case, you are
using either glut or freeglut).
This case seems to work just like the plib branch. The initial view
has the right aspect ratio as well as resized windows no matter what
the initial --geometry= is. Also, all the keyboard events are
translated correctly.
case 2: --enable-sdl is added to the ./configure command line.
In this case the initial window has the correct aspect ratio as well
as resized windows no matter what the initial --geometry= is. But
many keyboard event only work the first time. I have tried to trace
this bug down to no avail.
case 3: --enable-osgviewer in place of --enable-sdl.
In this case the initial window has the correct aspect ratio no
matter what the initial --geometry= is. But you need to adjust the
window once to get the mouse events in the right coordinates.
Before this adjustment, the hot spots are vertically off. Also, if
you adjust the window width or height so as to have a different
aspect ratio, the view will be distorted.
I believe we need to commit this patch so that those with non 4:3
monitors can continue to develop aircraft and other models for the osg
branch. They can use either case 1 or case 3 to configure an osg branch
fgfs compile and at least the first window will not be distorted. I am
continuing to use case 1.
Tim
| ? renderer.diff
| Index: renderer.cxx
| ===
| RCS file: /var/cvs/FlightGear-0.9/source/src/Main/renderer.cxx,v
| retrieving revision 1.100
| diff -p -u -r1.100 renderer.cxx
| --- renderer.cxx6 Jan 2008 23:03:20 -1.100
| +++ renderer.cxx16 Jan 2008 22:41:59 -
| @@ -864,6 +864,11 @@ static float fov_height = 42.0;
| static float fov_near = 1.0;
| static float fov_far = 1000.0;
|
| +float FGRenderer::getAspectRatio() {
| +float xsize = fgGetInt(/sim/startup/xsize);
| +float ysize = fgGetInt(/sim/startup/ysize);
| +return xsize/ysize;
| +}
|
| /** FlightGear code should use this routine to set the FOV rather than
| * calling the ssg routine directly
| @@ -872,7 +877,7 @@ void FGRenderer::setFOV( float w, float
| fov_width = w;
| fov_height = h;
| osgViewer::Viewer* viewer = globals-get_renderer()-getViewer();
| -viewer-getCamera()-setProjectionMatrixAsPerspective(fov_height,
| 4.0/3.0,
| +viewer-getCamera()-setProjectionMatrixAsPerspective(fov_height,
| FGRenderer::getAspectRatio(),
|fov_near,
| fov_far);
| }
|
| @@ -886,7 +891,7 @@ n = 0.1;
| fov_near = n;
| fov_far = f;
| osgViewer::Viewer* viewer = globals-get_renderer()-getViewer();
| -viewer-getCamera()-setProjectionMatrixAsPerspective(fov_height,
| 4.0/3.0,
| +viewer-getCamera()-setProjectionMatrixAsPerspective(fov_height,
| FGRenderer::getAspectRatio(),
|fov_near,
| fov_far);
| }
|
| Index: renderer.hxx
| ===
| RCS file: /var/cvs/FlightGear-0.9/source/src/Main/renderer.hxx,v
| retrieving revision 1.17
| diff -p -u -r1.17 renderer.hxx
| --- renderer.hxx21 Nov 2007 20:51:50 -1.17
| +++ renderer.hxx16 Jan 2008 22:41:59 -
| @@ -32,6 +32,8 @@ public:
| void splashinit();
| void init();
|
| +static
[Flightgear-devel] clearer patch to renderer.*xx - accomodates non 4:3 aspect ratios with osg
Patch adds a member function to FGRenderer class that returns the
current aspect ratio. Uses this in place of 4.0/3.0 in setFOV and
setNearFar.
The diff follows:
? renderer.diff
Index: renderer.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Main/renderer.cxx,v
retrieving revision 1.100
diff -p -u -r1.100 renderer.cxx
--- renderer.cxx6 Jan 2008 23:03:20 -1.100
+++ renderer.cxx16 Jan 2008 22:41:59 -
@@ -864,6 +864,11 @@ static float fov_height = 42.0;
static float fov_near = 1.0;
static float fov_far = 1000.0;
+float FGRenderer::getAspectRatio() {
+float xsize = fgGetInt(/sim/startup/xsize);
+float ysize = fgGetInt(/sim/startup/ysize);
+return xsize/ysize;
+}
/** FlightGear code should use this routine to set the FOV rather than
* calling the ssg routine directly
@@ -872,7 +877,7 @@ void FGRenderer::setFOV( float w, float
fov_width = w;
fov_height = h;
osgViewer::Viewer* viewer = globals-get_renderer()-getViewer();
-viewer-getCamera()-setProjectionMatrixAsPerspective(fov_height,
4.0/3.0,
+viewer-getCamera()-setProjectionMatrixAsPerspective(fov_height,
FGRenderer::getAspectRatio(),
fov_near,
fov_far);
}
@@ -886,7 +891,7 @@ n = 0.1;
fov_near = n;
fov_far = f;
osgViewer::Viewer* viewer = globals-get_renderer()-getViewer();
-viewer-getCamera()-setProjectionMatrixAsPerspective(fov_height,
4.0/3.0,
+viewer-getCamera()-setProjectionMatrixAsPerspective(fov_height,
FGRenderer::getAspectRatio(),
fov_near,
fov_far);
}
Index: renderer.hxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Main/renderer.hxx,v
retrieving revision 1.17
diff -p -u -r1.17 renderer.hxx
--- renderer.hxx21 Nov 2007 20:51:50 -1.17
+++ renderer.hxx16 Jan 2008 22:41:59 -
@@ -32,6 +32,8 @@ public:
void splashinit();
void init();
+static float getAspectRatio();
+
static void resize(int width, int height );
// calling update( refresh_camera_settings = false ) will not
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] two issues (bugs?) with fresh osg, Simgear, flightgear
Update on these two bugs. The 2nd bug is there for either --enable-sdl or --enable-osgviewer in the current cvs, but with neither option (just freeglut), all the keyboard bindings work as in version 1.0. Concerning the first bug; If I choose any 4:3 values in --geometry= ..., then the window is not distorted. If I drag the corner of the window so that the aspect ratio is preserved, no distortion. But if I drag so that the aspect ratio is changed, I get a corresponding distortion. Dragging so as to fill the screen is the same as clicking on the square to maximize the window and both give the distortion. However, it seems to me that anyone (even with a 4:3 monitor) can replicate this bug by setting the geometry to a non 4:3 value or by dragging the window boundary. Note that in version 1.0 or the plib branch, dragging the window boundaries does not distort the view. It results in the vertical and horizontal fov both being adjusted so as the view is not distorted. In the osg branch, it seems to me that the verital and horizontal fov are simply scaled the same which results in the distortion. I have looked in the source to try and find where this is happening to no avail. But I am still just learning c++. Can someone help me chase this down? dave perry wrote: Hi all, I have not had a working osg build since late September when I installed F7. Yesterday, I did fresh check outs of osg, simgear, and flightgear source and data. I now have two problems that are not there with V1.0, or the plib cvs branch. 1. Wrong ASPECT RATIO on non 4:3 monitors I have a 1680x1050 TFT monitor. Works great with V1.0 and the plib branch. But the aspect ratio is distorted with osg. This issue has been seen by others. Miak indicates that with osg and XP setting the geometry to 1680x1050 results in this distortion. But if he starts with a 4:3 resolution and then maximizes the window, he gets no distortion. Not so on my F7 system. One other related observation. The affect of changing the /sim/current-view/aspect-ratio-multiplier is different in osg compared to V1.0. With the plib version, changing this from 1 really adjusts the aspect ratio. With osg, adjusting this property just scales the view similar to adjusting fov. 2. Some aircraft-defined keyboard toggles work only once in osg branch Examples: pa24-250-set.xml and the pa28-161 both use the keys !, @, #, $, %, ^, (, and ). With older osg builds and current V1.0 and plib builds these work. With yesterdays osg build, most of these only work the first time. I tried other AC and some of their toggles also only worked the first time. Casaba indicated (IRC) with an older osg build, these toggles work repeatedly. By the way, the pannel hot spots use the same nasal functions to do the toggle and they all still toggle repeatedly. I have tried both osg 2.2 and osg cvs with the same results on both issues. Are others with current svn and cvs osg builds seeing these issues? -Dave P. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] two issues (bugs?) with fresh osg, Simgear, flightgear
dave perry wrote: Concerning the first bug; snip In the osg branch, it seems to me that the verital and horizontal fov are simply scaled the same which results in the distortion. I have looked in the source to try and find where this is happening to no avail. But I am still just learning c++. I found the place(s) in renderer.cxx where the aspect ratio is assumed to be 4:3 and by computing the aspect ratio from /sim/startup/xsize and /sim/startup/ysize and replacing the 4.0/3.0 in the code, the distortions are gone while dragging the window boundaries. I have a work teleconference at 1:00 PM MST, so after that and a little more testing, I will submit a patch. dave perry wrote: Hi all, I have not had a working osg build since late September when I installed F7. Yesterday, I did fresh check outs of osg, simgear, and flightgear source and data. I now have two problems that are not there with V1.0, or the plib cvs branch. 1. Wrong ASPECT RATIO on non 4:3 monitors I have a 1680x1050 TFT monitor. Works great with V1.0 and the plib branch. But the aspect ratio is distorted with osg. This issue has been seen by others. Miak indicates that with osg and XP setting the geometry to 1680x1050 results in this distortion. But if he starts with a 4:3 resolution and then maximizes the window, he gets no distortion. Not so on my F7 system. One other related observation. The affect of changing the /sim/current-view/aspect-ratio-multiplier is different in osg compared to V1.0. With the plib version, changing this from 1 really adjusts the aspect ratio. With osg, adjusting this property just scales the view similar to adjusting fov. 2. Some aircraft-defined keyboard toggles work only once in osg branch Examples: pa24-250-set.xml and the pa28-161 both use the keys !, @, #, $, %, ^, (, and ). With older osg builds and current V1.0 and plib builds these work. With yesterdays osg build, most of these only work the first time. I tried other AC and some of their toggles also only worked the first time. Casaba indicated (IRC) with an older osg build, these toggles work repeatedly. By the way, the pannel hot spots use the same nasal functions to do the toggle and they all still toggle repeatedly. I have tried both osg 2.2 and osg cvs with the same results on both issues. Are others with current svn and cvs osg builds seeing these issues? -Dave P. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] renderer.cxx patch - fix non-4:3 aspect ratio distortion
Patch fixes the bad assumption in osg fgfs that aspect ratio is always
4:3. I tested all the standard views and also resizing the window.
Would someone with cvs submit capability check the patch and then commit it.
- Dave P.
? renderer.diff
Index: renderer.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Main/renderer.cxx,v
retrieving revision 1.100
diff -p -u -r1.100 renderer.cxx
--- renderer.cxx 6 Jan 2008 23:03:20 - 1.100
+++ renderer.cxx 15 Jan 2008 21:22:27 -
@@ -871,8 +871,9 @@ static float fov_far = 1000.0;
void FGRenderer::setFOV( float w, float h ) {
fov_width = w;
fov_height = h;
+float aspect_ratio = fgGetDouble(/sim/startup/xsize, 0.0)/fgGetDouble(/sim/startup/ysize, 0.0);
osgViewer::Viewer* viewer = globals-get_renderer()-getViewer();
-viewer-getCamera()-setProjectionMatrixAsPerspective(fov_height, 4.0/3.0,
+viewer-getCamera()-setProjectionMatrixAsPerspective(fov_height, aspect_ratio,
fov_near, fov_far);
}
@@ -885,8 +886,9 @@ void FGRenderer::setNearFar( float n, fl
n = 0.1;
fov_near = n;
fov_far = f;
+float aspect_ratio = fgGetDouble(/sim/startup/xsize, 0.0)/fgGetDouble(/sim/startup/ysize, 0.0);
osgViewer::Viewer* viewer = globals-get_renderer()-getViewer();
-viewer-getCamera()-setProjectionMatrixAsPerspective(fov_height, 4.0/3.0,
+viewer-getCamera()-setProjectionMatrixAsPerspective(fov_height, aspect_ratio,
fov_near, fov_far);
}
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] renderer.cxx patch - fix non-4:3 aspect ratio distortion
dave perry wrote: Patch fixes the bad assumption in osg fgfs that aspect ratio is always 4:3. I tested all the standard views and also resizing the window. The testing done above was with no sdl or osgviewer (just freeglut). This works fine. But with --enable-sdl or with --enable-osgviewer, some issues remain. With renderer.cxx patch and --enable-sdl, the keys !, @, $, %, ^, *, (, and ) are recognized only the first time they are depressed. But no distortion of the view including when you drag the window to different aspect ratios. With renderer.cxx patch and --enable-osgviewer, the keys all seem to be recognized each depression. The mouse is verically off-set until you resize once so that I had to click below hot spots to get the desired event. Once you maximize or resize the window, this issue is cleared up. But resizing the window still causes some distortion of the image. Would someone with cvs submit capability check the patch and then commit it. - Dave P. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] two issues (bugs?) with fresh osg, Simgear, flightgear
Hi all, I have not had a working osg build since late September when I installed F7. Yesterday, I did fresh check outs of osg, simgear, and flightgear source and data. I now have two problems that are not there with V1.0, or the plib cvs branch. 1. Wrong ASPECT RATIO on non 4:3 monitors I have a 1680x1050 TFT monitor. Works great with V1.0 and the plib branch. But the aspect ratio is distorted with osg. This issue has been seen by others. Miak indicates that with osg and XP setting the geometry to 1680x1050 results in this distortion. But if he starts with a 4:3 resolution and then maximizes the window, he gets no distortion. Not so on my F7 system. One other related observation. The affect of changing the /sim/current-view/aspect-ratio-multiplier is different in osg compared to V1.0. With the plib version, changing this from 1 really adjusts the aspect ratio. With osg, adjusting this property just scales the view similar to adjusting fov. 2. Some aircraft-defined keyboard toggles work only once in osg branch Examples: pa24-250-set.xml and the pa28-161 both use the keys !, @, #, $, %, ^, (, and ). With older osg builds and current V1.0 and plib builds these work. With yesterdays osg build, most of these only work the first time. I tried other AC and some of their toggles also only worked the first time. Casaba indicated (IRC) with an older osg build, these toggles work repeatedly. By the way, the pannel hot spots use the same nasal functions to do the toggle and they all still toggle repeatedly. I have tried both osg 2.2 and osg cvs with the same results on both issues. Are others with current svn and cvs osg builds seeing these issues? -Dave P. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] view options
Maik Justus wrote: Hi, Maik Justus schrieb am 26.12.2007 20:38: Hi Syd, what's about an algorithm, which checks the ratio of the screen and sets fow to 55 for 4:3 screens and 70 for 16:9 screens? (55 / 70 = (4/3) / (16/9) ) Maik P.S.: for non-physicists: (55 / 73,333 = (4/3) / (16/9) ) Meanwhile I have a new computer wit 16:9 screen and the same problem. I've modified the calculation in viewer.cxx as mentioned above. Syd, please check, if this would work for you. Then we can think about, how to implement that in a clean way (maybe we need an FG_SCALING_HEIGHT case?). The patch is for the osg-branch, but it works with the plib branch, too (maybe some lines offset). Hi Maik, I have had a 16:9 flat pannel for some time. For the first time in several months, I built fgfs for osg from fresh svn and fresh cvs. What I noticed right away that has changed is that osg fgfs does not handle the --geometry=1680x1050 correctly anymore. The height of the image is too small for the width. The gages are not round. The plib branch still handles this correctly. Are you seeing what I am seeing or have I missed a patch? When I adjusted the width of the window until round objects are round and then measure the aspect ratio of the adjusted window, the aspect ratio is 4/3. Here is what comparing the plib to the osg response to changing the value of /sim/current-view/aspect-ratio-multiplier tells me: In plib, it adjusts the displayed aspect ratio. I can get the same distortion in plib fgfs as in osg fgfs by changing this value to ~1.2 instead of 1. But if I try to fix the view in osg fgfs by adjusting this value from 1 to 0.8333, all it does is scale the distorted image. i.e. it is adjusting the effective fov, not the aspect ratio. - Dave Perry - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] all flight trims initialize to 0.0?
Hi all, I searched this list for a change to trim initialization but did not find any. This is from the plib branch, essentially V1.0. I have initial values specified in the -set.xml file for /controls/flight/elevator-trim /controls/flight/aileron-trim /controls/flight/rudder-trim which are ignored and all three initialize to zero. I tried changing the values in preferences.xml and also tried using --prop:/controls/flight/elevator-trim=-0.25 etc. but the trims still start with 0.0 values. I checked all the .nas files for the AC and they are not initializing the trims. I have no ~.fgfsrc file. What else could be over riding all the above? - Dave P. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] all flight trims initialize to 0.0?
dave perry wrote: Hi all, I searched this list for a change to trim initialization but did not find any. This is from the plib branch, essentially V1.0. I have initial values specified in the -set.xml file for /controls/flight/elevator-trim /controls/flight/aileron-trim /controls/flight/rudder-trim which are ignored and all three initialize to zero. I tried changing the values in preferences.xml and also tried using --prop:/controls/flight/elevator-trim=-0.25 etc. but the trims still start with 0.0 values. I checked all the .nas files for the AC and they are not initializing the trims. I have no ~.fgfsrc file. What else could be over riding all the above? OK, with just ,/bin/fgfs --aircraft= ... the trims are not reset to zero. I was using fgrun-1.0.0. I will look at what defaults it is using. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] One-line patch to century3.nas - allows step-down ILS with GS acquire
I noticed that with the mode selector set LOC NORM, if you turned off
the ALT to use PITCH to do a step-down, and then went back to ALT on,
the GS would never be acquired. This one-line patch fixes this problem
that affected both the pa24-250 and the SenecaII. Would someone please
commit this patch.
? Generic.diff
Index: century3.nas
===
RCS file: /var/cvs/FlightGear-0.9/data/Aircraft/Generic/century3.nas,v
retrieving revision 1.2
diff -u -p -r1.2 century3.nas
--- century3.nas 25 Nov 2007 20:43:43 - 1.2
+++ century3.nas 27 Dec 2007 15:15:08 -
@@ -685,6 +685,7 @@ var altButton = func(switch_on) {
if ( getprop(enableAutoTrim) ) {
settingAutoPitchTrim.setDoubleValue(1);
}
+apModeControlsSet();
} else {
lockAltHold.setBoolValue(0);
lockPitchAxis.setBoolValue(0);
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] shadows question(s)
LeeE wrote: On Monday 24 December 2007 02:37, dave perry wrote: dave perry wrote: I was enjoying the new gallery pictures when I noticed that the rudder and vertical stab of the comanche do not cast a shadow on the stabilator. So I tried to discover why not. With shadows on and transparency off, the rudder and vertical stab do cast a shadow on the satabilator. But they do cast a shadow on the trim tab even with transparency on. The model was done in ac3d. I could have not yet found documentaion on shadows on aircraft. What do I need to change to correct this? Fixed. I will submit a patch to pa24-250.ac. Dave Perry Just so it's something to bear in mind for the future, what was the problem and the cure? Since we haven't had shadows in osg I've forgotten about them but I do seem to recall that objects, or was it polys? couldn't cast a shadow on themselves, or something like that. LeeE A search of www.flightgear.org for shadows on aircraft turned up this change to renderer.cxx: Update of /var/cvs/FlightGear-0.9/FlightGear/src/Main In directory baron:/tmp/cvs-serv12046/Main Modified Files: renderer.cxx Log Message: Harald JOHSEN: Changes === - shadowvolume.cxx, renderer.cxx : - reduced the polygon offset a bit to eliminate some artifact ; - changed again the cleanup code for objects inside a tile because it could crash on rare occasion ; - the culling of shadow casters has been rewritten to traverse the scene graph, it should be a bit faster when there is a lot of objects ; - the range selector was not correctly handled, sometimes the wrong LOD was casting shadows. - added the option to display aircraft's transparent objects after the shadows, this will reduce the problem of shadows being hidden by the transparent object (propeller disk, rotor, etc). A side effect is that aircraft's transparent objects won't receive shadows anymore. This is usually a good thing except when the aircraft use a 'transparent' texture where it should not. A transparent texture in the plib context is a texture with an alpha channel or a material with alpha = 0.99. - model.cxx, animation.cxx, shadowvolume.cxx : - added an optional condition under the noshadow animation And the texture pa24-250-fus2.rgb had an alpha channel. The wing2.rgb did not have an alpha channel. The wings and all wing control surfaces as well as the stailator trim were textured from wing2.rgb and the stabilator was textured from pa24-250-fus2.rgb. So I retextured the stabilator from wing2.rgb. I still find Gimp a bit confusing. Dave Perry - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] shadows question(s)
I was enjoying the new gallery pictures when I noticed that the rudder and vertical stab of the comanche do not cast a shadow on the stabilator. So I tried to discover why not. With shadows on and transparency off, the rudder and vertical stab do cast a shadow on the satabilator. But they do cast a shadow on the trim tab even with transparency on. The model was done in ac3d. I could have not yet found documentaion on shadows on aircraft. What do I need to change to correct this? Dave Perry - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] shadows question(s)
dave perry wrote: I was enjoying the new gallery pictures when I noticed that the rudder and vertical stab of the comanche do not cast a shadow on the stabilator. So I tried to discover why not. With shadows on and transparency off, the rudder and vertical stab do cast a shadow on the satabilator. But they do cast a shadow on the trim tab even with transparency on. The model was done in ac3d. I could have not yet found documentaion on shadows on aircraft. What do I need to change to correct this? Fixed. I will submit a patch to pa24-250.ac. Dave Perry - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Pre-final aircraft selection
gerard robin wrote: On sam 8 décembre 2007, Melchior FRANZ wrote: * Durk Talsma -- Saturday 08 December 2007: Based on all the input sofar, I'd like to propose the following list of aircraft for inclusion in the next release: Looks good. Not trying to say anything particular -- just FYI: 20M 787 20M A-10 26M bf109 3.2Mbo105* 84K c172 1.9Mc172p 6.4MSenecaII 8.5Mdhc2 5.9Mb1900d 12M Lightning 1.2Mj3cub 13M seahawk 12M p51d 1.8Mpa28-161 13M bocian 600Kufo* 9.5Mbleriot-XI + one of those 2.5MT38 9.9MPBY-Catalina 17M SR71-BlackBird * ... a bit less, actually, as this includes files that only I have The bleriot is very nice, much nicer than the wright. But its FDM is a bit ... ummm ... well, the engine is quite powerful and the aircraft allows some aerobatics, which the real one probably didn't ;-) m. About the Bleriot i fully agree with Melchior, the FDM could make laugh versus the Wright, However i am sure that somebody, here, very aware with YASim could could give to that wonderful plane an FDM which is at the right level ( roll, lift, engine power, may be drag). I took a look at the bleriot-XI-yasim.xml last night. The dimensions in this file do not match the .ac file. After some time with google looking for specifications, I found a few very good sources. The wing span in the .ac file is for the final configuration, not the channel crossing configuration. The .ac has the 3 cylinder Anzani engine (rated 23 - 25 hp on various sites at 1450 rpm). Also the wing incidence in the specs is 7 degrees which the yasim solver had a lot of trouble doing. The cruise with this engine was only 36 mph and only 48 with the 50 hp gnome rotary. I also found the 22 mile channel crossing took 36.5 min which implies a 47 mph ground speed (10 mph tail wind perhaps). Anyway, I was able to get much more realistic performance with some experimenting using the above data. I am not satisfied yet as I still cannot get sufficient elevator trim and convergence with the 7 degree incidence. I should have a satisfying config file by this weekend. I don't want to offend the originator of this beautiful model. So I ask, is it OK to submit a bleriot-XI-yasim.xml file that better matches the specifications ? -Dave Perry - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 3d instruments
the release would make the release not match any well tested cvs configuration. 4. Encouraging sharing files that should be common tends to improve the final results and discourage unnecessary and unrealistic differences between AC. An example of this is the common nasal for the Altimatic IIIc and the Century III autopilots. The ongoing communication and joint feedback between Torsten and myself made the final product significantly better and this joint effort is one of the most rewarding aspects of being a part of FlightGear. Regards, Dave Perry But I will go with what the consensus becomes on this issue. - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Pre-final aircraft selection
Melchior FRANZ wrote: The bleriot is very nice, much nicer than the wright. But its FDM is a bit ... ummm ... well, the engine is quite powerful and the aircraft allows some aerobatics, which the real one probably didn't ;-) Melchior, that is understatement! When I was flying for Des Moines Flying Service in 1968, I got to watch two very good pilots try and fly a copy of the bleriot. Even with a modern engine similar to a j3 engine, the cruise speed was only a few mph above the stall speed. Both pilots stalled the bleriot at about 10 feet off the ground shortly after take off. Both were shaken after the hard unplanned landings that followed the stalls. Makes one really appreciate the channel crossing accomplishment. The same pair owned a copy of the Curtis-Wright pusher with a real gnome rotary (stationary crank with rotating case and cylinders). That flew quite well and was very maneuverable although the rotary caused a lot of precession force with maneuvers. It had ailerons halfway between the two wings, a conventional vertical fin and rudder and a conventional horizontal stabilizer and elevator and even tricycle gear. Perhaps someone will add a model of this AC to FlightGear. -Dave Perry - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Pre-final aircraft selection
dave perry wrote: The same pair owned a copy of the Curtis-Wright pusher with a real gnome rotary (stationary crank with rotating case and cylinders). That flew quite well and was very maneuverable although the rotary caused a lot of precession force with maneuvers. Correction - it was a Curtis pusher. - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] nonzero turbulence set by Preferences.xml?
[EMAIL PROTECTED] wrote: I don't think turning turbulance to zero by dedault is a good solution. If the problem is only in JSBSim then it should be fixed. Meanwhile we can pro vide the zero turbulance workaround in a wiki page or some other place. The problem is the default AC (c172p) with the default turbulence has the 0 to 500 ft boundary layer turbulence set to 0.1 which is enough to set off this oscillation. I want to know what is the real cause of the problem. turbulance is just one f actor of the cause, I think. There is a long thread discussing what appears to be adverse aileron yaw. Since most AP's control roll with aileron only, right aileron causes a roll to the right with a yaw to the left. It is so noticeable with the SenecaII (with no auto coordination) that the ball is eventually pegged at one extreme and then the other and you see the yaw response and aileron inputs from the AP almost 180 degrees out of phase. If you turn on auto coordination, the oscillations disappear. I tried Jon Berndt's suggestion of adding a scaling value. It had only minimal affect. Even with this set to 0.0, the yaw problem persists. -Dave Perry - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] nonzero turbulence set by Preferences.xml?
Hi All, Would anyone object to setting all the turbulence values in Preferences.xml to 0.0 for this release? Even the small values set by Preferences.xml cause increasing oscillations for most JSBSim autopilots in APR mode because the 500 ft. agl boundary turbulence is 0.1. This is true for the c172p with the kap140 autopilot and the SenecaI with the AltimaticIIIc autopilot. Setting turbulence = 0.0 from fgrun will not zero these values. Using --turbulence=0.0 on the command line will result in all the turbulence values being zero. -Dave Perry - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] rotation sense error remains in JSBSim FGPropeller.cpp
While looking into the AP oscillation about the ILS near the runway for the SenecaII, I noticed that the sense is still accounted for twice (see Re: [Flightgear-devel] Bug in JSBSim FGPropeller.cpp, 08/07/2007) in FGPropeller.cpp. Jon, shouldn't this be fixed before the next release of FlightGear. -Dave Perry - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] [Fwd: Re: [Flightgear-users] Seneca II - couple of user comments]
dave perry wrote: Laurence Vanek wrote: I believe, however, that something else is going on with the A/P during ILS approach. I do not get the behavior you report on approach. The A/P begins to make large over corrections about one mile out, to the point where I need to disable the A/P make the approach manually using the HSI. Not good if in poor IMC conditions with no visual refs. until at DH (~200 ft). I get this behavior with any non zero turbulence even with the 0.3 scaling. If I open the Weather menu and the Weather Conditions sub menu and make sure all the turbulence tabs are slid all the way to the left and then click on apply, the SenecaII settles down and follows the ILS down to the runway. You cannot just use the fgrun advanced options weather tab to zero the turbulence as it does not really zero the turbulence. Make sure the property /environment/turbulence/magnitude-norm is '0' (double). With fgrun advanced weather turbulence set to zero, this property will still be 0.00067 ... which is enough to cause the oscillations on my system. One more interesting result. Since I beleive that the AP is chasing even very small turbulence and the aileron inputs are causing the adverse yaw out of phase with the turbulence, I tried using auto-coordination with 0.05 turbulence value. The AP flew the SenecaII right down the LOC/GS. There was continuous control movements and the ball was biased off to one side (see the note on the double sense - I had not yet recompiled with the 2nd sense removed). The point here is that with the rudder outputs from the auto-coordination to correct the adverse yaw, the out of phase yaw oscillations were gone. Conclusions: 1. We know that Jon is going to rework the JSBSim turbulence which should help a lot. 2. Even after that, the adverse-aileron yaw needs to be toned down a lot in JSBSim models to achieve more realistic response in low power cruse such as one has when flying an instrument approach. For the upcoming release, can we modify the JSBSim in fgfs to turn off turbulence modeling? For the upcoming release, should we select a scaling factor for the adverse-aileron yaw in the c172p and SenecaII that result in the performance more similar to the pa28-161 and pa24-250 respectively? -Dave Perry - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear prerelease
Durk Talsma wrote: On Thursday 22 November 2007 07:36, Durk Talsma wrote: This is a quick note to everybody: I'm planning to build an official FlightGear pre-release tonight. I did a full dress rehearsal last sunday and that all seemed to work well, but I still needed Curt's okay for a few remaining issues. In the mean time, if there are any *urgent* patches remaining please try to get them into CVS ASAP. I hope Jon Berndt will submit patches to the fgfs JSBSim code that 1. Turns off JSBSim modeling of turbulence that plays havoc with the default c172p, and 2. Removes the redundant sense from FGPropellers.cpp. Jon, you indicated #2 should be done. how hard is porting #1 from JSBSim cvs? Another question: we always have a limited number of aircraft that are in the distribution, with the rest being available as separate downloads. We like to keep the number of aircraft constant, and representative of the many types of aircraft supported by FlightGear. Is there any pressing reason to swap one aircraft for another one? IIRC, there have been some suggestions of replacing the 737 by the 787. FWIW, we currently have the following selection of aircraft (Taken from Makefile.am): data/Aircraft/Generic \ data/Aircraft/Instruments \ data/Aircraft/Instruments-3d \ data/Aircraft/UIUC \ data/Aircraft/737-300 \ data/Aircraft/A-10 \ data/Aircraft/bf109 \ data/Aircraft/bo105 \ data/Aircraft/c172 \ data/Aircraft/c172p \ IMHO we should not include the two c310 and replace them with 1. SenecaII (great twin with lots of documentation) 2. de Havilland Beaver - Floats (shows the on-water progress this release and a great bush AC) This exchange leaves a modern light twin and adds the on-water and bush categories to fgfs. data/Aircraft/c310 \ data/Aircraft/c310u3a \ data/Aircraft/Citation-Bravo \ data/Aircraft/f16 \ data/Aircraft/j3cub \ data/Aircraft/Hunter \ data/Aircraft/p51d \ data/Aircraft/pa28-161 \ data/Aircraft/Rascal \ data/Aircraft/T38 \ data/Aircraft/ufo \ data/Aircraft/wrightFlyer1903 \ Cheers, Durk -Dave Perry - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] [Fwd: Re: [Flightgear-users] Seneca II - couple of user comments]
I am forwarding an exchange from today's users list to the developers list because it raises a significant difference between jsbsim and yasim. These fdms treat turbulence very differently and jsbsim has a very exaggerated adverse-aileron yaw that makes this difference fatal for autopilot ILS approaches even in light turbulence. Original Message Subject:Re: [Flightgear-users] Seneca II - couple of user comments Date: Sun, 02 Dec 2007 19:10:05 -0700 From: dave perry [EMAIL PROTECTED] Reply-To: FlightGear user discussions [EMAIL PROTECTED] To: FlightGear user discussions [EMAIL PROTECTED] References: [EMAIL PROTECTED] Laurence Vanek wrote: For my money, the Seneca is one of the best done aircraft in FG. Have been flying it a good deal of late. Agreed! snip [2] On localizer during an ILS approach the A/P seems unstable (increasing roll oscillations) when within ~1 mile of approach end of runway. Perhaps this requires tweak of A/P controller constants. On a CAT II or III approach one would still not be able to see the runway at that distance. I usually disable the A/P at DH point. I have commented before about the difference between yasim and jsbsim when it comes to two autopilot issues. 1. jsbsim becomes almost uncontrolable with turbulence. Even at 0.1 or certainly at 0.2 turbulence, the c172p will not complete an approach with the kap140. So, make sure you have turbulence at 0. 2. I spent many many hours tweaking the SenecaII autopilot config file. Since jsbsim (in my opinion) has a very exagerated adverse aileron yaw response and most autopilots have aileron but not rudder roll outputs, this creates the oscillations. That is why I put in the menu options for the SenecaII a yaw-damper that may help some. It is a controller that applies rudder to try and keep the ball centered. To see the fdm difference, fly the Senecal II and then the pa24-250 (which has the same autopilot nasal file and very similar autopilot config file) down the same ILS. The pa24-250 with the Century III autopilot will be rock solid all the way to the runway center line even with light to moderate turbulence. The pa24 uses yasim. You can see the same comparison between the jsbsim c172p and the yasim pa28-161 which both have the kap140. snip Does anyone know of a jsbsim model with autopilot that will fly an ILS with no oscillation with even very light turbulence? -Dave Perry - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/flightgear-users - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] global still showing up on MP
SydSandy wrote: Hi all , still seeing the global error message pop up on MP , so I did a check and found these still using global. I'd be happy to fix them , but they aren't mine :) Instruments-3d/Century-III/AltimaticIIIc.xml Instruments-3d/Century-III/CenturyIII.xml I just emoved the lines with global from both files and a patch was submitted to Melchior this evening. snip ... /snip SenecaII/Instruments-3d/AutopilotMode.xml SenecaII/Instruments-3d/AltimaticIIIc.xml These two files are nolonger used by the SenecaII as it now uses the files from Instruments-3d/Century-III/ ; Right Torsten? - Dave - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New aircraft for CVS - Pitts S1C
Stuart Buchanan wrote: The model and FDM are fairly basic, but it is quite fun to fly, and a challenge to land. Comment and any modifications are very welcome. This is my first YASim aircraft, so I'm sure the FDM could benefit from some tuning. Stuart, this is a really nice addition. Taking you at your word, I spent some enjoyable time last evening tweaking the yasim fdm. Since this activity can be subject to personal preferences, I am attaching a diff file and will comment on the changes, and my reasons for each. I have never flown the real pitts, but have had several extended discussions with several pilots at my field that fly it regularly. 1. CG location - It seemed to be very tail heavy on my first flight, so I googled to find where the CG should be. Could not find the plan numbers, but did find a 1/3 scale RC CG recommendation. So added ballast to move the CG to x= -1.37 m which should be very similar to the location recommended for the RC pitts. I always use the 3d model and $FG_ROOT/bin/yasim to get the CG where documentation says it should be. This made a very big difference. 2. Approach configuration - In spite of the documentation, this needs to be the landing stall configuration. I found the landing stall speed using google and estimated the aoa. 3. Increased the roll rate - more flap0 lift and decreased twist. Decreasing the twist also makes stalls quicker, more positive which helps the snap rolls and spins. 4. The real AC snap rolls easily and spins easily (aerobatics). So decreased the wing and mstab stall widths. 5. Adjusted the cruise and take-off rpms so the engine behaves more like a fixed pitch prop should (i.e at full throttle, the rpm should increase as the AC accelerates. Hope this is helpful, Dave Perry ? pitts.diff Index: pittss1c.xml === RCS file: /var/cvs/FlightGear-0.9/data/Aircraft/pittss1c/pittss1c.xml,v retrieving revision 1.1 diff -p -u -r1.1 pittss1c.xml --- pittss1c.xml 10 Nov 2007 17:18:47 - 1.1 +++ pittss1c.xml 11 Nov 2007 21:38:47 - @@ -9,13 +9,13 @@ YASim aerodynamic model for a Pitts S1C airplane mass=720 !-- Approach configuration -- - approach speed=100 aoa=5 + approach speed=50 aoa=12 control-setting axis=/controls/engines/engine[0]/throttle value=0.5/ control-setting axis=/controls/engines/engine[0]/mixture value=1.0/ /approach !-- Cruise configuration -- - cruise speed=160 alt=0 + cruise speed=160 alt=7000 control-setting axis=/controls/engines/engine[0]/throttle value=0.75/ control-setting axis=/controls/engines/engine[0]/mixture value=0.75/ control-setting axis=/controls/flight/elevator-trim value=0.1/ @@ -27,10 +27,10 @@ YASim aerodynamic model for a Pitts S1C fuselage ax=0 ay=0 az=0 bx=-4.22 by=0 bz=-0.0 width=0.9 taper=0.8 midpoint=0.3/ - wing x=-1.87 y=0.31 z=-0.44 taper=1.0 incidence=0 twist=-3.0 + wing x=-1.87 y=0.31 z=-0.44 taper=1.0 incidence=0 twist=-1.0 length=2.3 chord=0.9 sweep=0 dihedral=2.7 camber=0.1 -stall aoa=22 width=4 peak=1.5/ -flap0 start=0.31 end=0.85 lift=1.3 drag=1.1/ +stall aoa=12 width=2.0 peak=1.5/ +flap0 start=0.31 end=0.85 lift=1.6 drag=1.1/ control-input axis=/controls/flight/aileron control=FLAP0 split=true/ control-input axis=/controls/flight/aileron-trim control=FLAP0 split=true/ control-output control=FLAP0 side=left @@ -39,26 +39,26 @@ YASim aerodynamic model for a Pitts S1C prop=/surface-positions/right-aileron-pos-norm/ /wing - hstab x=-3.91 y=0.1 z=0.04 taper=0.8 effectiveness=1.24 + hstab x=-3.91 y=0.1 z=0.04 taper=0.8 effectiveness=1.5 length=1.0 chord=1.0 sweep=0 -stall aoa=25 width=4 peak=1.5/ -flap0 start=0.5 end=1 lift=1.3 drag=1.2/ +stall aoa=20 width=4 peak=1.5/ +flap0 start=0.1 end=1 lift=1.65 drag=1.2/ control-input axis=/controls/flight/elevator control=FLAP0/ control-input axis=/controls/flight/elevator-trim control=FLAP0/ control-output control=FLAP0 prop=/surface-positions/elevator-pos-norm/ /hstab mstab x=-1.37 y=0 z=0.5 - taper=0.0 dihedral=0 twist=-3.0 + taper=0.0 dihedral=0 twist=-1.0 length=2.62 chord=0.9 sweep=6 incidence=0.0 -stall aoa=20 width=4 peak=1.5/ +stall aoa=12 width=2.0 peak=1.5/ /mstab !-- rudder -- vstab x=-3.9 y=0 z=-0.1 taper=0.8 effectiveness=2.0 length=0.65 chord=1.0 sweep=30 incidence=0.0 stall aoa=30 width=4 peak=1.5/ -flap0 start=0.2 end=0.8 lift=1.2 drag=1.1/ +flap0 start=0.0 end=0.1 lift=2.0 drag=1.1/ control-input axis=/controls/flight/rudder control=FLAP0 invert=true/ control-input axis=/controls/flight/rudder-trim control=FLAP0 invert=true/ control-output control=FLAP0 prop=/surface-positions/rudder-pos-norm @@ -66,16 +66,16 @@ YASim aerodynamic model for a Pitts S1C /vstab propeller radius=0.65
Re: [Flightgear-devel] New aircraft for CVS - Pitts S1C
dave perry wrote: Stuart Buchanan wrote: The model and FDM are fairly basic, but it is quite fun to fly, and a challenge to land. Comment and any modifications are very welcome. This is my first YASim aircraft, so I'm sure the FDM could benefit from some tuning. Stuart, this is a really nice addition. Taking you at your word, I spent some enjoyable time last evening tweaking the yasim fdm. Since this activity can be subject to personal preferences ... You may want to try setting the twist to zero for both the wing and mstab. This makes the inverted maneuvers as easy as the normal maneuvers and reduces the tendency to immediately snap roll when inverted and adding down elevator to climb inverted. It is great fun to roll inverted soon after lift off and climb out inverted. Takes gentile control movements though. From KSFO, I flew inverted to the Golden Gate and still inverted flew under the bridge and then into an inverted loop. Another challenge, after take-off and initial climb out to about 500 ft, roll inverted, turn back and fly down the runway inverted at about 50 ft. Climb inverted to about 1500 ft, pull the power and ease back on the stick to do the 2nd half of a loop to the runway and land. With the patch, this is not that difficult. Even easier with the twists set to zero. Nice to have a really aerobatic AC in FlightGear! Thanks again Stuart. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Minor keyboard reassignment
David Megginson wrote: Switches are hard to find, especially (a) if you're not a real pilot, or (b) if you're not familiar with the aircraft. A single key to turn on all the lights can be very useful for a new user, or even for an experienced user who just wants to fly at night and doesn't know the aircraft or doesn't want to pan around the panel. snip So, in summary, I think a single switch to turn on all required interior and exterior lights for night flying can be a big win for FlightGear. Hi Dave, I just looked at the changes in cvs. There is a significant problem with at least this implementation of one key to turn on all the lights for all AC. There is no standard followed for how to implement nasal electrical systems. The patches you made to cvs will accomplish your stated goal for the pa24 and pa28, but not for the SenecaII or the dhc2. This is because when I wrote electrical.nas for the pa28, I started from the eleictrical.nas for the pa24. Some of the nasal electrical systems bypass switches all together and toggle properties such as /electrical/landinglights. Others include functional circuit breakers that would need to be verified. A second observation is that I virtually never turn on the white cabin light or the map light because I don't want to ruin my night vision. So even for the pa24, I would not want to have all the light on for most flights. For both the pa24 and the pa28, the keys assigned to toggle the switches are in the same order on the keyboard as in the AC. This was to make it easier to quickly turn on or off the switches you want w/o moving the mouse or view. Also, the Help Aircraft Help menu for the pa24 or pa28 gives complete switch info and starting procedure. What frustrates me with some AC is that I am left in the cockpit with no hot spots and also no help to allow me to find the magneto switch(es) or fuel valve. My vote would be to require either (1) hot start with engine running and all normal things turned on, or (2) a clearly written Help Aircraft Help that gets you started with what you need to be ready to take-off. Regards, Dave Perry - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Strange sound performance with recent cvs update
Melchior FRANZ wrote: * dave perry -- Wednesday 07 November 2007: There is a strange worble in the sound [...] Please update (src/Main/main.cxx) and try again. That fixes this issue. Thanks! While testing this, I noticed another issue. When one switches on the nav1 ident, no ident sound. Same frequency on nav2 still has the ident sound when switched on. Nav1 is working but in a real AC, you would not trust it in IFR w/o the ident sound. Regards, Dave P - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Strange sound performance with recent cvs update
I just did a cvs up -dP for SimGear, fgfs, and data and then compiled both for the plib branch. There is a strange worble in the sound that gets worse at high angles of attach. This was not there after a similar update last weekend. I have only checked the pa24 for this so far. Sounds on the ground seem normal. Dave Perry - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Strange sound performance with recent cvs update
dave perry wrote: I just did a cvs up -dP for SimGear, fgfs, and data and then compiled both for the plib branch. There is a strange worble in the sound that gets worse at high angles of attach. This was not there after a similar update last weekend. I have only checked the pa24 for this so far. Sounds on the ground seem normal. (Should have been angle of attack) Just checked the SenecaII and the pa28. The SenecaII seemed not to have this and the pa28 did have it. It is especially noticeable with the stall warning for the pa28 and pa24, put also with the flap sound and gear sound for the pa24. You can hear it in the background noise as you approach an accelerated stall even before the stall warning comes on. Has the wind sound been changed recently? Is anyone else experiencing this? Dave Perry - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Warrior changes
David Megginson wrote: As I mentioned earlier, the Warrior model is looking great. Hi David, Welcome back. I am the one that made all the changes to the Warrior. Starting directions and keyboard switch equivalents are under the help menu-Aircraft help, just like with the pa24-250. It was after you had commented on how you liked what I had done on the pa24 that you sent me your pictures and asked if I wanted to continue developing the Warrior, so I used the pa24 nasal work as a starting point for implementing the Warrior electrical system and switches. However, because it was starting with the engine and fuel off and the brakes on, it took a while to get started (and wasn't realistic sitting on the threshold with the engine off), and I don't think it was possible to do an in-air start, e.g. fgfs --aircraft=pa28-161 --altitude=5000 --vc=100 There were some places that the Nasal scripts were overriding startup preferences. I started cleaning those up and made a few more changes, so that the Warrior now starts up just like the Cessna 172 or J3 Cub, ready to take off. Please let me know if you find any problems. I have not yet updated the warrior to your changes but I just used the command line above to do a mid air start. All it takes to have whatever power you have set from you throttle setting is to hit f and then s. Then you need to switch on whatever else you want on such as pannel lights, strobes, fuel pump, etc. It seems to me that anyone experienced enough to desire starting in the air to practice instrument approaches should be able to figure out which keys are needed to get the engine on in 2 seconds especially since those keys are in the help menu. I still consider the Warrior your aircraft and had communicated to you off list in mid August that I had made updates and changes. I asked for feedback in that note. I assume that you did not disable or bypass the nasal implemented switches with the above change. I will update the Warrior from cvs this evening and then give feedback. I am clearly one that prefers to start with the brakes set and all switches off as that is the way every real flight starts. But I also see the advantage of having an easy option to start in the air with switches and fuel valve set for an approach. Perhaps with a little more effort, there is a way to accomplish both. Side comment. There are some AC in fgfs that start with the engine off, but no hot spots or help to point to how to get the AC started. This definitely is bad. AC designers need to include starting help. Really great to have you back! All the best, Dave Perry - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] autopilots, adverse aileron yaw and jsbsim questions
leee wrote: On Monday 08 October 2007 02:17, dave perry wrote: While optimizing the aitopilot config files for the Century IIB and III autopilots for the pa24 and the Altimatic IIIc for the SenecaII, a significant difference between the values of parameters (gains in particular) that give non oscillatory behavior in yasim and jsbsim became very apparent. I had to completely turn off turbulence to get stability without significant overshoot in SenecaII/Systems/ALTIMATICIII.xml. With the values submitted to cvs, the Seneca still has a wing rock in LOC REV and LOC modes with the default weather that has some turbulence. The pa24 with the same values is as solid as a rock with the default turbulence all the way down the glide slope. With the turbulence zero, both behave the same. The SenecaII wing rock with light turbulence appears to result from a very exaggerated adverse aileron yaw. So I did the same experiment with the c172p and pa28-140 which both use the kap140. With the default turbulence, the c172p oscillates so bad that you cannot complete the approach with the LOC needle going full stop to full stop near the runway. The pa28-161 (also yasim) is as solid as a rock all the way down the glide slope with light to moderate turbulence. If you watch the oscillation for either jsbsim model, you should note that when the yoke is rotating counter clockwise, the nose is yawing right and then finally swings back left, as would be expected with extreme adverse aileron yaw. Most high performance AC show very little AAY except in significant slow flight. I would not expect that small aileron deflections should move the nose counter to the roll in a SenecaII or pa24. Two questions: 1. Have others noticed this difference between jsbsim and yasim? 2. Can this adverse aileron yaw be toned down in jsbsim? Regards, Dave Perry Is auto-coordination enabled? I don't think this is effective for YASim aircraft but it may be complicating things on JSBSim aircraft. Also, are you getting the same frame-rates with both aircraft? Last time I ran FG I found that the autopilot PID controllers ran at the frame rate and not at the Ts rate specified in the controller definitions, which could make them unstable outside a fairly narrow range of fps. I have the frame rate throttled to 25 hz as that is achievable with my setup and both AC. I have tried turning on auto coordination. This helps a little. Also, I included a yaw damper in the autopilot config file for the SenecaII. This helps most of the time but can also add to the problem. Toggle for the yaw damper is a SenecaII menu item in the patches I sent to Andy. Here are the switches from my last test from fgrun. /usr/local/FlightGear-plib/data/bin/fgfs --fg-root=/usr/local/FlightGear-0.9/data --fg-scenery=/usr/local/FlightGear-0.9/data/Scenery:/usr/local/FlightGear-0.9/Scenery-0.9.10 --airport-id=KSFO --aircraft=SenecaII-jsbsim --control=joystick --disable-random-objects --disable-ai-models [EMAIL PROTECTED] --turbulence=0.49 --geometry=1680x1050 --visibility-miles=15 --bpp=24 --fov=65 --timeofday=dusk --nmea=socket,out,5,localhost,5500,udp --prop:/sim/frame-rate-throttle-hz=25 In this test, I turned the turbulence up to 0.49. With this value, the pa24 bounces around a lot and you see the impact of what seems to be thermals and wind shear, but the Century III autopilot flies right down the LOC/GS past the inner marker for RW28R at KSFO. The turbulence means I am constantly adjusting the throttle, but the AP does a good job for all else. LOC and GS stay very nearly centered. With the SenecaII and 0.49 turbulence, it is hardly controllable without the AP, and definitely not controllable with the AP. I think Jon B. is onto something by asking how turbulence is implemented in the various fdms. Thanks for the ideas, Dave - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Century IIB, Century IIII, and Altimatic IIIc 3d autopilots submitted to cvs
Hi all, Autopilot changes to the pa24 and SenecaII: For the last 5 weeks, I have been working with Torsten Dreyer to implement accurate models of the actual autopilots used by the pa24 and SenecaII. Friday morning, I sent 4 patches to Andy Ross for submission to cvs that implement these three autopilots in a manner similar to the kap140 implementation. One patch puts the nasal models in Aircraft/Generic. Another patch puts the .ac models, the model xml, and the panel xml files in Instruments 3d. See the README.txt files in Aircraft/Instruments-3d/Century-IIB and Aircraft/Instruments-3d/Century-III for how to add these autopilots to other aircraft as well as where to get pdf files for Pilots Operating Handbook for these autopilots. Two other patches modify the pa24 and SenecaII to use these autopilots. The Altimatic IIIc is a modification of the Century III autopilot that uses the hsi pointer (both ends) in place of the DG heading bug vlaue that is referenced in the Century III documentation so that other than in heading mode, the heading bug is ignored. The SenecaII uses the Altimatic IIIc. With these patches, the pa24 now has two -set.xml files. The pa24-250-CIIB-set.xml file replaces the kap140 with the 2 axis Century IIB autopilot as in the real N7764P. The pa24-250-set.xml file replaces the kap140 with the 3 axis Century III autopilot. The autopilot config xml files are in the respective Systems folders. Check out these realistic autopilot implementations once they are in cvs. Cheers, Dave Perry - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] autopilots, adverse aileron yaw and jsbsim questions
While optimizing the aitopilot config files for the Century IIB and III autopilots for the pa24 and the Altimatic IIIc for the SenecaII, a significant difference between the values of parameters (gains in particular) that give non oscillatory behavior in yasim and jsbsim became very apparent. I had to completely turn off turbulence to get stability without significant overshoot in SenecaII/Systems/ALTIMATICIII.xml. With the values submitted to cvs, the Seneca still has a wing rock in LOC REV and LOC modes with the default weather that has some turbulence. The pa24 with the same values is as solid as a rock with the default turbulence all the way down the glide slope. With the turbulence zero, both behave the same. The SenecaII wing rock with light turbulence appears to result from a very exaggerated adverse aileron yaw. So I did the same experiment with the c172p and pa28-140 which both use the kap140. With the default turbulence, the c172p oscillates so bad that you cannot complete the approach with the LOC needle going full stop to full stop near the runway. The pa28-161 (also yasim) is as solid as a rock all the way down the glide slope with light to moderate turbulence. If you watch the oscillation for either jsbsim model, you should note that when the yoke is rotating counter clockwise, the nose is yawing right and then finally swings back left, as would be expected with extreme adverse aileron yaw. Most high performance AC show very little AAY except in significant slow flight. I would not expect that small aileron deflections should move the nose counter to the roll in a SenecaII or pa24. Two questions: 1. Have others noticed this difference between jsbsim and yasim? 2. Can this adverse aileron yaw be toned down in jsbsim? Regards, Dave Perry - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Century IIB autopilot modeled
The real N7764P (pa24-250) has a Century IIB autopilot, not the KAP140 that is in the fgfs Comanche in cvs. I found a pdf of the pilot's operating handbook for this autopilot on the internet and have modeled this autopilot and replaced the kap140 in my local version of fgfs. This autopilot does not have a pitch axis control. It is a precursor to the Altimatic IIIc that is in the SenicaII. The model is complete in that it behaves as the documentation describes and as the real Century IIB behaves in the real AC. I actually find the approaches I do with this autopilot more precise than with the kap140. Question to anyone that uses the fgfs pa24; does the increased realism of the Century IIBoffset the loss of the pitch and altitude capture of the kap140 for this model? I would like to update the pa24 in cvs with this autopilot in place of the kap140. In working on this AP model, I noted that the model in the SenicaII for the Altimatic IIIc is not finished. The approach I used to implement the roll knob function when in ROL mode would work very well for the Altimatic IIIc. Torsten, if I can find a pilot's handbook for the Altimatic IIIc, I would like to complete that model for the SenicaII. Between the approach to handling the coupler mode selector and the roll knob and the kap140.nas from Vegard Ovesen, this should not be more than a few evenings work. Any problem with contributing to you fine model? Regards, Dave Perry - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] cmake error building osg
dave perry wrote: I am getting the following error building osg: CMake Error: Error in cmake code at /usr/local/source-osg/OpenSceneGraph-2.1.5/src/osgPlugins/osgFX/CMakeLists.txt:15: Unknown CMake command SETUP_PLUGIN. I get it withOpenSceneGraph/trunk as well as with 2.1.5 from the zip archive. Was able to compile OpenSceneGraph OK using the 2nd cmake example in the OSG wiki.flightgear.org. The above error occurred usint the 1st example minimal build instructions. I had not compiled FlightGear using osg for more than a month, and it is significantly improved. In particular, the clouds are much improved, essentially the same as with plib. I really like the real weather interpolation which now is working very well. I flew a real weather IFR X-country in the pa24-250 in fgfs this morning from Bemidji, MN and ending with the VOR or GPS RW9 approach into Anoka CO (KANE). I broke out about 200 ft. above the MDH and in a about a minute, RW9 became visible. Very realistic! Thanks to all who continue to improve fgfs! Dave Perry - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] cmake error building osg
I am getting the following error building osg: CMake Error: Error in cmake code at /usr/local/source-osg/OpenSceneGraph-2.1.5/src/osgPlugins/osgFX/CMakeLists.txt:15: Unknown CMake command SETUP_PLUGIN. I get it withOpenSceneGraph/trunk as well as with 2.1.5 from the zip archive. I am running fc6 with cmake-1.4.6-3.fc6. Thanks for any suggestions, Dave - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] cmake error building osg
gh.robin wrote: On sam 18 août 2007, dave perry wrote: I am getting the following error building osg: CMake Error: Error in cmake code at /usr/local/source-osg/OpenSceneGraph-2.1.5/src/osgPlugins/osgFX/CMakeLists. txt:15: Unknown CMake command SETUP_PLUGIN. I get it withOpenSceneGraph/trunk as well as with 2.1.5 from the zip archive. I am running fc6 with cmake-1.4.6-3.fc6. Thanks for any suggestions, Dave hmm, the last fc6 cmake is cmake-2.4.6-3.fc6. which is in the extra repo The 1.4.6-3 is a typo. I have cmake-2.4.6-3.fc6. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] significant updates to pa28-161 and a few updates to the pa24-250
I submitted 3 patches via Melchior today. pa28-161 update Last year after I completed the pa24, David Megginson sent me all the detail pictures he had taken of his Piper Warrior II and indicated that I should finish up the details on the pa28-161 in FlightGear. I spent the last three weeks, evenings and weekends (other than 4 days at Oshkosh) finally doing just that. Since the next release will still be in plib, I did hot spots with panels (arg!). Many hot spots also have picks in osg. This update took the pa28 past the level of detail in the pa24, so I made several updates to the pa24 so they are at the same level now. You will notice that the aircraft now starts with all switches off and the fuel selector on off. As in the pa24, the clicking on help and then aircraft help will give you the keyboard keys for all the switches as well as a start sequence. There are now hot spots for all the switches, etc., including the flap lever, the rudder trim, and the elevator trim. The panel lights now are on a dimmer switch. Did the same for the pa24 via rotation of the nav light switch (as in the real pa24). Added nasal electrical system, the kt70 transponder, an AMP meter, magneto switch and key, flight com (texture only), vacuum gage, hobbs meter (texture only), carb heat, primer, and nasal simulated egt and stall warning that recognizes accelerated stall conditions, throttle and mixture on the power quadrant, rudder pedals with brakes, hand brake, yokes,and fuel valve and appropriate animations. Used several parts from Torsten Dreyer's fine SenecaII. 2. pa24-250 updates - added the kt70 transponder and dimming instrument lights as well as elevator trim hot spots on the overhead console. Changes to 3D instruments There are several changes to 3D instruments that might be noticed by other AC. 1. Rescaled the radio_stack slightly to match the real dimensions of the radios. Adding the kt70 made this dimension error obvious. 2. Shortened the RadioStack.ac rectangle so the extra space below the kap140 is gone. Without this change, it would have over lapped the pa28 switch panel. 3. Added a select animation to the kt70.xml file to only display the id_code (digit1 thru digit4) when the transponder has power. This should not negatively impact any other users as all the other features don't work without transponder power. 4. Changes to other 3D instruments: a. shortened the asi.ac needle so it stays within the instrument. b. added material animation to the pa28-fuel-oil.xml controlled by the panel light dimmer. c. added click groups and resized the pick rectangles to just slightly larger than the knobs they control in osg for alt.ac, hi.ac, and vor.ac. This was an attempt to make the pick rectangles less intrusive in plib. Let me know if any of these changes have a negative impact on any other AC. Enjoy a night approach in the Warrior II! Dave - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FIXME patch to kt_70.cxx
Curt,
You left a FIXME comment that the altitude should be for 29.92 inHg
and rounded. The encoder reports mode-c-alt-ft, so this patch points
the altitude node to this value and removes the redundant + 50 from the
FL rounding routine.
This requires a working encoder. Any AC using the encoder should have
instrumentation
...
encoder
serviceable type=booltrue/serviceable
/encoder
...
/instrumentation
in the name-set.xml file.
Index: kt_70.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Instrumentation/kt_70.cxx,v
retrieving revision 1.3
diff -p -u -r1.3 kt_70.cxx
--- kt_70.cxx 21 Feb 2006 01:19:03 - 1.3
+++ kt_70.cxx 5 Aug 2007 23:55:59 -
@@ -90,7 +90,8 @@ void FGKT_70::init ()
// Inputs
lon_node = fgGetNode(/position/longitude-deg, true);
lat_node = fgGetNode(/position/latitude-deg, true);
-alt_node = fgGetNode(/position/altitude-ft, true);
+alt_node = fgGetNode(/instrumentation/encoder/mode-c-alt-ft,
true);
bus_power = fgGetNode(/systems/electrical/outputs/transponder,
true);
serviceable_node = (node-getChild(inputs, 0, true))
-getChild(serviceable, 0, true);
@@ -205,12 +206,9 @@ void FGKT_70::update( double dt ) {
id_code = digit1 * 1000 + digit2 * 100 + digit3 * 10 + digit4;
-// flight level computation
+// flight level computation uses encoder mode-c altitude
-// FIXME This needs to be computed relative to 29.92 inHg,
-// but for the moment, until I figure out how to do that, I'll
-// just use true altitude.
-flight_level = (int)( (alt_node-getDoubleValue() + 50.0) /
100.0);
+flight_level = (int)( (alt_node-getDoubleValue() ) / 100.0);
// ident button
if ( ident_btn !last_ident_btn ) {
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] failure to run after cvs update from plib branch
After update of simgear, source, and data using cvs up -Pd -rPRE_OSG_PLIB_20061029 for each update, I am getting the error when I run fgfs: Unknown top level section: wxradar Fatal error: Detected an internal inconsistency in the instrumentation system specification file. See earlier errors for details. I have not updated the plib branch for several months. I am assuming that the above will give me essentially version 0.9.11. Am I wrong? regards, Dave P. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] failure to run after cvs update from plib branch
On Wed, 2007-07-11 at 01:26 +0200, Csaba Halász wrote: On 7/11/07, Dave Perry [EMAIL PROTECTED] wrote: After update of simgear, source, and data using cvs up -Pd -rPRE_OSG_PLIB_20061029 for each update, I am getting the error when I run fgfs: Unknown top level section: wxradar Fatal error: Detected an internal inconsistency in the instrumentation system specification file. See earlier errors for details. I think for the data you have to use HEAD, not the PRE_OSG_PLIB branch (even though there are some aircraft that have special plib versions - or so I have heard) Is this correct? I know for the plib version of the pa24-250 I have left several of the instruments in the pa24-250 folder that were moved to the 3d-Instruments folder in the osg version because of the lack of a pick capability in the plib branch. How are other ac maintainers handeling this for the 0.9.11 release? Dave - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG version 0.9.11
On Tue, 2007-05-15 at 11:17 -0500, Curtis Olson wrote: Here's a question for the group. We don't need to decide now, but we need to figure this out before the final official 0.9.11 release. Currently the data package is released with only a subset of all the available aircraft: 737-300, A-10, bf109, bo105, c172p, c310, c310u3a, Citation-Bravo, f16, j3cub, Hunter, p51d, pa28-16, Rascal, T38, ufo, wrightFlyer1903 Concerning the pa28-161; I had moved the radio stack and VOR heads from the pa24-250 to the Instruments-3d so the pa28-161 could use them in the osg branch. This required the pick implemented in osg to function. In the plib branch, I would have to implement the tedious panel hot spots to make this work for the VOR heads, and I viewed this as throw away work. Do we still want to include the pa28-161 without the radio stack and hot spots? I could add the radio stack and panel hot spot to the plib pa28-161 in perhaps a half day of trial and error. By the way, the pa24-250 version in the /data/plib branch is significantly down-level as the recent updates were osg specific. I have all these updates in a plib-only version on my system as I use the plib version for practicing IFR approaches due to the strange view inside a cloud layer in osg. What is the correct way to get a diff of the updated plib pa24-250? I tried the following: cvs diff -puRNrPRE_OSG_PLIB_20061029 patch_file.diff This produced a patch that looked correct except for some of the textures. D Perry - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] encoder/altimeter kap140.nas
On Wed, 2007-03-28 at 21:57 -0600, Ron Jensen wrote: Dave, I've been running John's code for a while now and have not noticed any problems with it. I compiled with your patch this morning but have not had a chance to fly it yet. One change I would like see from a neatness point of view: Is it possible to rename atmo.?xx as atmosphere.?xx? Thanks for the patch, Ron Ron, Thanks for the testing and feedback. I have been running a version of John's models similar to this patch for several weeks with no issues. I will do a replace of atmo with atmosphere. This is in the direction of clear naming of files that Melchior has often suggested. Thanks, - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] encoder/altimeter kap140.nas
On Sat, 2007-03-03 at 08:31 +0100, Melchior FRANZ wrote: * Dave Perry -- Saturday 03 March 2007: Have you asked to have atmo.diff applied to cvs?. I don't think it can be applied as it is. I'm no physicist and can't comment on the logic, but there are some formal aspects to fix IMHO: In an off-list exchange with John Denker, I volunteered to make the edits identified by Melchior to accelerate getting the atmo.*xx, altimeter.*xx, and the mods to related files into cvs. He agreed to this as the following excerpt from that exchange verifies: 1) Doing what you suggest is a good idea. By that I mean it is in the best interests of the user community. 2) Open code is open code. You do not need my permission to do as you suggest ... however ... 3) Since you more-or-less asked, the answer is yes, you have my blessing. I offer my help if you need it. I believe the requested edits have been made in the attached patch. Just to be clear, 1) This is an edit of my hand implementation of the last atmo.diff from John. 2) The kollsman shift is not saved to the property tree. 3) The kap140.nas is updated to compute the baroShift only when the baroSetting changes. The baroShift is computed in kap140 and the constants used are reconciled with the corresponding constants in atmo.cxx and atmo.hxx. 4) I did not change my bug fix to John's version of the fix for the fgGetLowPass PA rounding bug. His fix and mine are computational equivalents. Melchior, please look at the indents, etc. and if you see anything I missed or misinterpreted, let me know. Roy, please look at the changes to kap140.nas and make any suggestions/comments. John, any comments? I compiled and tested the edited code. Any other testing is welcome. If there are no changes requested after a few days, would Melchior please put this in cvs. The last time I attached a patch, Sourceforge deleted it, so I will send the patch off list to Melchior, Roy, and John just to be sure. atmo_etc.tar.gz Description: application/compressed-tar - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] problem updating base package
I get the following trying to update data. [EMAIL PROTECTED] ~]$ cd $FG_ROOT [EMAIL PROTECTED] data]$ su -c 'cvs update -dP' Password: cvs [update aborted]: error writing to server: Connection reset by peer [EMAIL PROTECTED] data]$ Tried last evening and again this morning with the same result. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] what happened?
On Sat, 2007-03-24 at 12:33 -0400, John Denker wrote: On 03/23/2007 11:01 PM, Dave Perry wrote: Does anyone know what happened to John Denker? Secondly, if he actually cared about my well-being, he would talk *to* me rather than talking *about* me on this list. This is not about you. It is about getting your good work into cvs so others can benefit from that work. All my communication has been targeted at getting agreement so the improved altimeter and atmosphere model would go into cvs. Thus I wrote again today ... I am still interested in the improved altimeter/atmosphere model being added to FlightGear. Therefore I ask all interested parties on this list, what remains to make that happen? - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] altimeter - encoder - kap140.nas
Hi all, Does anyone know what happened to John Denker? I am still interested in the improved altimeter/atmosphere model being added to FlightGear. I keep adding these back in after cvs/svn updates. Dave perry - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] error compiling osg with fresh fc6 install
On Sat, 2007-03-17 at 01:19 -0500, Laurence Vanek wrote: Dave Perry wrote: I get the following compile error well into the OSG compile on my just installed FC6. Entering directory freetype make[3]: Entering directory `/usr/local/source-osg/OpenSceneGraph/src/osgPlugins/freetype' make[4]: Entering directory `/usr/local/source-osg/OpenSceneGraph/src/osgPlugins/freetype/Linux32.Opt' make[4]: *** No rule to make target `/usr/include/freetype2/freetype/internal/internal.h', needed by `FreeTypeLibrary.o'. Stop. There is no '/usr/include/freetype2/freetype/internal' folder. I updated, compiled, and installed the osg branch in FC5 successfully this morning and then made a copy of all the directories before doing the FC6 install. After using the 'software updater' on FC6, I moved all the source back in place and compiled plib, OpenThreads, Producer successfully, but get the above error compiling OpenScenGraph. Do any of the FC6 users recognize this error? Thanks for any ideas in advance, Dave Dave - I have FC6 I am running FG svn OSG. I have these freetype rpms installed on my system: freetype-2.2.1-16.fc6 freetype-devel-2.2.1-16.fc6 Do you have the devel package installed? Dont think you get that with a new install. Yes, both are installed. And this is the svn OSG. Do you have the '/usr/include/freetype2/freetype/internal' folder? Thanks for the reply, Dave - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] getting fgrun working with fc6
With either the current fc6 fltk and fltk-devel installed (version 1.1.7-2) and fgrun-0.4.8 compiled from from tar ball, both the screen to select AC and the screen to select the airport are blank. I tried removing both fltk and fltk-devel rpms and compiling fltk-1.1.7 (from tarball) with ./configure --enable-shared --enable-threads per Melchior's note from months ago and got the same results. This is occurring with both my notebook and my desktop with up-to-date fc6. Any ideas from others using fc6? fgfs runs great from the command line. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] error compiling osg with fresh fc6 install
On Sat, 2007-03-17 at 08:48 -0500, Curtis Olson wrote: Did you carry over your osg compile tree from a previous install of linux? Perhaps there is some bits and pieces left over from the way your previous system was structured. That was it. Thanks! A clean checkout from svn solved it. Dave - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] getting fgrun working with fc6
On Sat, 2007-03-17 at 22:36 +0100, _hj_ wrote: Dave Perry wrote: I tried removing both fltk and fltk-devel rpms and compiling fltk-1.1.7 (from tarball) with ./configure --enable-shared --enable-threads You have to add --disable-largefile to the configure line in fltk. Hans Thanks! fgrun and fgfs are all runing well in fc6. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] error compiling osg with fresh fc6 install
I get the following compile error well into the OSG compile on my just installed FC6. Entering directory freetype make[3]: Entering directory `/usr/local/source-osg/OpenSceneGraph/src/osgPlugins/freetype' make[4]: Entering directory `/usr/local/source-osg/OpenSceneGraph/src/osgPlugins/freetype/Linux32.Opt' make[4]: *** No rule to make target `/usr/include/freetype2/freetype/internal/internal.h', needed by `FreeTypeLibrary.o'. Stop. There is no '/usr/include/freetype2/freetype/internal' folder. I updated, compiled, and installed the osg branch in FC5 successfully this morning and then made a copy of all the directories before doing the FC6 install. After using the 'software updater' on FC6, I moved all the source back in place and compiled plib, OpenThreads, Producer successfully, but get the above error compiling OpenScenGraph. Do any of the FC6 users recognize this error? Thanks for any ideas in advance, Dave - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] encoder/altimeter kap140.nas
Quick response with a few factual corrections:
On Fri, 2007-03-02 at 00:56 -0500, John Denker wrote:
On 03/01/2007 08:02 PM, Dave Perry wrote:
there are only 3 options still being put forward; all having to
do with how the kap140 gets the baro shift. These are:
1) computes it in kap140.nas using the pressureToHeight()
function already there but not presently used (need to check the
constants for consistency with John's model),
2) gets the kollsman shift value already computed by John's
altimeter.cxx (but not presently saved to the property tree by
John's altimeter.cxx) , or
3) gets it by fetching from the encoder propeties the indicated
altitude and the pressure altitude, and then subtracting.
I would add
4) Use the shift() function from the Kollsman object in
http://www.av8n.com/fly/fgfs/atmo.nas
Option 4 is essentially the same as option 1 in functionality but not in
clarity. As stated, in my note, the current kap140.nas will not compute
(or get from the property tree) a new kollsman value unless the value of
baro set has changed. And Roy's function includes the values of the
constants used to compute the coefficient and exponent which has the
advantage over 4) which just gives the two constants, coefficient and
exponent. This noted, the computational efficiency is the same.
If you won't share the computation of kollsman shift already computed in
the encoder, I believe Roy will want to just use option 1) once the
change to altimeter.cxx is in cvs.
Have you asked to have atmo.diff applied to cvs?.
The comparison as I see it goes like this:
1 2 3 4
verisimilitude+ 0 0 +
simplicity+ 0 0 +
accuracy + + + +
computational 0 + + +
efficiency
It seems like option (4) is Pareto-superior. As I said previously,
I would be astonished if real autopilots didn't use this approach,
or something very similar.
===
In the last couple of days, there have been bugfixes and
upgrades to atmo.nas, atmo.hxx and atmo.cxx ... the current
versions are, as usual, obtainable from:
http://www.av8n.com/fly/fgfs/atmo.nas
and
http://www.av8n.com/fly/fgfs/atmo.diff
The only changes in the files in these links are not bug fixes but
rather improvements of efficiency in the kollsman functions. The
returned values are unchanged.
However, I am glad to see that you did fix the bug in altimeter.cxx, so
the PA low pass for tau 0 now works correctly.
--
Dave Perry
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] encoder/altimeter kap140.nas
, -- Dave Perry alt-encode-kap140.tar.gz Description: application/compressed-tar - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] altimeter, encoder, and kap140
On Mon, 2007-02-26 at 11:37 -0500, John Denker wrote:
Hi --
I made an /object/ to calculate the Kollsman shift.
# Calculate Kollsman shift/ft versus setting/inHg
# Computationally efficient if, for any given instance
# of this class, the setting is not being changed often.
# Typical usage:
# kxx = atmo.Kollsman.new();
# kyy = atmo.Kollsman.new();
# print (kxx.shift(29.92)); # calculates
# print (kyy.shift(30.92)); # calculates
# print (kxx.shift(29.92)); # uses cached value
# print (kyy.shift(30.92)); # uses cached value
Kollsman = {
new : func { { parents : [Kollsman] } },
ft : nil,
set : nil,
shift : func(setting) {
if (setting == me.set) {return me.ft ~ xx}
me.set = setting;
me.ft = 145442.156 * (1 - math.exp(math.ln(me.set/29.921260) *
0.1902632365))
}
};
Do you plan on using this in altimeter.cxx?
It is written in c++.
John I am presently running your altimeter/encoder in one copy of fgfs
and a modified version in another copy of fgfs with two changes:
1) Of course the two lines of code that put the kollsman shift to the
property tree, and
2) I modified Altimeter::update (double dt) to properly handle the
truncation of pressure altitude for non zero tau. I saw the problem on
reading your diff.
This certainly is a bug. To see the problem in your version for non
zero _tau, it is enough to set _tau = 1.0 and take off and climb hard in
an AC with good climb rate and then level off. The pressure altitude
lags way behind and once you level off will stay perhaps 200 ft too low.
Same after a steep descent, except the pressure altitude lags high.
This is a BIG issue when using altitude capture in a step-down approach
which is common for mountain approaches.
The problem is the logic behind
press_alt = fgGetLowPass(press_alt, newPA, trat);
when press_alt and newPA are not the same kind of PA. newPA is
computed from
_altimeter.press_alt_ft(pressure) which is not truncated and press_alt
is truncated every iterate. So the weighted average done by
fgGetLowPass is meaningless in that it never converges to the target
even in level flight after a climb. The error is nearly as large as the
lag when you level off.
Here is an obvious fix for this bug in the update code:
void
Altimeter::update (double dt)
{
if (_serviceable_node-getBoolValue()) {
double trat = _tau 0 ? dt/_tau : 100;
double pressure = _pressure_node-getDoubleValue();
double setting = _setting_node-getDoubleValue();
// The mechanism settles slowly toward new pressure altitude:
raw_PA =
fgGetLowPass(raw_PA, _altimeter.press_alt_ft(pressure), trat);
_mode_c_node-setDoubleValue(100 * round(raw_PA/100));
_kollsman = fgGetLowPass(_kollsman,
_altimeter.kollsman_ft(setting), trat);
_kollsman_offset_node-setDoubleValue(_kollsman);
if (_quantum) press_alt = _quantum*round(raw_PA/_quantum);
else press_alt = raw_PA;
_press_alt_node-setDoubleValue(press_alt);
_altitude_node-setDoubleValue(press_alt - _kollsman);
}
}
// end of altimeter.cxx
Of cource you need to declare
private:
double press_alt;
double rawPA;
SGPropertyNode_ptr _kollsman_offset_node;
in the header file.
Can we land this flight by trading this bug fix for leaving the
kollsman_offset_node line in the code?
Please, lets agree and go work on some of the other more pressing
issues!
By the way, no matter what, our interaction has had value.
1) I had never used c++ to any extent (numerical analysts my age use
either fortran or just c). I have learned a lot by working on the
altimeter/encoder instances.
2). I have modified kap140.nas so that the kollsman (baro) shift is
computed or pulled from the property tree only when baro setting
changes. This is much more efficient as you have pointed out.
3) I think I have made some contributions to your efforts in this area
as well.
I for one want to see this much improved altimeter/encoder and
atmosphere model in cvs. I did a pros and cons analysis for the the two
likely resolutions to our disagreement which I will share if you are
really serious about putting this in cvs. The options are of course
with and without the 2 lines of code to save the kollsman shift.
After sharing this analysis with the list, I will go with what the
community sees as the best option.
Comments from others?
Dave P
--
Dave Perry
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo
Re: [Flightgear-devel] altimeter, encoder, and kap140
On Tue, 2007-02-27 at 19:07 -0700, Dave Perry wrote:
Sorry,
I copied from the wrong version. I will add the missing line and delete
a declaration:
Here is an obvious fix for this bug in the update code:
void
Altimeter::update (double dt)
{
if (_serviceable_node-getBoolValue()) {
double trat = _tau 0 ? dt/_tau : 100;
double pressure = _pressure_node-getDoubleValue();
double setting = _setting_node-getDoubleValue();
double press_alt = _press_alt_node-getDoubleValue();
// The mechanism settles slowly toward new pressure altitude:
raw_PA =
fgGetLowPass(raw_PA, _altimeter.press_alt_ft(pressure), trat);
_mode_c_node-setDoubleValue(100 * round(raw_PA/100));
_kollsman = fgGetLowPass(_kollsman,
_altimeter.kollsman_ft(setting), trat);
_kollsman_offset_node-setDoubleValue(_kollsman);
if (_quantum) press_alt = _quantum*round(raw_PA/_quantum);
else press_alt = raw_PA;
_press_alt_node-setDoubleValue(press_alt);
_altitude_node-setDoubleValue(press_alt - _kollsman);
}
}
// end of altimeter.cxx
Of cource you need to declare
private:
double rawPA;
SGPropertyNode_ptr _kollsman_offset_node;
in the header file.
Can we land this flight by trading this bug fix for leaving the
kollsman_offset_node line in the code?
Please, lets agree and go work on some of the other more pressing
issues!
By the way, no matter what, our interaction has had value.
1) I had never used c++ to any extent (numerical analysts my age use
either fortran or just c). I have learned a lot by working on the
altimeter/encoder instances.
2). I have modified kap140.nas so that the kollsman (baro) shift is
computed or pulled from the property tree only when baro setting
changes. This is much more efficient as you have pointed out.
3) I think I have made some contributions to your efforts in this area
as well.
I for one want to see this much improved altimeter/encoder and
atmosphere model in cvs. I did a pros and cons analysis for the the two
likely resolutions to our disagreement which I will share if you are
really serious about putting this in cvs. The options are of course
with and without the 2 lines of code to save the kollsman shift.
After sharing this analysis with the list, I will go with what the
community sees as the best option.
Comments from others?
Dave P
--
Dave Perry [EMAIL PROTECTED]
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] altimeter, encoder, and kap140
On Mon, 2007-02-26 at 04:57 -0500, John Denker wrote:
Here is the nasal code to calculate the Kollsman shift.
# Typical usage: indicated_altitude = pressure_altitude -
kollsman(baro_setting)
k_ft = k_set = nil;
kollsman = func{
if (arg[0] == k_set) {return k_ft}
k_set = arg[0];
k_ft = 145442.156 * (1 - math.exp(math.ln(k_set/29.921260) *
0.1902632365))
}
This is virtually no change. Only the constants are different (more
digits).
1) This achieves the goal of realism in the sense that it allows
the autopilot code to calculate the Kollsman shift using only
information available to a real autopilot.
I'd be astonished if real-world autopilots used anything much
different from this.
2) This is computationally efficient in the overwhelmingly-likely
case that the baro_setting is not being changed very often.
3) If you want to standardize this across the FG fleet, put it in
some accessible place [perhaps atmo.nas] and let people call it
from there [as atmo.kollsman(...)] rather than cut-and-pasting
it in multiple places.
4) If you don't think this is -- for all practical purposes -- the
right answer, please explain what is the right answer ... and
explain how a pilot could tell the difference between this and
the right answer.
5) Since this has some advantages and AFAICT no disadvantages, it
removes any temptation to use the c++ altimetry object as an oracle
for computing the Kollsman shift.
So only the altimeter can compute the kollsman shift via your oracle?
===
Tangentially related note: I made one recent change to the package
of diffs:
http://www.av8n.com/fly/fgfs/atmo.diff
I rigged it up so that encoder.[ch]xx are no longer needed, and are
not even mentioned in the Makefile.am or anywhere else. When you
configure an altimeter you get an instance of the Altimeter class,
and when you configure an encoder you get a different instance of
the Altimeter class. The only difference is that the former has a
default quantum of zero, while the latter has a default quantum
of ten.
Users should not notice any difference (except that their altimetry
suddenly becomes much more accurate). The configuration files such
as generic-instrumentation.xml can stay exactly the same, and the
runtime interface (via the property tree) is upward-compatible.
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
Dave Perry [EMAIL PROTECTED]
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] altimeter, encoder, and kap140
On Sun, 2007-02-25 at 01:55 -0500, John Denker wrote: On 02/25/2007 12:30 AM, Dave Perry wrote: I have been communicating off and on with both John Denker and Roy Vegard Ovesen off list concerning this topic. I am running an edit of John's most recent altimetry patch and have modified kap140.nas, altimeter.cxx, and altimeter.hxx so that the altitude capture in the kap140 is using the same atmosphere model as the altimeter. It is also using the altimeter.cxx as the encoder, bypassing encoder.cxx. When near sea level, the cvs encoder.cxx did not report the same pressure altitude as the altimeter with kollsman set to 29.92. By replacing the encoder.cxx with the new altimeter.cxx, this is fixed. Roger. Why does the kap140 need info from the altimeter other than the pressure altitude? The altitude capture in the current cvs kap140.nas used altFt = pressureAltitude + hpartial * (baroSetting - 29.92) and compared this to the target altitude. The problem with this is two fold. The second term is a linear approximation to the h(baroSetting,29.92). But h( , ) was the function before altAlert in kap140.nas. It used two transcendental functions each frame and was not the same function now used by John to model the atmosphere (close in the troposphere, but not the same). By saving the result, you only need to do two transcendental functions every time the pilot changes the baro setting (not two per frame) which seems affordable. The real issue here is that the function used is not the same function that the altimeter is using. By the way ... avoiding transcendental functions is not necessarily necessary nor sufficient for good programming. I've measured a few examples relevant to FG, and found that the transcendental functions are only percentage points slower than the interpolation tables that are being used to speed things up. It seems likely that a table small enough to be fast isn't accurate, and a table big enough to be accurate isn't fast. As the saying goes, premature optimization is the root of all evil. I would like to see some actual factual measurements before making very many decisions about what to optimize and how to optimize it. there are three different numbers that matter. There is the Alt inhg returned by metar. There is the setting the pilot puts in the kollsman window, and there is the baro setting the pilot enters in the KAP140. Yes, that's clear. The KAP140 must use the baro setting and the PA returned by the encoding altimeter to get the term altFt it compares to the target altitude. It has access to the static pressure according to the KAP140 manual, but could use a power function approximation similar to what John's altimeter uses to compute the baro offset w/o knowing the static pressure. I don't see how that could possibly work. Encoded pressure altitude and static pressure are two versions of the same idea. Comparing them cannot give any information about the present value and/or desired value of the baro setting. I am now not using the static pressure. The old linear approximation, hpartial, did use the static pressure. Then altFt = PA - baroOffset. The patch attached models the following pilot errors correctly. What patch? It was remove by Sorceforge, but was attached to the e-mail. Are you getting the e-mails sent to the list? Case 1: Pilot enters the QNH in baro setting on the KAP140 but does not enter QNH correctly in the kollsman window of the altimeter. If he sets the target altitude and arms it, the AC will still capture the right altitude, but the indicated altitude will be wrong. That's clear. Case 2: Pilot enters QNH correctly in the kollsman window on the altimeter, but sets baro setting wrong. Even if he sets the target altitude right and arms it, the AC will capture the wrong altitude. For example, if the baro setting is 29.92, the KAP140 will capture PA which is only correct if QNH = 29.92. But since he got QNH right in the kollsman window, the indicated altitude will be correct, telling him he captured the wrong altitude. That's clear. I modified John's code so the altimeter picks up baro setting from /autopilot/KAP140/settings/baro-setting-inhg and uses this to compute baroOffset using the same interpolation function model, _altimeter.kollsman_ft(baro_setting). No comment until I see the code. I will forward it to you off list. I also rearranged the truncation of pressure altitude in John's code so the indicated altitude is computed before the pressure altitude is rounded and saved. John, you may have already caught and corrected this bug. I quite intentionally rounded the pressure altitude not the indicated altitude. This is a realistic model of the action of a blind encoder, which knows nothing of the baro setting. There are multiple mechanical
Re: [Flightgear-devel] altimeter, encoder, and kap140
On Sun, 2007-02-25 at 06:39 -0700, Dave Perry wrote: On Sun, 2007-02-25 at 01:55 -0500, John Denker wrote: On 02/25/2007 12:30 AM, Dave Perry wrote: The altitude capture in the current cvs kap140.nas used altFt = pressureAltitude + hpartial * (baroSetting - 29.92) and compared this to the target altitude. The problem with this is two fold. The second term is a linear approximation to the h(baroSetting,29.92). But h( , ) was the function before altAlert in kap140.nas. It used two transcendental functions each frame and was not the same function now used by John to model the atmosphere (close in the troposphere, but not the same). By saving the result, you only need to do two transcendental functions every time the pilot changes the baro setting (not two per frame) which seems affordable. The real issue here is that the function used is not the same function that the altimeter is using. I should have added that I cannot save the baro offset only when the baro setting changes in kap140.nas since the only access to _altimeter.kollsman_ft(baro_setting) is via altimeter.cxx and the property tree. We could check for changes in /autopilot/KAP140/settings/baro-setting-inhg and only change the baro offset node when baro-setting-inhg changes. Regards, -- Dave Perry - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] altimeter, encoder, and kap140
John, I want to go back to the beginning of our discussion that led to a new atmos.cxx and altimeter.cxx. My reason for wanting this code to read the baro setting from the property tree and return to the tree the baro offset is to make sure it is clear that these are different than the altimeter setting and kollsman shift and can/should be different in two types of pilot error. Not being clear in terminology and semantics was one of your original complaints about the existing code. On Sun, 2007-02-11 at 00:22 -0500, John Denker wrote: While we're in the vicinity: Both the Weather Conditions popup and the atis.cxx code rely on the pressure-sea-level-inhg property and use it in ways that the altimeter setting should be used. This is at least a misnomer, and probably a misconception. The altimeter setting is not the same thing as the sea-level pressure. The altimeter setting is something else; it is properly called the altimeter setting. It is also properly called the QNH, although private pilots who fly only in the US may be unfamiliar with the QNH terminology. You convinced me of this. They are different. This property needs to be expunged and replaced with something else, something with a correct name and with correct semantics. Why does this argument apply to the above 2 of the three variable I point out as my rational for adding 5 lines of c++ to your altimeter.cxx, but not to the third. The setting refers to what is entered in the kollsman window and the baro setting refers to what is entered in the kap140. Even with a separate instantiation referred to as an encoder, not having these 5 lines of code forces the user to have save the baro setting variable to the autopilot baro setting location as well as the encoder setting location. This is exactly the type confusing and incorrect semantics you set out to eliminate. Then you suggest that the autopilot nasal should fetch the indicated altitude from the encoder and the pressure altitude from the encoder and subtract to get the baro setting offset. Again adding to the possibility of future confusion and just plane hard to read code. With the 5 additional lines, all using non ambiguous names we avoid what you set out to avoid. I had proposed this subtraction method to Roy off list and he did not want to use a value that was unavailable in real life to the kap140. Regards, -- Dave Perry - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] altimeter, encoder, and kap140
On Sun, 2007-02-25 at 15:14 -0500, John Denker wrote: On 02/25/2007 02:39 PM, Roy Vegard Ovesen wrote: I have not, and I don't think Dave Perry has either, expressed optinions to indicate that the pressure altitude should not be quantized. What we have said is that indicated altitude should not be quantized. My version of the altimetry object does not quantize the indicated output except insofar as it is based on the pressure altitude which might be (upon request) quantized. This is entirely realistic and natural behavior for a backup altimeter indication based on encoder output, such as we sometimes have in real life. Again, I have not heard any *rationale* for providing a fully-analog indicated altitude in cases where the underlying pressure altitude is quantized. This seems conspicuously unrealistic. I cannot imagine any real- life instrument that would or could work that way. If I'm wrong about that, the easiest thing to do is explain what instrument you have in mind ... then it will be straightforward to model that instrument. I am not in favor of a model instrument that is conspicuously unlike any real-world instrument. I have no problem having the rounding apply to the indicated altitude since we can have a separate encoder instantiation where I can ignore that value. I just misread your intent and rearranged the lines to give the performance I thought you intended, that is digitized PA but analogue indicated altitude. So I agree what I thought was a bug is the feature you intended. Sorry. The fact that this encoder instance (*not* the steam-gauge instance) can also be tricked into serving as an oracle for computing the Kollsman shift (by subtraction) is not entirely realistic, but is a natural by-product of the realistic features, so I'm happy to support this bit of trickery. Here I have two problems. 1) You compute the kollsman shift and the PA, but only report PA. What I added was to report the kollsman shift for the baro setting. The KAP140 should approximate this but the model to do this approximation should only be in one place. So having the encoder compute this and put in in the property tree is a reasonable request. 2) Getting the baro setting to the encoder should be done in an unconfusing way. Here is what avoiding 5 lines of c++ that I think are very clear forces in nasal: encoder=/Instrumentation/altimeter[1]/ ... propEncoder = props.globals.getNode(encoder, 1); ... encoderBaroSettingInhg = propEncoder.getNode(setting-inhg, 1); # An extra initialize in apInit encoderBaroSettingInhg.setDoubleValue(baroSettingInhg); ... # save the updated baro setting to /Instrumentation/altimeter[1]/setting-inhg encoderBaroSettingInhg.setDoubleValue(baroSettingInhg) ... # update altFt in altAlert No matter what, we retrieve a rounded PA from an instantiation of the altimeter. What is contested is how to model the baro shift. What you suggest is retrieve the indicated altitude and then subtract the PA to get the encoder baro shift and then add back in the PA. This means the kap140.nas has to retrieve the value it cannot have in reality (indicated altitude) and wants to approximate from values it does have (PA and baro shift), and then create the value it needs to approximate (baro shift) from values it has by subtracting the PA and then add it back in??? This is very unrealistic! The code to compute and save the baro shift using the atmos model is one line in c++ and uses a function I cannot call from Nasal. (see below). This is 5 new lines of code in kap140.nas before the altFt update. Roy does not want to just use the indicated altitude in the target altitude compare since it is not available to the real KAP140. We are assuming that the real KAP140 uses an approximation to the kollsman shift from the baro setting. The model to do this approximation is a function in your atmos/altimeter code and to use that model in a non confusing way is one of the contested 5 lines as _baro_offset_node-setDoubleValue(_altimeter.kollsman_ft(baro_setting)); Unrealistic features that increase the complexity, obscurity, and inefficiency need *some* kind of rationale, and I still haven't heard that. I claim that it is neither unrealistic nor adding complexity, obscurity, or inefficiency to want to use the interpolation model for the kollsman shift in a clear and direct way to approximate the baro shift. That line is clear. It is also clear that baro_setting came from the KAP140 and not from the altimeter setting in the added 5 lines of code. Removing these 5 new lines of code does not meet you stated original goal. Don't confuse the nomenclature; if something needs to be distinct, keep it distinct in the code. Summary proposed compromise: 1) Use an encoder instantiation (altimeter[1]) with quantum = 10 as well as altimeter[0] with quantum = 0. 2) Leave the 5 new lines to allow unambiguous service to autopilot use of the encoder. Regards
Re: [Flightgear-devel] altimeter, encoder, and kap140
On Sun, 2007-02-25 at 16:19 -0700, Dave Perry wrote: What is contested is how to model the baro shift. What you suggest is retrieve the indicated altitude and then subtract the PA to get the encoder baro shift and then add back in the PA. This means the kap140.nas has to retrieve the value it cannot have in reality (indicated altitude) and wants to approximate from values it does have (PA and baro shift), and then create the value it needs to approximate ^^^ Correction: values it does have (PA and baro setting) (baro shift) from values it has by subtracting the PA and then add it back in??? This is very unrealistic! The code to compute and save the baro shift using the atmos model is one line in c++ and uses a function I cannot call from Nasal. (see below). Summary proposed compromise: 1) Use an encoder instantiation (altimeter[1]) with quantum = 10 as well as altimeter[0] with quantum = 0. 2) Leave the 5 new lines to allow unambiguous service to autopilot use of the encoder. John, if you don't like the added 5 lines, why not just put the kollsman shift on the property tree? Then any autopilot can approximate the baro shift by putting the baro setting to /Instrumentation/altimeter[1]/setting-inhg and picking up the kollsman shift for the baro shift. At the start of this discussion, I thought you wanted just one model of the atmosphere. So it is a bad idea to have each autopilot use it's own model. Users are going to want to ignore different returned values for different instantiations for realism reasons. Regards, -- Dave Perry - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] altimeter, encoder, and kap140
On 2/12 Dave Perry wrote: It occurred to me that we should use John's interpolation function in several other places: 1. We use a form of this function in kap140.nas without the efficiency of the interpolation. 2. The encoder uses a similar interpolation that a general form of this function could replace. ... What I am proposing is to create a C++ function (say height_ft) that has two arguments, P0 and P1 that does the interpolation in John's new patch using his constants. To which John responded: That is the same spirit as what I was suggesting in the opening paragraphs of: http://www.av8n.com/fly/fgfs/README.altimetry.html Then the kap140.nas could use that function, the encoder could use that function to compute PA ... This would have the added advantage of standardizing the constants used in all three applications. I thought that would be one of the outcomes of your effort. On Sun, 2007-02-25 at 19:58 -0500, John Denker wrote: How about 2') Have the autopilot calculate the Kollsman shift on its own. That is counter to the same spirit you reference above. That is why I wrote: At the start of this discussion, I thought you wanted just one model of the atmosphere. So it is a bad idea to have each autopilot use it's own model. Users are going to want to ignore different returned values for different instantiations for realism reasons. But a real autopilot *does* have its own model ... not a model of the real atmosphere, but an ISA-model atmosphere (or, more precisely, a Kollsman-model atmosphere). The present cvs kap140 does approximate the baro shift with such a model as you well know. Since you already compute the kollsman shift for the value of setting-inhg, why not save that value to the property tree? That would accomplish giving the kap140, the altimeter, and the encoder access to your improved interpolation model for the two terms in equation (15) in your paper. You compute both PA and the kollsman shift, but only allow others access to PA. That only requires two additional lines of c++ in altimeter.cxx plus a declare in altimeter.hxx. I can integrate a 2nd instantiation into the kap140 including the identified changes to altimeter.cxx and altimeter.hxx. Regards, -- Dave Perry - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] altimeter, encoder, and kap140
Hi All, I have been communicating off and on with both John Denker and Roy Vegard Ovesen off list concerning this topic. I am running an edit of John's most recent altimetry patch and have modified kap140.nas, altimeter.cxx, and altimeter.hxx so that the altitude capture in the kap140 is using the same atmosphere model as the altimeter. It is also using the altimeter.cxx as the encoder, bypassing encoder.cxx. When near sea level, the cvs encoder.cxx did not report the same pressure altitude as the altimeter with kollsman set to 29.92. By replacing the encoder.cxx with the new altimeter.cxx, this is fixed. Why does the kap140 need info from the altimeter other than the pressure altitude? The altitude capture in the current cvs kap140.nas used altFt = pressureAltitude + hpartial * (baroSetting - 29.92) and compared this to the target altitude. The problem with this is two fold. The second term is a linear approximation to the h(baroSetting,29.92). But h( , ) was the function before altAlert in kap140.nas. It used two transcendental functions each frame and was not the same function now used by John to model the atmosphere (close in the troposphere, but not the same). The attached patch uses the PA (rounded to the nearest 10 ft.) from the new altimeter.cxx and a baro-offset = kollsman offset with baro setting replacing the altimeter setting. Why is that necessary? Well, there are three different numbers that matter. There is the Alt inhg returned by metar. There is the setting the pilot puts in the kollsman window, and there is the baro setting the pilot enters in the KAP140. The KAP140 must use the baro setting and the PA returned by the encoding altimeter to get the term altFt it compares to the target altitude. It has access to the static pressure according to the KAP140 manual, but could use a power function approximation similar to what John's altimeter uses to compute the baro offset w/o knowing the static pressure. Then altFt = PA - baroOffset. The patch attached models the following pilot errors correctly. Case 1: Pilot enters the QNH in baro setting on the KAP140 but does not enter QNH correctly in the kollsman window of the altimeter. If he sets the target altitude and arms it, the AC will still capture the right altitude, but the indicated altitude will be wrong. Case 2: Pilot enters QNH correctly in the kollsman window on the altimeter, but sets baro setting wrong. Even if he sets the target altitude right and arms it, the AC will capture the wrong altitude. For example, if the baro setting is 29.92, the KAP140 will capture PA which is only correct if QNH = 29.92. But since he got QNH right in the kollsman window, the indicated altitude will be correct, telling him he captured the wrong altitude. I modified John's code so the altimeter picks up baro setting from /autopilot/KAP140/settings/baro-setting-inhg and uses this to compute baroOffset using the same interpolation function model, _altimeter.kollsman_ft(baro_setting). I also rearranged the truncation of pressure altitude in John's code so the indicated altitude is computed before the pressure altitude is rounded and saved. John, you may have already caught and corrected this bug. I consider this combined patch to be a significant improvement to FlightGear. Where you will notice the improvement the most is 1) Mountain airports with QNH != 29.92, 2) Flying down glide slopes to a mountain airport (indicated DH will be close to accurate, often avoiding a crash situation should you fly the approach with the present cvs.) 3) The captured altitude for the KAP140 will be as accurate as it is with real autopilots. I am sure John can point out other situations the new atmosphere model improves. I want both John and Roy to try this patch before we consider submitting it to cvs. Of course, anyone can try it and comment. Is the encoder used anywhere other than by the KAP140? If so, we should use a separate instantiation as suggested by John. Regards, -- Dave Perry altimetry.tar.gz Description: application/compressed-tar - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] altimetry method ... alpha version
On Sun, 2007-02-18 at 18:02 -0700, Dave Perry wrote: I am not sure the new patch is giving the same results, but I have not done any controlled comparisons;... I will double check and compare some examples with the previous patch. I was wrong. Both are giving the same results, much improved indicated altitude for various QNH even at Lake Co @ 9928 ft. field elvation. TABLE OF RESULTS (rounded to nearest ft.) QNH 1st Patch 2nd Patch Field Elevation Airport 29.92 5019501950522V2 29.64 5019501950522V2 29.86 988798869928KLXV 30.32 991499149928KLXV 28.00 976497649928KLXV 29.74 987998799928KLXV 29.74 650265026540KEGE -- Dave Perry - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft/Instruments-3d/mag.sw/
On Mon, 2007-02-19 at 15:45 +0100, Melchior FRANZ wrote: Can people, please, choose meaningful names for files/dirs in public space? This directory could simply have been called magneto-switch or mag-switch if it really, *really* needs to be short. But sw is IMHO a bad and non-obvious choice for a switch. Melchior, Please rename Aircraft/Instruments-3d/mag.sw to Aircraft/Instruments-3d/magneto-switch and apply the attached patch, both in cvs. -- Dave Perry ? Instruments-3d/magneto-switch ? j7w/j7w.xml.dp Index: pa24-250/Models/pa24-250.xml === RCS file: /var/cvs/FlightGear-0.9/data/Aircraft/pa24-250/Models/pa24-250.xml,v retrieving revision 1.15 diff -p -u -r1.15 pa24-250.xml --- pa24-250/Models/pa24-250.xml 19 Feb 2007 12:18:34 - 1.15 +++ pa24-250/Models/pa24-250.xml 20 Feb 2007 04:55:50 - @@ -319,7 +319,7 @@ model namemags/name - pathAircraft/Instruments-3d/mag.sw/mags.xml/path + pathAircraft/Instruments-3d/magneto-switch/mags.xml/path offsets x-m2.1205/x-m y-m-0.145/y-m - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
