Discussion:
Dots, degrees and magic '5's
James Turner
2008-12-31 13:09:05 UTC
Permalink
(sorry for the long email, but please read if you are involved with
panel creation, or can shed light on nav-radios)

I have had an entertaining afternoon, and now morning, with the Mk-VIII.

Along the way, I believe I have discovered some genuine bugs in the
code, and some odd assumptions which explain various pieces of strange
behaviour. I'm pretty hopeful with a bit more attention, I can get all
the various modes working as intended, which would be nice.

However, I've hit one of those cases where the Mk-VIII is being
confused by other parts of the code, specifically navradio.cxx.

The Mk-VIII is trying to compute localiser and glideslope deviation in
'dots', and is being cofnused by a magic '5' multiplier at line 614 of
navradio.cxx - the needle deflection is not in degrees deviation from
the GS, but degrees * 5. There's comments indicating that no one
really knows this source of this term, and some grep-ing of data/
Aircraft reveals things like:

gs_needle = getprop("/instrumentation/nav/gs-needle-deflection");
if ( gs_needle > -2.5 and gs_needle < 2.5 ) {
# capture the glide slope if within 0.5 degrees by
switching
# to gs altitude mode. (2.5 = 0.5 * 5, FG has an odd
5x factor
# that came from some unknown place but it hard to
get rid of
# because so many instruments are build with this
converstion
# factor
altmode = "glide-slope";

Well, I've never been daunted by 'hard' :)

I'm going to add a 'gs-deviation-deg' property alongside the existing
deflection, so users who the true deviation in degrees don't need to
deal with this odd scaling. I will probably add a similar property for
the course error, so that users can also bypass the factor-of-4
scaling using for localiser deviation if they desire. (But as
discussed below, that scaling is less harmful, I think)

The next issue is mapping degrees to dots. Here I have to state
(again) that I am not a pilot. My impression is that the mapping from
degrees to dots is supposed to be standardised, i.e 1 dot deviation
implies the same degree deviation whether you're in a C172 or a
747-400. The MK-VIII cites this NTSB report:

http://www.ntsb.gov/Recs/letters/2000/A00_41_45.pdf

...as giving a value of 0.32 degrees GS deviation per dot. I'd love to
know if this is correct, and what the VOR/HSI deviation is (in degrees
per dot) (I believe the 'LOC is 4x the sensitivity of VOR' rule is
indeed correct, but again, please confirm or deny this).

Assuming we can agree the ratios, I will then add gs-deviation-dots
and cdi-deviation-dots properties to navradio, and hopefully remove
that source of problems going forwards.

Now, a final point: I'm testing this with the Bravo, as it happens.
The Primus 1000 has the usual 'two dots above and below a bar' GS
indicator, pretty much identical to what the Boeing and Airbus units
have, and presumably many others. The mapping in its instrument
animation is using a range of -10 to 10. Which, divided by the magic
factor-of-5, gives -2 to 2. ... which would be right ... for dots.
But of course, it's reading a deflection in degrees!

So, it seems like at least Syd may have been assuming the deflection
was in 'dots * 5' rather than 'degrees * 5' - I'd love Syd to confirm
or deny that. The upshot of this is that the GS indicator in Primus
is, **I think**, about 1/3rd as sensitive as it should be. However, I
could easily be wrong about this, so I'll wait for Syd to offer his
opinion.

Comments on any of the above are welcome.

Regards,
James


------------------------------------------------------------------------------
James Turner
2008-12-31 13:23:25 UTC
Permalink
Post by James Turner
...as giving a value of 0.32 degrees GS deviation per dot. I'd love to
know if this is correct, and what the VOR/HSI deviation is (in degrees
per dot) (I believe the 'LOC is 4x the sensitivity of VOR' rule is
indeed correct, but again, please confirm or deny this).
Assuming we can agree the ratios, I will then add gs-deviation-dots
and cdi-deviation-dots properties to navradio, and hopefully remove
that source of problems going forwards.
Addendum, this source:

http://www.pilotfriend.com/training/flight_training/fxd_wing/hsi.htm

Reckons 5 degrees per-dot for a VOR, 1.25 for a LOC (yay, the 4x
factor is sane) and 'about a quarter of a degree per dot' for a GS
indicator, so the 0.32 term is plausible.

It does also mention some alternative dot mappings when the HSI/CDI is
coupled to a GPS-style navigation source, but there's a whole set of
issues related to navradio's GPS-slaved-mode there, which I will think
about 'in the future'.

James


------------------------------------------------------------------------------
John Denker
2008-12-31 17:29:37 UTC
Permalink
Post by James Turner
Reckons 5 degrees per-dot for a VOR, 1.25 for a LOC (yay, the 4x
factor is sane) and 'about a quarter of a degree per dot' for a GS
indicator, so the 0.32 term is plausible.
Standard dogma in IFR training is that the VOR CDI indicates
two degrees per dot, while the LOC CDI indicates half a degree
per dot. These numbers are quite believable. Good practice
is to check them as part of the 30-day IFR receiver check.

Experience suggests that a better way to think about it is
in terms of _full scale_. The pilot sees ±10 degrees full
scale on a VOR and ±2.5 degrees full scale on a localizer.

That's because talking about "degrees per dot" doesn't work
too well for RNAV units, which display cross-track error with
dimensions of distance, not dimensions of angle. Again the
sensitivity is greater on approach than enroute.
http://www.avweb.com/news/system/183179-1.html

But even if we confine attention to VORs, the vast majority
of CDIs have ± 5 dots full scale (or a ring and four dots,
which comes to the same thing) ... so 10 degrees full scale
is equivalent to 2 degrees per dot:
www.psavionics.com/images/KI208hi.png
www.psavionics.com/images/ki209hi.gif
Loading Image...
Loading Image...
Loading Image...

And meanwhile some instruments VERY EXCEPTIONALLY have fewer dots
Loading Image...
which would mean MORE degrees per dot. I suspect there may
be some CDIs with 6 dots full scale, but I can't cite any
examples at the moment.

As to the "magic 5" fudge factor, I have no idea what purpose
that serves. It is *not* meant to create 10 volts full scale
or anything like that, because the industry standard is ±150
millivolts full scale.
http://www.seaerospace.com/lc/cart.php?target=productDetails&model=GNS-530&substring=011-00550-10



I'd be happy to consider alternatives to the "magic 5" :

One could make a case for
*) ±1.0 full scale, for obvious reasons, or
*) ±0.150 full scale i.e. ±0.150 _volts_ to model the real world
*) ±10.0 full scale, just to avoid changing things that don't
absolutely need to be changed.


==============================================

Before diving into navradio.cxx, I suggest you take a look at
http://www.av8n.com/fly/fgfs/servol.diff

which fixes the worst of the service volume silliness.

------------------------------------------------------------------------------
John Denker
2008-12-31 19:25:03 UTC
Permalink
Post by John Denker
Standard dogma in IFR training is that the VOR CDI indicates
two degrees per dot, while the LOC CDI indicates half a degree
per dot. These numbers are quite believable. Good practice
is to check them as part of the 30-day IFR receiver check.
Important clarification: The VOR numbers are quite believable,
and are checked monthly. However.....

The LOC numbers are only a rough rule of thumb. According to
the AIM, the localizer beam is supposed to be designed to be
700 ft wide at the threshold. That's ±350 feet if you prefer
to think of it that way.

That means that as the runway length varies from (say) 6000 ft
to 15000 ft, the CDI sensitivity varies from more than 0.6
degrees per dot to less than 0.3 degrees per dot. (I hear
rumors that it is artificially pegged at a minimum of 0.3
and a maximum of 0.6, overriding the 700 ft rule, but don't
quote me on that.)

The 0.5 degree dogma will get you in the ballpark, but
that's all.

Quoting from navradio.cxx

// According to Robin Peel, the ILS is 4x more
// sensitive than a vor
r *= 4.0;

That may be useful as a rough approximation, but nothing
beyond that.


