[Flightgear-devel] implemented: interval timer (aka approach timer) [aka stopwatch]

2007-01-01 Thread John Denker
Hi -- I cobbled up some XML code to implement an interval timer aka approach timer aka stopwatch. Having an interval timer is more-or-less indispensible for performing certain types of instrument approaches. The XML can be found at: http://www.av8n.com/fly/fgfs/stopwatch.xml This

[Flightgear-devel] implemented: Saitek X52 USB stick/throttle configuration

2007-01-01 Thread John Denker
Hi -- Over the weekend I went looking for an X52 configuration file, without success. I found rumors of its existence, but when I tried to fetch the file, either the server was down, or the tarball was gone, or the tarball didn't contain what I needed. Eventually I decided it was easier to

Re: [Flightgear-devel] won't compile ... also configuration issues: openAL +- osg +- whatever

2007-01-02 Thread John Denker
On 01/02/2007 12:09 AM, Ron Jensen wrote: I find including more libraries in some of the Makefile.am's does the trick for me... I'm attaching a diff of my debian-etch build tree against today's CVS. Thanks for the patches. They applied cleanly to the bleeding edge package but utterly failed

Re: [Flightgear-devel] out-of-date mailing-list addresses

2007-01-02 Thread John Denker
On 01/02/2007 03:51 PM, Roy Vegard Ovesen wrote: You can't possibly mean replacing every occurence of the old list address in the archive. Good point; I didn't mean that. How about starting with places like these: -- http://mail.flightgear.org/mailman/listinfo/flightgear-devel --

Re: [Flightgear-devel] location-in-air ... magnetic bearings from the reference

2007-01-03 Thread John Denker
On 01/03/2007 04:00 PM, Curtis Olson wrote: we do want this to work intuitively so I would welcome any changes to improve the in-air reposition dialog box. :-) I think it makes a lot more sense to focus on the gui dialog box. Agreed. I'm coming at this from the perspective of an

Re: [Flightgear-devel] location-in-air ... magnetic bearings from the reference

2007-01-03 Thread John Denker
I found a way to make it do what I want. Here's my version http://www.av8n.com/fly/fgfs/location-in-air.xml and the diff against the cvs version: http://www.av8n.com/fly/fgfs/location-in-air.diff On 01/03/2007 05:19 PM, Curtis Olson wrote: Only if you are relocating to a nearby position.

Re: [Flightgear-devel] radials

2007-01-03 Thread John Denker
On 01/03/2007 09:07 PM, Dave Perry wrote: This may seem a nit. I had the following quote drilled into my mind by Don Berman in one of his well know Instrument Written Ground School seminars. Radials eminate from the station; direction of flight has nothing to do with location. 1)

Re: [Flightgear-devel] radials

2007-01-04 Thread John Denker
On 01/04/2007 04:28 AM, Torsten Dreyer wrote: Well - at least on the eastern side of the atlantic, where I do instrument flights in real world, the 090 radial is always EAST of the station, the 270 radial is WEST of the station. A controller advice proceed on radial 090 or intercept radial

Re: [Flightgear-devel] location-in-air ... magnetic bearings from the reference

2007-01-05 Thread John Denker
On 01/05/2007 04:06 AM, Torsten Dreyer wrote: Less dirty and more correct should be: relocate to the position of the fix, grab the magnetic variation and calculate the transporter coordinates using bearing and distance. Relocate again to these coordinates. You can safely call this

Re: [Flightgear-devel] location-in-air

2007-01-06 Thread John Denker
Hi -- I have extensively reworked the location-in-air.xml popup. It is now much more pilot-friendly. I would appreciated if other folks would play with it and provide feedback. The latest greatest version is at http://www.av8n.com/fly/fgfs/location-in-air.xml there is also a diff

Re: [Flightgear-devel] location-in-air

2007-01-07 Thread John Denker
On 01/06/2007 04:25 PM, Jon S. Berndt wrote: I'm not sure what you are talking about here. Could you be more descriptive? I'll try! Let's start with some use case analysis: Scenario 1: User wants to practice landings. Using command-line options, the user initializes the system to 4 mile

Re: [Flightgear-devel] location-in-air

2007-01-07 Thread John Denker
On 01/07/2007 12:28 PM, Martin Spott wrote: John, actually, what you're looking for is a routine that allows you to dump the whole property tree at runtime into a file and allow re-loading this as a preset. In order not to break current behaviour it would be necessary to compile a

Re: [Flightgear-devel] location-in-air

