Re: [Flightgear-devel] Airspeed indicator and pitot system
On Mon, 21 Oct 2002 21:03:18 -0400, [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: Andy Ross writes: An excellent point -- I wonder how they do it, then? On the ground, they can obviously line up with something well known, and in VFR, they can line up two landmarks on the map, but how to update the DG in IFR? As Alex points out, if you have three receivers (and synchronize them to use the same satellite set) you can get the location for each point of a triangle and figure out the orientation for that. Right, but I'm not asking how people could do it but how they actually do. I doubt that most pilots in the north have 3-GPS in-flight setups right now. ..standard is one antenna for vfr type flight, position is accurate within a 300ft diameter by 450 ft tall error egg with cold war type crypto turned on, egg shrinks to 35?ft by 50?ft on turning off the crypto (random noise vector) signal. The error egg shrinks further when additional observations are added to the equation set, such as altimeter, DG, GS etc readings, exact position of antenna(s) and other sensors on airframe, in relation to its datum origo. Differential GPS may add one or more ground station satellite observations to the equation set, the early work tried to calculate and nullify the random noise vector, and instead added (athmosphaerically bent) signal path leg errors. ..AFAIK, the average aviator up north uses cheap shelf ware gps units to back up his nav work. ;-) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
Andy Ross writes: ..also, we may want to modify the fdm to model the airframe iceing, bending, dropping things or breaking up etc in mid-air, this is useable both for both post accident forensics and games. Most of that is really hard, but dropping things we can do already. It's really hard to do well (for an engineering application), but it might be possible to fake (for a pilot training application). For example, here are some symptoms of icing: 1. increased gross weight 2. decreased lift 3. decreased propeller performance 4. blocked carb intake 5. hstab stall We cannot do those right without an incredible amount of work, but in JSBSim (for example), we could simply add another dimension to some of the tables based on a simplistic icing input value. The hstab stall is particularly nasty because the recovery is the opposite of the wing-stall recovery that pilots normally practice. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
Andy Ross writes: An excellent point -- I wonder how they do it, then? On the ground, they can obviously line up with something well known, and in VFR, they can line up two landmarks on the map, but how to update the DG in IFR? As Alex points out, if you have three receivers (and synchronize them to use the same satellite set) you can get the location for each point of a triangle and figure out the orientation for that. Right, but I'm not asking how people could do it but how they actually do. I doubt that most pilots in the north have 3-GPS in-flight setups right now. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
On Mon, 2002-10-21 at 18:02, [EMAIL PROTECTED] wrote: Andy Ross writes: ..also, we may want to modify the fdm to model the airframe iceing, bending, dropping things or breaking up etc in mid-air, this is useable both for both post accident forensics and games. Most of that is really hard, but dropping things we can do already. It's really hard to do well (for an engineering application), but it might be possible to fake (for a pilot training application). For example, here are some symptoms of icing: 1. increased gross weight 2. decreased lift 3. decreased propeller performance 4. blocked carb intake 5. hstab stall We cannot do those right without an incredible amount of work, but in JSBSim (for example), we could simply add another dimension to some of the tables based on a simplistic icing input value. The hstab stall is particularly nasty because the recovery is the opposite of the wing-stall recovery that pilots normally practice. Umm .. that would require reworking most of our models from the ground up. We really do need a tail-off model for that sort of thing. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
If you don't want the full realism on the public CVS configuration then I'll hereby respectfully disagree with you. This is especially true for the autopilot. Many current AutoPilots do not use a manetic compass for heading and I expect that this will be even truer in the future. No; they normally use a DG. Larger acft use a DG that is slaved to a magnetic compass, thereby eliminating the heading drift error. Even larger acft use the six axis accelerometer data inside their INS unit to infer the DG indications (and avoid mechanical gyros). The difference between the last two is transparent to the pilot, assuming the failure patterns are correctly loaded into systems, so the only observable difference is between the first two. Basically, does the panel has a heading adjustment knob or a magnetic slaving control knob (with behavior installed). #define DEFAULT_AP_HEADING_LOCK FGAutopilot::FG_TRUE_HEADING_LOCK I am not aware of any real autopilot that uses true headings, but I don't see why we can't have that mode available by property. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
Alex Perry writes: I am not aware of a GPS unit that is able to report heading rather than track, but as far as I know, only cost is the driving factor there. http://www.intnlind.com/trimble/ms860.html http://www.geomatics.ucalgary.ca/research/GPSRes/GPS_GLON.html I should have said aviation approved. Any three-antenna DGPS install can, among other things, replace all the INS platform (ignoring availability). Presumably, there'll be someone who has a slaving DG hooked up to a GPS to get a track readout in addition to the conventional heading report. http://www.porcine.com/gps/sc/sc_index.shtml That doesn't look like it'll drive a DG; it just sends error data to the AP. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
Alex Perry writes: I am not aware of a GPS unit that is able to report heading rather than track, but as far as I know, only cost is the driving factor there. An excellent point -- I wonder how they do it, then? On the ground, they can obviously line up with something well known, and in VFR, they can line up two landmarks on the map, but how to update the DG in IFR? All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
Alex Perry Alex Perry writes: I am not aware of a GPS unit that is able to report heading rather than track, but as far as I know, only cost is the driving factor there. http://www.intnlind.com/trimble/ms860.html I should have said aviation approved. Any three-antenna DGPS install can, among other things, replace all the INS platform (ignoring availability). AFAIK You don't need DGPS for heading I understand that this kind of instrument might not be desirable in a Flight Training Device yet but there is certainly no reason not to model it in a general purpose flight simulator as it is the future and I bet it or its equivalant is in the air already if for no other reason then to gather data inorder to get 'aviation certification'. Regards Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
Alex Perry writes: I understand. Norm is thinking about, say, an NTSB investigation reconstructing different scenarios that might have led to an accident. Yes, I agree that an AI pilot (to distinguish from an autopilot) using true values would be useful here when true data is available from radar tapes or witness accounts. As other people have commented, if you want to use FGFS as a visualization tool to reproduce a recording (such as the black box tape, the enhanced NMEA data from a flight, or a simulation logfile) then the autopilot is the wrong tool. That's what the plug-in FDM infrastructure is for ... I'm thinking more along the lines of the flight went normally until lat/lon/alt, then the pilot may have done X. We could use an AI pilot to try doing X as soon as we hit lat/lon/alt. Granted, this would be a very specialized application, but it's my best guess at what Norm was talking about. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
Alex Perry said: Any three-antenna DGPS install can, among other things, replace all the INS platform (ignoring availability). Norman responded: AFAIK You don't need DGPS for heading I don't see how you'll manage heading reliably without going differential. The two links you pointed out, for example, were differential systems. I understand that this kind of instrument might not be desirable in a Flight Training Device yet On the contrary; I think we _should_ have the capability in FGFS; simulation is at the leading edge of RD and of advanced training. The simulation of that experimental aircraft would presumably refer to a new panel xml file specifically calling out those instruments. As far as I know, the uncooked data from the FDM will be an excellent simulation of a 3 channel GPS with MEMS accelerometer prediction, and a simple 10 Hz low pass filter will probably do the no-MEMS variant. Failure modes, at the systems level, would complicate that a lot though. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
I'm thinking more along the lines of the flight went normally until lat/lon/alt, then the pilot may have done X. We could use an AI pilot to try doing X as soon as we hit lat/lon/alt. Granted, this would be a very specialized application, but it's my best guess at what Norm was talking about. Oh. That'd be really handy. Do you think we can talk the FDM people into supporting a checkpoint and restore capability? If it is sufficiently fast, it'd permit an external iterative nonlinear solver to deduce control inputs that will reproduce (for example) several positions and altitudes (aka from secondary radar). ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
Alex Perry writes: Any three-antenna DGPS install can, among other things, replace all the INS platform (ignoring availability). Norman responded: AFAIK You don't need DGPS for heading I don't see how you'll manage heading reliably without going differential. The two links you pointed out, for example, were differential systems. The more separation between the antennas the better but a 'relative to each other' a multiple antenna system locked to the same 'clock' for each satelite is its own differential system with respect to the differance in the SAME signal recieved at the two locations. Not this is only valid for the relative 'position difference vector' which just happens to the directional vector between the antenae eg heading :-) absolute measurements such as position and/or elevation are a different story in other words since all antennas are receiving the same error the error is nullified in relative position calculations cheers norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
On Sun, 2002-10-20 at 18:02, [EMAIL PROTECTED] wrote: Alex Perry writes: I understand. Norm is thinking about, say, an NTSB investigation reconstructing different scenarios that might have led to an accident. Yes, I agree that an AI pilot (to distinguish from an autopilot) using true values would be useful here when true data is available from radar tapes or witness accounts. As other people have commented, if you want to use FGFS as a visualization tool to reproduce a recording (such as the black box tape, the enhanced NMEA data from a flight, or a simulation logfile) then the autopilot is the wrong tool. That's what the plug-in FDM infrastructure is for ... I'm thinking more along the lines of the flight went normally until lat/lon/alt, then the pilot may have done X. We could use an AI pilot to try doing X as soon as we hit lat/lon/alt. Granted, this would be a very specialized application, but it's my best guess at what Norm was talking about. A technique in which the pilot controls are driven from recorded data, combined with a switch to allow the pilot to take control at any time, is very useful for this sort of work. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
On Sun, 2002-10-20 at 18:19, Alex Perry wrote: I'm thinking more along the lines of the flight went normally until lat/lon/alt, then the pilot may have done X. We could use an AI pilot to try doing X as soon as we hit lat/lon/alt. Granted, this would be a very specialized application, but it's my best guess at what Norm was talking about. Oh. That'd be really handy. Do you think we can talk the FDM people into supporting a checkpoint and restore capability? This can be done now with David's save flight code or (in a different way) with JSBSim's trimming routine. If it is sufficiently fast, it'd permit an external iterative nonlinear solver to deduce control inputs that will reproduce (for example) several positions and altitudes (aka from secondary radar). This isn't as useful as you might think, however, since there are always going to be multiple solutions for the lateral-directional controls (ailerons, rudder, sideslip angle, and bank angle). This is only for steady-state, the situation becomes much worse if there are significant rates involved. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
On Sun, 20 Oct 2002 18:19:39 -0700 (PDT), Alex Perry [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: I'm thinking more along the lines of the flight went normally until lat/lon/alt, then the pilot may have done X. We could use an AI pilot to try doing X as soon as we hit lat/lon/alt. Granted, this would be a very specialized application, but it's my best guess at what Norm was talking about. Oh. That'd be really handy. Do you think we can talk the FDM people into supporting a checkpoint and restore capability? If it is sufficiently fast, it'd permit an external iterative nonlinear solver to deduce control inputs that will reproduce(for example) several positions and altitudes (aka from secondary radar). ..also, we may want to modify the fdm to model the airframe iceing, bending, dropping things or breaking up etc in mid-air, this is useable both for both post accident forensics and games. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
Tony Peden writes: This isn't as useful as you might think, however, since there are always going to be multiple solutions for the lateral-directional controls (ailerons, rudder, sideslip angle, and bank angle). This is only for steady-state, the situation becomes much worse if there are significant rates involved. Are we talking about taking flight data and trying to figure out what pilot controls led to the given behavior? i.e. what control inputs get us to the next step and the next and the next? If you take each control and map it to a dimension you wind up with an 'n' dimensional space where 'n' equals the number of control inputs you are interested in. Then it's a matter of searching this 'n' dimensional space for a solution that yields the position/orientation/velocity/acceleration of the next time step. Depending on the details of exactly what you are doing, there are quite a few different strategies for searching a space ... Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
On Sun, 20 Oct 2002 18:16:27 -0700 (PDT), Alex Perry [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: Alex Perry said: Any three-antenna DGPS install can, among other things, replace all the INS platform (ignoring availability). Norman responded: AFAIK You don't need DGPS for heading I don't see how you'll manage heading reliably without going differential. The two links you pointed out, for example, were differential systems. ..Alex, you ignore we're moving. (D)GPS heading is simply our last position minus our last few positions. ;-) I understand that this kind of instrument might not be desirable in a Flight Training Device yet On the contrary; I think we _should_ have the capability in FGFS; simulation is at the leading edge of RD and of advanced training. The simulation of that experimental aircraft would presumably refer to a new panel xml file specifically calling out those instruments. As far as I know, the uncooked data from the FDM will be an excellent simulation of a 3 channel GPS with MEMS accelerometer prediction, and a simple 10 Hz low pass filter will probably do the no-MEMS variant. Failure modes, at the systems level, would complicate that a lot though. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
On Sun, 20 Oct 2002 21:00:34 -0400, [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: Alex Perry writes: I am not aware of a GPS unit that is able to report heading rather than track, but as far as I know, only cost is the driving factor there. An excellent point -- I wonder how they do it, then? On the ground, they can obviously line up with something well known, and in VFR, they can line up two landmarks on the map, but how to update the DG in IFR? ..in laymans terms: our last position minus our last few positions. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
On 20 Oct 2002 19:53:39 -0700, Tony Peden [EMAIL PROTECTED] wrote in message 1035168820.13068.505.camel@raptor: On Sun, 2002-10-20 at 19:39, Arnt Karlsen wrote: On Sun, 20 Oct 2002 21:00:34 -0400, [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: Alex Perry writes: I am not aware of a GPS unit that is able to report heading rather than track, but as far as I know, only cost is the driving factor there. An excellent point -- I wonder how they do it, then? On the ground, they can obviously line up with something well known, and in VFR, they can line up two landmarks on the map, but how to update the DG in IFR? ..in laymans terms: our last position minus our last few positions. You can't get heading this way ... only ground track. The wind will often cause an airplane to travel in a different direction than its pointed. ..correct. Nonetheless, this _is_ gps heading in cheap equipment. Airworthy gps would call this 'ground track' or 'track'. ..I also see I failed to answer how to update the DG. If the DG can read a NMEA protocol message from the GPS, problem solved, else, some protocol translator box (FG spinoff?) or operator input is needed. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
On Sun, 2002-10-20 at 20:03, Alex Perry wrote: If you take each control and map it to a dimension you wind up with an 'n' dimensional space where 'n' equals the number of control inputs you are interested in. The real problem with lateral directional is that you have three states you need to solve for: lateral accel yaw accel roll accel and four controls: ailerons rudder sideslip bank There are an infinite number of solutions. Since the topic is coming up ... to what extent can you disambiguate using: (a) linear acceleration, i.e. excess drag due to the slip It depends on how well you know the airplane. If you have a good idea of what the drag due to sideslip is then you can probably take a good guess. (b) rate of heading, combined with wing g load, for coordinated bank. I think you'd also need to know the winds, which is very hard to do. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
IMHO in steam module should be added some reality switch. When /instrumentation/steam is true then it cook all values, when /istrumentation/steam is false then it simply copy /orientation/heading-deg to /instrumentation/magnetic-compass/indicated-heading-deg and etc. I suspect this might be a bad route to take, but I'm not sure. I have a suspicion that we will usually have many instruments that want cooked and many that want uncooked values. When the need changes, I don't think we will want to eliminate _all_ cooked values, just _some_. In the GUI property browser, can we add a button that does a 'find all properties that point to this property' listing ? That would make it convenient to push individual data users around. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
On Fri 11. October 2002 02:14, you wrote: Norman Vine writes: I will still argue that the method used was and still is poor There are those who want 'steam' and those who don't Sure, and we make both available through the property tree. If you want to know the exact true heading, look at /orientation/heading-deg; if you want to know the indicated compass heading, look at /steam/whatever, soon /instrumentation/magnetic-compass/indicated-heading-deg. No one took away information that you had before, and the HUD still displays the exact heading if you're interested. On the other hand, it's just silly to build a control panel that looks like a real one and not have it act that way -- why waste all the texture memory to simulate analog gauges when the HUD can do the job better? IMHO in steam module should be added some reality switch. When /instrumentation/steam is true then it cook all values, when /istrumentation/steam is false then it simply copy /orientation/heading-deg to /instrumentation/magnetic-compass/indicated-heading-deg and etc. Regards, MaDr -- Martin Dressler e-mail: [EMAIL PROTECTED] http://www.musicabona.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
Martin Dressler writes: IMHO in steam module should be added some reality switch. When /instrumentation/steam is true then it cook all values, when /istrumentation/steam is false then it simply copy /orientation/heading-deg to /instrumentation/magnetic-compass/indicated-heading-deg and etc. The steam module is just about finished, since most things have already moved to /instrumentation/. I don't think you really need a proper autopilot for using true values, just something that works with the magic FDM and moves the plane in a certain direction at a certain speed -- more of an animation manager than an autopilot. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
Norman Vine writes: I don't think you really need a proper autopilot for using true values, just something that works with the magic FDM and moves the plane in a certain direction at a certain speed -- more of an animation manager than an autopilot. http://gps.faa.gov/Programs/WAAS/waas.htm Norm, Norm, Norm -- I'm very disappointed. You're the one who has spent the most time drilling into everyone's head that GPS receiver readings are *not* the same as true values. Certainly, we'll want to be able to slave the autopilot to a GPS receiver as well as the HI, VOR, etc., but then we'll be modelling the GPS altitude errors and sampling-rate lag and adding a slight fuzzy factor (a significant one for altitude); if we get fancy we might even let the receiver have trouble locking on to satellites sometimes. In fact, even the C172R (which we're modelling) comes with a KLN89 or better GPS receiver, together with an autopilot that can be slaved to it instead of the VOR gauge for lateral control. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
David Megginson Norman Vine writes: I don't think you really need a proper autopilot for using true values, just something that works with the magic FDM and moves the plane in a certain direction at a certain speed -- more of an animation manager than an autopilot. http://gps.faa.gov/Programs/WAAS/waas.htm Norm, Norm, Norm -- I'm very disappointed. You're the one who has spent the most time drilling into everyone's head that GPS receiver readings are *not* the same as true values. David David David You rewrite history well all the best Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
Alex Perry writes: Ok, I found the problem. You're computing the dynamic pressure in psf and adding it to the static pressure in inHg to form the total pressure. The attached patch is the simple fix to the source. That's nasty, because the resulting airspeed is still correct under regular conditions. Thanks again for catching it -- the patch is now in CVS. I wonder if the casual users appreciate all the work we're doing to make the instruments less reliable. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
David Megginson writes: Alex Perry writes: Ok, I found the problem. You're computing the dynamic pressure in psf and adding it to the static pressure in inHg to form the total pressure. The attached patch is the simple fix to the source. That's nasty, because the resulting airspeed is still correct under regular conditions. Thanks again for catching it -- the patch is now in CVS. I wonder if the casual users appreciate all the work we're doing to make the instruments less reliable. There is a *lot* of subtle things built into FlightGear that most users probably don't realize. It might be interesting to make some sort of tour of the flightgear sim which would highlight or point out many of the more subtle features. Instrument modeling is a good point ... quite often we get bug reports that things don't work right, when in reality they are working too much like real life. :-) For instance, people may notice the correctly placed sun and moon, but the moon also has correct phase, is textured. We also have the top several hundred stars placed correctly with proper magnitude as well as the planets placed correctly with proper magnitude. All of course correct for time of day, season, location on the earth, etc. Airports can be non-flat, runway and approach lighting is/will be directional. There is a ton of internal infrastructure stuff that is useful in the geek sense ... property system, interfacing to external programs. The ability to build instrument panels, electrical systems, 3d models, animation, with absolutely no coding or plugins. Many features are setable via the property system, command line options, or preferences.xml which might not be immediately obvious to a new comer. 3D instrument panels are visible and fully live and working even when viewed from external chase views. The world is round, well wgs-84 round. You can fly correct great circle routes, there are no map-maker distortions that foul up ILS alignment or vor intersection locations. I'm sure there are plenty other things we could add to the list. It would be interesting to put together a web page that showed how to start up flightgear to high light these various options. Then as people run through the program in every day use, they'll notice and have a much better appreciation of some of the finer details. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
Alex Perry writes: Ok, I found the problem. You're computing the dynamic pressure in psf and adding it to the static pressure in inHg to form the total pressure. The attached patch is the simple fix to the source. Once again: This wouldn't have happend if we'd use real units like SI... thinking of song=WHERE HAVE ALL THE FLOWERS GONE When will we ever learn? /thinking CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
On 10/10/02 at 12:02 PM Alex Perry wrote: I wonder if the casual users appreciate all the work we're doing to make the instruments less reliable. Don't you remember the massive amount of whingeing (a couple of years ago) when I stuck all the compass turning errors onto the DG instrument ? The simulated aluminium was just _raining_ out of the sky ... 8-) That was one of my absolutely most favourite bits of Flightgear. I got a second hand pilots tuition hand-book from an old book shop some time ago, and was gobsmacked at the bit about the compass over and under-shooting in turns - I'd never even conceived of anything like that, and MSFS95 certainly never did it! When I fired up Flightgear and found it acted *exactly* like the book described I was ecstatic. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
Curtis L. Olson writes: There is a *lot* of subtle things built into FlightGear that most users probably don't realize. It might be interesting to make some sort of tour of the flightgear sim which would highlight or point out many of the more subtle features. Why not post a version of this message to the Web site, with a title like FlightGear: What's Under the Hood? All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
David Megginson writes: Curtis L. Olson writes: There is a *lot* of subtle things built into FlightGear that most users probably don't realize. It might be interesting to make some sort of tour of the flightgear sim which would highlight or point out many of the more subtle features. Why not post a version of this message to the Web site, with a title like FlightGear: What's Under the Hood? Today is flying away from me, but this is a great idea. Remind me when I get back next week or if in the meantime some one else wants to use that message as a starting point for compiling and organizing a list of key features, that would be very much appreciated. Thanks, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
Christian Mayer writes: Once again: This wouldn't have happend if we'd use real units like SI... I live in a (mostly) SI country and went through school learning SI units -- I have to convert Fahrenheit to Celsius to know how cold it is, for example. Still, converting to new units has its cost, including the near crash of an Air Canada 767 a while back (as posted previously): http://www.cadetworld.com/rgs/story2a.html All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
Alex Perry writes: That's true, but now I wonder ... When we are in multiplayer mode, and I fly up behind some unsuspecting pilot who is plugging along on autopilot, slightly above and at his five o-clock position, can I pick up a pair of electronic binoculars (what used to be the Z key?) and put mouse clicks onto his 3D panel ? Vicious grin ... No, that's unlikely -- only your own plane model will have hotspots. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
Alex Perry writes: David writes: I wonder if the casual users appreciate all the work we're doing to make the instruments less reliable. Don't you remember the massive amount of whingeing (a couple of years ago) when I stuck all the compass turning errors onto the DG instrument ? The simulated aluminium was just _raining_ out of the sky ... I will still argue that the method used was and still is poor There are those who want 'steam' and those who don't Forcing BOGUS values into the ONLY autopilot wasa CRASS thing for 'Johnny come lately's' to do. IF you had built a NEW autopilot and left the old one as is I would have been one of the biggest proponents of 'steam', In stead you forced me to take an adversarial position which I still hold FWIW - I put a LOT of effort into getting the navigational parts of FGFS working this included a lot of 'gentle nudging' and a lot of code and I RESENT having been force to used COOKED variables when I might not always always want to. FYI there was a time when Curt and I were probably the only two people that understood at least 90% of the code and we spent a LOT of energy and time trying to teach and/or explain to others how it all worked. I certainly didn't do that expecting those whom we 'enlightned' to change the code such that it was nigh onto impossible to use it in ways that I wanted too. To sum up I think that the work that has been done to make the 'instruments' act like a C172 is fantastic but it SHOULD be an option and not 'the way' Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
I will still argue that the method used was and still is poor There are those who want 'steam' and those who don't I have advocated, all along, that both the correct and the cooked values should be available through the property system. I also think that all panel instruments, and panel autopilots, should use the appropriate level of cooked-ness in accordance with realistic aircraft by embedding property pointers as created by David. I also personally think that the HUD should, again by default, use completely uncooked values for convenience and partial realism. If you don't want this behavior on _your_ system, feel free to hack away at the config files. My local config isn't exactly unmodified compared to CVS, but I think my changes are wrong for the general end-user population and don't recommend them. If you don't want the full realism on the public CVS configuration then I'll hereby respectfully disagree with you. This is especially true for the autopilot. Currently, it is far too easy to use and thus (in several ways) trivializes some of the IFR dangers. One of the reasons I rarely use autopilots in real small aircraft is that they use the same data sources as I have on my instruments, with all the errors. It thus takes non-trivial effort to make them do what I actually want and it is often easier to be manual. This is the very real difference between an autopilot and a FMS. Johnny. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
Norman Vine writes: I will still argue that the method used was and still is poor There are those who want 'steam' and those who don't Sure, and we make both available through the property tree. If you want to know the exact true heading, look at /orientation/heading-deg; if you want to know the indicated compass heading, look at /steam/whatever, soon /instrumentation/magnetic-compass/indicated-heading-deg. No one took away information that you had before, and the HUD still displays the exact heading if you're interested. On the other hand, it's just silly to build a control panel that looks like a real one and not have it act that way -- why waste all the texture memory to simulate analog gauges when the HUD can do the job better? Forcing BOGUS values into the ONLY autopilot wasa CRASS thing for 'Johnny come lately's' to do. IF you had built a NEW autopilot and left the old one as is I would have been one of the biggest proponents of 'steam', In stead you forced me to take an adversarial position which I still hold I have no objection to a new autopilot module if someone wants to build it; the current one is fine but it's showing its age a bit. That said, it shouldn't be hard to make it configurable to use different property sources for specialized applications like your (Norm's) GIS work. To sum up I think that the work that has been done to make the 'instruments' act like a C172 is fantastic but it SHOULD be an option and not 'the way' It should be not just an option but the default option, at least when we're simulating a C172. Still, the property tree does make it easy to do things different ways when you want to -- that was its intention. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
On Thu, 2002-10-10 at 12:02, Alex Perry wrote: David writes: I wonder if the casual users appreciate all the work we're doing to make the instruments less reliable. Don't you remember the massive amount of whingeing (a couple of years ago) when I stuck all the compass turning errors onto the DG instrument ? The simulated aluminium was just _raining_ out of the sky ... Not to mention all the confusion we get now from the rolling tendencies due to the propulsion system ... 8-) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
On Thu, 2002-10-10 at 11:59, Christian Mayer wrote: Alex Perry writes: Ok, I found the problem. You're computing the dynamic pressure in psf and adding it to the static pressure in inHg to form the total pressure. The attached patch is the simple fix to the source. Once again: This wouldn't have happend if we'd use real units like SI... thinking of song=WHERE HAVE ALL THE FLOWERS GONE When will we ever learn? /thinking SI is a technically superior system, but as David's example points out, technical issues aren't the only things that need to be considered when making such a switch. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
David Megginson writes: Norman Vine wrote: To sum up I think that the work that has been done to make the 'instruments' act like a C172 is fantastic but it SHOULD be an option and not 'the way' It should be not just an option but the default option, at least when we're simulating a C172. Still, the property tree does make it easy to do things different ways when you want to -- that was its intention. Yes thank you for finally making doable but it did take a lot of simulated aluminium just _raining_ out of the sky ... and a lot of rewriting code that just plainly ignored the the 'true' values that were there but enough cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
David Megginson Norman Vine writes: I will still argue that the method used was and still is poor There are those who want 'steam' and those who don't Sure, and we make both available through the property tree. If you want to know the exact true heading, look at /orientation/heading-deg; if you want to know the indicated compass heading, look at /steam/whatever, soon /instrumentation/magnetic-compass/indicated-heading-deg. No one took away information that you had before, and the HUD still displays the exact heading if you're interested. On the other hand, it's just silly to build a control panel that looks like a real one and not have it act that way -- why waste all the texture memory to simulate analog gauges when the HUD can do the job better? Forcing BOGUS values into the ONLY autopilot wasa CRASS thing for 'Johnny come lately's' to do. IF you had built a NEW autopilot and left the old one as is I would have been one of the biggest proponents of 'steam', In stead you forced me to take an adversarial position which I still hold I have no objection to a new autopilot module if someone wants to build it; the current one is fine but it's showing its age a bit. That said, it shouldn't be hard to make it configurable to use different property sources for specialized applications like your (Norm's) GIS work. To sum up I think that the work that has been done to make the 'instruments' act like a C172 is fantastic but it SHOULD be an option and not 'the way' It should be not just an option but the default option, at least when we're simulating a C172. Still, the property tree does make it easy to do things different ways when you want to -- that was its intention. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
Norman Vine writes: Yes thank you for finally making doable but it did take a lot of simulated aluminium just _raining_ out of the sky ... and a lot of rewriting code that just plainly ignored the the 'true' values that were there I'm pretty sure that the true values were accessible through the property tree before the steam values were, but I'd have to look back through old e-mail. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
David writes: I wonder if the casual users appreciate all the work we're doing to make the instruments less reliable. Don't you remember the massive amount of whingeing (a couple of years ago) when I stuck all the compass turning errors onto the DG instrument ? The simulated aluminium was just _raining_ out of the sky ... 8-) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
Curtis L. Olson wrote: There is a ton of internal infrastructure stuff that is useful in the geek sense ... property system, interfacing to external programs. The ability to build instrument panels, electrical systems, 3d models, animation, with absolutely no coding or plugins. Many features are setable via the property system, command line options, or preferences.xml which might not be immediately obvious to a new comer. Most of the geeks that I told that you can telnet into FGFS and have a shell there didn't believe me until I showed them... :) CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
Alex Perry writes: David replies: I probably made a stupid mistake on the math. I'll take another look at it tomorrow morning when my brain is fresh. Ok, I found the problem. You're computing the dynamic pressure in psf and adding it to the static pressure in inHg to form the total pressure. The attached patch is the simple fix to the source. Yep, that's a stupid mistake. Thanks for tracking it down, Alex. With that fix, failing the pitot while in cruise at 3k' will cause the airspeed to indicate beyond redline during climb ... well before 4k'. Thus, a pitot problem can be detected on any IFR altitude change. Similarly, failing the static (with working pitot) while cruising 4k' causes the airspeed to indicate beyond redline during a descent well before reaching 3k' (during which, of course, the ALT looks fine). Thus, a static failure can be detected before the aircraft breaks out of the pilot tolerance range and is blatantly conspicuous soon after. During the ground portion of my flight test in August, the examiner asked me how I could detect a static port blockage. I decided to list everything, just to be safe: I mentioned the behaviour of the ASI and he looked impatient; I mentioned the VSI freezing and he still looked impatient; finally, I mentioned the ALT freezing and he relaxed and (I found out later) gave me full marks. He said that it would be hard to detect and identify the ASI problem in real-life flight, but that the ALT freezing would be obvious with a little yoke movement. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
During the ground portion of my flight test in August, the examiner asked me how I could detect a static port blockage. I decided to list everything, just to be safe: I mentioned the behaviour of the ASI and he looked impatient; I mentioned the VSI freezing and he still looked impatient; finally, I mentioned the ALT freezing and he relaxed and (I found out later) gave me full marks. He said that it would be hard to detect and identify the ASI problem in real-life flight, but that the ALT freezing would be obvious with a little yoke movement. He's right. You can't easily check for a static failure using airspeed, because the altitude change needed to create an unambiguous response would bust your altitude tolerance on any clearance. If you have decided to be suspicious of the static, waving the elevators around is correct. Do remember that you're not going to do that routinely during cruise so it isn't the thing that will _initially_ make you suspicious. Flying along, completely trimmed in smooth air (esp at night), it is quite feasible for the altimeter to change by less than 20 ft in 15 minutes of straight and uneventful flight. You'd never notice getting ice on your static port in this situation, and you'd be unpopular with passengers waving the elevators around occasionally. However, if you've been flying along while thinking you are well trimmed yet actually in a slow descent with an iced static port in a cloud, the airspeed indicator error (as above) is the thing that'll first look odd during your regular scan. If you're that well trimmed, you don't expect your speed to change by even 10 knots either way. If it does, you get suspicious of the static and wave the elevators. Does that help ? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
Alex Perry writes: Do remember that you're not going to do that routinely during cruise so it isn't the thing that will _initially_ make you suspicious. Flying along, completely trimmed in smooth air (esp at night), it is quite feasible for the altimeter to change by less than 20 ft in 15 minutes of straight and uneventful flight. You'd never notice getting ice on your static port in this situation, and you'd be unpopular with passengers waving the elevators around occasionally. This is where cross-checking with a GPS receiver would be very useful, since (especially if it's battery powered) the GPS(*) has no interaction with the airplane systems and gives an entirely independent reading. Even a sub-$200 non-aviation hand-held mounted on the yoke could be a useful part of a VFR or IFR scan. I wonder how long it will be until the GPS(**) becomes a primary instrument and the static and vacuum instruments become backup (TAS is a trickier problem, of course). Apparently, there are already GPS-driven attitude indicators starting to appear, though I imagine that it will be a long time before pilots trust them. The other danger is that pilots might come to trust GPS too much, simply because it's digital. All the best, David Pedantic notes: * receiver implied in all future references to GPS. ** or some alternative GNSS system. -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
Alex Perry writes:
You may have mixed units; from memory, it should be more than that.
I don't have time to check into it right now.
David replies:
I probably made a stupid mistake on the math. I'll take another look
at it tomorrow morning when my brain is fresh.
Ok, I found the problem. You're computing the dynamic pressure in
psf and adding it to the static pressure in inHg to form the
total pressure. The attached patch is the simple fix to the source.
With that fix, failing the pitot while in cruise at 3k' will cause
the airspeed to indicate beyond redline during climb ... well before 4k'.
Thus, a pitot problem can be detected on any IFR altitude change.
Similarly, failing the static (with working pitot) while cruising 4k'
causes the airspeed to indicate beyond redline during a descent
well before reaching 3k' (during which, of course, the ALT looks fine).
Thus, a static failure can be detected before the aircraft breaks out
of the pilot tolerance range and is blatantly conspicuous soon after.
Sorry for the delay, Alex.
Index: src/Systems/pitot.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Systems/pitot.cxx,v
retrieving revision 1.1
diff -C3 -r1.1 pitot.cxx
*** src/Systems/pitot.cxx 28 Sep 2002 20:48:53 - 1.1
--- src/Systems/pitot.cxx 7 Oct 2002 05:47:50 -
***
*** 37,52
{
}
void
PitotSystem::update (double dt)
{
if (_serviceable_node-getBoolValue()) {
// The pitot tube sees the forward
// velocity in the body axis.
! double p = _pressure_node-getDoubleValue();
double r = _density_node-getDoubleValue();
double v = _velocity_node-getDoubleValue();
! double q = 0.5 * r * v * v; // dynamic pressure
_total_pressure_node-setDoubleValue(p + q);
}
}
--- 37,56
{
}
+ #ifndef INHGTOPSF
+ # define INHGTOPSF (2116.217/29.9212)
+ #endif
+
void
PitotSystem::update (double dt)
{
if (_serviceable_node-getBoolValue()) {
// The pitot tube sees the forward
// velocity in the body axis.
! double p = _pressure_node-getDoubleValue(); // static
double r = _density_node-getDoubleValue();
double v = _velocity_node-getDoubleValue();
! double q = 0.5 * r * v * v / INHGTOPSF; // dynamic
_total_pressure_node-setDoubleValue(p + q);
}
}
Index: src/Instrumentation/airspeed_indicator.cxx
===
RCS file:
/var/cvs/FlightGear-0.9/FlightGear/src/Instrumentation/airspeed_indicator.cxx,v
retrieving revision 1.1
diff -C3 -r1.1 airspeed_indicator.cxx
*** src/Instrumentation/airspeed_indicator.cxx 28 Sep 2002 20:48:53 - 1.1
--- src/Instrumentation/airspeed_indicator.cxx 7 Oct 2002 05:47:50 -
***
*** 54,66
# define FPSTOKTS 0.592484
#endif
void
AirspeedIndicator::update (double dt)
{
if (_serviceable_node-getBoolValue()) {
double pt = _total_pressure_node-getDoubleValue();
double p = _static_pressure_node-getDoubleValue();
! double q = pt - p; // dynamic pressure
// Now, reverse the equation
double v_fps = sqrt((2 * q) / SEA_LEVEL_DENSITY_SLUGFT3);
--- 54,70
# define FPSTOKTS 0.592484
#endif
+ #ifndef INHGTOPSF
+ # define INHGTOPSF (2116.217/29.9212)
+ #endif
+
void
AirspeedIndicator::update (double dt)
{
if (_serviceable_node-getBoolValue()) {
double pt = _total_pressure_node-getDoubleValue();
double p = _static_pressure_node-getDoubleValue();
! double q = ( pt - p ) * INHGTOPSF; // dynamic pressure
// Now, reverse the equation
double v_fps = sqrt((2 * q) / SEA_LEVEL_DENSITY_SLUGFT3);
[Flightgear-devel] Airspeed indicator and pitot system
I've just checked in a new pitot system and airspeed-indicator instrument to FlightGear CVS. Here's how everything works: 1. The pitot system reads /environment/pressure-inhg (p), /environment/density-slugft3 (r), and /velocities/uBody-fps (v). It then calculates q (dynamic pressure) with q = 0.5 * r * v * v and then sets /systems/pitot/total-pressure-inhg to q + p. 2. The ASI reads /systems/static/pressure-inhg and /systems/pitot/total-pressure-inhg, then reconstructs dynamic pressure by subtracting the static pressure from the total pressure; obviously, if the static port is blocked, the result will be wrong and the gauge will misread. Next, it gets the indicated airspeed in fps simply by reversing the equation from the pitot system, and substituting standard sea-level density for the actual air density (R): v = sqrt((2 * q) / R); Finally, it converts the speed to knots and plugs it into /instrumentation/airspeed-indicator/indicated-speed-kt. It seems to work very well so far, but I'm concerned about not correcting for non-standard sea-level density (say, on a hot, humid day). Any suggestions? Should the static and pitot systems provide an indicated density as well as indicated pressure? Note that because of the sqrt, a static-port failure is not that easy to detect on the ASI -- I disabled the static port at 9000ft, descended to below 3000ft, and the ASI was overreading by only a little over 10kt (I doubt anyone would notice that). All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