------------------------------------------------------------------------------
Alex Perry
2009-01-01 06:46:46 UTC
Permalink
Post by John Denker
Post by John Denker
Standard dogma in IFR training is that the VOR CDI indicates
two degrees per dot, while the LOC CDI indicates half a degree
per dot. These numbers are quite believable. Good practice
is to check them as part of the 30-day IFR receiver check.
Important clarification: The VOR numbers are quite believable,
and are checked monthly. However.....
The LOC numbers are only a rough rule of thumb. According to
the AIM, the localizer beam is supposed to be designed to be
700 ft wide at the threshold. That's ±350 feet if you prefer
to think of it that way.
That means that as the runway length varies from (say) 6000 ft
to 15000 ft, the CDI sensitivity varies from more than 0.6
degrees per dot to less than 0.3 degrees per dot. (I hear
rumors that it is artificially pegged at a minimum of 0.3
and a maximum of 0.6, overriding the 700 ft rule, but don't
quote me on that.)
The 0.5 degree dogma will get you in the ballpark, but
that's all.
I've observed this variation in sensitivity in practical operations. We
can get away with using the 0.5 degree rule, but I'd prefer us to
perform the divide-and-constrain that John describes. If you want more
detail than the handwave that the AIM contains, go read the FAA
technical manual on how to design and deploy LOC antenna arrays ...



------------------------------------------------------------------------------
John Denker
2009-01-01 11:32:56 UTC
Permalink
Post by Alex Perry
I've observed this variation in sensitivity in practical operations. We
can get away with using the 0.5 degree rule, but I'd prefer us to
perform the divide-and-constrain that John describes.
I've got most of the code to do this.
In the absence of any clipping, some rather extreme examples include:

At Kennedy:
IMOH localizer axis: 4771.2 m ==> +- 1.28109 full scale or 0.256217 degrees per dot

At Robert J. Miller:
IMJX localizer axis: 1964.73 m ==> +- 3.11101 full scale or 0.622203 degrees per dot
Post by Alex Perry
If you want more
detail than the handwave that the AIM contains, go read the FAA
technical manual on how to design and deploy LOC antenna arrays ..
I don't have a copy of this. Does anybody have it, or a pointer?

=======

All indications are that for short runways, the width is not
allowed to exceed 6 degrees peg-to-peg (peg at +- 3).

I gather that "few" airports operate with less than 3 degrees
peg-to-peg (peg at +- 1.5), even if the runway is very long. I
get the impression there may be some discretion. I propose to
clip it at 3 for now, subject to change if/when we get better
information. In any case, if the Kennedy localizer is really
set for 2.56 peg-to-peg, approximating it by 3 is a lot better
than approximating it by 5, which is what version 1.9.0 and
all previous versions have done.


------------------------------------------------------------------------------
John Denker
2009-01-01 17:46:51 UTC
Permalink
Post by Alex Perry
If you want more
detail than the handwave that the AIM contains, go read the FAA
technical manual on how to design and deploy LOC antenna arrays ..
Found it.

In such matters, the FAA defers to the ICAO.

http://dcaa.slv.dk:8000/icaodocs/Annex%20X%20-%20Aeronautical%20Telecommunications/Volume%20I%20-%20Radio%20Navigation%20Aids/Vol.1%20-%206th%20Edition,%20July%202006.pdf


See in particular paragraph 3.1.3.7.1. Basically the rule is 210 m
at threshold, with complex exceptions for short runways. It never
exceeds 6 degrees full width (peg to peg). I see absolutely no
mention of any clipping at the low end.

========================

More generally,
http://dcaa.slv.dk:8000/icaodocs/
is a large trove of authoritative ICAO documents. I suspect some
people on this list will want to copy the entire tree.


------------------------------------------------------------------------------
syd adams
2009-01-02 05:05:08 UTC
Permalink
Post by James Turner
So, it seems like at least Syd may have been assuming the deflection
was in 'dots * 5' rather than 'degrees * 5' - I'd love Syd to confirm
or deny that. The upshot of this is that the GS indicator in Primus
is, **I think**, about 1/3rd as sensitive as it should be. However, I
could easily be wrong about this, so I'll wait for Syd to offer his
opinion.
Comments on any of the above are welcome.
Regards,
James
I think i assumed long ago that the GS deflection had a limit of -10 to 10
like the heading-needle-deflection , and so scaled the needle to the
outermost dot accordingly.
The manual states that in GS mode the vertical scale is in degrees , and
captures at 0.5 degrees , and I'm assuming (again) , that each dot must
represent 1 degree, since I havent come across exact numbers yet.In other
words, my setup could be wrong, I'll have to research this more.
John Denker
2009-01-02 05:59:53 UTC
Permalink
Post by syd adams
I think i assumed long ago that the GS deflection had a limit of -10 to 10
like the heading-needle-deflection , and so scaled the needle to the
outermost dot accordingly.
That is not consistent with what is implemented in navradio.cxx

That instrument, and all the CDI instruments I've seen, assume
-3.5 to +3.5 for the glideslope signal. I have no clue as to
the history or rationale for this, but it is what it is.
Post by syd adams
The manual states that in GS mode the vertical scale is in degrees , and
captures at 0.5 degrees , and I'm assuming (again) , that each dot must
represent 1 degree, since I havent come across exact numbers yet.In other
words, my setup could be wrong, I'll have to research this more.
In the Real World, the entire usable part of the glideslope beam
is only 0.7 degrees thick. Having a scale in degrees would not
be very useful.

====================================

Meanwhile ..... pursuing the other part of this thread ....

I wrote the code to make localizer sensitivity proportional to
runway length, as it is in Real Life, in accordance with ICAO
standards.

I've shot a few approaches with it.

If you fly from KMJX 6R to KJFK 31L there is quite a contrast:
the latter is about two-and-a-half times more sensitive.

I tied the sensitivity into the property tree so you can look
at it and even monkey with it.

The code implements the ICAO standard in some detail, even to
the point of producing slightly odd results for very short
runways e.g. San Diego KMYF (Montgomery Field).


------------------------------------------------------------------------------
James Turner
2009-01-02 12:13:23 UTC
Permalink
Post by John Denker
Post by syd adams
I think i assumed long ago that the GS deflection had a limit of -10 to 10
like the heading-needle-deflection , and so scaled the needle to the
outermost dot accordingly.
That is not consistent with what is implemented in navradio.cxx
That instrument, and all the CDI instruments I've seen, assume
-3.5 to +3.5 for the glideslope signal. I have no clue as to
the history or rationale for this, but it is what it is.
Post by syd adams
The manual states that in GS mode the vertical scale is in
degrees , and
captures at 0.5 degrees , and I'm assuming (again) , that each dot must
represent 1 degree, since I havent come across exact numbers yet.In other
words, my setup could be wrong, I'll have to research this more.
Note to John, this is the part of the discussion I care more about
right now, because the Mk-VIII defines various rules and alerts in
terms of 'dots'. It does however specify (in the installation guide) a
mapping from DDM to dots, using fixed values. DDM seems to be
expressed as a percentage of the loc or GS arc, eg +/- 0.4 for the
loc, and +/- 0.8 for the GS. However, those definitions bring us back
Post by John Denker
Post by syd adams
In the Real World, the entire usable part of the glideslope beam
is only 0.7 degrees thick. Having a scale in degrees would not
be very useful.
Important thing - all the instruments John linked to do indeed have 5
dots for the CDI, but all the glass displays, and high-end HSIs I've
seen, have two. This is interesting - 5 dots * 2 degrees (as John
said) gives ten degrees. The reference I found (which shows a 2-dot
CDI) says 5 degrees. And 2 dots * 5 degrees is ..... ten! :)

This bring us back to, we should probably be working in percentage of
full deviation (i.e DDM) for all these things, and exposing degrees
deviation as a bonus for other users. There's still the issue of what
full deviation is for both - I've heard 15 degrees for LOC stated,
which would mean +/- 0.4 DDM (which is what the Mk-VIII uses as
limits) would be +/- 6 degrees, and they state 0.0775 of DDM per dot,
so full range would be 5.161 dots.

