Re: [Flightgear-devel] OT: question about Atlas build - missing files on MacOS X

[James Turner]

On Tuesday, February 4, 2003, at 01:38  am, Ima Sudonim wrote:


I can't find any information on building Atlas from CVS to use with 
flightgear. I've modified configure.ac to get past autogen.sh and 
configure. I have the following build problems.

I'll give Atlas a shot today :-)



LoadPng.o: Where/what is png.h


Get libPng via Fink, hopefully Atlas has a ./configure --with-libpng= 
option, otherwise we'll need to add one.
'fink install libpng' or pick it from the list using dselect. Or you 
can just build it from source, Apple already supply 'zlib' which libpng 
requires.

MapMaker.o: What is dirent.h? The problem is the uint parts of this 
struct
This sounds a bit strange, possibly pulling in  will help 
(as Bert Dreihuis suggested) but I think that should have been done 
automatically..

I am using MacOS 10.3 with 12/2002 dev tools, gcc 2.95, latest plib, 
fg from cvs, simgear is recent

Is there any reason you're using 2.95 rather than 3.2? It's a much 
better compiler for C++
And unlike other OS-s, switching back and forth is simple.

H&H
James

--
That which does not kill me has poor aim


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] Return of the BPCVS

[John Check]

On Monday 03 February 2003 5:54 pm, Julian Foad wrote:
> Arnt Karlsen wrote:
> > On Sun, 02 Feb 2003 19:39:28 -0500,
> > John Check <[EMAIL PROTECTED]> wrote in message
> >
> > <[EMAIL PROTECTED]>:
> >>Base package cvs is back, now with more cvsweb
> >>
> >>http://rockfish.net/cgi-bin/cvsweb/
> >
> > ..imaginary folder like directory icons?  ;-)
>
> I see this effect too.  No image is displayed by " HREF="FlightGear/"> WIDTH="20" HEIGHT="22">"; just an empty square.  Maybe the path
> "/doc/..." is wrong or inaccessible.
>
> - Julian
>

Okay, now I know what he meant. Maybe I'll just pull the plug.

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] Partially Offtopic: Help open up the FSDprotocol

[Bert Driehuis]

On Tue, 28 Jan 2003, Mathew McBride wrote:

> I have some more info on this in a seperate thread:
> http://seneca.me.umn.edu/pipermail/flightgear-devel/2003-January/014707.html

My message is probably fully off-topic here, but then again; maybe
not...

I'm a rookie here. Don't want to know the virtual damage I've done to
the virtual planes I flew. I'd like to throw in a few observations based
on comments you made, and some of my own.

> 1) IVAO. This is more of a european network, but with much better
> connections in other parts of the world (Australia). I belive they use their
> own server, and you can download it from
> http://www.ivao.org/network/default.htm. I use this network

They've got a nice assortment of info in addition to the virtual live
world. But it once again struck me that there is no open (as in, at
least GPL/LGPL, or BSD styled) repository of aviation related data. I've
pieced together some databases myself (country registration prefixes,
airline data, aircraft data, ACARS codes), but I rate this collection
Personal Use because of unclear licensing of the base data gleaned from
web sites (and the way data is presented, such as on the IVAO web site,
makes it pretty obvious that you're not supposed to feed that data into
your personal database).

Is there any web site that has a meta-database of available info, that
specifies license restrictions? Am I overlooking any sources of data?
Would a Sourceforge project dedicated just to avdata make sense to
anyone?

It's all window dressing as far as I'm concerned, but it is nice to be
able to augment
  PH-HZF HV0992 H1 #M1BPRG/FNHV0992/DTEHAM,19R,77,014711,29C98F
with
  B737-8K2 delivered 06/11/99
  Flight: Transavia 992
  Destination: Schiphol Apt, Amsterdam, The Netherlands
  Runway: 19R
  ETA: 01:47:11
without having to perform a gazillion of web lookups, followed by
parsing the HTML response.

> Some other FG comms stuff on my long term radar:
> 1) ACARS. Hey, aircfaft don't communicate over voice completely. They do use
> Text comms some times.

In my copious spare time, I've been playing the sorcerors apprentice at
DSP coding and come up with a Unix tool to decode ACARS from a radio
receiver with a sound card. It sort of works (I'm not really impressed
with the number of packets I decode successfully, but when working from
recorded chirps my code seems to beat SkySweeper, and it certainly beats
WACARS and KRACARS that I never got to work properly :-)

