Hello Andras,
thanks for your feedback. I think I'll have to read your posting twice,
as I'm short in time, but I already found some appealing ideas (because
they almost match what I have in mind :-))
Major A wrote:
> This also means that UNICOM must be voice, not text-only as on
> VATSIM. This is most easily accomplished by creating unmanned idle ATC
> posts on given frequencies across the globe, running on the ATC
> server(s).
I'm not sbolutely sure but I believe different countries have different
UNICOM frequencies. Germany uses 123,45, as far as I remember we used
different frequency on a trip to Denmark ....
> On VATSIM, pushing PTT does NOT disable radio reception on that radio,
> which is unrealistic. Make sure PTT turns the corresponding COM audio
> output off. On the issue of realistic distortions -- can anyone tell
> me what modulation air communication uses?
Amplitude Modulation - that's why the sound is that bad .... I thought
we'll get close to reality by employing a GSM codec :-)
> Latency on the voice channel is not a problem, since radio
> communication is always PTT-based. So I would go for the simplest
> option of using the speex codec and a simple TCP-based protocol (maybe
> using the streaming parts from IAX2?)
Fine. My idea was to set up an Asterisk server with a conference
application that opens one channel for every frequency in use. The
difficulty lies in the fact that frequencies are being reused around
the world. Someone has to come up with an idea on how to add the
current location to the data stream without disturbing the voice
channel (preferably while staying interoperable with unlocated voice
communication). We could then calculate the distances between aircrafts
and radio stations in order to determine where communication is
possible.
> On VATSIM, there is a general bad habit of not checking ATIS.
This can happen in real life as well. The C150 I took for most of my
trainig hours doesn't have a radio that goes below 118 MHz. You still
easily can fly cross-country in such a bird if you behave polite to the
FIS personnel :-)
> [...] VATSIM pilot clients, to the best of my
> knowledge, only send information on the position and attitude of the
> aircraft, along with rates of change. It wouldn't be very hard to
> include second derivatives (accelerations), which would, for instance,
> make take-off and landing rolls look much smoother in case of network
> load problems
This also could serve as a means to _reduce_ network load. The aircraft
client could send position plus a velocity- and an acceleration-vector.
_Everyone_ who participates in the play, including the aircraft that
sends these vectors, could then do a prediction based on a pre-defined
algorithm on how the respective aircraft is supposed to move. The
aircraft then does not need to send a single position update unless the
internal calculation determines that the actual movement doesn't match
the prediction any more.
But this is not voice-ATC stuff any more .... ;-)
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