Which close enough to 5 :)

For the GS, John states that the 'usable' part is only 0.7 degrees
thick. I'm unsure what usable means in that context, but given then
+/- 0.8 DDM range used by the Mk-VIII GPWS, and their dots-to-DMM
factor of 0.0875 for the GS, maximum deviation is 9.142 **dots**.
Clearly that's a much larger deviation that could ever be seen in a
real world-approach.

Give that definition, it seems unlike that the 'full deviation' (as
opposed to usable) for the GS should be taken as 0.7 degrees, since
that would make each dot 0.076 of a degree - which is an order of
magnitude less than the 0.3 or 0.6 definitions we've been talking about.
Post by John Denker
I wrote the code to make localizer sensitivity proportional to
runway length, as it is in Real Life, in accordance with ICAO
standards.
I've shot a few approaches with it.
the latter is about two-and-a-half times more sensitive.
I tied the sensitivity into the property tree so you can look
at it and even monkey with it.
The code implements the ICAO standard in some detail, even to
the point of producing slightly odd results for very short
runways e.g. San Diego KMYF (Montgomery Field).
So, I read the ICAO document, but I'm not quite familiar enough with
the radio model here to follow this discussion - could you start again
with the definitions, and walk me through it in baby-steps?

------------------------------------------------------------------------------
Torsten Dreyer
2009-01-02 12:57:22 UTC
Permalink
Post by James Turner
For the GS, John states that the 'usable' part is only 0.7 degrees
thick. I'm unsure what usable means in that context, but given then
+/- 0.8 DDM range used by the Mk-VIII GPWS, and their dots-to-DMM
factor of 0.0875 for the GS, maximum deviation is 9.142 **dots**.
Clearly that's a much larger deviation that could ever be seen in a
real world-approach.
Give that definition, it seems unlike that the 'full deviation' (as
opposed to usable) for the GS should be taken as 0.7 degrees, since
that would make each dot 0.076 of a degree - which is an order of
magnitude less than the 0.3 or 0.6 definitions we've been talking about.
What I remember from my ifr flight training and the manuals I read, at least
for the ki525 HSI the distance between two dots of the GS indicator is 0.35
degrees. There are two dots above and two dots below the center. This
calculates as in indicatable range of 0.7 degrees above and 0.7 degrees below
glidepath or 1.4 degrees width - or better thickness.

Torsten

------------------------------------------------------------------------------
syd adams
2009-01-02 18:37:27 UTC
Permalink
Going through the Primus manaul again , and one section states that capture
occurs at +- 0.5 degrees , and an approach illustration states typical
capture point at 1/3 dot ... so for the Primus it looks like each dot is 1.5
degrees deviation...
John Denker
2009-01-02 19:32:30 UTC
Permalink
Post by syd adams
Going through the Primus manaul again , and one section states that capture
occurs at +- 0.5 degrees , and an approach illustration states typical
capture point at 1/3 dot ... so for the Primus it looks like each dot is 1.5
degrees deviation...
Which are you going to believe:
-- the manual, or
-- the trees coming through the windshield?

The _center_ of the glideslope is only 3 degrees above horizontal
(sometimes less) and there are trees and things that stick up
above the horizontal plane. If each dot is 1.5 degrees, I'd
hate to be two dots low on the approach.

------------------------------------------------------------------------------
John Denker
2009-01-02 19:53:03 UTC
Permalink
Hi Folks

FG puts a model of a VOR shack into the scenery in places where
there is supposed to be a VOR shack. So far so good.

The problem is, the model seems awfully small. It looks like
it is about 5 meters in diameter. I've never seen one in RL
that is that small. I've seen them sometimes with twice that
diameter and more often with three times that diameter. If
you want more data on this, measure some of them using Google
maps / satellite view.

These things are rather important if you want realism. In
the vicinity of a VOR shack, in VFR conditions, pilots
really should not be looking at the CDI needle; they
should be looking out the window so they don't run into
the idiot who *is* only looking at the CDI needle.

Having an easily-visible VOR shack model helps with this.

There are other useful uses for VOR shacks.

Would somebody be kind enough to make a bigger model, or
at least in the interim triple the diameter of the existing
model?

Thanks!


------------------------------------------------------------------------------
Jon Stockill
2009-01-02 19:59:07 UTC
Permalink
Post by John Denker
Hi Folks
FG puts a model of a VOR shack into the scenery in places where
there is supposed to be a VOR shack. So far so good.
The problem is, the model seems awfully small. It looks like
it is about 5 meters in diameter. I've never seen one in RL
that is that small. I've seen them sometimes with twice that
diameter and more often with three times that diameter. If
you want more data on this, measure some of them using Google
maps / satellite view.
These things are rather important if you want realism. In
the vicinity of a VOR shack, in VFR conditions, pilots
really should not be looking at the CDI needle; they
should be looking out the window so they don't run into
the idiot who *is* only looking at the CDI needle.
Having an easily-visible VOR shack model helps with this.
There are other useful uses for VOR shacks.
Would somebody be kind enough to make a bigger model, or
at least in the interim triple the diameter of the existing
model?
Send me a model, I'll update the database.

AFAIK though ther eare currently 2 models in the db, and one at least
was modeled on a real VOR.

Jon


------------------------------------------------------------------------------
Alex Perry
2009-01-02 20:04:20 UTC
Permalink
Putting on my aluminium foil hat, I'll point out that there are five
combinations of VOR/DME/TACAN even before you decide whether it is
going to be monitored locally and whether the earth has repeatable
conductivity to act as a ground plane. These decisions change what
gets physically installed ... it may be worth us having multiple
models available.
Post by Jon Stockill
Post by John Denker
Hi Folks
FG puts a model of a VOR shack into the scenery in places where
there is supposed to be a VOR shack. So far so good.
The problem is, the model seems awfully small. It looks like
it is about 5 meters in diameter. I've never seen one in RL
that is that small. I've seen them sometimes with twice that
diameter and more often with three times that diameter. If
you want more data on this, measure some of them using Google
maps / satellite view.
These things are rather important if you want realism. In
the vicinity of a VOR shack, in VFR conditions, pilots
really should not be looking at the CDI needle; they
should be looking out the window so they don't run into
the idiot who *is* only looking at the CDI needle.
Having an easily-visible VOR shack model helps with this.
There are other useful uses for VOR shacks.
Would somebody be kind enough to make a bigger model, or
at least in the interim triple the diameter of the existing
model?
Send me a model, I'll update the database.
AFAIK though ther eare currently 2 models in the db, and one at least
was modeled on a real VOR.
Jon
------------------------------------------------------------------------------
_______________________________________________
Flightgear-devel mailing list
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
------------------------------------------------------------------------------
Erik Hofman
2009-01-02 20:01:09 UTC
Permalink
Post by John Denker
Hi Folks
FG puts a model of a VOR shack into the scenery in places where
there is supposed to be a VOR shack. So far so good.
The problem is, the model seems awfully small. It looks like
it is about 5 meters in diameter. I've never seen one in RL
that is that small. I've seen them sometimes with twice that
diameter and more often with three times that diameter. If
you want more data on this, measure some of them using Google
maps / satellite view.
I've modeled them after these images in the past:
Loading Image...
Loading Image...
Loading Image...

It might have been a bad choice though..

Erik

------------------------------------------------------------------------------
John Denker
2009-01-02 20:32:01 UTC
Permalink
Post by Erik Hofman
http://i149.photobucket.com/albums/s63/tundratantrum/kotzebuevortac1.jpg
http://www.dot.state.mn.us/aero/avoffice/navaids/images/vor3.jpg
http://members.chello.nl/vdleije/pics/ssj_vor.jpg
Wow, those are small.
Post by Erik Hofman
It might have been a bad choice though..
Obviously there's considerable variability. I have no idea
how to determine what style is used in any given location.

Here's a picture of a rather bigger one. I've seen
plenty of them that look roughly like this. I reckon
the door is 2 m tall and the disk is 12 m in diameter.

Loading Image...


==========