Given how sparse ACARS info is, I think that free-text is the only
viable part of ACARS to emulate. Even something as simple as a position
report comes with many options to represent the data (some conflicting
with observed practice; possibly as a result of comms error on board,
but not showing up through parity error or CRC failure).

As an illustration of just how perilous parsing ACARS data is without
access to the airline specs, I've seen WACARS decode a weather report
for traffic enroute to EGLL into "Wanxian - China" simply because "WXN"
was in the string.

The biggest brick wall I run into is lack of redistributable reference
data; and, of course, lack of documentation on the data that travels
ACARS.

My personal impression is that most people collecting and publishing
such data got bitten by con artists taking off with the fruits of their
labor; a practice that seems common in the MSFS and MSTS communities; in
that sense (as well as many others), FlightGear is a breath of fresh
air.

Anyway, I'm looking for guidance on how to approach this ACARS toy
project of mine. It's easy enough to register the thing on SourceForge
and put some code out, but it's a different thing altogether to bundle
it with enough data to make sense of the packets, and not run afoul of
licensing issues. The DSP bits probably make more sense in the HAM
community, but the ACARS data components drag if firmly back into the
realm of the aviation emulators (how's about the AI Tower Controller
warning you about conflicting traffic that actually is overhead of where
you're playing FlightGear, or even warning that TransAvia flight that
there is a rogue Cessna in the pattern and would the Cessna turn left
_now_?).

Cheers,

-- Bert
-- 
Bert Driehuis -- [EMAIL PROTECTED] -- +31-20-3116119
If the only tool you've got is an axe, every problem looks like fun!


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] OT: question about Atlas build - missingfiles on MacOS X

[Bert Driehuis]

On Mon, 3 Feb 2003, Ima Sudonim wrote:

> I can't find any information on building Atlas from CVS to use with
> flightgear. I've modified configure.ac to get past autogen.sh and
> configure.

I'm not a MacOS X user myself, but meddling with configure.ac is deep
magic :-)

> I have the following build problems.
>
> LoadPng.o: Where/what is png.h

You'll need to install libpng and the associated header files.

> MapMaker.o: What is dirent.h? The problem is the uint parts of this

It's an interface to the operating system directory structure. On older
MacOS's it was an emulation of a UNIX interface, on MacOS X it probably
maps directly to the underlying BSD code. It's there to support the
opendir(3) family of library calls.

The uint_xxx stuff can be dragged in by including  before
.

Cheers,

-- Bert
-- 
Bert Driehuis -- [EMAIL PROTECTED] -- +31-20-3116119
If the only tool you've got is an axe, every problem looks like fun!


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] TACANs (was DAFIFT progress)

[David Megginson]

James Turner writes:

 > That said, the UPP TACAN is not listed in NAV.TXT, if you know of any 
 > others, please let me know and I'll check. (Or did you mean UUP, 
 > 'Uplands'?)

That's it -- I was giving the ident from memory.


All the best,


David

-- 
David Megginson, [EMAIL PROTECTED], http://www.megginson.com/

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

[Flightgear-devel] OT: question about Atlas build - missing files on MacOS X

[Ima Sudonim]

I can't find any information on building Atlas from CVS to use with 
flightgear. I've modified configure.ac to get past autogen.sh and 
configure. I have the following build problems.

LoadPng.o: Where/what is png.h
MapMaker.o: What is dirent.h? The problem is the uint parts of this 
struct
struct dirent {
	u_int32_t d_fileno;		/* file number of entry */
	u_int16_t d_reclen;		/* length of this record */
	u_int8_t  d_type; 		/* file type, see below */
	u_int8_t  d_namlen;		/* length of string in d_name */
#ifdef _POSIX_SOURCE
	char	d_name[255 + 1];	/* name must be no longer than this */
#else
#define	MAXNAMLEN	255
	char	d_name[MAXNAMLEN + 1];	/* name must be no longer than this */
#endif
};
OutputGL.o: where's all this stuff defined?

I am using MacOS 10.3 with 12/2002 dev tools, gcc 2.95, latest plib, fg 
from cvs, simgear is recent

thank you, Ima

