Re: [Flightgear-devel] null-FDM and UFO-FDM instrument outages
John Denker wrote: Here's a mystery for you: Please take a look at http://www.av8n.com/fly/fgfs/img48/null-fdm-instruments.png Most of the instruments are working, but the rate-of-turn indicator and the Nav 1 CDI/GS needles are frozen. You can see from the property browser that the Nav receiver is properly tuned up and is trying to drive the needles. This is observed during playback using the null FDM. The same sort of frozen instruments are observed using the UFO FDM. The mystery gets deeper because I also observed that clicking on the OBS setting knob does successfully rotate the OBS card on Nav 1. I have debugged this as far as I can. I'm stuck. I don't have any good hypotheses as to why some instruments are working while some parts of other instruments are not working. Well, The Null-FDM does what is say, nothing. It's expected that an external application fill in the gaps. I did once create a support FDM for ACMS (black-box) data but I don't think it touches anything but position and velocity data. I guess that to get the cockpit fully working in playback a new support FDM has to be written that fills in the missing gaps. Erik -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] null-FDM and UFO-FDM instrument outages
On 02/20/2010 02:23 AM, Erik Hofman wrote: Well, The Null-FDM does what is say, nothing. It's expected that an external application fill in the gaps. I did once create a support FDM for ACMS (black-box) data but I don't think it touches anything but position and velocity data. I guess that to get the cockpit fully working in playback a new support FDM has to be written that fills in the missing gaps. That's all true. For instance, the playback.xml protocol should not bother to replay the state of the starter, since the process whereby the starter starts the engine is under control of the FDM, and the null FDM doesn't do this at all. It works better for the protocol to just replay the engine RPM. Similarly if you want the rate-of-turn needle to work, the protocol should replay /instrumentation/turn-indicator/indicated-turn-rate However ... that doesn't solve the mystery. I have already made those changes to my copy of playback.xml, and things are still messed up: -- The rate-of-turn needle flickers between correct (replayed) rate and zero. (This may be related to the longstanding flicker/shudder problems with external views during playback.) -- Replaying /engines/engine[0]/rpm has no effect ... even though setting the same property via the property browser has the expected effect: causing the engine to spin at the specified rate. -- As previously mentioned, the LOC and GS needles are frozen, even though the properties used by the animations in vor.xml are being set. It's one thing to say more properties need to be set ... but when the properties are being set and the instruments still don't work, I have no idea how to get them to work. If the FDM should do more ... what more should it do? -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] null-FDM and UFO-FDM instrument outages
On 02/20/2010 07:01 AM, I wrote: -- Replaying /engines/engine[0]/rpm has no effect ... even though setting the same property via the property browser has the expected effect: causing the engine to spin at the specified rate. ... It's one thing to say more properties need to be set ... but when the properties are being set and the instruments still don't work, I have no idea how to get them to work. If the FDM should do more ... what more should it do? Progress report: I found out one important thing that the FDM (or the playback mechanism) should be doing: calling listeners! In particular, I attached a listener to /engines/engine[0]/rpm. *) Setting this property via the property browser causes the listener to be called, and everything is hunky-dory. *) During ordinary non-playback JSBSim operation, the listener apparently gets called after every FDM iteration, as it should. *) During playback, the listener does not get called by the FDM. This needs to get fixed. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] null-FDM and UFO-FDM instrument outages
Hi John, John Denker wrote: I ran into the same problem with using generic instruments when developing the bluebird over 2 years ago. Some instruments rely on properties that are only updated by the FDM, and the ufo doesn't. That's valuable information. Can you be more specific? Can you be more specific? What nasal are we talking about? Which instruments? Sorry, I was attempting to provide hints, rather than the answer to everything. Looking at Aircraft/bluebird/Instruments-3d/alt-2/alt2-3d-b.xml and Aircraft/Instruments-3d/alt-2/alt2-3d.xml Comparing the two reveals a dependance on /systems/electrical/outputs/instrument-lights in the generic version, which I thought wasn't powered without the engine running. Maybe this has changed a little in 2 years. Maybe it is running on battery, I see a small drain... 2nd. diff Aircraft/bluebird/Instruments-3d/ai/ai-ufo.xml Aircraft/Instruments-3d/ai/ai.xml includes a reference to /instrumentation/attitude-indicator/indicated-pitch-deg which is not updated by ufo FDM. 3rd: Aircraft/bluebird/Nasal/bluebird.nas line# 2361 says position/altitude-agl needs updating, which upon a second look, appears to no longer be true, as of FG 1.0 it does update. Looking at your screenshot, I see the instruments that would be frozen or Off with --fdm=ufo are actually showing good information, so that must be from a replay? It doesn't look as bad as I expected. That's an interesting hypothesis. However, I see nothing in vor.xml to support this hypothesis. I was not looking at vor. There are lots of aircraft with no electrical bus. I would consider it a bug in the instrument for it to demand an electrical bus and not implement a reasonable default. This should be easy to fix. Which instruments are you referring to? Just the one I mentioned. I thought it would be an indicator that other systems may depend on the same or similar workings to function. Since it appears the ufo now has a battery, but no way to recharge, it is not the real problem you are looking for. Stewart -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] null-FDM and UFO-FDM instrument outages
Here's a mystery for you: Please take a look at http://www.av8n.com/fly/fgfs/img48/null-fdm-instruments.png Most of the instruments are working, but the rate-of-turn indicator and the Nav 1 CDI/GS needles are frozen. You can see from the property browser that the Nav receiver is properly tuned up and is trying to drive the needles. This is observed during playback using the null FDM. The same sort of frozen instruments are observed using the UFO FDM. The mystery gets deeper because I also observed that clicking on the OBS setting knob does successfully rotate the OBS card on Nav 1. I have debugged this as far as I can. I'm stuck. I don't have any good hypotheses as to why some instruments are working while some parts of other instruments are not working. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] null-FDM and UFO-FDM instrument outages
Hi John, I ran into the same problem with using generic instruments when developing the bluebird over 2 years ago. Some instruments rely on properties that are only updated by the FDM, and the ufo doesn't. So I wrote my own nasal to fill in those gaps, and/or I made my own instruments by modifying a line or two from the generic version. In another case, the instrument(s) look to the property systems/electrical/outputs and so does not work because the ufo does not have an electrical bus. :) Another property the ufo fdm does not update is altitude-agl etc. etc. So you can't change the FDM and expect everything that rely on a specific FDM, to keep working. Stewart John Denker wrote: Here's a mystery for you: Please take a look at http://www.av8n.com/fly/fgfs/img48/null-fdm-instruments.png Most of the instruments are working, but the rate-of-turn indicator and the Nav 1 CDI/GS needles are frozen. You can see from the property browser that the Nav receiver is properly tuned up and is trying to drive the needles. This is observed during playback using the null FDM. The same sort of frozen instruments are observed using the UFO FDM. I have debugged this as far as I can. I'm stuck. I don't have any good hypotheses as to why some instruments are working while some parts of other instruments are not working. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] null-FDM and UFO-FDM instrument outages
On 02/19/2010 05:59 PM, S Andreason wrote: I ran into the same problem with using generic instruments when developing the bluebird over 2 years ago. Some instruments rely on properties that are only updated by the FDM, and the ufo doesn't. That's valuable information. Can you be more specific? So I wrote my own nasal to fill in those gaps, and/or I made my own instruments by modifying a line or two from the generic version. Can you be more specific? What nasal are we talking about? Which instruments? In another case, the instrument(s) look to the property systems/electrical/outputs and so does not work because the ufo does not have an electrical bus. :) That's an interesting hypothesis. However, I see nothing in vor.xml to support this hypothesis. There are lots of aircraft with no electrical bus. I would consider it a bug in the instrument for it to demand an electrical bus and not implement a reasonable default. This should be easy to fix. Which instruments are you referring to? Another property the ufo fdm does not update is altitude-agl etc. etc. Can you be more specific? I'm pretty sure the LOC and GS needles don't depend on altitude-agl. As far as I can tell, the only variables the OBS head depends on are being set. That's why I put up a screen shot including a property browser window. So you can't change the FDM and expect everything that rely on a specific FDM, to keep working. I'm pretty sure I don't expect that. See my note on the subject from a couple of hours ago. However, given that the null fdm is documented to work (according to README.io and according to getstart.pdf) I think we should discuss it when it doesn't work, especially given that it comes so very close to working. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