What form are the original models in? Are they available?


------------------------------------------------------------------------------
Curtis Olson
2009-01-02 20:37:41 UTC
Permalink
Post by John Denker
Post by Erik Hofman
http://i149.photobucket.com/albums/s63/tundratantrum/kotzebuevortac1.jpg
http://www.dot.state.mn.us/aero/avoffice/navaids/images/vor3.jpg
http://members.chello.nl/vdleije/pics/ssj_vor.jpg
Wow, those are small.
I can say from personal experience that Gopher (GEP, 117.30) is really tough
to spot from the air. Of course you are talking to a guy who gets lost
after about the first 30 seconds after take off (assuming I don't look out
the window sooner than that, in which case I'd be lost sooner.) :-)

Curt.
--
Curtis Olson: http://baron.flightgear.org/~curt/
John Denker
2009-01-02 21:10:40 UTC
Permalink
Post by Curtis Olson
I can say from personal experience that Gopher (GEP, 117.30) is really tough
to spot from the air.
Here's the picture:
http://www.google.com/maps?ll=45.145694,-93.373194&spn=0.012077,0.018539&t=h&z=16

If I'm measuring it properly, it's even bigger than the previous
one I mentioned. The disk appears to be 17 m in diameter. This
supports the notion that we need some much larger VOR shack
models.


Here's one that's *not* hard to spot.
http://maps.google.com/maps?f=q&hl=en&ie=UTF8&ll=42.221311,-87.951474&spn=0.001232,0.002843&t=h&z=19

The groundplane disk is 150 feet in diameter.
Post by Curtis Olson
Post by Alex Perry
... it may be worth us having multiple
models available.
That sure would be nice ... But then we need decide what goes where.
I don't know where to get that kind of data.

Here's a proposal:
0) If somebody has actual data, use that; otherwise:
1) Put 17m diameter shacks in "enroute" locations.
2) Put 12m diamater shacks in "on airport" locations.


Anybody got a better idea?

------------------------------------------------------------------------------
Alex Perry
2009-01-02 21:25:05 UTC
Permalink
Post by John Denker
1) Put 17m diameter shacks in "enroute" locations.
2) Put 12m diamater shacks in "on airport" locations.
Anybody got a better idea?
Here is a derivative idea. There are several classes of VOR
(irrespective of the other radio services that might be colocated)
which determine what the receivable range is ... and whether they're
usable for jet routes. That change in transmitter power may be a
defining factor for how big the shack is.

------------------------------------------------------------------------------
Jon Stockill
2009-01-02 21:32:19 UTC
Permalink
Post by Alex Perry
Here is a derivative idea. There are several classes of VOR
(irrespective of the other radio services that might be colocated)
which determine what the receivable range is ... and whether they're
usable for jet routes. That change in transmitter power may be a
defining factor for how big the shack is.
If we have range data available then we can use that to select an
appropriate model too.

Jon

------------------------------------------------------------------------------
John Denker
2009-01-02 22:56:28 UTC
Permalink
Post by Alex Perry
Here is a derivative idea. There are several classes of VOR
(irrespective of the other radio services that might be colocated)
which determine what the receivable range is ... and whether they're
usable for jet routes. That change in transmitter power may be a
defining factor for how big the shack is.
That sounds good. That is a huge improvement over my previous
suggestion.


Continuing that thought, the long-range ones need to be bigger
not just because of power, but because of accuracy. A bigger
shack has better "leverage" on the radials. For example there
is a high-power VORTAC on-field at JFK and it is not small.
http://www.google.com/maps?sll=37.0625,-95.677068&sspn=54.884801,75.9375&ie=UTF8&ll=40.632867,-73.771576&spn=0.001624,0.002317&t=h&z=17


The only T-VOR I can think of offhand is FHU
http://www.google.com/maps?f=q&hl=en&geocode=&sspn=50.402258,75.9375&ie=UTF8&ll=31.589978,-110.345204&spn=0.003646,0.004635&t=h&z=18
which is tiny.




So, to be specific, how about this, based on the navaid range
in nav.dat:
if actual size data, ...... use actual data
else if range >= 100 ...... 17 m shack
else if range >= 35 ...... 12 m shack
else ...... 5 m shack (like the existing model)

This won't cover all the bases, but it would be an immediate and
significant improvement over the existing setup.


------------------------------------------------------------------------------
Martin Spott
2009-01-02 23:23:48 UTC
Permalink
Post by John Denker
Obviously there's considerable variability. I have no idea
how to determine what style is used in any given location.
Pass by and take pictures of each individual station. The size/type of
the respective housing is usually not recorded anywhere.
Post by John Denker
http://www.thtech.net/images/databanks/towerhunt/46-1-big.jpg
This shape is quite uncommon on the continent where I live,

Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------

------------------------------------------------------------------------------
Bohnert Paul
2009-01-07 03:42:29 UTC
Permalink
Developers,

Many nan's when flying near KOSH. Scenery 1.0.1. FlgihtGear cvs from a couple of days ago.

CullVisitor::apply(Geode&) detected NaN,
depth=nan, center=(0 0 0.011732),
matrix={
nan nan nan nan
nan nan nan nan
nan nan nan nan
nan nan nan nan
}

CullVisitor::apply(Geode&) detected NaN,
depth=nan, center=(-0.0075 5.00004e-07 0.023495),
matrix={
nan nan nan nan
nan nan nan nan
nan nan nan nan
nan nan nan nan
}

CullVisitor::apply(Geode&) detected NaN,
depth=nan, center=(-0.0075 0 0.0047475),
matrix={
nan nan nan nan
nan nan nan nan
nan nan nan nan
nan nan nan nan
}

CullVisitor::apply(Geode&) detected NaN,
depth=nan, center=(-0.014 0 -0.014487),
matrix={
nan nan nan nan
nan nan nan nan
nan nan nan nan
nan nan nan nan
}

CullVisitor::apply(Geode&) detected NaN,
depth=nan, center=(-0.012 9.80012e-05 -1.69985e-05),
matrix={
nan nan nan nan
nan nan nan nan
nan nan nan nan
nan nan nan nan
}

CullVisitor::apply(Geode&) detected NaN,
depth=nan, center=(-0.018 0 0),
matrix={
nan nan nan nan
nan nan nan nan
nan nan nan nan
nan nan nan nan
}

CullVisitor::apply(Geode&) detected NaN,
depth=nan, center=(-0.0145 0 0),
matrix={
nan nan nan nan
nan nan nan nan
nan nan nan nan
nan nan nan nan
}

CullVisitor::apply(Geode&) detected NaN,
depth=nan, center=(-1.79311 0 -0.123913),
matrix={
nan nan nan nan
nan nan nan nan
nan nan nan nan
nan nan nan nan
}

Best Regards,
Paul B
***@yahoo.com
Csaba Halász
2009-01-07 04:22:30 UTC
Permalink
Post by Bohnert Paul
Developers,
Many nan's when flying near KOSH. Scenery 1.0.1. FlgihtGear cvs from a couple of days ago.
I have identified a number of problematic places in the code where
NaNs can be produced. (See my recent emails) So far not many have been
fixed.
I'll have a look tomorrow if this particular NaN happens here as well,
and whether it is something new or already covered by my reports.
--
Csaba/Jester
Bohnert Paul
2009-01-03 00:33:06 UTC
Permalink
Subject: Re: [Flightgear-devel] VOR shack : scenery model upgrade opportunity
Date: Friday, January 2, 2009, 2:01 PM
Post by John Denker
Hi Folks
FG puts a model of a VOR shack into the scenery in
places where
Post by John Denker
there is supposed to be a VOR shack. So far so good.
The problem is, the model seems awfully small. It
looks like
Post by John Denker
it is about 5 meters in diameter. I've never seen
one in RL
Post by John Denker
that is that small. I've seen them sometimes with
twice that
Post by John Denker
diameter and more often with three times that
diameter. If
Post by John Denker
you want more data on this, measure some of them using
Google
Post by John Denker
maps / satellite view.
http://i149.photobucket.com/albums/s63/tundratantrum/kotzebuevortac1.jpg
http://www.dot.state.mn.us/aero/avoffice/navaids/images/vor3.jpg
http://members.chello.nl/vdleije/pics/ssj_vor.jpg
It might have been a bad choice though..
Erik
------------------------------------------------------------------------------
_______________________________________________
Flightgear-devel mailing list
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
http://scenemodels.flightgear.org/modeledit.php?id=39 vordme_1
http://scenemodels.flightgear.org/modeledit.php?id=615 vordme_2

