Steven Beeckman wrote:
Hi,
I don't know if it's of any use to you guys (and girls), but I've come
across Ivy on the net
(<http://www.tls.cena.fr/products/ivy/index.html>). From this site:
it's certainly interesting, but I'm not sure about implementing
efficient protocols using a merely text-based approach, particularly not
without broadband connections ?
You'd probably finally end up applying compression, anyway.
Usually, a protocol should be lightweight - most of them do not
even send FULL "messages" but rather use connection-less
transmissions of single packets where possible.
Ivy is a simple protocol and a set of open-source (LGPL) libraries and
programs that allows applications to broadcast information through text
messages, with a subscription mechanism based on regular expressions.
Ivy libraries are available in C, C++, Java and Perl, on Windows and
Unix boxes and on Macs. Several Ivy utilities and hardware drivers are
available too.
It's certainly a good idea to really look into it, which I didn't
yet do, by the way ...but, I interpret the following:
Ivy is currently used in research projects in the air traffic control
and human-computer interaction research communities as well as in
commercial products. It is also taught to CS students.
as somethin that EuroControl is/are currently trying to do:
developing means to standardize voice-less communications,
so they want to make most of the standard voice transmissions
unnecessary by simply tranmitting text-based instructions using
a separate data link, these instructions show then up on the
CDU, where the crew can confirm each individual instruction -
without ever having to talk back to ATC.
While the controller in front of the RADAR screen could simply
provide instructions by using a simple GUI - this would have
several advantages, because you would standardize all
transmissions using technical means,which would also mean
that several new possibilities are created, so you can for
example easily maintain & display a 'history' or rather 'log' about
all the transmissions that were made, and all transmissions that
were confirmed.
This is one of the first steps to automatize Air Traffic Control,
so I think this is not really about a protocol for aircraft -> ATC
telemetry, but rather it's an attempt to reduce standard
voice communications and computerize the whole thing:
Basically, they want to do what most flight simulators with *basic* ATC
support already do: provide a graphically interface to the possible
instructions, so that communications can ulitmately become automatized.
So, as the flight crew you end up seeing a simple GUI where you're
told "climb to FL120" - depending on whether you confirm or not,
this dialogue extends ...
Likewise, you would have a standard set of transmissions that you
can make: "request lower".
This means, that as soon as this technology is really 'ready for action'
simulating it within a flight simulator, would require to look back into
the source code that was written years ago :-)
By the way: if you simply wait for "free flight" to be introduced,
this whole VIRTUAL/AI ATC thing could become obsolete, anyway ;-)
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