2007-01-07 Thread John Denker
On 01/07/2007 01:25 PM, Martin Spott wrote: [...] For my purposes (and I suspect a lot of other purposes besides), is much more useful to be able to warp to some improvised place, without ever having been there before. Without ever having been there before I'd say you'll never know in which

[Flightgear-devel] memory leak

2007-01-07 Thread John Denker
My version of fgfs has a rather large memory leak. If I leave the thing parked after a flight, brakes on, simulator paused, it will gobble up about 3 gigabytes of virtual memory overnight. (In contrast, it's only a little over 500 meg after a few minutes of flight.) I'm running the version of

[Flightgear-devel] C182 creeping features

2007-01-08 Thread John Denker
On 01/08/2007 10:06 AM, Stuart Buchanan wrote: Are you particularly interested in using the c182? Well, yes I am. A lot of FBOs will let you rent a 182. If we make an XY plot trading off availability versus a combination of speed and roominess, the 182 has high availability for a given

Re: [Flightgear-devel] C182 creeping features

2007-01-08 Thread John Denker
On 01/08/2007 12:44 PM, Stuart Buchanan wrote: OK - I'll probably leave this as a general emissive light. Where is the switch located? On the ceiling? Multiple switches. Perhaps the most relevant to the model are the two dimmer knobs (commonly but improperly called rheostats) located just to

[Flightgear-devel] translate PoV up/down left/right

2007-01-08 Thread John Denker
On 01/08/2007 02:17 PM, Stuart Buchanan wrote: Already available - hold down the [middle] mouse-button when in tile/pan mode and drag the mouse around. 1) Thanks for the clue. I've been relying on my joystick (not mouse) since Day One, so I had never explored the various combinations of mouse

Re: [Flightgear-devel] won't compile ... also

2007-01-09 Thread John Denker
Here are some hints on how to build fgfs from source. This is what I have had to do to get it to come anywhere /close/ to working on Debian etch; there are still compilation errors. If anybody has corrections or further suggestions, please speak up. Also, I point out (again) that the

[Flightgear-devel] c182 panel -- somewhat more realistic

2007-01-10 Thread John Denker
Hi -- I rejiggered the instrument placement on the c182 3d panel to make it more nearly resemble the real aircraft. My handiwork can be found at http://www.av8n.com/fly/fgfs/c182s-3d-panel.xml.htm http://www.av8n.com/fly/fgfs/c182s-3d-panel.xml References, for comparison:

Re: [Flightgear-devel] c182 panel -- somewhat more realistic

2007-01-10 Thread John Denker
On 01/10/2007 01:08 PM, Stuart Buchanan wrote: Looks good, except that the OMI marker cover the DME and the logo is hiddden behind one of the radios Good catch. (though it was probably already like that). No, I broke it. But it's fixed now.

[Flightgear-devel] hsi.xml now responds to serviceable flag (or lack thereof)

2007-01-10 Thread John Denker
The hsi now responds correctly to simulated failure as commanded by the heading indicator item on the instrument failure popup. My handiwork can be found at http://www.av8n.com/fly/fgfs/hsi.xml.htm http://www.av8n.com/fly/fgfs/hsi.diff I have not checked other hsi-like instruments to see if

[Flightgear-devel] picking the /nearest/ navaid or waypoint

2007-01-11 Thread John Denker
1) Did you know that there are 8 different BRAVO intersections in the database? Until now there was no support in the code for this; all but one of the entries was thrown away at the lowest level. There was a comment in the code saying that fixing this was on the TODO list. Well,

Re: [Flightgear-devel] c182 revision version?

2007-01-11 Thread John Denker
On 01/11/2007 10:58 AM, Stuart Buchanan wrote: John Denker has suggested that a C-182 RG would be a good addition. I'm still interested in that. It would be tremendously useful as a procedures trainer. However, this is very much on the drawing-board and would require significant effort - we

[Flightgear-devel] navaid+fix : case insensitive

2007-01-11 Thread John Denker
I munged the code so that the routines that manage the fix database (waypoints etc.) and the navaid database are now insensitive to the upper-case / lower-case distinction. That is, the RBX VOR/DME is now equivalent to the rbx VOR/DME. I have checked that all navaids and waypoints in the

[Flightgear-devel] broken radios : KX 165 on Seneca II

2007-01-11 Thread John Denker
On the Seneca II model, the KX 165 radios are broken. -- When I try to tune 116.0 I get 116.99 -- When I try to tune 111.7 I get 111.69 -- But you can't just say everything is off by 0.01 MHz, because if I put in 116.01, I get 116.01. The 116.0 result is skipped, i.e. avoided! I imagine