vordme_1 is the default VOR/DME model for FlightGear. I don't know it's history.

I modeled vordme_2. It is modeled after VOR/DME OSH. Located at KOSH airport. I used photographs to estimate it's dimensions.

vordme_2 is positioned at VOR/DME OSH and VOR/DME SFO. SFO is the one at KSFO airport. It is not the correct model for SFO. If someone can provide pictures and dimensions for SFO I will model it for FlightGear.

Best Regards,

Paul B
***@yahoo.com






------------------------------------------------------------------------------
John Denker
2009-01-03 05:01:30 UTC
Permalink
Post by Bohnert Paul
http://scenemodels.flightgear.org/modeledit.php?id=39 vordme_1
http://scenemodels.flightgear.org/modeledit.php?id=615 vordme_2
1) Thanks for the points.

2) For folks without "edit" passwords, the following is more
useful:
http://scenemodels.flightgear.org/modelbrowser.php?shared=12
Post by Bohnert Paul
vordme_1 is the default VOR/DME model for FlightGear. I don't know it's history.
That can serve as a model for "tiny" VOR shacks, but those seem
to be rare in the US, although FHU VOR is tiny; see below
Post by Bohnert Paul
I modeled vordme_2. It is modeled after VOR/DME OSH. Located at KOSH
airport.
Very nice.
Post by Bohnert Paul
I used photographs to estimate it's dimensions.
These days you can google the critical dimension i.e. diameter.

Tiny: FHU http://www.google.com/maps?f=q&ie=UTF8&ll=31.589978,-110.345204&spn=0.003646,0.004635&t=h&z=18

Medium: SFO http://maps.google.com/maps?ll=37.61953,-122.374024&spn=0.000848,0.001159&t=h&z=20

Large: GEP http://www.google.com/maps?ll=45.145694,-93.373194&spn=0.012077,0.018539&t=h&z=16
COL http://www.google.com/maps?q=+39.8156++-74.4316

Huge: JFK http://www.google.com/maps?ll=40.632867,-73.771576&spn=0.001624,0.002317&t=h&z=17

Monstrous OKB http://maps.google.com/maps?f=q&hl=en&ie=UTF8&ll=42.221311,-87.951474&spn=0.001232,0.002843&t=h&z=19


My conclusions bases on what I see are:

FHU Tiny -1 model OK
SFO Medium -2 model OK
GEP Large should switch to larger version of -2 model
COL Large ditto
JFK Huge could switch to much larger version of -2 model
although for now I'd be happy to lump it in with
the merely "large" VORs
OKB Monstrous maybe a project for another day
Post by Bohnert Paul
vordme_2 is positioned at VOR/DME OSH and VOR/DME SFO. SFO is the
one at KSFO airport. It is not the correct model for SFO.
It looks OK to me. It looks nice, and it's pretty much the
right size. What's not to like?
Post by Bohnert Paul
If someone
can provide pictures and dimensions for SFO I will model it for
FlightGear.
IMHO the most reward per unit effort would be
a) start by making a scaled-up version of the -2 model, scaled up
to about 17 meter diameter
b) in parallel with that, somebody could add the code to choose
the VOR model based on range as tabulated in nav.dat

As before, for the US at least the proposal is:
if actual size data, ...... use actual data
else if range >= 100 ...... 17 m shack large (scaled up -2)
else if range >= 35 ...... 12 m shack medium (-2)
else ...... 5 m shack tiny (-1)



------------------------------------------------------------------------------
syd adams
2009-01-02 20:02:01 UTC
Permalink
Post by James Turner
Post by syd adams
Going through the Primus manaul again , and one section states that
capture
Post by syd adams
occurs at +- 0.5 degrees , and an approach illustration states typical
capture point at 1/3 dot ... so for the Primus it looks like each dot is
1.5
Post by syd adams
degrees deviation...
-- the manual, or
-- the trees coming through the windshield?
The _center_ of the glideslope is only 3 degrees above horizontal
(sometimes less) and there are trees and things that stick up
above the horizontal plane. If each dot is 1.5 degrees, I'd
hate to be two dots low on the approach.
I see your point , but not being a pilot , I tend to believe the manual...
I'm still searching for cold hard facts, though.
syd adams
2009-01-02 20:12:30 UTC
Permalink
Further online searching turned up this ....

This deflection corresponds to the direction the pilot must fly to intercept
the glide path and is proportional to the angular displacement from the
glide path angle. As with the localizer, the full scale deflection is 150
microamperes. Typically, the glide slope sensitivity is set so that the
full-scale indications occur at approximately 2.3 and 3.7 degrees elevation.

this is from
http://www.ohio.edu/avionics/research/nav/ils/glideslope.cfm
syd adams
2009-01-02 22:09:05 UTC
Permalink
Ok , Im getting closer...i think
Another manual i have states min glideslope angle = 2.5 degrees , maximum =
3.25 degrees,
so does that mean the needle animation range should be 0.25 at the upper
second dot, and -0.5 for the bottom second dot ?
That approach illustration is really confusing me now :)
Alex Perry
2009-01-02 22:28:12 UTC
Permalink
No. The standard design is based around 3 degrees slope. With that
design, the usable range is 1.4 degrees high, from 2.1 to 3.7 degrees
and offers 0.35 degrees per dot. Therefore, a dot equals 50ft per
mile range from the touchdown zone of the runway. When the standard
design is scaled for terrain or other approach spaces, all that is
modified is where the antenna array has the intensity maximuma.
Consequently all those numbers grow by up to 8% or shrink by up to
16%.
From the point of view of implementation in a simulator, just take the
actual slope number for a specific runway and combine that with the
aircraft's position to generate a ratio. Repair the ratio to allow
for the side lobes (which as I recall are the standard series with a
negative at 6 and one you can follow at 9). Then pass that ratio to
the instrument implementation. The instrument should probably show
full scale from 0.6 to 1.4 with center at 1.0 and dots at 0.77 0.88
1.11 1.23
Ok , Im getting closer...i think
Another manual i have states min glideslope angle = 2.5 degrees , maximum =
3.25 degrees,
so does that mean the needle animation range should be 0.25 at the upper
second dot, and -0.5 for the bottom second dot ?
That approach illustration is really confusing me now :)
------------------------------------------------------------------------------
_______________________________________________
Flightgear-devel mailing list
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
------------------------------------------------------------------------------
syd adams
2009-01-02 22:56:36 UTC
Permalink
OK , so my needle animation is far too insensitive , but the needle
deflection property shows 0 at dead center (3 degrees). What I was asking is
what amount of deflection per dot the needle should move based on the
existing property , so I'll go with 0.35 and try some approaches.
Thanks everyone for pointing out this error...
John Denker
2009-01-02 23:12:50 UTC
Permalink
From the point of view of implementation in a simulator, just take the
actual slope number for a specific runway and combine that with the
aircraft's position to generate a ratio. Repair the ratio to allow
for the side lobes (which as I recall are the standard series with a
negative at 6 and one you can follow at 9). Then pass that ratio to
the instrument implementation.
I agree with all of that. And I have implemented it in the code,
including the extra lobes i.e. false glide slopes.

===========

Tangential remark: I am surprised by this reference:
http://www.freepatentsonline.com/3757338.html

which alleges
For reasons well known to those skilled in the art but
to minor importance here, the first significant side lobe,
that is a side lobe which comprises a stable false glide
slope indistinguishable from the true glide slope except
for its steepness, occurs at 5A.

I'm wondering if that's a typo. A 9 degree false glideslope is
more-or-less followable but a 15 degree false GS would be too
steep to be followable without extraordinary effort. I've seen
students actually capture and try to follow a false GS. It's not
easy but it can be done. So I've implemented 6-degree periodicity,
i.e. 3, 6r, 9, 12r, etc. where "r" means reverse sensing.

OTOH it might not be a typo. I haven't worked out the electrodynamics
of the situation, so I can't be sure what's actually going on.


------------------------------------------------------------------------------
Alex Perry
2009-01-02 23:31:14 UTC
Permalink
Post by John Denker
From the point of view of implementation in a simulator, just take the
actual slope number for a specific runway and combine that with the
aircraft's position to generate a ratio. Repair the ratio to allow
for the side lobes (which as I recall are the standard series with a
negative at 6 and one you can follow at 9). Then pass that ratio to
the instrument implementation.
I agree with all of that. And I have implemented it in the code,
including the extra lobes i.e. false glide slopes.
===========
http://www.freepatentsonline.com/3757338.html
which alleges
For reasons well known to those skilled in the art but
to minor importance here, the first significant side lobe,
that is a side lobe which comprises a stable false glide
slope indistinguishable from the true glide slope except
for its steepness, occurs at 5A.
I'm wondering if that's a typo. A 9 degree false glideslope is
more-or-less followable but a 15 degree false GS would be too
steep to be followable without extraordinary effort. I've seen
students actually capture and try to follow a false GS. It's not
easy but it can be done. So I've implemented 6-degree periodicity,
i.e. 3, 6r, 9, 12r, etc. where "r" means reverse sensing.
OTOH it might not be a typo. I haven't worked out the electrodynamics
of the situation, so I can't be sure what's actually going on.
Nor me. I recall seeing the analysis somewhere (but I don't remember
where). It could be that 2A is a null rather than reversed, in which
case 3A is the reverse, 4A would be the next null and 5A is indeed the
next followable slope. 9 degrees is 1000 fpm for a C172 and is
trivially achievable without special effort. 15 degrees implies
intentional increase in drag. However, gear down and approach flaps
_is_ an increase in drag ... so the additional drag of taking the
engine to completely idle may be enough without adding more flaps.

------------------------------------------------------------------------------
James Turner
2009-01-03 13:58:15 UTC
Permalink
Post by Alex Perry
No. The standard design is based around 3 degrees slope. With that
design, the usable range is 1.4 degrees high, from 2.1 to 3.7 degrees
and offers 0.35 degrees per dot. Therefore, a dot equals 50ft per
mile range from the touchdown zone of the runway. When the standard
design is scaled for terrain or other approach spaces, all that is
modified is where the antenna array has the intensity maximuma.
Consequently all those numbers grow by up to 8% or shrink by up to
16%.
From the point of view of implementation in a simulator, just take the
actual slope number for a specific runway and combine that with the
aircraft's position to generate a ratio. Repair the ratio to allow
for the side lobes (which as I recall are the standard series with a
negative at 6 and one you can follow at 9). Then pass that ratio to
the instrument implementation. The instrument should probably show
full scale from 0.6 to 1.4 with center at 1.0 and dots at 0.77 0.88
1.11 1.23
Okay, trying to steer this back to things I have more of a handle on:

- everyone seems agreed that the GS is a 1.4 degree volume, so 0.7
degrees above and below the GS line. And the '0.35' degrees per dot
comes up, which basically implies 2 dots from the center line to the
0.7 degree limit. Referring back to the ICAO docs that John Denker
posted, and the Mk-VIII manual, which says 0.0875 DDM per dot on the
GS, and the ICAO docs say the GS 'sector' is 0.175, and the half-
sector is 0.0875.

I.e two 'dots' would be the very edge of the sector (0.175 DDM). This
is important because the 'soft' alert limit is defined as 1.3 dots,
and the hard limit is 2 dots. Which again makes sense, and brings us
back to the fact that most high-end GS indicators (Primus, Honeywell/
Boeing) use two dots either side for the indicator.

Sooooo .... my inclination is to add the degrees deviation properties
as discussed, and to avoid 'dots' in the navradio code, but to add -
ddm properties. Obviously I won't touch the existing 'deflection'
properties, but I hope over time they'll rot. For the Mk-VIII, I'll
convert to 'dots' using the terms defined in the INSTALL manual, which
of course match the ICAO 'half-sector' values exactly.

I'm not sure where all of this leaves Syd, or other panel designers.
Working in DDM seems a little awkward, unless we define the maximum
deflection as a property (entirely possible) or provide a normalised
version (also entirely possible). A normalised version would probably
be the easiest thing to use in simple displays (like in the current
C172) but also in glass displays.

Comments?

James



------------------------------------------------------------------------------
John Denker
2009-01-03 15:04:20 UTC
Permalink
Post by James Turner
- everyone seems agreed that the GS is a 1.4 degree volume, so 0.7
degrees above and below the GS line.
I concur.
Post by James Turner
And the '0.35' degrees per dot
comes up, which basically implies 2 dots from the center line to the
0.7 degree limit.
Sorry, no. Here's a counterexample:
http://www.aircraftspruce.com/catalog/graphics/11-05106.gif
Post by James Turner
Referring back to the ICAO docs that John Denker
posted, and the Mk-VIII manual, which says 0.0875 DDM per dot on the
GS, and the ICAO docs say the GS 'sector' is 0.175, and the half-
sector is 0.0875.
Please let's not confuse ICAO (which is quite general) with
Mk-VIII (which is just one instrument).
Post by James Turner
I.e two 'dots' would be the very edge of the sector (0.175 DDM). This
is important because the 'soft' alert limit is defined as 1.3 dots,
and the hard limit is 2 dots. Which again makes sense, and brings us
back to the fact that most high-end GS indicators (Primus, Honeywell/
Boeing) use two dots either side for the indicator.
Please let's write code that works for all instruments, not
"most" instruments or "most high-end" instruments.
Post by James Turner
Sooooo .... my inclination is to add the degrees deviation properties
as discussed, and to avoid 'dots' in the navradio code,
Yes, dots are to be avoided. Anything involving dots is
just begging to be misunderstood.

While we're on the subject: It is good practice to spell
out what is meant by "full scale". It could be either
center-to-side or side-to-side. (I've made this mistake
myself :-)

Talking about 1.4 degrees "full sector" (peg to peg) seems
reasonably convenient and unambiguous. Also talking about
an interval in the form [0 ± 0.7] is unambiguous.
Post by James Turner
but to add -
ddm properties.
DDM? I can't imagine why anyone would want to mess with
that level of detail. Deflection as a fraction of full
sector is all any Sim World instrument designer needs.
Maybe once in ten years somebody should check that the
full-sector width is what we think it is, but that's been
done now.
Post by James Turner
Obviously I won't touch the existing 'deflection'
properties, but I hope over time they'll rot.
I think they're just fine. I don't see any need for
additional complexity. If it ain't broke, don't fix it.
Post by James Turner
For the Mk-VIII, I'll
convert to 'dots' using the terms defined in the INSTALL manual, which
of course match the ICAO 'half-sector' values exactly.
Since the deflection values are exact, why not use them?
Post by James Turner
I'm not sure where all of this leaves Syd, or other panel designers.
Working in DDM seems a little awkward,
Agreed, awkward and unnecessary.


