Re: [Flightgear-devel] Voice ATC
"Vivian Meazza" wrote: > I have today sent a bug fix to Erik for some outstanding problems with the > multiplayer implementation, but which also includes extrapolation of the > client position using 1st and 2nd derivatives. Now, I'm thrilled to hear that, this is definitely the right (TM) direction ! 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
RE: [Flightgear-devel] Voice ATC
Major A wrote Snip ... > The last issue (though not very important) is visualization. Though > not a voice issue, it would have to be dealt with as part of the > system sooner or later. 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 (I have seen aircraft on landing roll jumping back by > several 100ft on VATSIM...). I have today sent a bug fix to Erik for some outstanding problems with the multiplayer implementation, but which also includes extrapolation of the client position using 1st and 2nd derivatives. This patch was developed in collaboration with Gregor Richards, Oliver Schroeder, Mathias Froelich, and tested by AJ Mcleod. > I also don't like the way aircraft visual > models are dealt with in VATSIM: only a code describing the aircraft > type is transmitted, leaving the client software to find a suitable > model. I'm very much leaning towards each client submitting the rough > geometry of the airframe, including reference point, to the ATC > servers so that other clients can download and show them (this would > only have to be done at logon time and can be asynchronous, so I don't > expect bandwidth problems). Only the copyright issues would have to > clarified. As a suggestion, for copyright-protected airframes, one > could transmit a few main points on the airframe only so that the > other users can anticipate the extent of the aircraft without seeing > its exact shape. > Currently the Multiplayer code ignores aircraft which are not in the local system. There is no intention to change this atm. Vivian --- 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
Re: [Flightgear-devel] Voice ATC
> 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 That's why it would have to be multiple virtual ATC posts. The distance checking we would have to do anyway would make sure that only those pilots can talk to each other who are in radio range from each other. AFAIK, the USA has different UNICOM across regions. Thinking about it, a vast improvement over VATSIM would be if all frequencies were open whenever someone is tuned to them -- in VATSIM, if a controller disconnects, there no longer is voice connection between the pilots on that frequency. This would also do away with the need for virtual ATC posts for each UNICOM. > > 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 :-) OK, that's the easiest case as far as the handling of signal quality (no shifting as in SSB) and pile-ups (non-trivial in FM) go: just add the signals, with amplitudes related to distance (ok, it's getting complicated already as this means either dedicated downstreams to each pilot or multicasts of each transmission with mixing done by the pilot clients...). Andras --- 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
Re: [Flightgear-devel] Voice ATC
> I'm not sure whether TCP is a good idea. After all TCP tries > retransmitting packets over and over even on a temporary line problem. > Voice packets are not that important. If transmissions are lost, it's > not a problem for voice and might even add to the realism. ;-) True -- I was (wrongly) under the impression that IAX2 uses TCP only, that's why I suggested this. Since IAX2 works very well in my experience, I think it'll form a good basis for voice ATC. The only disadvantage it has compared to SIP is that it hasn't been declared a standard, but other than that, it's better in every respect. Andras --- 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
Re: [Flightgear-devel] Voice ATC
Christian Mayer wrote: The usual SIP based VoIP is -- IIRC -- a P2P network that uses a central server (the SIP server) to establish the connection. If you are already thinking of Asterisk you might have a good look there. Chances are that it implements already the required stuff. SIP has problems with NAT though, since the control and media streams are on seperate ports (and the control messages contain the source address) - something like IAX doesn't suffer from that limitation - everything goes over the same port - therefore it'll be as NAT friendly as the MP code. -- Jon Stockill [EMAIL PROTECTED] --- 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
Re: [Flightgear-devel] Voice ATC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ralf Gerlich schrieb: > Regarding NAT problems: Have a look at http://www.ietf.org/rfc/rfc3489.txt > > It describes STUN, a protocol which can be used for traversing NATs > using UDP, even if both partners are behind a NAT. There's a similar > thing for TCP and it works even with multiple NATs except for some types. > > P2P would allow a multicast-like distribution, taking load and traffic > costs off the server. This could be critical especially in case of voice > streams. However, that could be tricky to implement and I have no idea > of P2P implementations at all. The usual SIP based VoIP is -- IIRC -- a P2P network that uses a central server (the SIP server) to establish the connection. If you are already thinking of Asterisk you might have a good look there. Chances are that it implements already the required stuff. CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFDwq0ulhWtxOxWNFcRAouPAJ49+7muxlwJWLIRTuKYw01mo/0iBgCgh1Uk Xb2KdQpMD8nO5KVhWr0owzM= =kC2I -END PGP SIGNATURE- --- 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
Re: [Flightgear-devel] Voice ATC
Major A schrieb: 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?). Just make sure it traverses NAT routers transparently! And I don't think P2P connections are required -- all voice had better go through the servers. I'm not sure whether TCP is a good idea. After all TCP tries retransmitting packets over and over even on a temporary line problem. Voice packets are not that important. If transmissions are lost, it's not a problem for voice and might even add to the realism. ;-) Regarding NAT problems: Have a look at http://www.ietf.org/rfc/rfc3489.txt It describes STUN, a protocol which can be used for traversing NATs using UDP, even if both partners are behind a NAT. There's a similar thing for TCP and it works even with multiple NATs except for some types. P2P would allow a multicast-like distribution, taking load and traffic costs off the server. This could be critical especially in case of voice streams. However, that could be tricky to implement and I have no idea of P2P implementations at all. Regards, Ralf --- 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
Re: [Flightgear-devel] Voice ATC
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
Re: [Flightgear-devel] Voice ATC
> I'd be very happy to hear your opinion on VATSIM, as I've ben trying to > push the idea of human voic ATC within FlightGear. I _do_ have some > ideas how voice ATC could/should be realized but my ideas didn't fall > on prolific soil, OK, here's the breakdown. I've used VATSIM with FS2004+FSInn and X-Plane+XSquawkBox. Most importantly, make sure there is no text mode. On VATSIM, you can go online either using text or using voice, which means that there are users who are not aware of any voice transmissions, and also that voice users are required to read text transmissions (which is a bit much to expect on a manual short final, for instance). Last night, in particular, I was faced with the situation that a text-only jet airliner popped up in front of me from below while I was 4nm final or so -- he had no idea that I had been cleared to land on the voice channel, and ATC had probably forgotten that my Dash7 was a lot slower than the jet. 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). 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? 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?). Just make sure it traverses NAT routers transparently! And I don't think P2P connections are required -- all voice had better go through the servers. Which brings me to another problem -- the VATSIM ATC client needs open UDP ports on any firewall/router that separate it from the internet. This is bad as it requires reconfiguration of existing network installations, so I think it's important to make sure everything traverses NAT and firewalls transparently. On VATSIM, there is a general bad habit of not checking ATIS. This is probably because ATC are not really forced to issue ATIS, and there is usually no voice ATIS (I think it must be recorded manually). Since FlightGear already has code for voice ATIS, it should be possible to create voice ATIS on all published ATIS frequencies. This can (should -- as part of the ATC logon procedure) be set by the responsible ATC, and in its absence the current METAR can/should be relayed. The latter is required because otherwise you have no good way of working out QNH/base pressure for an unmanned airport. The last issue (though not very important) is visualization. Though not a voice issue, it would have to be dealt with as part of the system sooner or later. 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 (I have seen aircraft on landing roll jumping back by several 100ft on VATSIM...). I also don't like the way aircraft visual models are dealt with in VATSIM: only a code describing the aircraft type is transmitted, leaving the client software to find a suitable model. I'm very much leaning towards each client submitting the rough geometry of the airframe, including reference point, to the ATC servers so that other clients can download and show them (this would only have to be done at logon time and can be asynchronous, so I don't expect bandwidth problems). Only the copyright issues would have to clarified. As a suggestion, for copyright-protected airframes, one could transmit a few main points on the airframe only so that the other users can anticipate the extent of the aircraft without seeing its exact shape. What do you think? Andras --- 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
Re: [Flightgear-devel] Voice ATC
Major A wrote: > I'd love to see human ATC (like VATSIM) becoming reality one day, so I > can ditch FS2004 and X-Plane and fly online with fgfs. Has there been > any progress on that so far? If there's interest, I can tell you what > I like and what I dislike about the way it's done in VATSIM, though I > probably haven't got the time to help with the actual coding. I'd be very happy to hear your opinion on VATSIM, as I've ben trying to push the idea of human voic ATC within FlightGear. I _do_ have some ideas how voice ATC could/should be realized but my ideas didn't fall on prolific soil, 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
Re: [Flightgear-devel] Voice ATC
> Maybe I am out of the subject. Was somebody > intersted in taking the development of the voice ATC. > If no I will be very happy to help and to take it and > to start to dig/read/document/propose > solutions/develop about the voice ATC subject. By voice ATC, do you mean computer-generated or human ATC? I'd love to see human ATC (like VATSIM) becoming reality one day, so I can ditch FS2004 and X-Plane and fly online with fgfs. Has there been any progress on that so far? If there's interest, I can tell you what I like and what I dislike about the way it's done in VATSIM, though I probably haven't got the time to help with the actual coding. > P.S . Before the list changed its location I was > receiving diggest list...no after the location of the > list was changed I receive all the posts one by one > and I have my mail box full all the time with 100 > flightgear posts which is harder and harder for me to > follow :-). How can I switch back to digest mode? Click on the URL at the bottom of the post, you can reset your list options from there. Andras --- 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
