Re: [Flightgear-devel] generic input device support: wrong button event names in Linux
Hi Brant,
Though your problem should be looked and fixed, it is different from
this one since the generic input device support is not implemented on
windows yet.
Plus, it does nothing on any platform unless you make a configuration
file for your device under $FG_ROOT/input/event//product>.xml.
Thus this problem doesn't affect the existing joystick feature.
Btw, is any one kindly enough to implement this feature on windows?
Tat
On 2009/09/15, at 8:30, Brant G wrote:
Indeed. I have a X52 joystick and it's very confusing to configure
in the joystick .xml file. When I updated to CVS recently, the hats
buttons don't work properly in windows. This should be looked at and
fixed.
On Mon, Sep 14, 2009 at 6:45 PM, Tatsuhiro Nishioka > wrote:
Hi,
I've been testing X52 joystick with FGLinuxEventInput.cxx on liunx
and found that button event names for joysticks/gamepad are very
suspicious, and we need to consider some other means of naming
button events.
The problem is that a joystick (, mouse or gamepad) button can have
wrong event name if a device has more than 16 buttons.
This is because Linux hid driver (drivers/hid/hid-input.c) assumes
that a device has 16 buttons at most.
e.g. If a joystick has more than 16 buttons, a button event name for
button-#16 or higher are mistakenly assigned to ones in game pads,
digitizer, or others.
This is the excerpt from hid-input.c ( hidinput_configure_usage)
that shows how Linux driver converts HID usage to a code of hid
event written to /dev/input/js*
case HID_UP_BUTTON:
code = ((usage->hid - 1) & 0xf); // Note:
assuming #buttons <= 16.
switch (field->application) {
case HID_GD_MOUSE:
case HID_GD_POINTER: code += 0x110;
break;
case HID_GD_JOYSTICK: code += 0x120;
break;
case HID_GD_GAMEPAD: code += 0x130;
break;
default:
switch (field->physical) {
case HID_GD_MOUSE:
case
HID_GD_POINTER: code += 0x110; break;
case
HID_GD_JOYSTICK: code += 0x120; break;
case
HID_GD_GAMEPAD: code += 0x130; break;
default: code += 0x100;
}
}
map_key(code);
break;
As a matter of fact, event names for X52 buttons are assigned as
follows in FGLinuxEventInput.cxx:
#00 button-trigger: type=1, code=288 (trigger)
#01 button-thumb: type=1, code=289 (FIRE button on stick)
#02 button-thumb2: type=1, code=290 (A button on stick)
#03 button-top: type=1, code=291 (B button on stick)
#04 button-top2:type=1, code=292 (C button on stick)
#05 button-pinkie: type=1, code=293 (pinkie button)
#06 button-base:type=1, code=294 (D button on throttle)
#07 button-base2: type=1, code=295 (E button on throttle)
#08 button-base3: type=1, code=296 (T1)
#09 button-base4: type=1, code=297 (T2)
#10 button-base5: type=1, code=298 (T3)
#11 button-base6: type=1, code=299 (T4)
#12 button-300: type=1, code=300 (T5)
#13 button-301: type=1, code=301 (T6)
#14 button-302: type=1, code=302 (strong press of trigger)
#15 button-dead:type=1, code=303 (top hat up)
// buttons below are mistakenly assigned to GamePad buttons
#16 button-a: type=1, code=304 (top hat right)
#17 button-b: type=1, code=305 (top hat down)
#18 button-c: type=1, code=306 (top hat left)
#19 button-x: type=1, code=307 (hat up on throttle)
#20 button-y: type=1, code=308 (hat right on throttle)
#21 button-z: type=1, code=309 (hat down on throttle)
#22 button-tl: type=1, code=310 (hat left on throttle)
#23 button-tr: type=1, code=311 (mode1 on stick)
#24 button-tl2: type=1, code=312 (mode2 on stick)
#25 button-tr2: type=1, code=313 (mode3 on stick)
#26 button-select: type=1, code=314 (Function button on
throttle)
#27 button-start: type=1, code=315 (Start button on
throttle)
#28 button-mode:type=1, code=316 (RESET button on
throttle)
#29 button-thumbl: type=1, code=317 (i button on throttle)
#30 button-thumbr: type=1, code=318 (mouse button on
throttle)
#31 button-319: type=1, code=319 (wheel button on
throttle) // undefined in input.h
// buttons below are mistakenly assigned to Digitizer buttons
#32 button-pen
Re: [Flightgear-devel] generic input device support: wrong button event names in Linux
Indeed. I have a X52 joystick and it's very confusing to configure in the
joystick .xml file. When I updated to CVS recently, the hats buttons don't
work properly in windows. This should be looked at and fixed.
On Mon, Sep 14, 2009 at 6:45 PM, Tatsuhiro Nishioka
wrote:
> Hi,
>
> I've been testing X52 joystick with FGLinuxEventInput.cxx on liunx and
> found that button event names for joysticks/gamepad are very suspicious, and
> we need to consider some other means of naming button events.
>
> The problem is that a joystick (, mouse or gamepad) button can have wrong
> event name if a device has more than 16 buttons.
> This is because Linux hid driver (drivers/hid/hid-input.c) assumes that a
> device has 16 buttons at most.
> e.g. If a joystick has more than 16 buttons, a button event name for
> button-#16 or higher are mistakenly assigned to ones in game pads,
> digitizer, or others.
> This is the excerpt from hid-input.c ( hidinput_configure_usage) that shows
> how Linux driver converts HID usage to a code of hid event written to
> /dev/input/js*
>
> case HID_UP_BUTTON:
> code = ((usage->hid - 1) & 0xf); // Note: assuming
> #buttons <= 16.
> switch (field->application) {
> case HID_GD_MOUSE:
> case HID_GD_POINTER: code += 0x110; break;
> case HID_GD_JOYSTICK: code += 0x120; break;
> case HID_GD_GAMEPAD: code += 0x130; break;
> default:
> switch (field->physical) {
> case HID_GD_MOUSE:
> case HID_GD_POINTER: code
> += 0x110; break;
> case HID_GD_JOYSTICK: code
> += 0x120; break;
> case HID_GD_GAMEPAD: code
> += 0x130; break;
> default: code
> += 0x100;
> }
> }
> map_key(code);
> break;
>
>
> As a matter of fact, event names for X52 buttons are assigned as follows in
> FGLinuxEventInput.cxx:
>
> #00 button-trigger: type=1, code=288 (trigger)
> #01 button-thumb: type=1, code=289 (FIRE button on stick)
> #02 button-thumb2: type=1, code=290 (A button on stick)
> #03 button-top: type=1, code=291 (B button on stick)
> #04 button-top2:type=1, code=292 (C button on stick)
> #05 button-pinkie: type=1, code=293 (pinkie button)
> #06 button-base:type=1, code=294 (D button on throttle)
> #07 button-base2: type=1, code=295 (E button on throttle)
> #08 button-base3: type=1, code=296 (T1)
> #09 button-base4: type=1, code=297 (T2)
> #10 button-base5: type=1, code=298 (T3)
> #11 button-base6: type=1, code=299 (T4)
> #12 button-300: type=1, code=300 (T5)
> #13 button-301: type=1, code=301 (T6)
> #14 button-302: type=1, code=302 (strong press of trigger)
> #15 button-dead:type=1, code=303 (top hat up)
>
> // buttons below are mistakenly assigned to GamePad buttons
> #16 button-a: type=1, code=304 (top hat right)
> #17 button-b: type=1, code=305 (top hat down)
> #18 button-c: type=1, code=306 (top hat left)
> #19 button-x: type=1, code=307 (hat up on throttle)
> #20 button-y: type=1, code=308 (hat right on throttle)
> #21 button-z: type=1, code=309 (hat down on throttle)
> #22 button-tl: type=1, code=310 (hat left on throttle)
> #23 button-tr: type=1, code=311 (mode1 on stick)
> #24 button-tl2: type=1, code=312 (mode2 on stick)
> #25 button-tr2: type=1, code=313 (mode3 on stick)
> #26 button-select: type=1, code=314 (Function button on throttle)
> #27 button-start: type=1, code=315 (Start button on throttle)
> #28 button-mode:type=1, code=316 (RESET button on throttle)
> #29 button-thumbl: type=1, code=317 (i button on throttle)
> #30 button-thumbr: type=1, code=318 (mouse button on throttle)
> #31 button-319: type=1, code=319 (wheel button on throttle) //
> undefined in input.h
>
> // buttons below are mistakenly assigned to Digitizer buttons
> #32 button-pen: type=1, code=320 (wheel down on throttle)
> #33 button-rubber: type=1, code=321 (wheel up on throttle)
>
> This shows that button #16 or higher have wrong event names that are not
> compatible with Mac or Windows.
> # button-dead for top-hat up button is also weird.
> I don't know why linux driver assumes the button number is less than 16,
> but this is a big problem.
>
> I gu
[Flightgear-devel] generic input device support: wrong button event names in Linux
Hi,
I've been testing X52 joystick with FGLinuxEventInput.cxx on liunx and found
that button event names for joysticks/gamepad are very suspicious, and we need
to consider some other means of naming button events.
The problem is that a joystick (, mouse or gamepad) button can have wrong event
name if a device has more than 16 buttons.
This is because Linux hid driver (drivers/hid/hid-input.c) assumes that a
device has 16 buttons at most.
e.g. If a joystick has more than 16 buttons, a button event name for button-#16
or higher are mistakenly assigned to ones in game pads, digitizer, or others.
This is the excerpt from hid-input.c ( hidinput_configure_usage) that shows how
Linux driver converts HID usage to a code of hid event written to /dev/input/js*
case HID_UP_BUTTON:
code = ((usage->hid - 1) & 0xf); // Note: assuming
#buttons <= 16.
switch (field->application) {
case HID_GD_MOUSE:
case HID_GD_POINTER: code += 0x110; break;
case HID_GD_JOYSTICK: code += 0x120; break;
case HID_GD_GAMEPAD: code += 0x130; break;
default:
switch (field->physical) {
case HID_GD_MOUSE:
case HID_GD_POINTER: code +=
0x110; break;
case HID_GD_JOYSTICK: code +=
0x120; break;
case HID_GD_GAMEPAD: code +=
0x130; break;
default: code +=
0x100;
}
}
map_key(code);
break;
As a matter of fact, event names for X52 buttons are assigned as follows in
FGLinuxEventInput.cxx:
#00 button-trigger: type=1, code=288 (trigger)
#01 button-thumb: type=1, code=289 (FIRE button on stick)
#02 button-thumb2: type=1, code=290 (A button on stick)
#03 button-top: type=1, code=291 (B button on stick)
#04 button-top2:type=1, code=292 (C button on stick)
#05 button-pinkie: type=1, code=293 (pinkie button)
#06 button-base:type=1, code=294 (D button on throttle)
#07 button-base2: type=1, code=295 (E button on throttle)
#08 button-base3: type=1, code=296 (T1)
#09 button-base4: type=1, code=297 (T2)
#10 button-base5: type=1, code=298 (T3)
#11 button-base6: type=1, code=299 (T4)
#12 button-300: type=1, code=300 (T5)
#13 button-301: type=1, code=301 (T6)
#14 button-302: type=1, code=302 (strong press of trigger)
#15 button-dead:type=1, code=303 (top hat up)
// buttons below are mistakenly assigned to GamePad buttons
#16 button-a: type=1, code=304 (top hat right)
#17 button-b: type=1, code=305 (top hat down)
#18 button-c: type=1, code=306 (top hat left)
#19 button-x: type=1, code=307 (hat up on throttle)
#20 button-y: type=1, code=308 (hat right on throttle)
#21 button-z: type=1, code=309 (hat down on throttle)
#22 button-tl: type=1, code=310 (hat left on throttle)
#23 button-tr: type=1, code=311 (mode1 on stick)
#24 button-tl2: type=1, code=312 (mode2 on stick)
#25 button-tr2: type=1, code=313 (mode3 on stick)
#26 button-select: type=1, code=314 (Function button on throttle)
#27 button-start: type=1, code=315 (Start button on throttle)
#28 button-mode:type=1, code=316 (RESET button on throttle)
#29 button-thumbl: type=1, code=317 (i button on throttle)
#30 button-thumbr: type=1, code=318 (mouse button on throttle)
#31 button-319: type=1, code=319 (wheel button on throttle) //
undefined in input.h
// buttons below are mistakenly assigned to Digitizer buttons
#32 button-pen: type=1, code=320 (wheel down on throttle)
#33 button-rubber: type=1, code=321 (wheel up on throttle)
This shows that button #16 or higher have wrong event names that are not
compatible with Mac or Windows.
# button-dead for top-hat up button is also weird.
I don't know why linux driver assumes the button number is less than 16, but
this is a big problem.
I guess it is safer to use button-0, button-1, ... button-N for button event
names so the names stays the same on different OSs.
maybe we need to pull out some info using ioctl to find the first hid event
code for a given device (e.g. 228 for joystick).
Best,
Tat
--
Come build with us! The BlackBerry® Developer Conference in SF, C
Re: [Flightgear-devel] Glideslope bugs/improvements
On 14 Sep 2009, at 16:54, Torsten Dreyer wrote: > But I can provide a fix for a potential division by zero bug: Some > stations > don't have a range configured and bomb here: > double range_exceed_norm = loc_dist/effective_range_m; > Thanks Torsten, I fixed this slightly differently, but a good catch. I wonder if I should also warn about such navids at startup, so we can get the nav.dat entries fixed? Regards, James -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Glideslope bugs/improvements
On 14 Sep 2009, at 18:44, James Turner wrote: >> Specifically, I recommend introducing dme_inrange >> and gs_inrange properties. The concept of "dme in >> range" and "gs in range" are meaningful to real >> world pilots. > The gs-in-range prop is in CVS now. Next up is integrating your navradio-DME patch. > >> If you want to add a low-pass filter, that would >> be a Good Thing. It is going to be needed anyway, >> if/when we try to construct a decent model of >> fringe-area behavior. > I've done some testing, and all the weirdness seems to occur in cases where the ILS for both ends is on the same frequency. At EDDM, where the runway ends do NOT share an ILS frequency, I see an extremely stable GS response until I'm practically level with the GS transmitter (which is what I'd expect / hope). At EGPH, at about 200ft above the runway, the navradio suddenly picks the 'other' end, with, as they say, hilarious consequences. Actually the GS angle jumps from 3.0 degrees to 177 degrees, instantaneously. I suspect penaltyForNav is broken, probably by me - so that's where I shall look next. Torsten, it would be good if you could confirm my analysis, by trying some approaches in runways where the ends do not share an ILS frequency, and report on what you see. >> >> signal all the way to the runway, I'd say we have >> _two_ bugs (unrealistically good GS signal, and >> unrealistic autoland implementation). When the code is not being screwed around by conflicting GS transmitters, the behaviour is stable down to pretty much the runway surface. I think that's 'good', for the moment; if in the future someone wants to add code to make the GS less perfect, that's fine with me (possible controlled by a /sim/realism flag) Regards, James -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Glideslope bugs/improvements
On 14 Sep 2009, at 18:51, syd adams wrote: > Another thing I've always wanted in the nav system is an RNAV radial > and RNAV distance > property, and the nav calculations done from this phantom station. > Dont know how doable that is since I dont feel qualified enough to > tackle that. I'm lost by this - could you explain what RNAV means in this context? (Apologies if I'm missing something obvious, it's been a long weekend, several hours of which was spent upside down) > And James , no , I have no objections to your updates , its nice to > see these issues being tackled. > The Aerostar problem was just an off the top of my head guess , > before any real testing. Thanks Syd! As always, it's a pleasure to work with your aircraft, the attention to detail is really fantastic when it comes to testing more subtle features of the C++ code. Regards, James -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] overlay problem
Hello, i try to overlay a HUD over my flightgear application. The HUD is generated by a other computer and I am grabbing it with a framegrabber card. The backgroundcolor of the HUD which I display in a window (windows) I set transparent so that the background is the output of my flightgear application. Now I have the problem that the video output jitters very much (I think because flightgear is programmed with openGL). Has someone a tip for me how I can solve this problem. Thanks for your help. Regards, Julian -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Glideslope bugs/improvements
I'll change all of my AP glideslope behaviors , the hacks are usually because I haven't found any documentation , so I go with a rough guess. I have come across information that states that on some systems , the glideslope will not capture until the localizer has been. I also use the "has-gs" when APPR mode is armed to decide if it should revert to VOR mode. So any tips on more realistic behavior are welcome. Another thing I've always wanted in the nav system is an RNAV radial and RNAV distance property, and the nav calculations done from this phantom station. Dont know how doable that is since I dont feel qualified enough to tackle that. And James , no , I have no objections to your updates , its nice to see these issues being tackled. The Aerostar problem was just an off the top of my head guess , before any real testing. Cheers -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Glideslope bugs/improvements
On 14 Sep 2009, at 15:44, John Denker wrote: > Specifically, I recommend introducing dme_inrange > and gs_inrange properties. The concept of "dme in > range" and "gs in range" are meaningful to real > world pilots. Yep, seems reasonable to me, I was already looking at the navradio DME patch. > Ninety percent of this erratic behavior is realistic! > > The other ten percent is a small problem, explained > by the fact that real-world GS receivers incorporate > a rather heavy low-pass filter ... so if you fly > through a region of rapidly-changing signals they > mostly average out ... and navradio.cxx has not > heretofore implemented such a filter. What's your confidence factor on the 90:10 split? I've never flow an ILS approach in my life, but I find it hard to believe the real world behaviour is as poor (close to the transmitter) as ours is now. > If you want to add a low-pass filter, that would > be a Good Thing. It is going to be needed anyway, > if/when we try to construct a decent model of > fringe-area behavior. Happy to do so - I'll experiment with this and post back here. If you wish to experiment with it yourself, and suggest some filter parameters that seem appropriate, I would be most grateful - otherwise I'll make some guesses, and we can tune later. > I guarantee you real-world autoland systems do not > try to follow the GS signal all the way to the > runway. Among other things, they rely on a fancy > radar altimeter to judge height during the flare. > > If existing aircraft have been following the GS > signal all the way to the runway, I'd say we have > _two_ bugs (unrealistically good GS signal, and > unrealistic autoland implementation). Yep, fair point. I don't think any aircraft we currently have claim an actual auto-land (as modelled) Cheers, James -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Using ogr-decode and shape-decode
Hi all. I've got a bunch of shapefile data for the island of Newfoundland that I'm intending to use in Terragear. It's called Canvec data, and I think I'm going to need to use ogr-decode on it to get it into WGS84 format. Provided I'm understanding this correctly, that is. Everything in the data set is in the .shp format, but unlike the VMAP0 that I've used previously, it's devided into many geographical subsections. These subsections are organized using the National Topographic System. So I think I need to re-organize them before I use shape-decode. Is that correct? I'm assuming that this means I need to run ogr-decode on them. How do I use ogr-decode to convert a large number of road shapefiles (for example) to the shapefile that shape-decode is expecting to see? Will the final result be one shapefile for all the roadways in Newfoundland, or will that combination not happen until after I've run shape-decode? Almost all the references I've found on doing this assume that I'll use VMAP0 data (which I have before), then say that you can also try other data sets, but give almost no information on how to do that. Any guidance on how I need to go about doing all this would be greatly appreciated. I think it's probably all fairly strait forward, but I sure can't find any good instructions! -cullam __ Ask a question on any topic and get answers from real people. Go to Yahoo! Answers and share what you know at http://ca.answers.yahoo.com -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Glideslope bugs/improvements
> Two (unrelated) glideslope things: > > 1) I tested making the has-gs property be based upon the GS range > check (leaving aside any discussion of how GS reception range should > be calculated). This is good, because existing panels generally use > has-gs as a 'valid GS signal being received', to un-park / show the > needle/pointer. > > The catch is, most of the flightdirector / autopilot scripts have been > written assuming that when approach mode is *armed*, has-gs is already > true. I.e they don't arm GS holding, if no valid GS is being received > at that point. It feels like this is a genuine problem - depending on > how far out the localiser is captured, and given that you could be > intercepting the localiser from an angle, I *guess* the real-life > equipment wouldn't assume a valid GS signal was being received at that > time. > > What do the real world pilots say? The 'fix' would be to remove the > 'has-gs' flag checks from the various autopilot/flight-director Nasal > scripts, which I'm not exactly thrilled at the prospect of - but it > would make the GS needle/pointer behaviour more correct 'for free'. The only autopilot manual I have at hand (Century III) says: "The Glideslope Deviation Indicator must be deflected upward for at least 20 seconds before the logic circuit of the Glideslope Coupler is armed. [..] A 60% full scale deflection for 20 seconds will always accomplish arming." So, for the A/P, there is no such thing like has-gs, the autopilot only needs an upward deflection. > > 2) Torsten noted the GS signal behaves very erratically below a > certain elevation (above the landing threshold) - on the order of > 100-150ft. I'm going to do some testing to establish the cause (aside > from the dreaded penaltyForNav / double-ended-ILS-runway mess), but I > have a suspicion the false lobes might be a factor. Would it be > reasonable to disable the false lobes below a certain distance to the > GS transmitter (at a guess, something like 1000m?). I know it's an > unpleasant rule to add, but the current GS behaviour makes CAT-III or > auto-land operation impossible, I think. > > I still need to verify that the false lobes are the cause, I don't > necessarily see why they should be. The mentioned behaviour is best visible close to the station. If you move further out, the movements of the gs-needle get slower and slower. If you fly level and have your NAV tuned to an ILS station, you catch all the side lobes - one after another - which causes your GS needle project the sawtooth function that generates the lobes. I think the model for the side lobes is to simple. Just generating them all with the same strength at a 6 degrees period is not enough. However I am not in the position to complain, because I don't have a better model at hand ;-) But I can provide a fix for a potential division by zero bug: Some stations don't have a range configured and bomb here: double range_exceed_norm = loc_dist/effective_range_m; Here is a fix for that, setting a range of 25 Index: navradio.cxx === RCS file: /var/cvs/FlightGear-0.9/source/src/Instrumentation/navradio.cxx,v retrieving revision 1.44 diff -u -p -r1.44 navradio.cxx --- navradio.cxx11 Sep 2009 23:05:23 - 1.44 +++ navradio.cxx14 Sep 2009 15:00:44 - @@ -459,6 +459,9 @@ void FGNavRadio::updateReceiver(double d = adjustNavRange( nav_elev, pos.getElevationM(), _navaid->get_range() ); } + if( effective_range < SGLimitsd::min() ) +effective_range = FG_NAV_DEFAULT_RANGE; + double effective_range_m = effective_range * SG_NM_TO_METER; // Torsten -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Glideslope bugs/improvements
On Mon, 2009-09-14 at 10:38 +0100, James Turner wrote: > Two (unrelated) glideslope things: > > 1) I tested making the has-gs property be based upon the GS range > check (leaving aside any discussion of how GS reception range should > be calculated). This is good, because existing panels generally use > has-gs as a 'valid GS signal being received', to un-park / show the > needle/pointer. > > The catch is, most of the flightdirector / autopilot scripts have been > written assuming that when approach mode is *armed*, has-gs is already > true. I.e they don't arm GS holding, if no valid GS is being received > at that point. It feels like this is a genuine problem - depending on > how far out the localiser is captured, and given that you could be > intercepting the localiser from an angle, I *guess* the real-life > equipment wouldn't assume a valid GS signal was being received at that > time. > > What do the real world pilots say? The 'fix' would be to remove the > 'has-gs' flag checks from the various autopilot/flight-director Nasal > scripts, which I'm not exactly thrilled at the prospect of - but it > would make the GS needle/pointer behaviour more correct 'for free'. I have always assumed and used the "has-gs" to identify a valid ILS frequency instead of a VOR frequency. This flag is needed so every instrument doesn't have to implement the rather arcane rules for determining whether or not a tuned frequency is ILS or VOR. "The localizer is a VHF radio transmitter and antenna system using the same general range as VOR transmitters (between 108.10 MHz and 111.95 MHz). Localizer frequencies, however, are only on odd-tenths, with 50 kHz spacing between each frequency." http://www.allstar.fiu.edu/aero/ILS.htm Or the chart here: http://en.wikipedia.org/wiki/Instrument_landing_system#Frequency_list Thanks, Ron -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Glideslope bugs/improvements
On 09/14/09 02:38, James Turner wrote: > Two (unrelated) glideslope things: > > 1) I tested making the has-gs property be based upon the GS range > check (leaving aside any discussion of how GS reception range should > be calculated). This is good, because existing panels generally use > has-gs as a 'valid GS signal being received', to un-park / show the > needle/pointer. > > The catch is, most of the flightdirector / autopilot scripts have been > written assuming that when approach mode is *armed*, has-gs is already > true. I.e they don't arm GS holding, if no valid GS is being received > at that point. It feels like this is a genuine problem - depending on > how far out the localiser is captured, and given that you could be > intercepting the localiser from an angle, I *guess* the real-life > equipment wouldn't assume a valid GS signal was being received at that > time. > > What do the real world pilots say? The 'fix' would be to remove the > 'has-gs' flag checks from the various autopilot/flight-director Nasal > scripts, which I'm not exactly thrilled at the prospect of - but it > would make the GS needle/pointer behaviour more correct 'for free'. Changing all the instruments overnight is indeed an unthrilling prospect. Fortunately there are better ways of fixing the problem. There is nothing real-world pilots can say about the has_gs property. Nothing good, anyway. For many many years, this property has been set according to whether the ground station had a GS transmitter installed, without regard to range, and without regard to the serviceability of the ground station or of the onboard GS receiver. This behavior was not, AFAICT, documented anywhere, except insofar as you could figure out the behavior by reading the code, which some people call crockumentation. This behavior is wildly unrealistic. In the real world, there is no way for onboard instrumentation to know whether the ground station has GS equipment installed, except/unless/until it receives a valid signal. Over the years, to overcome the lack of valid range information about DME and GS signals, instrument designers have been forced to assume that the range of the DME part of a localizer/DME was equal to the localizer range, and similarly to assume that the range of the GS, if installed, was equal to the localizer range. Both assumptions are wildly unrealistic, as has been pointed out several times over the years. I don't recommend changing the behavior of the has_gs property to include range or validity information. That would be a major departure from the crockumented behavior, and would break lots of things. The time-honored way out of situations like this is to leave the old property alone, and introduce a new property with good behavior and good documentation. Specifically, I recommend introducing dme_inrange and gs_inrange properties. The concept of "dme in range" and "gs in range" are meaningful to real world pilots. The concept of "has_gs" is not part of real world pilot vocabulary, and never will be. By bringing up the new properties without disrupting the old property, we avoid the need for a "flag day". Instruments that want to make use of the new inrange information can be taught to do so. They are taught one by one, on a convenient schedule, and in the meantime everything continues to work, no worse than before. The code I wrote in 2007 and rebased in January 2009 to this approach. > 2) Torsten noted the GS signal behaves very erratically below a > certain elevation (above the landing threshold) - on the order of > 100-150ft. I'm going to do some testing to establish the cause (aside > from the dreaded penaltyForNav / double-ended-ILS-runway mess), but I > have a suspicion the false lobes might be a factor. Would it be > reasonable to disable the false lobes below a certain distance to the > GS transmitter (at a guess, something like 1000m?). I know it's an > unpleasant rule to add, but the current GS behaviour makes CAT-III or > auto-land operation impossible, I think. > > I still need to verify that the false lobes are the cause, I don't > necessarily see why they should be. Ninety percent of this erratic behavior is realistic! The other ten percent is a small problem, explained by the fact that real-world GS receivers incorporate a rather heavy low-pass filter ... so if you fly through a region of rapidly-changing signals they mostly average out ... and navradio.cxx has not heretofore implemented such a filter. If you want to add a low-pass filter, that would be a Good Thing. It is going to be needed anyway, if/when we try to construct a decent model of fringe-area behavior. I guarantee you real-world autoland systems do not try to follow the GS signal all the way to the runway. Among other things, they rely on a fancy radar altimeter to judge height during the flare. If existing aircraft have been following the GS signal all the way to the run
[Flightgear-devel] Offer for a MPServer
Hello, few days ago I have explore FlightGear and I have install a FGMS on my server. Now I have seen, that the MPServer network has a very few selection for servers that are running. So I offer the server for the MPServer network. If you want one server more in your network that stands in Germany write me a message with the replay informations and I will start the server. For the DNS-Records I will write you the IP in a extra e-mail. (I don't want that every one can red it.) So if you want a message is enough. ;-) Daniel Vigano -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Glideslope bugs/improvements
Two (unrelated) glideslope things: 1) I tested making the has-gs property be based upon the GS range check (leaving aside any discussion of how GS reception range should be calculated). This is good, because existing panels generally use has-gs as a 'valid GS signal being received', to un-park / show the needle/pointer. The catch is, most of the flightdirector / autopilot scripts have been written assuming that when approach mode is *armed*, has-gs is already true. I.e they don't arm GS holding, if no valid GS is being received at that point. It feels like this is a genuine problem - depending on how far out the localiser is captured, and given that you could be intercepting the localiser from an angle, I *guess* the real-life equipment wouldn't assume a valid GS signal was being received at that time. What do the real world pilots say? The 'fix' would be to remove the 'has-gs' flag checks from the various autopilot/flight-director Nasal scripts, which I'm not exactly thrilled at the prospect of - but it would make the GS needle/pointer behaviour more correct 'for free'. 2) Torsten noted the GS signal behaves very erratically below a certain elevation (above the landing threshold) - on the order of 100-150ft. I'm going to do some testing to establish the cause (aside from the dreaded penaltyForNav / double-ended-ILS-runway mess), but I have a suspicion the false lobes might be a factor. Would it be reasonable to disable the false lobes below a certain distance to the GS transmitter (at a guess, something like 1000m?). I know it's an unpleasant rule to add, but the current GS behaviour makes CAT-III or auto-land operation impossible, I think. I still need to verify that the false lobes are the cause, I don't necessarily see why they should be. Regards, James -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Prime Meridian Crash
It doesnt happen on every aircraft. Eg Concorde works fine, whilst 787 Crashes. If you want me to test which aircraft do and dont crash then let me know. However an aircraft which does crash eg Bravo/777-200ER does it predictably and consistently. I also considered the positions of VOR's as well either east or west, but that seems to have no effect. pete James Turner wrote: > On 14 Sep 2009, at 00:23, Pete Morgan wrote: > > >> Flying the East to West eg from EGLC London City to EGLL Heathrow >> crashes in a similar fashion. >> > > That's weird, I flew from EGLL to EGLC just the other day, and it > worked fine. > > I'll try the route, and aircraft you suggested, in the next couple of > days - happy for others to test, though. > > Regards, > James > > > -- > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Prime Meridian Crash
On 14 Sep 2009, at 00:23, Pete Morgan wrote: > Flying the East to West eg from EGLC London City to EGLL Heathrow > crashes in a similar fashion. That's weird, I flew from EGLL to EGLC just the other day, and it worked fine. I'll try the route, and aircraft you suggested, in the next couple of days - happy for others to test, though. Regards, James -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