------------------------------------------------------------------------------
James Turner
2009-01-03 15:34:42 UTC
Permalink
Post by John Denker
Post by James Turner
- everyone seems agreed that the GS is a 1.4 degree volume, so 0.7
degrees above and below the GS line.
I concur.
Post by James Turner
Please let's not confuse ICAO (which is quite general) with
Mk-VIII (which is just one instrument).
Please let's write code that works for all instruments, not
"most" instruments or "most high-end" instruments.
Understood, see below...
Post by John Denker
Post by James Turner
Sooooo .... my inclination is to add the degrees deviation properties
as discussed, and to avoid 'dots' in the navradio code,
Yes, dots are to be avoided. Anything involving dots is
just begging to be misunderstood.
Right :)
Post by John Denker
DDM? I can't imagine why anyone would want to mess with
that level of detail. Deflection as a fraction of full
sector is all any Sim World instrument designer needs.
Maybe once in ten years somebody should check that the
full-sector width is what we think it is, but that's been
done now.
Understood
Post by John Denker
Post by James Turner
Obviously I won't touch the existing 'deflection'
properties, but I hope over time they'll rot.
I think they're just fine. I don't see any need for
additional complexity. If it ain't broke, don't fix it.
No, the *deflection* properties really are broken, because they're in
ambiguous units, I think (especially the magic factor-of-5 multiple
that started this thread). I am going to add 'deviation-degrees' for
both the LOC and GS, and I think that's what should be preferred going
forwards, especially once the full-sector is defined - which it seems
to be, now.

I'd still be inclined to include deviation-norm alongside deviation-
deg, i.e just do the divide by full-sector deviation inside the
navradio code, since I am sure this would make panel designers much
happier.

So:

/instruments/navradio[n]/heading-deviation-deg: [-10.0 to 10.0 for a
VOR, -2.5 to 2.5 for a LOC] (i.e no 'magic 4' multiple for LOCs)
/instruments/navradio[n]/heading-deviation-norm: [-1.0 .. 1.0]
/instruments/navradio[n]/gs-deviation-deg: [-0.7 to 0.7]
/instruments/navradio[n]/gs-deviation-norm: [-1.0 to 1.0]

Does this seem reasonable to all concerned? I'm happy to make these
changes, and then we can (separately!) consider using John's
sensitivity-as-a-function-of-runway-length logic, which seems to be
generally agreed as better than the current situation, but which I am
profoundly under-qualified to given an opinion upon :)

James



------------------------------------------------------------------------------
John Denker
2009-01-03 16:17:18 UTC
Permalink
On 01/03/2009 08:34 AM, James Turner wrote:

<snip> Lots of stuff we agree on.... </snip>
Post by James Turner
No, the *deflection* properties really are broken, because they're in
ambiguous units, I think (especially the magic factor-of-5 multiple
that started this thread).
As always, I look at things primarily from the _user_ point
of view. We should do what's best for the _users_.

They don't care what local units are used to communicate
between the tuner and the CDI head. It could be "gallons"
as Torsten mentioned.

The existing code uses [0 ± 10] gallons for the left/right
needle and [0 ± 3.5] gallons for the up/down needle. The
xml instrument designers have come to terms with this.
Some comments here and there, documenting this convention,
wouldn't hurt. IMHO nothing more than comments is worth
bothering with.

On the scale of things, this is not "broken". There are
dozens upon dozens of things far more broken than this.
Post by James Turner
I am going to add 'deviation-degrees' for
both the LOC and GS, and I think that's what should be preferred going
forwards, especially once the full-sector is defined - which it seems
to be, now.
Not a great idea, for reasons discussed below, including
the fact that it fails miserably for RNAV units.
Post by James Turner
I'd still be inclined to include deviation-norm alongside deviation-
deg, i.e just do the divide by full-sector deviation inside the
navradio code, since I am sure this would make panel designers much
happier.
That would make instrument designers much happier, because
VOR sensitivity is different from LOC sensitivity, and LOC
sensitivity varies from place to place. Real World LOC
sensitivity is *not* half a degree per dot, no matter how
many non-experts say it is.

Also RNAV units drive the left/right needle in units that
have nothing to do with degrees.

In the Real World, there is an industry standard that is
used to communicate from the tuner to the CDI head,
namely
CDI Left/Right 150 mV into 1K load
CDI Up/Down 150 mV into 1K load
CDI Glide Slope Flag 300 mV into 1K load
CDI VOR/LOC Flag 300 mV into 1K load


which has never been and cannot be denominated in
degrees. Sending "degrees" to the CDI head is a waste
of time. Why do things the hard way when the easy
(and almost realistic) way is already implemented?

The existing scheme, which puts out a normalized
full-scale deflection, is almost realistic and has
proven perfectly adequate over the years. The
choice of what the normalization constant should
be is a private matter between the tuner-designers
and the CDI-designers. Fussing over private
matters doesn't do the users much good.

There are dozens and dozens of bugs that *do* adversely
affect real users who really fly the sim ... and IMHO
those should get priority. After the real bugs are
fixed we can fuss over things users don't see.


------------------------------------------------------------------------------
James Turner
2009-01-03 17:04:18 UTC
Permalink
Post by John Denker
They don't care what local units are used to communicate
between the tuner and the CDI head. It could be "gallons"
as Torsten mentioned.
The existing code uses [0 ± 10] gallons for the left/right
needle and [0 ± 3.5] gallons for the up/down needle. The
xml instrument designers have come to terms with this.
Some comments here and there, documenting this convention,
wouldn't hurt. IMHO nothing more than comments is worth
bothering with.
On the scale of things, this is not "broken". There are
dozens upon dozens of things far more broken than this.
Except that, it caused the GPWS code to misbehave, and I am enough of
pedant that I am not prepared to accept an arbitrary scale of gallons
just because that's what's gone before. My dislike of magic numbers /
units / scales is really quite intense. I understand that from a
strictly pragmatic point of view, the easiest thing would be to just
do one more magic conversion in the Mk-VIII code, but, yuck.
Post by John Denker
Not a great idea, for reasons discussed below, including
the fact that it fails miserably for RNAV units.
Well, in the medium term, I have another idea on that front, but I
really want to get the GPWS working better, so that's a discussion for
another day. For now, let's just say that navradio is a very bad fit
for RNAV or GPS units, and that things there will have to change, but
not as part of this work. One thing at a time, and all that.
Post by John Denker
The existing scheme, which puts out a normalized
full-scale deflection, is almost realistic and has
proven perfectly adequate over the years. The
choice of what the normalization constant should
be is a private matter between the tuner-designers
and the CDI-designers. Fussing over private
matters doesn't do the users much good.
Except it's normalised to these somewhat arbitrary values, so rather
than just agreeing on some bad values because they exist, why not add/
migrate to some that actually make sense, and stop people (eg, Syd)
guessing what full-range is.

I.e, let's just normalise to [-1.0 .. 1.0] and be done with it.
(Except, as Torsten just noted, the values can probably go slightly
beyond that, since any clamping should be done at the panel-instrument
level, not the receiver level).

James



------------------------------------------------------------------------------
John Denker
2009-01-03 17:38:27 UTC
Permalink
Post by James Turner
I.e, let's just normalise to [-1.0 .. 1.0] and be done with it.
(Except, as Torsten just noted, the values can probably go slightly
beyond that, since any clamping should be done at the panel-instrument
level, not the receiver level).
OK.... So ....

A) We are now agreed that deflection as a fraction
of full scale is a supported feature, not deprecated,
not scheduled to "rot", right?

B) The proposal is to add a new output, just like
the old output, but with a different normalization
factor. That's the main point of this thread, right?

C) The old oddly-normalized output will continue to
be supported for the foreseeable future, since is doesn't
interfere with new features and preserves compatible
interoperation with older CDIs, right?

D) Lesser points include:

-- Outputs should not be clamped by the tuner. Each
CDI head may choose to peg the needles, or not, in
its own way.

-- Localizer sensitivity is runway-dependent.

-- Dozens of other navradio.cxx bugs as discussed
elsewhere.