Re: [Flightgear-devel] c182 revision version?

2007-01-12 Thread John Denker
On 01/12/2007 04:08 AM, Stuart Buchanan wrote: I don't know whether this should just a c182rg-set.xml file in the c182 directory, or completely separate in a c182rg directory. I suspect the latter as the FDM and models files will (eventually) be different. Eventually, I suppose. But there's

[Flightgear-devel] patching model-howto ... and other things

2007-01-12 Thread John Denker
On 01/12/2007 05:41 PM, Georg Vollnhals wrote: Hi John, Generally spoken, I read all your posts with big interest. :-) Thanks for the feedback. don't worry - this was one of Melchior's usual jokes. We all saw he corrected it in CVS thanks to your hint. OK, thanks for the explanation; I

Re: [Flightgear-devel] c182 revision version?

2007-01-12 Thread John Denker
On 01/12/2007 09:23 AM, Stuart Buchanan wrote: Perhaps you could take a look at the FDM ? That's not really on the list of things I was looking forward to I think that most of the coefficients were copied from a c172 (from looking at the CVS logs), so are probably inaccurate. As I've

Re: [Flightgear-devel] c182rg

2007-01-15 Thread John Denker
On 01/13/2007 09:53 PM, Ron Jensen wrote: squat switch. Well, I decided to plug the script in and make it work... Done Nifty. I'm in the process of implementing a gear warning horn that comes on when manifold pressure drops below 13 inches and gear lever is up. I know the POH expresses

Re: [Flightgear-devel] c182rg ... and list follies

2007-01-15 Thread John Denker
On 01/15/2007 04:27 AM, Stuart Buchanan wrote: I think it is time for this to go into CVS, if no-one objects. Certainly no objections from me. Any remaining nits should be fixed within CVS, not without. While we're on the subject: the 182rg should be added to the download page:

Re: [Flightgear-devel] c182rg

2007-01-15 Thread John Denker
On 01/13/2007 09:53 PM, Ron Jensen wrote: squat switch. Well, I decided to plug the script in and make it work... Done Nifty. I'm in the process of implementing a gear warning horn that comes on when manifold pressure drops below 13 inches and gear lever is up. I know the POH expresses

[Flightgear-devel] retraction issues

2007-01-15 Thread John Denker
On 01/15/2007 12:12 AM, Ron Jensen wrote: Remapped the G/g keys to control only the gear handle. controls/gear/gear-down is only controlled by nasal. That brings to light a problematic situation. There are three properties of interest: 1) gear-handle-down 2) wow (aka squat switch) 3)

[Flightgear-devel] ?update fix.dat?

2007-01-15 Thread John Denker
The current (cvs) fix.dat.gz has, internally, a 2005 date. There are fixes missing from that database, and also fixes in the database that are wrongly located. How might we go about updating the databases? - Take Surveys.

Re: [Flightgear-devel] gear compression +- wow

2007-01-16 Thread John Denker
On 01/16/2007 12:35 PM, Curtis Olson wrote: I was told that JSBSim only runs the wow computations when the altitude 200' agl. That's what we call an undocumented feature. It would be nice to change this behavior, but you'll need to convince the jsbsim gods that this is a problem that

Re: [Flightgear-devel] C182-RG model

2007-01-16 Thread John Denker
On 01/13/2007 11:53 AM, Stuart Buchanan wrote: John - can you tell me if I've got the gear animation approximately correct. From photographs I've guessed that they fold up rearwards. Yes, it is approximately correct. 1) I observe that the two main gear retract at unequal rates; this is

Re: [Flightgear-devel] c182rg flight dynamics

2007-01-16 Thread John Denker
On 01/15/2007 04:27 AM, Stuart Buchanan wrote: I have done some work on the FDM to decrease the aileron response and adverse yaw. That sounds great! Thanks! I still have some tuning to do however - I can't get above 112kts @ 5,000ft, even at 100% throttle which suggests some of the drag

[Flightgear-devel] segfault in listener +- location-in-air

2007-01-17 Thread John Denker
Hi -- Below is a piece of nasal code that reproducibly segfaults. Remarks: a) IMHO interpreted code should never segfault. b) This code doesn't seem particularly unreasonable. 1) The stack trace and other lines of evidence indicate that it is significant that the code sets and removes a

Re: [Flightgear-devel] segfault in listener +- location-in-air

2007-01-17 Thread John Denker
On 01/17/2007 09:22 AM, Melchior FRANZ wrote: An old-school polling loop wouldn't be less effective. Ah, don't worry, there is a solution -- involving a timer rather than a listener -- that is adequate for this unusual purpose. Not elegant, but adequate. Letting a listener remove itself is

[Flightgear-devel] OT: c182rg gear trouble

2007-01-17 Thread John Denker
This is getting somewhat OT, but it's fun, so I thought I would mention it: When you fly the Skylane RG, always take the tow-bar with you; don't leave it in the hangar. I guy I know had a gear failure involving loss of hydraulic fluid (not simply failure of the hydraulic pump) such that the

Re: [Flightgear-devel] segfault in listener +- location-in-air

2007-01-17 Thread John Denker
On 01/17/2007 01:47 PM, Melchior FRANZ wrote: May I ask why this is a bad idea? Because it's not supported? :-) May I suggest that the documentation should /say/ it's not supported? Waiting for a runtime error message that may or may not occur within any bounded time is not a good way to

Re: [Flightgear-devel] segfault in listener +- location-in-air

2007-01-17 Thread John Denker
On 01/17/2007 02:31 PM, Melchior FRANZ wrote: The documentation doesn't say that. It says exactly: Note that a listener can not remove itself, neither directly nor indirectly. Sorry, I missed that. - Take Surveys. Earn

Re: [Flightgear-devel] ?update fix.dat?

2007-01-17 Thread John Denker
On 01/16/2007 12:57 PM, daveluff wrote: The best way to keep the data updated would be to feed improvements to Robin Peel (http://x-plane.org/home/robinp/) and then pull his updated data periodically. An excellent suggestion. In the meantime, 1) I pulled the data from the x-plane site.

[Flightgear-devel] proper tach for skylane (c182 and c182rg)

2007-01-21 Thread John Denker
I cobbled up a tachometer with the proper green arc and redline for the c182 and c182rg Here's the graphic plus the xml to make it work: http://www.av8n.com/fly/fgfs/tach-skylane.tgz Here's a patch to install it in the panel of both aircraft: http://www.av8n.com/fly/fgfs/tach-skylane.diff

[Flightgear-devel] improved engine sound for skylane (c182 and c182rg)

2007-01-21 Thread John Denker
Here is a patch to make the engine sound more like it should for the skylane (c182 and c182rg) http://www.av8n.com/fly/fgfs/skylane-sound.diff Previously the sound was the same for all engine speeds from 1500 RPM on up. This detracted from the realism. Pilots are verrry attuned to small

[Flightgear-devel] transponder situation

2007-01-21 Thread John Denker
1) Here's a patch to add some semblance of a transponder to the Skylane (c182 and c182rg) http://www.av8n.com/fly/fgfs/xpdr-skylane.diff This increases the usefulness of the model as a procedures trainer. 2) I notice that xpdr.xml is presently not much more than a stub. It

[Flightgear-devel] ident from phantom DME ... and some questions

2007-01-27 Thread John Denker
In the real world, some VOR stations and even some localizers have a colocated DME station ... but there are plenty that don't. The DME has its own Morse ident, with a distinctive higher pitch. In the simulator, due to a bug in the code, all stations transmit the DME Morse ident ... even

[Flightgear-devel] location-in-air

2007-01-28 Thread John Denker
On 01/28/2007 05:12 AM, Melchior FRANZ wrote: I would, for example, have felt responsible for your location-in-air dialog, as I had worked a lot on GUI matters. There were reasons why I didn't pick it up: (1) I wasn't at my computer at that time. Please check again the next time you are at

[Flightgear-devel] picking the /nearest/ navaid or waypoint

2007-01-28 Thread John Denker
On 01/28/2007 05:12 AM, Melchior FRANZ wrote: If one patch has been ignored for longer, point to it again. On 01/11/2007 03:55 AM, John Denker wrote: 1) Did you know that there are 8 different BRAVO intersections in the database? Until now there was no support in the code

Re: [Flightgear-devel] KT-70 3D Model for Instruments-3D

2007-01-28 Thread John Denker
Ron Jensen wrote: I modelled a KT-70 transponder. It is at http://www.jentronics.com/fgfs/Instruments-3d.tgz Attached is a patch to install it in the c182rg. On 01/28/2007 01:28 PM, Martin Spott wrote: Did you check that this doesn't collide with the transponder that's already present ?

Re: [Flightgear-devel] KT-70 3D Model for Instruments-3D