make  all-recursive
Making all in data
make[2]: Nothing to be done for `all'.
source='LoadPng.cxx' object='LoadPng.o' libtool=no \
depfile='.deps/LoadPng.Po' tmpdepfile='.deps/LoadPng.TPo' \
depmode=gcc /bin/sh ../depcomp \
g++ -DHAVE_CONFIG_H -I. -I. -I/Desktop/FlightGear/fgdev9.1/include   
-DFGBASE_DIR=\"/Desktop/FlightGear/fgfsbase\"  -g -O2 -c -o LoadPng.o 
`test -f 'LoadPng.cxx' || echo './'`LoadPng.cxx
LoadPng.cxx:24: png.h: No such file or directory
make[2]: *** [LoadPng.o] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

g++ -DHAVE_CONFIG_H -I. -I. -I/Desktop/FlightGear/fgdev9.1/include   
-DFGBASE_DIR=\"/Desktop/FlightGear/fgfsbase\"  -g -O2 -c -o MapMaker.o 
`test -f 'MapMaker.cxx' || echo './'`MapMaker.cxx
In file included from /usr/include/dirent.h:64,
 from MapMaker.cxx:24:
/usr/include/sys/dirent.h:73: syntax error before `;'
/usr/include/sys/dirent.h:74: syntax error before `;'
/usr/include/sys/dirent.h:75: syntax error before `;'
/usr/include/sys/dirent.h:76: syntax error before `;'
make: *** [MapMaker.o] Error 1
[:src/atlas/src] root# make ./MapPS.o

[:src/atlas/src] root# make ./OutputGL.o
source='OutputGL.cxx' object='OutputGL.o' libtool=no \
depfile='.deps/OutputGL.Po' tmpdepfile='.deps/OutputGL.TPo' \
depmode=gcc /bin/sh ../depcomp \
g++ -DHAVE_CONFIG_H -I. -I. -I/Desktop/FlightGear/fgdev9.1/include   
-DFGBASE_DIR=\"/Desktop/FlightGear/fgfsbase\"  -g -O2 -c -o OutputGL.o 
`test -f 'OutputGL.cxx' || echo './'`OutputGL.cxx
OutputGL.cxx: In method `void OutputGL::closeOutput()':
OutputGL.cxx:76: `png_structp' undeclared (first use this function)
OutputGL.cxx:76: (Each undeclared identifier is reported only once
OutputGL.cxx:76: for each function it appears in.)
OutputGL.cxx:76: parse error before `='
OutputGL.cxx:78: `png_ptr' undeclared (first use this function)
OutputGL.cxx:81: `png_infop' undeclared (first use this function)
OutputGL.cxx:81: parse error before `='
OutputGL.cxx:82: `info_ptr' undeclared (first use this function)
OutputGL.cxx:84: `png_infopp' undeclared (first use this function)
OutputGL.cxx:84: parse error before `0'
OutputGL.cxx:88: implicit declaration of function `int setjmp(...)'
OutputGL.cxx:89: implicit declaration of function `int 
png_destroy_write_struct(...)'
OutputGL.cxx:94: implicit declaration of function `int png_init_io(...)'
OutputGL.cxx:95: `PNG_COLOR_TYPE_RGB' undeclared (first use this 
function)
OutputGL.cxx:96: `PNG_INTERLACE_NONE' undeclared (first use this 
function)
OutputGL.cxx:96: `PNG_COMPRESSION_TYPE_DEFAULT' undeclared (first use 
this function)
OutputGL.cxx:97: `PNG_FILTER_TYPE_DEFAULT' undeclared (first use this 
function)
OutputGL.cxx:97: implicit declaration of function `int 
png_set_IHDR(...)'
OutputGL.cxx:98: implicit declaration of function `int 
png_write_info(...)'
OutputGL.cxx:100: `png_byte' undeclared (first use this function)
OutputGL.cxx:100: `row_pointers' undeclared (first use this function)
OutputGL.cxx:100: parse error before `*'
OutputGL.cxx:102: parse error before `)'
OutputGL.cxx:106: implicit declaration of function `int 
png_write_image(...)'
OutputGL.cxx:110: implicit declaration of function `int 
png_write_end(...)'
make: *** [OutputGL.o] Error 1


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] TACANs (was DAFIFT progress)

[James Turner]

On Monday, February 3, 2003, at 07:40  pm, David Megginson wrote:


It's more complicated than that.  DME receivers (which are UHF) can
use TACANs to get distance information -- usually, you do that by
tuning in a fake paired VOR frequency.  For example, if I tune my DME
to 108.8, or slave it to a NAV radio tuned to 108.8, I get distance
readings from the UPP TACAN at CYOW, even though there's no VOR.  Can
the paired frequency be deduced from the channel?


Right now, I think the answer is no. I was hoping that such TACANs 
simply listed the fake frequency in their FREQ column, but I've got 
checks for that in place and I'm not hitting them (just got that code 
working).

That said, the UPP TACAN is not listed in NAV.TXT, if you know of any 
others, please let me know and I'll check. (Or did you mean UUP, 
'Uplands'?)

H&H
James

--
Whenever a friend succeeds, a little something in me dies.


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

[Flightgear-devel] Possible change in FAA FTD rules

[Alex Perry]

From: nafi <[EMAIL PROTECTED]>
 

FTD NPRM to Increase Oversight

The FAA is proposing to amend current flight simulation device qualification 
requirements to include increased regulatory oversight of all operators. While the FAA 
proposal does not cover personal computer-based aviation training devices (PCATD), it 
would increase regulatory oversight of flight schools and establish a mandatory 
simulator quality assurance program. 

The notice of proposed rulemaking (NPRM) would establish FAR Part 60-Flight Simulation 
Device Initial and Continuing Qualification and Use. The FAA also proposes to modify 
Part 1-Definitions and Abbreviations, Part 61-Certification: Pilots, Flight 
Instructors, and Ground Instructors, Part 141-Pilot Schools, and Part 142-Training 
Center.

Part 60 would also require the mandatory use of an FAA-approved quality assurance 
program that requires pilot schools and training centers to adopt certain flight 
simulation device maintenance regimes, recurrent inspections and maintenance 
evaluations, operating procedures, and record keeping and reporting to identify and 
correct any deficiencies. It also requires the development of all-inclusive manuals 
that fully describe the procedures to be followed. 

For years, general aviation pilot schools have used flight simulation devices to 
enhance flight training and proficiency under the FAA's current rules and advisory 
circular guidance without incurring any known safety problem. The use of flight 
simulation devices gives general aviation pilots access to important procedures and 
proficiency training opportunities in a safe environment that helps enhance safety. 

The proposed flight simulation device regulations will significantly increase the 
complexity and operational costs to all general aviation pilot training schools that 
use flight simulation devices for pilot training, pilot evaluation, or required flight 
experience, according to AOPA. The costs associated with the proposed regulations 
could cause many general aviation pilot schools, which cater to these types of 
aircraft operators, to discontinue providing necessary simulator-based training, thus 
undermining general aviation's use of simulators as an effective training and 
proficiency tool.

The text of the NPRM is available at www.aopa.org/whatsnew/regulatory/regfsd.html. The 
FAA is accepting public comments on the NPRM until February 24, 2003. Comments may be 
sent to the Docket Management System, U.S. Department of Transportation, Room Plaza 
401, 400 Seventh Street, SW., Washington, DC 20590-0001, or can be sent through the 
Internet to http://dms.dot.gov  . 


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

[Flightgear-devel] BAC Lightning F.Mk.6

[David Culp]

> > Lightnings would be so cool, another high performance jet. Like some
> > people over here described it, "its just a large engine with wings
> > tacked on". Guess thats a good way to describe it.

Try this, it's a blast.  It uses BAC Lightning F.Mk.6 metrics, Rolls-Royce 
Avon 301 engines, and T-38 coefficients.

If you figure out how to get the afterburners lit, please let me know. (But as 
you can see, this airplane does fine without them.)

http://home.attbi.com/~davidculp2/BAC/lightning-set.xml
http://home.attbi.com/~davidculp2/BAC/lightning.xml
http://home.attbi.com/~davidculp2/BAC/Avon301.xml

Dave Culp

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] Return of the BPCVS

[Julian Foad]

Arnt Karlsen wrote:

On Sun, 02 Feb 2003 19:39:28 -0500, 
John Check <[EMAIL PROTECTED]> wrote in message 
<[EMAIL PROTECTED]>:

Base package cvs is back, now with more cvsweb

http://rockfish.net/cgi-bin/cvsweb/


..imaginary folder like directory icons?  ;-)


I see this effect too.  No image is displayed by ""; just an empty square.  Maybe the path 
"/doc/..." is wrong or inaccessible.

- Julian


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] Harrier Data

[Jon Stockill]

On 3 Feb 2003, Matthew Johnson wrote:

> Lightnings would be so cool, another high performance jet. Like some
> people over here described it, "its just a large engine with wings
> tacked on". Guess thats a good way to describe it.

I can arrange as many cockpit pics as we need for this, with the added
bonus that there's no seat in it at the moment, making photography rather
less cramped.

> So he is OK with cockpit renditions?

No problem with that at all - this is the reason he game me the pics.

> What planes do you have access to in the Museum? Maybe a better way to
> ask is what do they have there?

Chipmunk, Vampire, Jet Provost, Lightning, Scout, lots of stuff in the
workshop. I don't know who owns all the aircraft, but I've been told that
access to the lightning isn't a problem.

Their web site is here:

http://www.syam.freehosting.net/

I'm reading through this harrier manual at the moment - there's an awful
lot of information (it's about 2" thick, A4 sized, with pullouts for A3
diagrams).

The diagrams look very useful for putting together a 2d panel background,
onto which we can add instruments which is where the photos should come in
handy.

-- 
Jon Stockill
[EMAIL PROTECTED]


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] Harrier Data

[Matthew Johnson]

On Mon, 2003-02-03 at 08:47, Jon Stockill wrote:
> I had a trip to the South Yorkshire Air Museum this weekend - and now have
> silly amounts of data.
> 
> I currently have in my grubby little mitts a Harrier GR3 aircrew manual,
> and a cd with a boat load of cockpit photos.
> 
> I also have the offer of access to a lightning F3 to get cockpit photos
> should we want to model one (apparently an awful lot of the instruments
> are common to both).
> 

Lightnings would be so cool, another high performance jet. Like some
people over here described it, "its just a large engine with wings
tacked on". Guess thats a good way to describe it.

> I'll go through the Harrier photos and see if I can get any straight on
> instument pics that are useable for modelling. The photographer is happy
> for the pics to be used to generate a cockpit model, but would rather not
> have the photos openly accssible on the net, due to some of his pics being
> used without consent before.
> 

So he is OK with cockpit renditions? 

> If there's info that anyone desperately needs, I'll see what I can come up
> with.

What planes do you have access to in the Museum? Maybe a better way to
ask is what do they have there?

Matt
PS Is it worth getting a flightgear-modeler mailing list? I don't care
either way, just a thought...


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] TACANs (was DAFIFT progress)

[Jon Stockill]

On Mon, 3 Feb 2003, David Megginson wrote:

> It's more complicated than that.  DME receivers (which are UHF) can
> use TACANs to get distance information -- usually, you do that by
> tuning in a fake paired VOR frequency.  For example, if I tune my DME
> to 108.8, or slave it to a NAV radio tuned to 108.8, I get distance
> readings from the UPP TACAN at CYOW, even though there's no VOR.  Can
> the paired frequency be deduced from the channel?

ISTR there being a lookup table for this in the back of the british
isles/north atlantic en route supplement - I'll have a look when I get
home.

-- 
Jon Stockill
[EMAIL PROTECTED]


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] TACANs (was DAFIFT progress)

[David Megginson]

James Turner writes:

 > So, armed with the knowledge that TACANs are UHF, not VHF, and that 
 > they use military channel codes, I went and looked at the DAFIF fields 
 > again ... and guess what the field two after FREQ is? Yeah, it's the 
 > channel. Boy do I feel silly.

It's more complicated than that.  DME receivers (which are UHF) can
use TACANs to get distance information -- usually, you do that by
tuning in a fake paired VOR frequency.  For example, if I tune my DME
to 108.8, or slave it to a NAV radio tuned to 108.8, I get distance
readings from the UPP TACAN at CYOW, even though there's no VOR.  Can
the paired frequency be deduced from the channel?


All the best,


David

-- 
David Megginson, [EMAIL PROTECTED], http://www.megginson.com/

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

re: [Flightgear-devel] DAFIFT progress

[David Megginson]

James Turner writes:

 > - I uncovered some API inconsistencies between the fixlist and the 
 > navlist (some routines taking degrees, others radians, for lat / lon) : 
 > which do we prefer? (I'll fix the offenders)

In general, we prefer degrees on the user side and radians on the
math/physics side.


All the best,


David

-- 
David Megginson, [EMAIL PROTECTED], http://www.megginson.com/

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] TACANs (was DAFIFT progress)

[James Turner]

On Monday, February 3, 2003, at 05:30  pm, Mally wrote:


The UK ones appear to be TACANs at Odiham and St Athan:
http://www.nightstop.freeola.com/beacon%20decodes/beacon%20decodes.htm


Thanks for this, I've now done a bit more background reading on TACANs..


In the netherlands:
TWN
SSB
At least the UK ones all have the 'TAC' prefix on my SimCharts. So ...


You are right, its TACAN.
They will be replaced by ILS this year.


So, armed with the knowledge that TACANs are UHF, not VHF, and that 
they use military channel codes, I went and looked at the DAFIF fields 
again ... and guess what the field two after FREQ is? Yeah, it's the 
channel. Boy do I feel silly.

Of course, this leaves one problem / task (especially for the A4 and 
harrier pilots): does anyone fancy adding a TACAN receiver to the 
radio-stack? I'll add in another field on the FGNav class, and do the 
right thing for VORTACs, now that the light-bulbs have switched on in 
my addled head. Actually, it'll be two fields: an unsigned int channel 
ID and a flag for X / Y band, whatever they are. Oh, and these things 
can be mobile, for example on a carrier. If anyone fancies doing that, 
FGNav list is going to need some work, it's not quite set up for navids 
that don't stay put.

H&H
James

--
The lack of planning on your part does not constitute to an emergency 
on mine


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] DAFIFT progress

[Bert Driehuis]

On Mon, 3 Feb 2003, Erik Hofman wrote:

> Just out of curiositty, does EHAM already contain the 6th runway?

It's not finished yet, but they were testing the ILS last week. I heard
some misgivings about actually having to land on a runway before getting
certification for the ILS ;-)

Cheers,

-- Bert

-- 
Bert Driehuis -- [EMAIL PROTECTED] -- +31-20-3116119
If the only tool you've got is an axe, every problem looks like fun!


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] DAFIFT progress

[Erik Hofman]

James Turner wrote:

Okay, so I have FG working with the DAFIFT NAV and WPT data (replaces 
default.fix and default.nav). Now, I need some advice:

Just out of curiositty, does EHAM already contain the 6th runway?

Erik


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] DAFIFT progress

[Erik Hofman]

James Turner wrote:


- I'm getting a bunch of odd records from the DAFIFT NAV file: they have 
no frequency defined (which renders them rather useless except as 
waypoints). They appear on my SimCharts from Jeppesen, along with 
frequencies. Examples:


In the netherlands:
TWN
SSB

At least the UK ones all have the 'TAC' prefix on my SimCharts. So ...


You are right, its TACAN.
They will be replaced by ILS this year.

Erik


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] DAFIFT progress

[Erik Hofman]

James Turner wrote:

- I'm getting a bunch of odd records from the DAFIFT NAV file: they have 
no frequency defined (which renders them rather useless except as 
waypoints). They appear on my SimCharts from Jeppesen, along with 
frequencies. Examples:


In the netherlands:
TWN
SSB


Those are millitary airfields which are open for civillian transport 
between 17.00 hour and 8.00 hour and in the weekends. That might be part 
of the problem.

Erik


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] DAFIFT progress

[Mally]

> In the UK:
> SAT
> ODH

> At least the UK ones all have the 'TAC' prefix on my SimCharts. So  
> does anyone know what these things are? I'm guessing it's something 
> military related. The have frequencies in the VOR range (eg 117.7 Mhz 
> based on SimCharts). Now, I can happily ignore them, but I'd like to 
> know what I'm looking at before I do that.

The UK ones appear to be TACANs at Odiham and St Athan:
http://www.nightstop.freeola.com/beacon%20decodes/beacon%20decodes.htm

Mally



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.449 / Virus Database: 251 - Release Date: 27/01/03

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

[Flightgear-devel] DAFIFT progress

[James Turner]

Okay, so I have FG working with the DAFIFT NAV and WPT data (replaces 
default.fix and default.nav). Now, I need some advice:

- What things to test that may have broken. I've extended 'testnavs' 
quite a bit and everything in there works, but this is a minute sample 
compared to what's out there. So, any suggestions for things to try? 
Other than 'fly around a bit, tuning the radios lots'..

- I uncovered some API inconsistencies between the fixlist and the 
navlist (some routines taking degrees, others radians, for lat / lon) : 
which do we prefer? (I'll fix the offenders)

- I'm getting a bunch of odd records from the DAFIFT NAV file: they 
have no frequency defined (which renders them rather useless except as 
waypoints). They appear on my SimCharts from Jeppesen, along with 
frequencies. Examples:

In the UK:
	SAT
	ODH

In the US:
	VBG
	TOL
	SSC
	PAM

In the netherlands:
	TWN
	SSB

At least the UK ones all have the 'TAC' prefix on my SimCharts. So  
does anyone know what these things are? I'm guessing it's something 
military related. The have frequencies in the VOR range (eg 117.7 Mhz 
based on SimCharts). Now, I can happily ignore them, but I'd like to 
know what I'm looking at before I do that.

- The current code detects the datafile format dynamically, so with a 
trivial patch to fg_init, I can dynamically use FG_ROOT/DAFIFT instead 
of FG_ROOT/Navaids  if the DAFIFT files are present ... assuming I do 
this, shall I go ahead and send my changes out for some wider testing? 
Curt / Dave, which of you is less busy?

- Next stop, airways  and I almost have a 737 to fling about them, 
thanks to Dave Culp :-)

H&H
James

--
That which does not kill me has poor aim



___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

[Flightgear-devel] Harrier Data

[Jon Stockill]

I had a trip to the South Yorkshire Air Museum this weekend - and now have
silly amounts of data.

I currently have in my grubby little mitts a Harrier GR3 aircrew manual,
and a cd with a boat load of cockpit photos.

I also have the offer of access to a lightning F3 to get cockpit photos
should we want to model one (apparently an awful lot of the instruments
are common to both).

I'll go through the Harrier photos and see if I can get any straight on
instument pics that are useable for modelling. The photographer is happy
for the pics to be used to generate a cockpit model, but would rather not
have the photos openly accssible on the net, due to some of his pics being
used without consent before.

If there's info that anyone desperately needs, I'll see what I can come up
with.

-- 
Jon Stockill
[EMAIL PROTECTED]


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

[Flightgear-devel] some 737 goodies

[David Culp]

Here some 737 files I've been working on.  First the general config.

http://home.attbi.com/~davidculp2/737/737-set.xml
http://home.attbi.com/~davidculp2/737/737-sound.xml

It's a JSBSim model with a generic electrical system, it's own sound config, a 
transparent mini panel, a hud based on the engineering hud, and the 747 
exterior.  The flight dynamics and engine models are at:

http://home.attbi.com/~davidculp2/737/737.xml
http://home.attbi.com/~davidculp2/737/CFM56.xml

It flies nicely, although not everything works yet as I haven't broken the 
code on the flaps.  Anyway, takeoff power is about 90% throttle, rotate at 
about 140 knots, climb at about 15 degrees pitch and about 180 knots to 1500 
feet, then raise flaps and climb at 210 knots to 3000 feet, then climb at 250 
knots (about 12 degrees pitch) to 1 feet, then climb at 300 knots (about 
8 degrees pitch until mach 0.75, then hold 0.75 to level-off.

For landing, downwind with flaps 1 and 200 knots,  base with flaps 10 and 170 
knots, final with gear down, flaps 30 and 140 knots.  The flaps aren't 
working properly so you'll have to fake it.

The 2D HUD, based on the engineering HUD, is at:

http://home.attbi.com/~davidculp2/737/hud/default.xml
http://home.attbi.com/~davidculp2/737/hud/Instruments/hudladder.xml
http://home.attbi.com/~davidculp2/737/hud/Instruments/hudcard.xml
http://home.attbi.com/~davidculp2/737/hud/Instruments/instrlabel.xml
http://home.attbi.com/~davidculp2/737/hud/Instruments/fgtbi.xml

I expanded the ladder a bit to help with precise pitch control; the card 
removes the radio altitude display for now; the instrlabel config removes 
beta and nlf, which weren't working anyway, removes lat/lon and attempts to 
display speed.  The fgtbi is shortened a little to make room for the 
mini-panel, which is at:

http://home.attbi.com/~davidculp2/737/737-trans-mini-panel.xml
http://home.attbi.com/~davidculp2/737/737-trans-mini-bg.rgb

The texture is the extant transparent texture without the ghost-edge on top.  
The first instrument is a standard Boeing 450-knot airspeed indicator:

http://home.attbi.com/~davidculp2/737/asi-450-knot.xml
http://home.attbi.com/~davidculp2/737/asi-450-knot.rgb

The MACH and KNOTS odometer-style displays aren't installed.  The needle 
functions until about 170 knots and then wanders (compared to the hud 
display).  The calibration has been checked closely, so I'm not sure what the 
problem is there.  The Vmo/Mmo needle, also called a "barber pole" doesn't 
quite work yet.  I'm trying to have it start at 350 knots and then decrease 
with altitude, linearly, to about 260 knots at 5 feet.  That's a good 
approximation.  Unfortunately I haven't quite grokked the config.  My next 
step is to add an internal "bug" and four external ones.

The 737 flap control is at:

http://home.attbi.com/~davidculp2/737/737-flaps.xml
http://home.attbi.com/~davidculp2/737/737-flaps.rgb

Slick, but not yet fully functional.  Again a grokking problem.

http://home.attbi.com/~davidculp2/737/N1-0.xml
http://home.attbi.com/~davidculp2/737/N1-1.xml

The above N1 gauges are based on the standard N1 gauge, with only a minor 
change.  n1-0.xml  uses property  /engines/engine[0]/n1  and n1-1.xml uses 
property /engines/engine[1]/n1.  Neither work yet, but they look slick.

Dave Culp



___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] [PATCH] switching views (trivial)

[Jim Wilson]

Hi Geoff,

I've got several changes and fixes to the viewer code, one of which changes
the view manager to allow what you are describing.  It is actually a little
more flexible than just reversing,  you can select the view through a
property.  This allows going forward, backward and directly to any specific
view without using a special command.

It's been done for a couple weeks now.  I'll try and get it together and
submit the changes in the next day or two.

Best,

Jim

Geoff Reidy <[EMAIL PROTECTED]> said:

> Hi all,
> 
> I always wanted to be able to hit shift "v" to be able to cycle through 
> views the other way.
> 
> That way you can toggle between 2 views without having to go through 
> them all, which can be uncomfortable if you're about to run into a 
> mountain or something.
> 
> It looked like the code was all there to do it so I have made these 
> minor modifications to enable it. It works fine for me but be warned I 
> know just enough C++ to be dangerous ;)
> 
> Diffs are against current cvs.
> 
> There is one patch for the base:
> home.pacific.net.au/~greendog/flightgear/rev-view-cycle-fgfsbase.diff
> 
> and one for Flightgear:
> home.pacific.net.au/~greendog/flightgear/rev-view-cycle-FlightGear.diff
> 


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

[Flightgear-devel] [PATCH] switching views (trivial)

[Geoff Reidy]

Hi all,

I always wanted to be able to hit shift "v" to be able to cycle through 
views the other way.

That way you can toggle between 2 views without having to go through 
them all, which can be uncomfortable if you're about to run into a 
mountain or something.

It looked like the code was all there to do it so I have made these 
minor modifications to enable it. It works fine for me but be warned I 
know just enough C++ to be dangerous ;)

Diffs are against current cvs.

There is one patch for the base:
home.pacific.net.au/~greendog/flightgear/rev-view-cycle-fgfsbase.diff

and one for Flightgear:
home.pacific.net.au/~greendog/flightgear/rev-view-cycle-FlightGear.diff

Regards,
Geoff


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Re: [Flightgear-devel] [OT] Graduate Schools

[Arnt Karlsen]

On Sun, 02 Feb 2003 19:05:19 -0600, 
JD Fenech <[EMAIL PROTECTED]> wrote in message 
<[EMAIL PROTECTED]>:

> I know it isn't quite development related, but you guys seem like the
> best folks to ask this question...
> 
> I'm a fifth-year senior, CompSci major with physics and math minors...
> I have an interest in cosmology/astronomy/simulation/etc.
> I'm looking for a good grad school where I can put these aptitudes to
> work, except my GREs weren't exactly stellar (they were average). 
> Since a lot of you are in the academic areas, you probably have a far
> better idea than me of where would be good to look at. I only have one
> major stipulation and that's basically that I don't want to go any
> further west than I am now (especially not California!) Perferably in
> the South.

..your track record here, may be worthwhile to put on your cv, 
to bring up your academic score.  

..for example, we don't yet have a helicopter fdm.  And, we require
OpenGL which again means we require rather high spec video hardware. 

..writing a chopper fdm, or a low spec (ncurses, svga, framebuffer?) 
video interface is a _tangible_ thing for human resource admin etc 
trained staff, who recruits people at your favorite university etc.

..for ideas: http://autopilot.sourceforge.net/ 
or http://decopter.sourceforge.net/ 

..another set of ideas is model the space shuttle launch, and show
whether or not the last crash could have been prevented by aborting 
the launch after that foam piece was seen hitting the left wing, 
or, show whether a Twin Otter is controlable after shedding its 
tail after a midair, or, whether that Air France Concorde could 
have survived riding a 747 wing vortice.  
And, we have athmosfaeres on most planets around here.  ;-)

..I think a _tangible_ "Here."-response to a "Show Me!" from 
your average non-engineer academic, and documented in classic 
academic report style, is worthwhile.  It also allows building 
your own _custom!_ academic career launch pad.

> Thanks,
> JD
> 
> --
> "The modern definition of 'racist' is someone who is winning an
> argument with a liberal."
>  --Peter Brimelow

..heh, I have great fun proving them (liberals) racists.  ;-)

-- 
..med vennlig hilsen = with Kind Regards from Arnt... ;-)
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel