James,

I was perusing the cvs logs online for this source file and this code goes
back quite a ways ...

http://cvs.flightgear.org/viewvc/source/src/Navaids/navlist.cxx?view=log

Revision *1.7* -
(view<http://cvs.flightgear.org/viewvc/source/src/Navaids/navlist.cxx?revision=1.7&view=markup>)
(download<http://cvs.flightgear.org/viewvc/source/src/Navaids/navlist.cxx?revision=1.7>)
(annotate<http://cvs.flightgear.org/viewvc/source/src/Navaids/navlist.cxx?annotate=1.7>)
- [select for 
diffs]<http://cvs.flightgear.org/viewvc/source/src/Navaids/navlist.cxx?r1=1.7&view=log>
*Mon Jul 19 18:02:00 2004 UTC* (4 years ago) by *curt*
Branch: 
*MAIN*<http://cvs.flightgear.org/viewvc/source/src/Navaids/navlist.cxx?view=log&pathrev=MAIN>
Changes since *1.6: +53 -6 lines*
Diff to previous
1.6<http://cvs.flightgear.org/viewvc/source/src/Navaids/navlist.cxx?r1=1.6&r2=1.7>

Ed Sirett submitted a patch to consider antenna orientation when searching
for localizers.  I further hacked this to support GS and DME transmitters
(although Robin's DME transmitter data doesn't convey orientation
unfortunately.)

So it looks like you've stumbled on a chunk of code that could use some
tidying up.  It's strange, hdg_deg seems totally unused.  Clearly something
weird there crept in.  It does seem to make sense to use it below as you
suggest.  For DME's maybe we always want the closest one anyway, but the
code as it stands could arbitrarily penalize one over the other if there are
two dme's on the same frequence for a single runway.

Since this code came from a user patch originally, I'd be happy to give you
the green light to improve it.

Regards,

Curt.



On Fri, Aug 15, 2008 at 3:30 PM, James Turner wrote:

> I encountered the following code, in the middle of
> FGNavList::findNavFromList:
>
> ======================================================
>
>         // LOC, ILS, GS, and DME antenna's could potentially be
>         // installed at the opposite end of the runway.  So it's not
>         // enough to simply find the closest antenna with the right
>         // frequency.  We need the closest antenna with the right
>         // frequency that is most oriented towards us.  (We penalize
>         // stations that are facing away from us by adding 5000 meters
>         // which is further than matching stations would ever be
>         // placed from each other.  (Do the expensive check only for
>         // directional atennas and only when there is a chance it is
>         // the closest station.)
>         int type = station->get_type();
>         if ( d2 < min_dist &&
>              (type == 4 || type == 5 || type == 6 || type == 12 ||
> type == 13) )
>         {
>             double hdg_deg = 0.0;
>             if ( type == 4 || type == 5 ){
>                 hdg_deg = station->get_multiuse();
>
>             } else if ( type == 6 ) {
>                 int tmp = (int)(station->get_multiuse() / 1000.0);
>                 hdg_deg = station->get_multiuse() - (tmp * 1000);
>
>             } else if ( type == 12 || type == 13 ) {
>                 // oops, Robin's data format doesn't give us the
>                 // needed information to compute a heading for a DME
>                 // transmitter.  FIXME Robin!
>             }
>
>             double az1 = 0.0, az2 = 0.0, s = 0.0;
>             SGGeod geod = SGGeod::fromCart(aircraft);
>             geo_inverse_wgs_84( geod, station->get_pos(), &az1, &az2,
> &s);
>             az1 = az1 - station->get_multiuse();
>             if ( az1 >  180.0) az1 -= 360.0;
>             if ( az1 < -180.0) az1 += 360.0;
>             // penalize opposite facing stations by adding 5000 meters
>             // (squared) which is further than matching stations would
>             // ever be placed from each other.
>             if ( fabs(az1) > 90.0 ) {
>                 double dist = sqrt(d2);
>                 d2 = (dist + 5000) * (dist + 5000);
>             }
>         }
>
> =========================================================
>
> Now, there's two bad things here: (I think)
>  - in the DME case (type == 12 or 13), hdg is left 0.0
>  - hdg, having been computed, isn't then used: I assume it should
> replace the 'station->get_multiuse' on this line:
>        az1 = az1 - station->get_multiuse();
>
> It'd be great if someone who knows more about this code could comment
> on how 'important' it is, since it's only doing the right thing in the
> ILS/LOC case (the GS will be wrong because 'multiuse' contains other
> data, and DME because multiuse is empty)
>
> It feels like this ought to cause visible weirdness with nav-radios,
> but I don't have a strong understanding for how 'bad' this might be.
>
> Maybe we only actually encounter this code for ILS transmitters, so
> the bug is masked?
>
> Any light that can be shed, would be appreciated.
>
> James
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>



-- 
Curtis Olson: http://baron.flightgear.org/~curt/
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Reply via email to