2007-01-28 Thread John Denker
On 01/28/2007 01:28 PM, Martin Spott wrote: Did you check that this doesn't collide with the transponder that's already present Ah, yes, very newly present. Here is the patch to remove my semblance of a transponder to make way for Ron Jensen's vastly nicer transponder. This is a patch

[Flightgear-devel] communication; project-within-project

2007-01-29 Thread John Denker
On 01/28/2007 04:43 PM, Martin Spott wrote: [last week] I applied the patch which implemented your 'semi-transponder' right the next day. Anything wrong with this ? Definitely not wrong! Thanks! Indeed this week's patches are dependent on last week's patches. Only a few lines of last week's

Re: [Flightgear-devel] communication; project-within-project

2007-01-29 Thread John Denker
On 01/29/2007 06:15 PM, Martin Spott wrote: I don't think there's a real solution to this problems that adresses all your concerns. /All/ my concerns? As the saying goes: Do not let the perfect be the enemy of the good. I don't expect a SCM system to end world hunger. But there are things

Re: [Flightgear-devel] radials revisited

2007-01-30 Thread John Denker
On 01/29/2007 11:01 PM, Dave Perry wrote: This is exactly the situation that John Denker maintained was an exception to the rule report position as the radial from the station and DME distance. This pilot agreed with John. Actually I have changed my mind about this. A couple of days ago I

Re: [Flightgear-devel] hsi.xml now responds to serviceable flag (or lack thereof)

2007-01-31 Thread John Denker
On 01/31/2007 10:04 AM, Torsten Dreyer wrote: I just checked you patch to hsi.xml where you tied the rotation of the compass rose to the heading of the heading-indicator. This leads to a drift of the compass rose due to precession and internal errors as one can see in

Re: [Flightgear-devel] hsi.xml now responds to serviceable flag (or lack thereof)

2007-01-31 Thread John Denker
On 01/31/2007 11:53 AM, Torsten Dreyer wrote: - starting fg with a c182 - opening property browser - browsing to /instrumentation/heading-indicator - observing properties indicated-heading-deg and offset-deg - opening second property browser - browsing to /orientation - observing property

Re: [Flightgear-devel] hsi.xml now responds to serviceable flag (or lack thereof)

2007-01-31 Thread John Denker
On 01/31/2007 05:18 PM, I wrote: Another migration strategy: The only aircraft that would require fiddling are ... It's even easier than I thought. The three that presently provide power to the so-called DG also provide power to the hsi, so AFAICT the patch can be dropped in with no

Re: [Flightgear-devel] where to put optional Nasal addon script?

2007-02-02 Thread John Denker
On 02/02/2007 10:20 AM, Stuart Buchanan wrote: and have all the .nas files that are loaded by default defined in preferences.xml. I've never liked the fact that we always pick up any .nas files in the Nasal/ directory. There are two sides to that coin. a) There are plenty of situations

Re: [Flightgear-devel] hsi.xml now responds to serviceable flag (or

2007-02-04 Thread John Denker
Torsten Dreyer wrote in part: this one needs patching of all aircraft that uses the hsi. I believe that is no longer true. AFAIK, no aircraft require patching to use the new hsi. More particularly, it is my /goal/ to make the new hsi upward-compatible with the old hsi. If that goal is

[Flightgear-devel] bug roundup

2007-02-05 Thread John Denker
Here is the current list of bugs etc. from http://wiki.flightgear.org/flightgear_wiki/index.php?title=Bugs 1 Known Bugs 1.1 Z-buffer burn-through 1.2 Memory leak 1.3 Numerous bugs in ATIS feature 1.4 Problems with --altitude option 1.5 Multiple bugs in the location-in-air popup

Re: [Flightgear-devel] memory leak (was: bug roundup)

2007-02-06 Thread John Denker
On 02/05/2007 07:55 PM, Durk Talsma wrote: I've never seen any memory leaks that bad. Could you please try it with the simulator /paused/? A rather steady leak of 2 meg per minute is observed chez moi during pause, no matter whether the aircraft is aloft or parked on the ground. Vastly less

Re: [Flightgear-devel] J7W Shinden

2007-02-06 Thread John Denker
On 02/06/2007 03:47 PM, Tatsuhiro Nishioka wrote: I calculated the position of CG with the equation obtained at: http://www.paragonair.com/public/docs/FAA-Handbooks/8083-01_WnB/ 8083-01_ch08.pdf According to this document, the distance from the nose to the CG is calculated as: CGoffset

[Flightgear-devel] reverse Turing test

2007-02-06 Thread John Denker
Can you pretend to be a computer? Try interpreting the following trivial piece of nasal code by hand. Then see if the nasal interpreter agrees with your interpretation. node = props.globals.getNode(/foo/bar, 1); bar = getprop(/foo/bar); if (bar == nil) { str = bar: nil, ; }

Re: [Flightgear-devel] Textranslate Step and Scroll

2007-02-07 Thread John Denker
On 02/07/2007 09:47 AM, Ron Jensen wrote: While working on 3D cockpit instruments I keep hitting into issues with internal floating point representation and the textranslatestep tag. The step tag effectively truncates the property, 29.9199 becomes 29.91, so a (3D) readout reads off

[Flightgear-devel] rounding and truncation (was: Textranslate Step and Scroll)

2007-02-07 Thread John Denker
On 02/07/2007 12:26 PM, Ron Jensen wrote: How would the step function know to round to the proper number of decimal places? In the 2D instruments a printf-style statement is used, i.e. format%02.2f/format. However, we're not exactly printing in textranslate. I thought about a

[Flightgear-devel] rounding and truncation

2007-02-07 Thread John Denker
On 02/07/2007 02:14 PM, Andy Ross wrote: The patch itself looks sane and easy. But I think I agree with John, this is a workaround for a design flaw in the step animation that we should just fix. :-) So you want to pass in the floating point value 29.92 and a step of 10 and get back

