Extend reception range of GS

[Hyde]

Currently GS valid signal is received at 10nm(actually 9.7nm).
This is critical for 3000ft approach.
I'm using 2500ft approach and capture at 7.9nm.

When you approach to low angle GS such as UUEE-07L/25R Sheremetyevo International Airport whose angle is 2.6deg, 2500ft is still critical.

And RJAA has three ILS antennas for 2500ft, 3500ft and 4500ft approach and we can not use 3500ft or 4500ft approach.

If we have a method to adjust reception range for each antenna then no problem. But we have only one reception range for all the ILS.
Don't you think we have to extend that reception range 2 or 3miles more?

[Hyde]

No one is interested in?

O.K. then I change locally.
I extented 3nm. Now I can do 3000ft approach with enough margin, even 3500ft is available.

adversaria: navradio.cxx
- gsInRange = (gsDist < (_gs->get_range() * SG_NM_TO_METER));
+ gsInRange = (gsDist < ((_gs->get_range() + 3) * SG_NM_TO_METER));

[Hyde]

https://www.youtube.com/watch?v=VykZ98Qa0Hw
See this video, exact time 2:58, they capture GS at 4830 feet. RJAA field elevation is 140feet so the distance is 14.4nm. DME says 14.9nm.
https://www.youtube.com/watch?v=jG8dzLhvKx0
And also see this video 1:10. GS captured at 3000 feet, DME says 14.7nm.

This requires to expand the range at least 15nm to simulate this situation.

[KL-666]

But we have only one reception range for all the ILS.

Does this mean that all ils in the fg world have the same range? If so, then maybe there is something else known of each individual ils, that can be used to multiply the reception distance dynamically.

i.e. If of all individual ils the slope-angle is known, then that could be used as multiplier factor. The greater the slope-angle, the longer the reception distance (or should it be the other way around?). Maybe the calculation can be as simple as: <global distance> * <slope angle>

Differential reception distances would make the ils more realistic i think.

Kind regards, Vincent

[ludomotico]

Afaik, there is no one reception range for all GS station. The range is defined in FG_ROOT/Navaids/nav.dat.gz, and you can modify this range individually for each station. In fact, this is hinted in the code quoted by Hyde:

_gs->get_range()

The information is there and I assumed it was used by flightgear. Are you really sure if you modify the station in nav.dat.gz the range is not modified?

[Hyde]

I think this value is a minimum guaranteed range.
If you don't receive the signal until this distance then you can find something wrong.
Usually if you want to keep this guarantee with bad weather such as rain or snow you need to have margin.
Why don't we have 50% of margin, then we don't need to tweak nav.dat.gz.

[Hooray]

I suggest to get in touch with Adrian, he should be able to provide the necessary pointers here.

[adrian]

I think this value is a minimum guaranteed range.
If you don't receive the signal until this distance then you can find something wrong.
Usually if you want to keep this guarantee with bad weather such as rain or snow you need to have margin.
Why don't we have 50% of margin, then we don't need to tweak nav.dat.gz.

You are correct. However, the current code does not simulate signal levels in a realistic fashion. The range is in fact represented as a cone with altitude steps. The cone limits are defined by whatever values you have in apt.dat. What would really happen in reality is the signal would gradually be attenuated with distance squared, also depending on the angle to the ground antenna, more or less. The receiver would start to get a signal way outside the publisged range, unless there are geographical obstructions, of course. What you now get in Flightgear is published ranges or nothing. That's the short explanation.

[Hyde]

What you now get in Flightgear is published ranges or nothing.

And this won't be fixed soon, right?
Then I suggest to increase range 50% until that method will be implemented.
That is much more real than current inplenetation.
What do you think? Any side effects?

[adrian]

I've written code which simulates realistic radio ranges, including obstruction by terrain. See http://wiki.flightgear.org/Radio_propagation
If you want, I can explain how to clone and compile my branch from Gitorious. Unfortunately, I haven't got the time to keep up with all changes in the main tree, so it's behind next by a few months.

[Hooray]

Actually, I think that merging this should be pretty straightforward, because the corresponding code in next hasn't really been touched in any significant way in months - so "git pull --rebase" should handle most things already.

[Hyde]

I've submitted merge request.

[Hyde]

@Torsten
I received the comment from Torsten that new navradio strategy is already implemented.
To enable it, set --prop:/instrumentaion/use-new-navradio=true.
New GS range of this is 18nm. Easily do the 4000ft approach. Thank you.
I've almost done to change to new navradio but still can't find the equivalent of these two propertys.

/instrumentation/nav/radials/target-auto-hdg-deg
/instrumentation/nav/gs-rate-of-climb

Should I calculate by my side or they can be prepared near future?

[Hyde]

@Torsten,
Could you kindly answer my question?

[ctesc356]

Hello,
excuse me I unearths an old topic.
I tried to start fg with "--prop: / instrumentation / use-new-navradio = true"
The ranges of GS are increased but there is some collateral damage:
ILS are not displayed at the MAP
The PA 777 is uncontrollable
Is there a solution?

On the other hand, changings in "navradio.cxx"

gsInRange = (gsDist < ((_gs->get_range() + 3) * SG_NM_TO_METER));

by Hyde was not adopted.
Why?