Re: [Flightgear-devel] FGCOM
Hi Holger, I'm glad to know that FGCom integration is surprising you. It seems you have a pretty well vision of the perfect solution for radio simulation and I agree with you on this "how-it-should-works". As James said, all of this is mostly based on P2P architecture which is far to be the easier things to create :) - Each client need to know the position of others clients - Each client must send a _clean_ sound signal (no distortion, no attenuation...) - Each client need to calculate the distorsion/attenuation of others clients depending of their distance (I'm callsign01; callsign02 is at 20nm from me = I can hear him loud, callsign03 is at 120nm from me = I can hear him quiet, callsign04... etc... etc...) We could also use a centralized architecture with a server which could works like: - I know the position and frequency of each clients - callsign01 is speaking on 122.50MHz - callsign02 is listening on 122.50MHz, the distance between callsign01 and callsign02 is 20nm = I send a clean signal from callsign01 to callsign02 - callsign03 is listening on 122.50MHz, the distance between callsign01 and callsign03 is 120nm = I send a distorted/attenuated signal from callsign01 to callsign02 - ... - ... I can't imagine the amount of work to create this new system. Also I have absolutely no idea where we should start if we really want (need?) this _much_ realistic system. Do you have any hint ? For sure this level of realism would be a really nice feature. But I admit I don't know if our users will be _much_more_ happy with this level of realism and they need/want this level of realism OR are they already very happy to have a "simple" way of communication better than a simple TeamSpeak-like application ? In this case is it necessary to work during months and months on this project ? Is it worth ? Of course if this level of realism I would be happy to use it ! But I'm not sure to be ready to work on this (big) project for only few of our "pro-realistic" users. But if the task is supported by some people, devs are involved, and my skills are sufficient, yes I would be part of this effort ;) 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=48897031&iu=/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=48897031&iu=/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=48897031&iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FGCOM
Hi all, after some years of abstinence I subscribed back to fg-devel. But I have currently not much time to get more involved into FG. Guy Brand asked me for some details of FGCOM via email and told me that some of you are using FGCOM and (surprising for me) are integrating FGCOM into FG. I must say that I am really surprised :-) I wrote FGCOM about seven or eight years ago as a kind of prototype. Over the years I tried to get it better with - implementing an Asterisk Conference Module, which transfers position data via IAX and mixes the audio streams based on a distance matrix. But the Asterisk API changed too fast and I was a newbie on this and there was noone who liked to get involved to this project - so it lies on SF (http://sourceforge.net/projects/appfgcom/) and begins to get musty. - writing an own conference system which does the same as app_fgom, but with an own simple and small protocol. You can find it at SF (http://sourceforge.net/projects/fgcomd/). But there are so much race conditions, dead locks and problems and again: I was alone to fix it. So I decided: That's too much for one programer. The allover idea is until today the same: - collecting position data from a (new) fgcom client (e.g. every 30 secs) - client sends audio in 8bit ulaw UDP packets and only when PTT is pressed -> low network usage - calculating a distance matrix (e.g. every 10 to 30 seconds) on the server based on the position data - mixing audio based on the distance matrix and used frequency: more distance means more noise or no signal (or perhaps other distortion). - sending the mixed data only to clients "in range" - so one frequency mixing thread can mix "the whole world" - but only if clients in range, they can hear each other. This seems to be very small amount of describing text - but programming is not easy because every client, the distance matrix calculator and every frequency mixer is a seperate thread - much fun with synchronising them :-) So - if someone here likes to set up this system in the future: let me know! At the end this maybe get a real radio simulation - exactly the right toy for a real flight simulation :-) (and for other simulations?). Regards, Holger -- 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=48897031&iu=/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=48897031&iu=/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 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=48897031&iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] How does the FlightGear read in the Scenery data?
Hi, I have been trying to find out how the FlightGear reads the Scenery data (Terrain stg, Texture, building, trees etc.), however I can't find the part of the code that handles this, I know the file IOs are handled by the OSG, but I am still wondering where this is happening. It would be really great if someone familiar with the structure can point me to the source file that deals with this task. Thanks! -- 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=48897031&iu=/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 Thursday, August 15, 2013 22:52:34 Clement de l'Hamaide wrote: > > - 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) > > > > Regards, > Clément Hi guys, Clement, 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. Cheers, Adrian -- 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=48897031&iu=/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=48897031&iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