Re: [Flightgear-devel] rounding and truncation

2007-02-07 Thread John Denker
Improved code. Previous version went against the POSIX convention. # Following the POSIX convention, # halfway cases are rounded away from zero, # to the extent this is possible given the inherent # inexactitude of the floating-point representation. round = func(arg, quantum=1){ if (quantum

Re: [Flightgear-devel] C172p strange behaviour

2007-02-08 Thread John Denker
On 02/08/2007 12:35 PM, gh.robin wrote: If it is FG cvs with OSG, it is not a surprise to me, i told before on several topics regarding autopilot, that it is not working. Nobody but Lee answered to confirm that it is not working. The default c172p in the current CVS is messed up in ways

Re: [Flightgear-devel] Textranslate Step and Scroll

2007-02-08 Thread John Denker
On 02/07/2007 02:14 PM, Andy Ross wrote: So if there's a design flaw here, it's at a higher level. Maybe what's really needed is a digit extractor animation instead. Good news: The /design/ is not as flawed as it looks. All evidence indicates that the primary problem with the

Re: [Flightgear-devel] Textranslate Step and Scroll

2007-02-09 Thread John Denker
On 02/09/2007 11:08 AM, Ron Jensen wrote: I stripped the apply_mod() function out into its own small program for analysis. The experimental analysis confirms that the code is numerically unstable. I don't think there is any way to make it numerically stable. The instability can be swept

Re: [Flightgear-devel] Textranslate Step and Scroll

2007-02-09 Thread John Denker
On 02/09/2007 09:34 PM, Ron Jensen wrote: [250 lines of stuff we agree about] Except in your algorithm '0' can never be used as a scroll value. Well, I fixed that just now. New version: http://www.av8n.com/fly/fgfs/animation.diff Anybody who wants to set scroll0/scroll is now free to do

[Flightgear-devel] ILS service volume issues

2007-02-10 Thread John Denker
In some parts of the world, (including the southwest US), a goodly fraction of the localizers have an expanded service volume (ESV), often quite a bit larger than the standard service volume you see in the AIM. The code in navradio.cxx has been ignoring the service volume information in the

[Flightgear-devel] building the library of 3D instruments (was: DME for pa28)

2007-02-10 Thread John Denker
On 02/10/2007 09:48 AM, Dave Perry wrote: On my system, I have the following running: 1. Moved the pa24 radio stack to Aircraft/Instruments-3d/, along with the required changes to the pa24-250. [etc.] Yes, that's a good move. While were on the subject ... could you please similarly export

[Flightgear-devel] altimeter.xml

2007-02-10 Thread John Denker
The standard altimeter (used by the default c172p aircraft and many others) had been using an unhappy hodgepodge of layers. The analog Kollsman window was unusable, because it was unlabeled, and the digital altimeter setting was unusable, especially at altitudes near 2500 feet, partly from being

[Flightgear-devel] incorrect altimetry

2007-02-10 Thread John Denker
There is evidently at least one serious misconception in the code that calculates atmospheric pressure, altimeter settings, et cetera. This can be easily demonstrated: Park at or near the threshold of runway 33 at Aspen (KASE). Under standard conditions, observe that the altimeter reads 7820 feet