------------------------------------------------------------------------------
James Turner
2009-01-03 17:55:48 UTC
Permalink
Post by John Denker
A) We are now agreed that deflection as a fraction
of full scale is a supported feature, not deprecated,
not scheduled to "rot", right?
Err, I would say that we don't have that as a current feature, but I
think that's getting into semantics of what 'normalised' means, and my
opinion as a graphics coder may be different to an engineering
meaning. Anyway, there is certainly no way (even if it was desired) of
getting rid of heading-deflection or gs-deflection, and they have to
continue to work.
Post by John Denker
B) The proposal is to add a new output, just like
the old output, but with a different normalization
factor. That's the main point of this thread, right?
At this point, I think so. There's code that would be simpler if it
could talk about degrees deviation rather than peg-to-peg percentage
(eg, all the autopilots that 'capture with 0.5 degrees (or whatever)'
of the localiser) but I think a degree based definition will always be
troublesome. Clearly real world autopilots know about a signal from
the navradio, not real degrees, so when the manual specifies a value
in degrees they're applying some approximate conversion factor.
Post by John Denker
C) The old oddly-normalized output will continue to
be supported for the foreseeable future, since is doesn't
interfere with new features and preserves compatible
interoperation with older CDIs, right?
Yep, sadly that's too far baked in to be removed at this point, at
least for the amount of effort required.
Post by John Denker
-- Outputs should not be clamped by the tuner. Each
CDI head may choose to peg the needles, or not, in
its own way.
Yep, but someone needs to verify what the fallout of such a change
might be.
Post by John Denker
-- Localizer sensitivity is runway-dependent.
-- Dozens of other navradio.cxx bugs as discussed
elsewhere.
Indeed, but again not the core thing I'm worrying about here.

James

------------------------------------------------------------------------------
Torsten Dreyer
2009-01-03 15:49:00 UTC
Permalink
Post by James Turner
/instruments/navradio[n]/heading-deviation-deg: [-10.0 to 10.0 for a
VOR, -2.5 to 2.5 for a LOC] (i.e no 'magic 4' multiple for LOCs)
/instruments/navradio[n]/heading-deviation-norm: [-1.0 .. 1.0]
/instruments/navradio[n]/gs-deviation-deg: [-0.7 to 0.7]
/instruments/navradio[n]/gs-deviation-norm: [-1.0 to 1.0]
Does this seem reasonable to all concerned?
Yes - allmost. But please don't clamp the xxx-deviation-deg to +/-10.0 or
+/-0.7.
When I look at my KI525a HSI (real life, not simuland), the glideslope markers
move out of sight when I am more than 0.7deg off the center of the glide
slope. That will be hard to model when the values are clamped to +/- 0.7.
In other words: The glideslope receiver notices deviations of more than 0.7
degrees off center, only the display shows the range of +/-0.7deg.

The CDI needle can move a little further out, than the outermost dot on the
scale. Here, also the receiver detects offsets of more than 10deg, just the
display is limited to full deflection.

So my question is: why clamp the xxx-deviation-deg properties at all?
Shouldn't it be a duty of the instrument to define where it hits the border?

Torsten

------------------------------------------------------------------------------
John Denker
2009-01-03 17:12:48 UTC
Permalink
Post by Torsten Dreyer
So my question is: why clamp the xxx-deviation-deg properties at all?
Shouldn't it be a duty of the instrument to define where it hits the border?
I completely agree with TD.

Currently there is no clamp on the GS deflection in
navradio.cxx. The existing clamp on CDI deflection is
unrealistic and should be removed IMHO.

=============

BTW t
A) The existing navradio implements target radial and
actual radial for the azimuth (CDI) which is realistic
for some instruments
B) It doesn't implement the corresponding things for
the glideslope.

Is there anything unrealistic about item (B)? Is there
any instrument/system in the world that expects the
nav tuner to put out the GS angle in degrees?

The only MK-VIII known to me is a GPWS, and I very much
doubt it needs to know any GS info beyond the usual
position within the GS beam as a fraction of the
peg-to-peg sector.

Is there any realistic market for gs-deg information?

Should model instruments depend on info not available
to the corresponding RW instruments?


------------------------------------------------------------------------------
James Turner
2009-01-03 17:31:02 UTC
Permalink
Post by John Denker
Is there anything unrealistic about item (B)? Is there
any instrument/system in the world that expects the
nav tuner to put out the GS angle in degrees?
The only MK-VIII known to me is a GPWS, and I very much
doubt it needs to know any GS info beyond the usual
position within the GS beam as a fraction of the
peg-to-peg sector.
When I write 'Mk -VIII' I was assuming everyone realised I was talking
about the GPWS unit, since it's what I'm trying to fix, and the only
thing we have with that name in FG. And what it actually uses is mV
CDI deflection if driven by analogue volts, or ARINC 429 words
expressing DDM. The problem is driving this sensibly from what we have
at present from navradio.cxx.

If I add a gs-deviation-norm, I'll assume (based on the INSTALL docs
for the Mk-VIII, and the ICAO spec) that their 'dots' correspond to
the half- and full- sector deviations for both LOC and GS purposes,
i.e two dots to full-sector. But that's entirely a problem for me and
the GPWS code :) That would be absolutely fine - as you say, the
fraction of peg-to-peg is what's needed - but we don't have that at
this moment.

I greatly dislike working in 'peg-to-peg percentage multiplied by
3.5', which is what we sort of have right now, for the GS, and 'peg to
peg multiplied by 10' for the LOC. Especially when people then *think*
that those numbers correspond to degrees, when we have pretty clearly
established that quite often they do not :)

The Mk-VIII is guilty of all of the above - assuming degrees, *and*
being oblivious to the factor of 5 multiple. Since the author was
clearly not a fool, I don't think better documentation is a
'sufficient' fix, but normalising to -1..1 is. (And letting the actual
panel instrument clamp, i.e remove the clamping in navradio.cxx ...
but that needs to be done with considerable care, lest we break
something)

James



------------------------------------------------------------------------------
Alex Perry
2009-01-03 19:10:15 UTC
Permalink
Post by Torsten Dreyer
Post by James Turner
/instruments/navradio[n]/heading-deviation-deg: [-10.0 to 10.0 for a
VOR, -2.5 to 2.5 for a LOC] (i.e no 'magic 4' multiple for LOCs)
/instruments/navradio[n]/heading-deviation-norm: [-1.0 .. 1.0]
/instruments/navradio[n]/gs-deviation-deg: [-0.7 to 0.7]
/instruments/navradio[n]/gs-deviation-norm: [-1.0 to 1.0]
Does this seem reasonable to all concerned?
The CDI needle can move a little further out, than the outermost dot on the
scale. Here, also the receiver detects offsets of more than 10deg, just the
display is limited to full deflection.
Yeah, please don't clamp any of the deviation properties to the
nominal instrument full scale. The instrument designer will determine
how much travel exists beyond full scale (if any) and apply the
appropriate value. I think a clamp is a good idea, but at maybe
double full scale, which is probably slightly beyond where the
electronic drivers give out anyway.

------------------------------------------------------------------------------
John Denker
2009-01-24 07:29:40 UTC
Permalink
Post by Alex Perry
Post by Torsten Dreyer
The CDI needle can move a little further out, than the outermost dot on the
scale. Here, also the receiver detects offsets of more than 10deg, just the
display is limited to full deflection.
That is the sensible approach.
Post by Alex Perry
Yeah, please don't clamp any of the deviation properties to the
nominal instrument full scale. The instrument designer will determine
how much travel exists beyond full scale (if any) and apply the
appropriate value. I think a clamp is a good idea, but at maybe
double full scale, which is probably slightly beyond where the
electronic drivers give out anyway.
Again: Yes, that is the sensible approach.

As you know, I coded it that way. My version of navradio.cxx has
been doing it that way for many weeks. However.........


I am now having second thoughts. It turns out that there are some
aircraft in the FG fleet that still _depend_ on navradio.cxx to
clamp the swing of the CDI needle. The "flagship" c172p is an
example. If the needle goes offscale it disappears, which is
ugly, unfriendly, and wildly unrealistic.

This is a dilemma. This is a direct conflict between compatibility
and long-term desirability.

Here's how I propose to proceed:
*) The new heading-needle-norm property will remain unclamped.
Any instrument designer who wishes to use this property will
presumably know what he's getting.
*) The old un-normalized heading-needle property will revert
to being clamped to [-10 .. 10]. Therefore any old instruments
will continue to work, and it will be safe to deploy the new
navradio.cxx without requiring any per-aircraft or per-instrument
fiddling.

============

If anybody has a better idea, please let me know.

Continue reading on narkive:
Loading...