Re: [Flightgear-devel] FlightGear voice communication
Lloyd, $ROOT/extensions.conf is created by the script in the same folder you are executing the script then moved to /etc/asterisk. Here is the content of extensions.conf: (this file must be in /etc/asterisk) [general] static=yes writeprotect=yes ; [default] #include fgcom.conf include = fgcom DAHDI is here for sync purpose required by meetme (the plugin used by Asterisk to manage chat rooms) Have you generated the fgcom.conf file ? it is correctly placed in /etc/asterisk ? I just tried to connect to your server but the connection is refused. You should open port 4569 UDP Feel you free to contact me personally if you need more assistance. Regards, Clément -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FlightGear voice communication
As a point from a user: I am getting very worried about this discussion about every body has the possibility to setup his own FGCom server disabling the guest:guest account and only accept registered pilot on their server. To my knowledge this issue has been discussed for FGFS very extensively already several times - and it was decided not to do that. For FGCOM I would be against that even stronger - because with FGCOM we want to attract more and more users to use the multiplayer environment - I guess such restrictions will achieve the opposite: - I myselfe would have problems to open again another (or even many!) world wide accessible account(s) - with my data stored by unknown people on unknown servers with unknown security! I guess you all heard about the current security issues being raised right now worldwide (NAS, Facebook, etc etc pp) - and: what would it really help? As described that bad guy can always get a new account - and bad words are not as bad as bad security. - till now I see FGCOM as the ideal tool for multiplayer because of the limited range with many realistic frequencies - but still being able to talk worldwide to anybody! (there is already now a (little) problem having just two FGCOM servers! - How shall that work in future? Changing the server for each multiplayer event? And prior to that investigate which users are permitted? Or whenever you go to another airport? Or country? How do you explain the pilots how to do that and when and why? Would'nt it be easier then just to use e.g. mumble (at least there you can change the group on the fly - many users ask us (ATC'S) already now to use that easy to handle tool instead of the realistic but complicated frequency changes in FGCOM! - etc. -etc And believe me: Doing ATC at EDDF for 4 days a week with 4h each session I know that problem of babies all the way from nice kids being unable to communicate with grown ups up to using absolutely abusive language! There is only one solution to that: Warn them, then neglect them, ask all others to neglect them too -- and most important: Do not even try to discuss with them! Come to EDDF and you will see: It works!! Also remember: We have the Neglect-button in the PilotList - use that also for FGCOM to blank any user out you do not want to hear! And that decision may be kept for each user himself! And it works within seconds - just compare that to the needed administrative efforts to get somebody removed/locked from a server! Please - please - do not kill the very positive social aspects of the multiplayer environment because of a few misbehaving people! Thanks for working on improving the FGCOM - I like it - see how it gets used more and more on: http://www.emmerich-j.de -- EDDF-Triangel Movies! -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear voice communication
Hi Clément,
I'm not convinced adding a string is relevant, in real life you haven't a
message you tell you if you are correctly connected to X frequency. The
only way to check is to look at your radio, in FG it's the same.
seams we have different experience in fgcom. And there will be no indication of
the intersection problem? pls be so kind and approach a intersecting frequency
from the the intersecting side.
[intersecting frequency]course[target frequency]-
and try to communicate with the target frequency.
I agree that in real life there are no problems.
But in reality we are sitting in flightgear and want to improve the fgcom tool.
Which has some borders:
- selecting a chatroom by frequencies
- from the source(apt.dat) of the frequency position
The question is how to deal with that to improve the simulation grade of
flighgear.
I don't discus the update process of the apt.dat here, but how log it will
take to update the frequency intersection errors ?
I don't understand the purpose to communicate with a ground frequency over a
distance of 100nm.
I see we share the same worries about the bandwidth, I agree we need to have
a solution for sharing FGCom bandwidth. It seems IAX trunk is the solution
but I don't know how to setup this for now.
connection(trunking) 2 servers will not save any bandwidth it raise the total
use.
client1 -- server1 == server2 -- client2
Let the client dial the server direct. The sum of traffic is not raised and
split to several server.
client2--server2-- client2
Then anyone can setup an fgcom server and handle as much frequencies he can.
Also Your server at home could participate in the production operation.
dialbook.select(position, frequency, host, phonenumber){
...
}
fgcom.dial(user,password,host,phonenumber){
if( lastHost != host ){
iaxc_register(user, password, host);
}
iaxc_call(phonenumber);
}
Regards,
Dirk
--
Introducing Performance Central, a new site from SourceForge and
AppDynamics. Performance Central is your source for news, insights,
analysis and resources for efficient Application Performance Management.
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear voice communication
Clément, The easier solution is the last one, it can be really easy to implement this in FGCom standalone/integrated and totally transparent for our users. As example, we can decide that fgcom01.flightgear.org handles frequencies 118.0 to 124.9 fgcom02.flightgear.org handles frequencies 125.0 to 131.9 fgcom03.flightgear.org handles frequencies 132.0 to 137.0 A simple test in FGCom standalone/integrated could be: if (freq 118.0 freq 125) server = fgcom01.flightgear.org if (freq 124.9 freq 132) server = fgcom02.flightgear.org if (freq 131.9) server = fgcom03.flightgear.org We can also check if a server is up or down and skip it if needed, and redistribute the frequency flow on remaining servers. All of this is doable and totally transparent for the user. @Dirk: I would have your agreement to do that, is it ok for you ? pls no hard-coded server decision. Implement a dial book which reads a file(cvs) like: ID,icao, frequency, lat, lon, type, name, range, server, phonenumber The entity should be the radio station. We have to manage the bandwidth so selecting server by frequency will not really fit. In future it means exchange stations between servers to balancing the load. The fgcom client can download the dialbook on start up, so we can provide a fast update rate. may bee http/git/terrasync. A main question is which source we use. IMO Where is fgcom relevant. On our most atced airports ! There are atcs who dealing with the matters. So if there are frequency problems they would fix it if they could. I think we have the power to manage our own dialbook Database. We should start with the actual version of the postions.txt get it in our next dialbook DB and then manage it through git merges. So we can get much faster closer to reality(at our atced areas). updates through apt.dat would be a hard thing. I cant see a mistakeless update process. apt.dat = unique dialbook_ID my bee ICAO Freqency Type = dialbook_ID We have the Neglect-button in the PilotList - use that also for FGCOM to blank any user out you do not want to hear! Unfortunately this is not doable... at least, not doable without a registration system. I agree it is impossible unit flightgear has a unique user id. dirk -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear voice communication
Hi all, Registration can be really usefull if some of our user are considering there is too many children on the frequency. Ebery body has the possibility to setup its own FGCom server disabling the guest:guest account and only accept registered pilot on their server. In this case server admin can choose who can use his server or not. He just need to add an account for each user he is accepting to use his server. If you need to restart FGCom, just un-check then re-check the Enable checkbox in FGCom dialog, that's done ! :) I'm not convinced adding a string is relevant, in real life you haven't a message you tell you if you are correctly connected to X frequency. The only way to check is to look at your radio, in FG it's the same. FGCom standalone is not yet ready for the new FGCom server because he use an old positions.txt file. If you upgrade your server now every OpenRadar/FGCom standalone user won't be able to connect to most of frequencies and here is my main problem... FGCom has been created with some bugs and now it's time to solve them but it require to loose the compatibility with old FGCom. That's something really hard to deal. As resume: - If you upgrade your server OpenRadar/FGCom standalone will be unsable until positions.txt is upgraded - If we upgrade positions.txt, your server will be unusable for OpenRadar/FGCom standalone - Until positions.txt is not upgraded OpenRadar/FGCom cannot use fgcom.flightgear.org As example, today if you use FGCom integrated and you are connected to fgcom.flightgear.org you need to set 118.175MHz (which is correct in real life) in order to be connected to Carpentras LFNH Twr. If you are connected to delta384.server4you.de you need to set 118.170MHz (which is wrong in real life) in order to be connected to Carpentras LFNH Twr. As you can see it looks like a headache... I think we are forced to break the old compatibility for a time (once every client are up to date everything will works as expected). But this new feature has revelated others projects. If we choose to develop another communication system we will break the system again... A solution could be to release a new FGCom standalone (used by OpenRadar) compatible with fgcom.flightgear.org with FG 3.0.0. Once FG (and so FGCom) 3.0.0 are released you can upgrade your server. For information I've create a script which do all the work for you, you just need to setup a debian system, then execute the script, take a long coffee, then come back and you have a working FGCom server. The script is available at: http://clemaez.dyndns.org/build_fgcom_server.sh I see we share the same worries about the bandwidth, I agree we need to have a solution for sharing FGCom bandwidth. It seems IAX trunk is the solution but I don't know how to setup this for now. @Adrian: feel you free to inform me about your works for radio propagation - fgcom. We will see what we can do and if the server side can manage it. Regards, Clément -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear voice communication
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi! Nice work! Will it be possible in the future to use different sound devices for fgcom and the simulator to get only the fgcom voice via the soundcard with the headset connected? For example using the main soundcard for fg and a usb headset for the communications. - -- gpg-id: D31AAEEA http://www.setho.org/people -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) iQEcBAEBAgAGBQJSFPFRAAoJEMMw//HTGq7q9p4IAJC5Cs9NA1Kk8X8xLC+mG26l J3i5DGXfj0ZvYLF12+qvmRJyJ+WO7r5VpeoaSpabywyaDbPgRpm8U2NOOL2MO9GM 17LuYQbc3IBwI1rlMGVB0KZWheP0zDz5iKNt4gMTz5MVx6c2OqkxedbuGinBbcao 0/W9QXCTgv5F4OIGRD3lVjTrlBtNxAC4iVWRgdLbC5qCRFsfaCCkiyfLHD2yFg2U ux4m4LennF2f3YJTLyliTXnlyLYtB0hRGG2LssLw8Wb+jeFqj+yu826Vg/pj83lv zeMcBMJroFKkf9aBw3KfMv3qp7TyvTnfjHrrj3X7zTxNnujeXWbYxUUYZXyLjXI= =PVZr -END PGP SIGNATURE- -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear voice communication
On Aug 21, Clement de l'Hamaide wrote: Hello FGCom standalone is not yet ready for the new FGCom server because he use an old positions.txt file. If you upgrade your server now every OpenRadar/FGCom standalone user won't be able to connect to most of frequencies and here is my main problem... FGCom has been created with some bugs and now it's time to solve them but it require to loose the compatibility with old FGCom. That's something really hard to deal. https://gitorious.org/~bxn/fg/bxns-fgcom contains a modified fgcom (the standalone client) which has the same changes as the one embedded in the FlightGear git (range of communication as a function of aircraft altitu- de limited between 20 and 100 nm, support for 25 kHz steps frequencies, up to date source for positions of airports and frequencies e.g. apt.dat version 1000 revision 20131327). OpenRadar can use this modified fgcom and only needs the new phonebook, which is also in the repository above. Tests and feedback are welcome. The new positions file contained in the repository cannot be used with a previous version of fgcom. For information I've create a script which do all the work for you, you just need to setup a debian system, then execute the script, take a long coffee, then come back and you have a working FGCom server. The script is available at: http://clemaez.dyndns.org/build_fgcom_server.sh You should probably add this script to your fgcom repo clone and request a merge. -- bug -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear voice communication
On Aug 15, Dirk Dittmann wrote: Hello - Dialbook get Nummer : the search should not return the first frequency, the nearest in Range is more suitable. True, it currently returns the first in alphabetical order. As Clement answered, adding ranges, even simple one, should narrow the choice of returned. - Thinking about center controller: the dialbook could summarize all frequencies of the control area and dials one number on the server. So we have one desk for the center. Especially for OpenRadar it will be an interesting feature. What is 'center controler'? Do you mean Air Control Center i.e. En Route long distance or other FIR frequencies? - As main problem i see in the ranges of the frequencies: the apt.dat provides no info about ranges. And there are a lot of intersections between frequencies. apt.dat provides a type for each frequency (the 5x code on the line of each freq). I thought about defining a range for each type (say 20 nm for TWR freq = type 54, 10 nm for GND freq = type 53), but if it is acceptable for ground frequencies (which rarely go over a few nm) it is not for towers or approaches which can have very different ranges (at least in real life). For the overlap in the frequencies, yes there are a lot currently. It should be better with the range depending on altitude (I have a patch against fgcom to add that to the standalone fgcom as Clement already did it for the embeeded fgcom), but may not be enough. So on the long term adding ranges to frequencies based on their type is probably needed too. Approaching EDDP from east is no fun for the controller. The pilot dials to all other airports in the near until it intercepts the ils. Must be very nice if there are some ground frequencies he reaches when approaching :) IMO we should maintain a own dialbook. May bee based on apt.dat (or more realistic infos ???) + manual correction of used(atced) airports. And for this airports we need a working solution to increase the fun for atc pilot. You can find the VFR frequencies at the ICAO website. Integrating that to apt.dat would be a big work, but I would help if apt.dat was maintained and distributed in a more collaborative manner (a git repo for example). fgcom's (the standalone one) data comes from apt.dat, so the source is apt.dat. This is the point where realism meets fg reality, we have hopefully one atc at the airport and he needs a 100nm range frequency at the tower. It is the case, except when the tower frequency overlaps with another station nearby because of one having a too long range. We can fix that :) All frequencies could have the real range and each airport gets a special frequency all in one (100nm). So we can play real and real. As said, this means addind the ranges to each freq. Either with a brutal rule (such as any GND freq, never talks over 10 nm range) or using range numbers from a source (apt.dat). BTW, flightgear uses a very old apt.dat currently, this also does not help (Clement, this might even reintroduce some wrong data which is fixed in fgcom's positions.txt :)) -- bug -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear voice communication
On 16 Aug 2013, at 09:25, Adrian Musceac kanto...@gmail.com wrote: If you'd use my new radio propagation code, which is an improvement over what's already in git, range would be as close to reality as possible for all type of radio comms, be they VHF voice, VOLMET, ACARS, ADS-B, VOR/DME, radar, etc. My code takes into account not only terrain obstruction, altitude, distance, but also frequency and standard equipment capabilities. Now, IMHO, for the future it would be desirable to integrate voice comms into Flightgear itself, without the need to use Asterisk or other external tools. Some other simulators have this as default, minus the realistic propagation of course. Hmm, as far as I'm aware every other simulator and game which includes voice comms does so via some kind of helper library (or process) - whether it be TeamSpeak or Roger Wilco or whatever. I don't think the choice of VoIP technology is really important so long as the price is right (free), it supports our target platforms and is well maintained. Unfortunately iaxclient2 is a little lacking in the last part but at least it's open source so we can hack on it. (Of course right now the intergation between FlightGear and FGCom is a bit ugly, but that's exactly what Clement's code fixes, once I merge it) Having the centralised Asterix servers seems to work pretty well, and we've had no problems (so far) finding someone to host them - a purely P2P solution would be much more unreliable I think, in terms of NAT, people in different real-worl locations talking in the same simulated location, and so on. Of course getting the very accurate range modelling would be good, but it's quite tricky to reconcile that with modelling frequencies as a conference call - to be truly accurate we need each transmit / receive pair modelled as a distinct audio stream in terms of signal effects (as I suspect your code is capable of doing!), but that would either place massive loads on the server (especially as number of concurrent clients in a room increases, e.g. KSFO GND or BAY APPROACH), or bring us back to P2P solutions which are flaky. All my opinion of course, but I've some experience with trying to do arbitrary P2P between home connections (i.e NAT at both ends) and it very ugly to support. I'm always amazed how trouble-free our iaxclient + Asterix solution is. James -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear voice communication
Am Donnerstag, 15. August 2013, 21:52:34 schrieb Clement de l'Hamaide: Hi Clément, - bandwith: Indeed IAXClient has a function called void iaxc_set_silence_threshold(float thr); unfortunately, looking at source code this function does exactly the same as we are doing in FGCom source code : set input_volume to 0. So silent still sent over network. have a look at http://sourceforge.net/p/iaxclient/code/1466/tree/branches/2.1/lib/audio_encode.c#l272 line 272 audio_send_encoded_audio if silent stops encoding and return immediately. I think its controlled by the threshold and some filters ?? - share bandwith with other servers: Your solution seems to be not the better choice, what happens if someone fly during a long distance which require to disconnect from the current server then reconnect to the new one ? I think a better solution would be to investigate into IAX trunk, but it looks like we need to replace meet_me by confbridge... It require some skills that I haven't for now, if you want to investigate into this you are welcome ;) thx atm im out of time may bee winter. When im flying and dailing an new frequency i have 1-2 sec until i would recognise that the channel is not tuned. That's time enough to connect to a server and dial a number. Sending traffic from on server to another would raise bandwidth 3x. confbridge - nice for Air2Air to connect the aircraft bubble ;-) - As main problem I see in the ranges of frequencies: In the new integrated FGCom ranges is dynamically calculated depending of the altitude of the pilot/ATC in accordance to this formula : http://fr.wikipedia.org/wiki/Radiocommunication_a%C3%A9ronautique#Port.C3.A 9e_et_propagation (sorry only french page has the formula) mmh increasing the range for each station, increases the intersection problem. How can i select the right airport frequency ? EDDP119.700 51.421592 12.234473 LEIPZIG APP Leipzig-Halle EDDC119.700 51.1267213.769712 TWR Dresden EDDE119.700 50.975862 10.962116 GND Erfurt EDAH119.700 53.878399 14.140107 TWR Heringsdorf EDDP124.170 51.421592 12.234473 LEIPZIG APP Leipzig-Halle EDBM124.170 52.077322 11.625983 BERLIN RADARMagdeburg Dirk -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear voice communication
Dirk, - bandwith: Good catch ! indeed silent variable is set by the threshold, so it can be worth to investigate here. Once the current state of FGCom will be merged I will try to add this threshold function. - frequencies range: I understand your problem about multiple identical frequences but it seems the problem comes from our apt.dat file which is excessively out-dated. Looking at Jeppensen charts it appears that - EDBM doesn't transmit on 124.170 in real world : http://va-transaero.ru/files/charts/EDBM.pdf (look at last page) - EDDE doesn't transmit on 119.700 in real world : http://va-transaero.ru/files/charts/EDDE.pdf (look at last page) - EDDC doesn't transmit on 119.700 in real world : http://va-transaero.ru/files/charts/EDDC.pdf (look at last page) - EDAH doesn't transmit on 119.700 in real world : http://norway04.cfg023.de/charts/EDAH-Heringsdorf.pdf (look at first page) So finally in real world there is no frequencies conflict, the problem comes from our apt.dat file. For information the new fgcom.flightgear.org server use a dialBook generated with the last apt.dat (04/2013) and FGCom building is ready to use the last 5 number ( in real worlt 124.170 doesn't exist, it's 124.175 since we use 25KHz spacing) I hope apt.dat file will be updated as soon as possible. Regards, Clément -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear voice communication
- frequencies range: I understand your problem about multiple identical frequences but it seems the problem comes from our apt.dat file which is excessively out-dated. Looking at Jeppensen charts it appears that - EDBM doesn't transmit on 124.170 in real world : http://va-transaero.ru/files/charts/EDBM.pdf (look at last page) - EDDE doesn't transmit on 119.700 in real world : http://va-transaero.ru/files/charts/EDDE.pdf (look at last page) - EDDC doesn't transmit on 119.700 in real world : http://va-transaero.ru/files/charts/EDDC.pdf (look at last page) - EDAH doesn't transmit on 119.700 in real world : http://norway04.cfg023.de/charts/EDAH-Heringsdorf.pdf (look at first page) So finally in real world there is no frequencies conflict, the problem comes from our apt.dat file. For information the new fgcom.flightgear.org server use a dialBook generated with the last apt.dat (04/2013) and FGCom building is ready to use the last 5 number ( in real worlt 124.170 doesn't exist, it's 124.175 since we use 25KHz spacing) I hope apt.dat file will be updated as soon as possible. Yes you are right that the source is not along with the real-life. And it will take some time to adjust that. I'm not talking about the frequencies in EDDP its just an example what happens using the apt.dat source. I think in real world the stations have a well defined output power. So that they don't interact with there neighbours. Made a quick intersection test on the actual positions.txt file of fgcom. every station with every station on the same frequency. 6993 stations Range 50 nm : 3498 intersections Range 100 nm : 9262 intersections Range 150 nm : 16736 intersections Range 200 nm : 25734 intersections Range 250 nm : 35920 intersections Range 300 nm : 47650 intersections My vote stays for a dialbook layout: icao, frequency, lat, lon, type, name, range, server, number So fgcom can dial a number on a server, connect if in range to a station. And we can establish relay stations. work to do for this DB - Initially build by apt.dat source. ranges by station type according to real life. - Adding correction for the most atced airports( and neighbours ) in fg . - Adding one 100nm Range frequency for each Airport for ATC(all in one desk). - Summarize all center/radar frequencies to dial one number for the center- controller desk. fg should read this DB to display frequencies. fgcom should read it too ;-) openradar i don't know ? distribution : for me terrasync, then we can get a fast update rate of the dialbook. merge git delivered by terrasync. features: - split traffic to several server - less frequency intersection - better frequency coverage - high update rate - possibility to establish a center-controller desk Regards, Dirk -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear voice communication
Hi Dirk, Thanks you for your feedback ! I will try to bring you some answer. - bandwith: Indeed IAXClient has a function called void iaxc_set_silence_threshold(float thr); unfortunately, looking at source code this function does exactly the same as we are doing in FGCom source code : set input_volume to 0. So silent still sent over network. - share bandwith with other servers: Your solution seems to be not the better choice, what happens if someone fly during a long distance which require to disconnect from the current server then reconnect to the new one ? I think a better solution would be to investigate into IAX trunk, but it looks like we need to replace meet_me by confbridge... It require some skills that I haven't for now, if you want to investigate into this you are welcome ;) - Dialbook get number: This is already done in the new integrated FGCom - As main problem I see in the ranges of frequencies: In the new integrated FGCom ranges is dynamically calculated depending of the altitude of the pilot/ATC in accordance to this formula : http://fr.wikipedia.org/wiki/Radiocommunication_a%C3%A9ronautique#Port.C3.A9e_et_propagation (sorry only french page has the formula) Today I asked James to merge my clone into next branch, so this feature will be soon available. Regards, Clément -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear voice communication
Hi all, I've now implemented all what I wanted about FGCom. Now FGCom built-in is stable and fully working. As stated with James, it's planned to add the feature once 2.12 branch is created. Also Vivian will add the new dialog ( http://i83.servimg.com/u/f83/16/09/76/33/captur13.png ) in fgdata at same time. Usage and working: - In order to use FGCom built in you need to compile FG with -DENABLE-IAX=ON (default is OFF) then running FG with --enable-fgcom - You can set a server with --prop:/sim/fgcom/server=mydomain.com - Missing --enable-fgcom or disable-fgcom have the same effect : FGCom is not activated - You can switch FGCom server at run-time just by selecting a server in the server list available in the GUI dialog - You can use the Test Mode by checking the Test checkbox - You can enable/disable FGCom at run-time by checking Enable checkbox - Registration is working About registration: For those who want to use a private/restrictive FGCom server (Virtual Airlines ?), you can setup your own FGCom server and remove the guest user then add a username/password for your user. In this way, only allowed person can use your server. It's possible to connect this feature with a database (mySQL, PostGreSQL...) and a website. In this case you can setup a website with a registration webpage which add a record in your database then the user is automatically allowed to use your FGCom server (immediately, or after validation... depending how you want to add a record to your database) This is not directly related to FG development, but about website/asterisk dev, so feel you free to use the forum or contact me for more info. For remember, my clone is available at https://gitorious.org/~f-jjth/fg/f-jjths-flightgear @James: Feel you free to push my latest work from my topics/fgcom branch to the FG topics/fgcom branch Cheers, Clément -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear voice communication
Hi Pedro, Asterisk is not a peer-to-peer based infrastructure. Bandwidth cost is ~40kb/s by user (upstreamdownstream)Sound card is not required. The most important things for FGCom hosting is to be able to maintain the server once he is started :-) I'm saying that because a big update (but easy to manage) will be required once 850 terrain (or at least apt.dat) will be used as default in FG. Sorry for the long delay before reply and the small reply, I'm currently busy. For information James is ready to push the fgcom feature soon in topics/fgcom branch. Cheers,Clément -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear voice communication
Whats involved in hosting an fgcom/asteriks server ? Is it gonna eat the quota on my dedicated ? Can the server work with no soundcard ? Is it peer to peer ? Candidate is http://fgcom.freeflightsim.org alongside http://fgms.freeflightsim.org Hopefully with some client/server interaction.. Pete -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear voice communication
On 8 Jun 2013, at 16:28, Clement de l'Hamaide clem...@hotmail.fr wrote: Hi all, With help from Geoff and James I've successfully added FGCom feature to FlightGear. And thanks the Clement for tackling this. 1) Simultaneous calls snip If someone want to expand IAXClient library in order to manage simultaneous calls, please raise your hand ! I would say that would be 'quite' tough, but more likely we can run two instances of iaxclient simultaneously. 2) OpenAL context In order to avoid context conflict I've merged FGCom sound into global FG sound system. This mean that we can choose to redirect FGCom sound into our headphone and FG sound into our speaker. The question is: can we agree that FGCom sound is played on the same output than FG sound ? Again, if someone is ready to investigate OpenAL deeply, raise your hand. This one I care about, but on Mac stand-alone has the same issue. The fix on Mac is for me to create a non-OpenAL backend for iaxclient, either the PortAudio one or write a native CoreAudio one myself. Anyway this is just 'an enhancement', what you suggest is fine for now. BTW I suspect the iaxclient ALSA backend might give this feature trivially on Linux. I know very little about Linux audio, so I leave it to people there to experiment. Regards, James -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear voice communication
Jörg, Could it be possible to start 2 instances of FGCOM in the background (just with different ports) and thus be able to switch between those two from within FGFS? Ok in this case I will keep active COM1 and COM2, but keep in mind that you _can't_ listen to COM1 and COM2 at same time. Could there be a restart-button (just in case)? Of course, a new GUI dialog (designed by Vivian, thanks to him!) will come with FGCom In this GUI dialog you have a checkbox Enable FGCom, if you uncheck then re-check it the whole FGCom subsystem is reinitialized. James, I would say that would be 'quite' tough, but more likely we can run two instances of iaxclient simultaneously. It could be a solution, but I admit that for now I don't see how to achieve this. There still some work before releasing FGCom into next branch like: - Implement the isInRange() designed to detect if the freq still in range or not and hangup/re-call in case - Move the content of update() into helper in order to avoid copy/paste - Clean code (mostly done) This require only some hours of work, unfortunately I will be away from keyboard for the next week and freeze period comes at the end of the week... Frustrating isn't it ! :D Cheers, Clément -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear voice communication
Hi all, With help from Geoff and James I've successfully added FGCom feature to FlightGear. Therefore I'm facing to 2 limitations from IAXClient library. 1) Simultaneous calls IAXClient library has not be designed to handle simultaneous calls. So it's not possible to listen COM1 and COM2 at same time, or COM1 and NAV2... For NAV12 it's not dramatic because fgcom-server (Asterisk) is simply sending morse code, since FlightGear is already providing this feature we just need to admit taht FGCom feature is only used for COM but not NAV. For COM12 it's more problematic since we should be able to listen to COM12 at same time (at least for aircraft equipped by 2 COM stations) The question is: can we agree that FGCom is operating _only_ on COM1 ? If someone want to expand IAXClient library in order to manage simultaneous calls, please raise your hand ! 2) OpenAL context In order to avoid context conflict I've merged FGCom sound into global FG sound system. This mean that we can choose to redirect FGCom sound into our headphone and FG sound into our speaker. The question is: can we agree that FGCom sound is played on the same output than FG sound ? Again, if someone is ready to investigate OpenAL deeply, raise your hand. Let me know if these 2 limitations are not a sine qua non condition for FGCom integration into FG. IMO, I think that FGCom integration - even if it's limited to COM1 - is already a good step forward. I've also added record feature to FGCom (only for standalone binary) which make possible to record an ATIS message. That way, pilots can listen ATIS message from ATC like it's done in real life (at least in France, but I'm now aware that UK ATIS are TTS messages) If this feature is accepted, we need to disable ATIS messages generated by FG (only if FGCom is enabled) For information, on server side it works as follow : - If a record is present = play the record - Else = play a TTS (via Festival in Asterisk) containing current metar For those you want to test the current state, you need to compile FG from https://gitorious.org/~f-jjth/fg/f-jjths-flightgear/ = topics/fgcom branch Then run FG like : fgfs --enable-fgcom --airport=LFMV --com1=125.35 For now, my personal Asterisk server is used (clemaez.dyndns.org) and he is designed for testing only. I'm ready to manage an Asterisk server, also a new subdomain name could be welcome (e.g fgcom.flightgear.org). If someone is ready to provide a public server receiving Asterisk, so raise your hand. Any opinion/feedback are welcome. Cheers, Clément -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FlightGear voice communication
Hi Clement thanks a million times for taking the initiative for that - i guess I am one of the bigger users and promoters for FGCOM since a long time - and waited very long for such a solution. Just one point: Could it be possible to start 2 instances of FGCOM in the background (just with different ports) and thus be able to switch between those two from within FGFS? We once had an additional panel in FGFS to switch between two instances of FGCOM (uncontrolled design status only i believe - but it worked fine! And helps a lot if you need to switch during start/landing between Twr/Gnd) (Wolfram Wagner wolf...@wagnerw.de) is doing that in his OpenRadar - and it works fine.) A second point: During our ATC-events the FGCOM always goes into a hang after some time of usage - so we have to restart FGCOM (after somebody tells you about the problem!). If you then use FGCOMGUI that is fine with its Stop/Start buttons -- if you just work FGCOM that is a bigger effort! So please: Could there be a restart-button (just in case)? thanks again jomoATC -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear voice communication
Hi, James wrote : Making the current fgcom code work as a thread inside fgfs isn't especially hard, I am happy to offer advice on it, and keeping this an #ifdef / CMake flag so it can be a standalone process is also pretty easy. My current topics/fgcom branch already include a CMake flag (-D ENABLE_FGCOM) at OFF by default. I think a simple --enable-fgcom will be efficient . I don't know how to make a cross platform process for now. Can you confirm me that you are ready to accept a similar solution as QProcess in Qt ? In this way FGCom will lives in a separate PID, the problem being : what happens to this separate PID if FG has a crash ? He will become a ghost and make the network port busy, right ? What about implementing an SGProcess ? Eric wrote : So if you are changing stuff to FGCOM /FG, maybe you can consider supporting 8.33kHz spacing? FG/FGCom are ready for 8.33KHz spacing. It require a little change on Asterisk side (118.305 = 118.300, 118.330 = 118.325, 118.355 = 118.350 118.380 = 118.375) but the main problem is that X-Plane data are not yet ready for 8.33KHz spacing. Here is some examples : ICAO :: apt.dat = possible frequency EDFA :: 12103 = 121.030 ? 121.035 ? EDCQ :: 12338 = 123.380 ? 123.385 ? EBAV :: 12343 = 123.430 ? 123.435 ? KSPI :: 13141 = 131.410 ? 131.415 ? That's why we need to wait the next APT format who support 8.33KHz spacing (i.e: add a new digit in the frequency field) Cheers, Clement -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FlightGear voice communication
Hi all, I've done some work on FGCom and I'm now able to have a realistic voice communication system which is less far than the reality. As a featuring : - Record ATIS message from FGCom into Asterisk - Playback an ATIS message into FlightGear via FGCom - Listen a _real_ morse code for VOR/DME into FlightGear via FGCom - Use 25KHz step frequencies (118.175, 124.225...) - Use COM1 NAV1 via FGCom If you want to test, you can use my clone ( https://gitorious.org/~f-jjth/fg/f-jjths-flightgear ) and checkout on topics/fgcom branch, then use the fgcom executable (newly) available in fgfs/bin/ ./fgcom -Sclemaez.dyndns.org -f_atis_frequency_ -a_icao_for_atis_frequency_ = in order to record a message (ATC mode) ./fgcom -Sclemaez.dyndns.org -p16661 = in order to use fgcom normally (FG mode) For a concrete example: ./fgcom -Sclemaez.dyndns.org -f120.825 -aLFMV = At the end of your message, quitting (Ctrl+c) save the record on the server (I've already recorded a message on this frequency, but you can override it) [You must start FlightGear near of LFMV (LFNH, LFMO... or even LFMV)] ./fgcom -Sclemaez.dyndns.org -p16661 In Radio panel (F12) switch to 120.825, now you can heard your ATIS message like it's done in real life After this (demonstrative) introduction I would look deeply into a voice communication architecture. My experiments with FGCom show me that we can easily have a realistic voice communication system. IMO FlightGear is a _simulator_, a simulator want to simulate the reality. In real life radio communication is the base of the airspace control. That's why I think that voice communication must be as important than FDM, graphism or whatever. Without voice communication we can't consider that we simulate the reality. So I've looked deeply what is existing, what we have, what others have... Looking at X-Plane, it seems that there is no integrated voice communication system. For FSX it's the same. Both leave this part to independant organizations like VATSIM/IVAO. So looking at IVAO he use external software like TeamSpeak and VATSIM use its own communication system included in [X]SqwakBox. Teamspeak being closed source we can forget it. IVAO is also closed source and X-Plane/FSX doesn't provide voice communication. In conclusion, we can't base our work on experience from other, we must do our own choice and the cross compatibility between system still not possible. Finally we are back to our good old IAX(fgcom)/Asterisk architecture and to be honest I think this choice is the better one because he is open source and license compliant making it accessible to every X-Plane/FSX/IVAO/VATSIM (they just need to create an external client like our FGCom)... Clearly we can't adapt our source code to match their _closed_ system but they can easily adapt their _closed_ source code for our _open_ system. They are greatly invited to switch to IAX/Asterisk system. But that's another thing where we don't care. Now that I talked about others and demonstrated their experience can't help us, I will talk about our dear FlightGear and available technical solution. For now we use an external software (FGCom) who is an IAX client receiving information from FlightGear (frequency, sqwak, ptt, position...) then transmit/receive voice to an Asterisk server. IMO it's not a bad choice and it works. Asterisk is really a perfect choice for this usage and I guess real ATC system use it for their ATIS/closed airspace message. But I heard that IAX protocol was not expected by some devs, so I looked at different protocols. Asterisk is a powerful software who support a lot of protocol like H.323, MGCP, SCCP, SIP and finally IAX. Two last are commonly knows and I admit that I know nothing about others. So it still SIP and IAX. SIP protocol seems to be more recent than IAX and more and more used. Main convenient : he use multiple port will IAX use only 1 port. But this is not the main aspect for a choice. The main aspect is the library, indeed, if there is no doc/C++ source/license compliant we can't use the protocol. Looking at SIP, I've only found 2 libraries compatible with our project : oSIP2 and eXoSIP2 (eXoSIP being an higher layer for oSIP... a kind of library of a library...) Looking at IAX, the only choice is IAXclient already used by FGCom. Finally we have the choice about protocols and libraries ! But a really little choice... oSIP2/eXoSIP2 for SIP protocol or IAXclient for IAX protocol. IMO, IAXclient library works fine since many years with FGCom, the only need is to update the library version in order to use the last one. IAXclient is licensed under LGPL who make him a perfect choice for SimGear integration, while oSIP2/eXoSIP2 is GPL. Now that we know all technical solution, it's the moment to write a plan. What do we want for the future of voice communication in FlightGear ? What is your opinion ? Here is mine : - Integrate an IAX library into SimGear (1) - Integrate
Re: [Flightgear-devel] FlightGear voice communication
On 22 May 2013, at 12:16, Clement de l'Hamaide clem...@hotmail.fr wrote: I'm expecting opinion, comments, contributions and even join to this effort. I can't do all this alone because I haven't enough C++ skills (integrate an IAX library in SimGear is impossible for me). I think we need 1 or 2 person who works on the SG/FG side and 1 or 2 on FGCom side. I'm ready to work on the FGCom side (rewrite) with help. Thanks for the good summary :) I agree with most of what you said, especially that IAXClient / Asterix is working okay for us. I wish the Iaxclient code was better maintained, and if there was an actively maintained SIP library we could use, it would certainly be appealing, but the options are surprisingly limited. In terms of the code layout, some people want the option of a standalone application for fgcom, but just like TerraSync, 98% of people want an integrated function that 'just works' when they choose a GUI checkbox. Making the current fgcom code work as a thread inside fgfs isn't especially hard, I am happy to offer advice on it, and keeping this an #ifdef / CMake flag so it can be a standalone process is also pretty easy. (I'd vote for moving the code into FlightGear, SimGear doesn't really make sense for this) The big problem for me is not iaxclient, but the audio backend it uses. We're mostly using the OpenAL backend, but on Mac that works quite badly (can't select different output device for FGCom vs normal sim audio) I'd prefer to use PortAudio on Mac (a newer version that the one included with fgcom!), but I am (very) worried about introducing audio problems with different PortAudio backends on Linux. (I have looked at writing a custom CoreAudio backend for iaxclient for Mac, but I didn't find the enthusiasm for that yet) Anyone who wants to work on any parts of this, I'm happy to offer guidance or sample code or anything else to help! Regards, James -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