Re: [Flightgear-devel] incorrect altimetry

2007-02-11 Thread John Denker
On Sun, 2007-02-11 at 00:22 -0500, John Denker wrote: 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

Re: [Flightgear-devel] incorrect altimetry

2007-02-11 Thread John Denker
On 02/11/2007 01:42 PM, I wrote: OK ... assuming by altitude they mean pressure altitude not true altitude or absolute altitude or ... Typo: I meant indicated altitude instead of pressure altitude. Pressure altitude is something else yet again. Sorry for any added confusion; this was a

Re: [Flightgear-devel] incorrect altimetry

2007-02-11 Thread John Denker
Reference: Altimetry principles. Lurid details including equations and derivations. http://www.av8n.com/physics/altimetry.htm - Using Tomcat but need to do more? Need to support web services, security? Get stuff done

[Flightgear-devel] weekly bug roundup

2007-02-11 Thread John Denker
From http://wiki.flightgear.org/flightgear_wiki/index.php?title=Bugs 1 Known Bugs 1.1 Incorrect altimetry. 1.2 Altimetry misnomers and misconceptions. 1.3 Z-buffer burn-through. 1.4 Memory leak. 1.5 Numerous bugs in ATIS feature. 1.6 Problems with --altitude option.

Re: [Flightgear-devel] incorrect altimetry

2007-02-11 Thread John Denker
On 02/11/2007 11:29 PM, Dave Perry wrote: By the way, I agree that the current algorithm in altimeter.cxx is wrong. This evening, I had time to look at your posted patch and I think it would give the right hi. It is, for now, restricted to the troposphere (36000 feet and below). Extending

[Flightgear-devel] Newton's laws violated by environment.cxx

2007-02-12 Thread John Denker
Consider the following results of an experiment using fgfs: alt: 662 mM: 0.0288 P: 99000.8462 T: 286.8563 rho: 1.1975 alt: 3462 mM: 0.0288 P: 89341.6721 T: 281.3920 rho: 1.1009 alt: 662 mM: 0.0289 P: 99000.8422 T: 256.9910 rho: 1.3404 alt: 3462 mM: 0.0289 P: 89341.6740

Re: [Flightgear-devel] incorrect altimetry

2007-02-12 Thread John Denker
On 02/12/2007 07:24 PM, Dave Perry wrote: This looks really slick, :-) ... why is this patch good above the troposphere ( 100,000 ft.)? It should give the same answer as the last patch, only much more efficiently. The tabulated numbers come from a three-layer model, namely layers 0

Re: [Flightgear-devel] incorrect altimetry

2007-02-12 Thread John Denker
On 02/13/2007 12:11 AM, Dave Perry wrote: I can see how you generate a table that gives PA and C(s) for layers with nonzero lapse rate. I assume you use equation (8) solved for h to generate the table when lamda = 0. Yes, equation 8, but I don't even need to solve for h. That's the

Re: [Flightgear-devel] ILS service volume issues

2007-02-13 Thread John Denker
On 02/10/2007 12:48 PM, John Denker wrote: ... other service volume issues. The code has no understanding of how azimuth affects the localizer. I fixed this. There are now six localizer courses: -- one front course -- one back course (reverse sensing) -- four false courses (two

Re: [Flightgear-devel] [OT]: Range of radios

2007-02-13 Thread John Denker
On 02/13/2007 09:31 AM, Holger Wirtz wrote: What I need is a simple number which should describe the maximum range og a COM1. For example 5 km? oder 20 km??? As others have pointed out, the simple answer is line of sight. See algorithms below. COM1 in a Cessna is not as one of an Airbus.

Re: [Flightgear-devel] fg_sqawk Version 0.2beta

2007-02-15 Thread John Denker
On 02/15/2007 09:25 AM, Holger Wirtz wrote: FG seems to have a built-in ATIS for KSFO 118.85 which overlaps with the realtime voice communication. My question was actually how to tell FG not to use its internaly ATIS. A better solution would be to use 122.75 for air-to-air communications,

Re: [Flightgear-devel] fg_sqawk Version 0.2beta

2007-02-15 Thread John Denker
On 02/15/2007 09:56 AM, Holger Wirtz wrote: My question was actually how to tell FG not to use its internaly ATIS. Hmmm... you misunderstand my approach for voice communication: There is a voice-server in thebackground which has for every frequency a conference room (as a simulation of

Re: [Flightgear-devel] incorrect altimetry

2007-02-15 Thread John Denker
On 02/15/2007 04:55 PM, Alex Perry wrote: More generally: It is always very important to distinguish between the facts that arise from the simulation of the planet (such as SLP and variation), and the facts that arise from simulation of the airspace (such as QNH and VOR alignment). Yes.

[Flightgear-devel] altimetry method ... alpha version

2007-02-18 Thread John Denker
On 02/12/2007 08:43 PM, Dave Perry wrote: 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. Then the kap140.nas could use that function, the encoder could use that function

[Flightgear-devel] ATIS audio +- default.vce

2007-02-19 Thread John Denker
It appears that interest is coming from multiple directions, interest in upgrading the audio overall, plus particular interest in having usable ATIS audio. This is not unrelated to the effort to handle non-ISA-standard-day weather conditions, since if you're going to have a non-standard day, you

Re: [Flightgear-devel] ATIS audio +- default.vce

2007-02-20 Thread John Denker
On 02/19/2007 07:40 PM, Dave wrote: The ATIS as currently written *should* give usable altimeter and visibility. Is this broken at the moment? If so, how and under what circumstances? The altimeter setting is incorrect in most circumstances other than sea-level and/or ISA-standard-day

[Flightgear-devel] altimeter +- encoder

2007-02-21 Thread John Denker
In the course of fixing up altimeter.cxx, I decided to incorporate all of the features of encoder.cxx. They were so similar in function that it didn't make sense to maintain two of them. In particular, -- The basic altimeter is also an encoding altimeter. If you don't want the encoding

Re: [Flightgear-devel] Zero lag altimeter

2007-02-22 Thread John Denker
On 02/22/2007 01:27 AM, John wrote: Modern avionics and air data computers provide an instantaneous vertical velocity and altimeter. Yes. Is there a property/variable in flightgear that does not contain the lag present in simple baro systems? Yes. I'm under the impresssion that the

Re: [Flightgear-devel] Zero lag altimeter

2007-02-22 Thread John Denker
On 02/22/2007 08:32 AM, AJ MacLeod wrote: On Thursday 22 February 2007 13:28, John Denker wrote: Solving this problem is easy: I'd say so too... for exact values rather which don't rely on modelled instrumentation can't one just use the values provided under /position in the property tree

Re: [Flightgear-devel] altimeter, encoder, and kap140

2007-02-24 Thread John Denker
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

Re: [Flightgear-devel] altimeter, encoder, and kap140

2007-02-25 Thread John Denker
There are two ideas that need to be kept separate. a) The idea of an /class/ aka /object/, versus b) the idea of an /instance/ of such a class. As applied to altimetry: a) Writing a single altimetry /object/ that can perform either as a digital encoder *or* as an analog steam gauge

Re: [Flightgear-devel] altimeter, encoder, and kap140

2007-02-25 Thread John Denker
On 02/25/2007 12:49 PM, Roy Vegard Ovesen wrote: I have to agree with Dave on this. The indicated altitude should _not_ be quantized. The indicated altitude belongs to the altimeter part of the class, and _not_ to the encoder part. Parts? I didn't know the class has an altimeter part

Re: [Flightgear-devel] Zero lag altimeter

2007-02-25 Thread John Denker
On 02/25/2007 12:32 PM, Alex Perry wrote: There are three types of altimeter in common use: (1) Air data computers, which go to a lot of trouble to report the instantaneous value. Right. Aircraft with such instruments should use the environment value, Is that a typo? I don't know of

Re: [Flightgear-devel] altimeter, encoder, and kap140

2007-02-25 Thread John Denker
On 02/25/2007 02:39 PM, Roy Vegard Ovesen wrote: I suggested an encoding altimeter as an instance that has both. Do you think that makes sense? Yes, that has been suggested. But what's the rationale? It's not the craziest idea in the world... but I still haven't heard an argument for it that

Re: [Flightgear-devel] altimeter, encoder, and kap140

2007-02-25 Thread John Denker
distinction, and then sometimes within a few sentences they trample roughshod over the distinction. Not being clear in terminology and semantics was one of your original complaints about the existing code. Agreed. On Sun, 2007-02-11 at 00:22 -0500, John Denker wrote: While we're

Re: [Flightgear-devel] altimeter, encoder, and kap140

2007-02-25 Thread John Denker
On 02/25/2007 04:49 PM, Martin Spott wrote: John, a significant part of introducing yourself to the list - the one our readers will probably remember best - was you strongheaded instisting of how to read VOR radials. Well: 1) As you know, I changed my mind about how to report radials. 2)

  1   2   3   4   5   6   >