Hi all, 

LOts of ideas given over th last few days...


*EMAILS*

From:   Pat <pat.callahan1@gmail.com>
To:     TDO Brandano <tdo_brandano@hotmail.com>, ubuntu@geoffair.info
Cc:     fbrisa@gmail.com, clemaez@hotmail.fr
Subject:    Re: Hi, Introduction and question about FGCOMGUI
Date:   Wed, 14 Aug 2013 21:05:06 -0400 (08/15/2013 03:05:06 AM)



I'd like to put together a complete list of next steps to take with
regard to fgcomgui.  Currently the script is getting it from svn
$FGCOMGUI_STABLE_REVISION_ co https://fgcomgui.googlecode.com/svn/trunk
fgcomgui.    We can continue to get it
from there if we can figure out what's wrong with the build on Ubuntu
13.04.  (haven't tried on 12.10 recently, i really need a virtual).

Question 1: Should we try to bring fgcomgui under gitorious/fg/fgcomgui?

Question 2: How do you go about setting up cmake for a project

I'd like to find out exactly what to do to create a cmake script
for it, so I'll do a little reading.  Meanwhile if anyone has a
suggestion of what to read, let me know.

Question 3. Is there a way to have a gitorious repository based on what
is in the https://fgcomgui.googlecode.com/svn/trunk and add new features
to it in gitorious, but still get any updates to the svn to merge?

Question 4: Should fgcomgui be part of the fgcom project?

Question 5: What does the original person who developed fgcomgui think?

Question 6: Should we take this discussion to the Flightgear-devel
mailing list for wider comment?

I think its time,   If you agree, I'll write a brief summary of
the various conversations regarding fgcom and fgcomgui and post it to
flightgear-devel. If anyone objects, I won't include their comments and
they can comment on the thread as usual.

-Pat

Here's  Geoff's e-mail recent e-mail comment regarding FGCOMGUI.

From: Geoff McLane <ubuntu@geoffair.info>
To: Pat <pat.callahan1@gmail.com>
Subject: Re: Trouble building FGCOM on Ubuntu 13.10 - Patch for
fgcom/CMakeLists.txt Date: Wed, 14 Aug 2013 14:54:12 +0200
X-Mailer: Evolution 3.2.3-0ubuntu6 

Hi Pat,

<snip>
(d) problem with FGCOMGUI

Wow, it is quite a while since I built that ;=() Back 
at 2012/06/08 in fact...

Just checking the current source I note the fgcomgui.pro
file seems to have been removed??? And the build system 
is just scons, which I do not have in windows...

One idea would be to re-create fgcomgui.pro... It is after 
all a Qt project, so why not use qmake???

But wait, previously I had used the fgcomgui.pro to 
generate a CMakeLists.txt so I could use cmake... I have 
a perl script for that, qt2cmake.pl, and a quick review 
shows it appears the source list has not changed...

Hmmm, like before had to put a USE_CMAKE_BUILD macro 
switch around the inclusion of the moc files at the 
bottom of the main sources files... cmake deals with 
these in another way...

So using my previous CMakeLists.txt I had it built 
and running in a few minutes... hmmm, note the server 
defaults to fgcom.flightgear.org.uk which I understand 
no longer exists... 

I changed this to delta384.server4you.de to try an 
echo test... searched to get my last build of fgcom.exe,
*** AND IT ALL WORKED *** ;=))

And for good measure also tried Clement's voip server,
clemaez.dyndns.org, and it too worked...

TODO: Feature in fgcomgui - add a dropdown list of 
voip servers to make the server selection easier...

Anyway, I guess this is NOT much help to you, since 
it requires using a modified source, and my 
CMakeLists.txt, but advise if you want to go that 
way...

I could open a gitorious (cloned) repo, probably in my 
fgtools, and put this modified source, and CMakeLists.txt 
there... seems Jacob has done nothing with this code since 
back in 2010... will think a little about that...

HTH.

Regards,
Geoff.

On Tue, 2013-08-13 at 19:48 -0400, Pat wrote:
> Ok,
> 
> A couple of problems to solve.
> 
> First, the script contains sed commands to do an edit to src/Makefile.
> Yhat is obsolete and needed to be removed.
> 
> Second, the issue with teh failure of the second build is solved by
> adding  -DCMAKE_SKIP_RPATH:BOOL=TRUE and 
> -DCMAKE_SKIP_INSTALL_RPATH:BOOL=TRUE
> 
> cd $CBD/build
> rm CMakeCache.txt
> cmake  \
> -DCMAKE_SKIP_INSTALL_RPATH:BOOL=TRUE  \
> -DCMAKE_SKIP_RPATH:BOOL=TRUE \
> -DFIND_PTHREAD_LIB:BOOL=TRUE  \
> -D CMAKE_BUILD_TYPE="Release"  \
> -D "CMAKE_PREFIX_PATH=$INSTALL_DIR_PLIB"   \
> -D "CMAKE_INSTALL_PREFIX:PATH=$INSTALL_DIR_FGCOM" \
> "$CBD"/fgcom 
>   
> cmake --build . --config Release
> 
> cmake -DBUILD_TYPE=Release -P cmake_install.cmake
> 
> Whoever put this fgcom CMake routine together seems to have known
> exactly what they were doing.  
> 
> The build for fgcom appears to be entirely
> built on CMake and apparently uses the makefile in build/fgcom.  It
> does not use the Makefile in fgcom/src at all, so there's no need to
> edit it's paths as was done previously.
> 
> I think this is working, but I still have a problem with FGCOMGUI,
> which also does not build.  




On Wed, 14 Aug 2013 16:27:25 +0000
TDO Brandano <tdo_brandano@hotmail.com> wrote:

> Hi Pat, yes, I did originally add the fgcomgui build step to the
> script, ut it's a really small wrapper around scons. Scons throws a
> warning, but it is just a warning and shouldn't prevent the build
> process from running through. I suppose I could look into patching
> the sconscript to use the new syntax. From what I can understand from
> the scons traceback the QT resource compiler fails to compile
> qt_resources.qrc, and causes a segmentation fault. Sincerely I have
> no idea of what could be causing this. Perhaps it is looking for the
> source files in the wrong path, or trying to write the compiled file
> to the wrong build dir, that would make sense in view of the earlier
> warning. I'll have a look, maybe try and see if it works with an
> older version of scons, and in case propose a patched sconscript to
> build with the newer version. Or maybe someone will make a cmake
> script for it? Seems to be the most popular build system these days.
> 
> 
> 
> > To: tdo_brandano@hotmail.com
> > Subject: Hi, Introduction and question about FGCOMGUI
> > From: flightge@flightgear.org
> > Date: Wed, 14 Aug 2013 03:48:46 +0400
> > 
> > Hello Brandano,
> > 
> > The following is an e-mail sent to you by callahanp via your
> > account on "FlightGear Forum". If this message is spam, contains
> > abusive or other comments you find offensive please contact the
> > webmaster of the board at the following address:
> > 
> > flightge@flightgear.org
> > 
> > Include this full e-mail (particularly the headers). Please note
> > that the reply address to this e-mail has been set to that of
> > callahanp.
> > 
> > Message sent to you follows
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > 
> > Hi,
> > 
> > I'm pac1 on IRC and in the multiplayer Flightgear.
> > I've recently been working with Francesco Brisa and others on
> > changes to the download_and_compile.sh script.  Fgcomgui is
> > currently not building on Ubuntu 13.10 and I'm not sure what's
> > going on with it yet.
> > 
> > Did you originally contributed the part of the script that build
> > this?  Is there a newer way to build it? 
> > 
> >  What are your thoughts on this?  
> > 
> > -Pat Callahan
> > 
> > pac1@spinnaker130432:~/work/fg/1.9.10/stable$ ../d*.sh -p n FGCOMGUI
> > **************************************
> > *                                    *
> > * Warning, the compilation process   *
> > * is going to use 12 or more Gbytes  *
> > * of space and at least a couple of  *
> > * hours to download and build FG.    *
> > *                                    *
> > * Please, be patient ......          *
> > *                                    *
> > **************************************
> > ****************************************
> > *************** FGCOMGUI ***************
> > ****************************************
> > A    fgcomgui/LICENSE.txt
> > A    fgcomgui/qt_resources.qrc
> > A    fgcomgui/INSTALL.txt
> > A    fgcomgui/src
> > A    fgcomgui/src/aboutdialog.hpp
> > A    fgcomgui/src/configview.cpp
> > A    fgcomgui/src/model.cpp
> > A    fgcomgui/src/licensedialog.cpp
> > A    fgcomgui/src/fgcomgui.hpp
> > A    fgcomgui/src/model.hpp
> > A    fgcomgui/src/configview.hpp
> > A    fgcomgui/src/fgcominfo.cpp
> > A    fgcomgui/src/licensedialog.hpp
> > A    fgcomgui/src/commonconfigview.cpp
> > A    fgcomgui/src/fgcominfo.hpp
> > A    fgcomgui/src/commonconfigview.hpp
> > A    fgcomgui/src/appviewcontroller.cpp
> > A    fgcomgui/src/main.cpp
> > A    fgcomgui/src/appviewcontroller.hpp
> > A    fgcomgui/src/configdialog.cpp
> > A    fgcomgui/src/aboutdialog.cpp
> > A    fgcomgui/src/configdialog.hpp
> > A    fgcomgui/SConstruct
> > A    fgcomgui/docs
> > A    fgcomgui/docs/README.html
> > A    fgcomgui/docs/images
> > A    fgcomgui/docs/images/fgcomgui_systray.png
> > A    fgcomgui/docs/images/fgwizard_advanced.png
> > A    fgcomgui/docs/images/fgcomgui_main.png
> > A    fgcomgui/docs/images/fgwizard_generic_fgcom.png
> > A    fgcomgui/docs/images/fgcomgui_config.png
> > A    fgcomgui/docs/images/fgwizard_generic.png
> > A    fgcomgui/docs/images/fgcomgui_tooltip.png
> > A    fgcomgui/data
> > A    fgcomgui/data/images
> > A    fgcomgui/data/images/appicon.ico
> > A    fgcomgui/data/images/fgcomgui.png
> > A    fgcomgui/data/images/fgcomgui_medium.png
> > A    fgcomgui/data/images/fgcomgui_22.png
> > A    fgcomgui/data/images/fgcomgui_32.png
> > A    fgcomgui/data/images/fgcomgui_24.png
> > A    fgcomgui/data/images/fgcomgui_16.png
> > A    fgcomgui/data/images/fgcomgui_small.png
> > A    fgcomgui/data/images/fgcomgui_xtra.svg
> > A    fgcomgui/data/images/fgcomgui_64.png
> > A    fgcomgui/data/images/fgcomgui_large.png
> > A    fgcomgui/data/images/fgcomgui_48.png
> > A    fgcomgui/data/images/fgcomgui.svg
> > A    fgcomgui/data/fgcomgui.desktop
> > A    fgcomgui/win_resources.rc
> > A    fgcomgui/README.txt
> > A    fgcomgui/templates
> > A    fgcomgui/templates/cpp
> > A    fgcomgui/templates/hpp
> > Checked out revision 46.
> > scons: Reading SConscript files ...
> > 
> > scons: warning: BuildDir() and the build_dir keyword have been
> > deprecated; use VariantDir() and the variant_dir keyword instead.
> > File "/home/pac1/work/fg/1.9.10/stable/fgcomgui/SConstruct", line
> > 57, in <module>
> > scons: done reading SConscript files.
> > scons: Building targets ...
> > g++ -o linux/build/main.o -c -pipe -Wall -O2 -DLINUX
> > -DFGCOM_GUI_PREFIX=\"/home/pac1/work/fg/1.9.10/stable/install/fgcomgui\"
> > -DFGCOM_GUI_BUILD=\"46\" -DNDEBUG -I/usr/include/qt4
> > -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui
> > linux/build/main.cpp moc-qt4 < linux/build/commonconfigview.hpp >
> > linux/build/commonconfigview.hpp.moc
> > g++ -o linux/build/commonconfigview.o -c -pipe -Wall -O2 -DLINUX
> > -DFGCOM_GUI_PREFIX=\"/home/pac1/work/fg/1.9.10/stable/install/fgcomgui\"
> > -DFGCOM_GUI_BUILD=\"46\" -DNDEBUG -I/usr/include/qt4
> > -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui
> > linux/build/commonconfigview.cpp
> > moc-qt4 < linux/build/appviewcontroller.hpp >
> > linux/build/appviewcontroller.hpp.moc
> > g++ -o linux/build/appviewcontroller.o -c -pipe -Wall -O2 -DLINUX
> > -DFGCOM_GUI_PREFIX=\"/home/pac1/work/fg/1.9.10/stable/install/fgcomgui\"
> > -DFGCOM_GUI_BUILD=\"46\" -DNDEBUG -I/usr/include/qt4
> > -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui
> > linux/build/appviewcontroller.cpp
> > moc-qt4 < linux/build/model.hpp > linux/build/model.hpp.moc
> > g++ -o linux/build/model.o -c -pipe -Wall -O2 -DLINUX
> > -DFGCOM_GUI_PREFIX=\"/home/pac1/work/fg/1.9.10/stable/install/fgcomgui\"
> > -DFGCOM_GUI_BUILD=\"46\" -DNDEBUG -I/usr/include/qt4
> > -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui
> > linux/build/model.cpp moc-qt4 < linux/build/configview.hpp >
> > linux/build/configview.hpp.moc g++ -o linux/build/configview.o -c
> > -pipe -Wall -O2 -DLINUX
> > -DFGCOM_GUI_PREFIX=\"/home/pac1/work/fg/1.9.10/stable/install/fgcomgui\"
> > -DFGCOM_GUI_BUILD=\"46\" -DNDEBUG -I/usr/include/qt4
> > -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui
> > linux/build/configview.cpp rcc qt_resources.qrc >
> > linux/build/qt_resources.cpp Segmentation fault (core dumped)
> > scons: *** [linux/build/qt_resources.cpp] Error 139
> > scons: building terminated because of errors.
> > scons: Reading SConscript files ...
> > 
> > scons: warning: BuildDir() and the build_dir keyword have been
> > deprecated; use VariantDir() and the variant_dir keyword instead.
> > File "/home/pac1/work/fg/1.9.10/stable/fgcomgui/SConstruct", line
> > 57, in <module>
> > scons: done reading SConscript files.
> > scons: Building targets ...
> > rcc qt_resources.qrc > linux/build/qt_resources.cpp
> > Segmentation fault (core dumped)
> > scons: *** [linux/build/qt_resources.cpp] Error 139
> > scons: building terminated because of errors.
>                                         


            email message attachment (CMakeLists.txt)

From:   Geoff McLane <ubuntu@geoffair.info>
To:     Pat <pat.callahan1@gmail.com>
Subject:    Re: Trouble building FGCOM on Ubuntu 13.10 - Patch for
fgcom/CMakeLists.txt
Date:   Wed, 14 Aug 2013 14:54:12 +0200
        
        
        Hi Pat,
        
        Re: src/Makefile
        
        That was an VERY OLD residual file that I 'missed' 
        deleting when I switch fgcom to CMake. It has 
        now been REMOVED ;=))
        
        You can see how out-of-date it was by the fact that it 
        referred to the OLD simgear libraries -lsgmisc -lsgdebug 
        from a few years ago now...
        
        There ARE maybe a few other old files that should be removed 
        at some point. One I know about is - 
         iaxclient/lib/gsm/inc/config.h
        
        And for the Windows build, you HAVE to use config.h.msvc, 
        copied to the build directory as config.h, as mentioned in 
        the README.msvc.txt, otherwise the build will FAIL...
        
        TODO: But I have not as yet done the extra work to generate 
        a config.h file with cmake, but will one day get around to 
        it I hope...
        
        It sound like the script you mentioned was started using 
        the previous autoconf system, and some stuff was left 
        when changed to using cmake... glad you have deleted it...
        
        > Whoever put this fgcom CMake routine together seems to 
        > have known exactly what they were doing.  
        
        Well I suppose we all learn as we go on ;=)) but would 
        seldom use the words 'know exactly'. I am sure like all 
        of us, we are usually reluctant to change things after 
        spending effort to get it working, in case the 'new' idea 
        causes MORE pain...
        
        But some things I feel SURE about. 
        
        (a) Items like -
        -D CMAKE_BUILD_TYPE="Release"  \
        is NOT required in unix/linux, which defaults to the 
        release if nothing specified. 
        
        You ONLY need to set this IFF you want cmake to build 
        the Debug (with symbols) version, for use say with gdb...
        
        (b) I will repeat I do not think the following should 
        be used in unix/linux -
        
        cmake --build . --config Release
        cmake -DBUILD_TYPE=Release -P cmake_install.cmake
        
        As stated the default generator is a Makefile, output to 
        the 'build' directory as you suggest, thus the 
        standard unix mantra can be used instead -
        
        $ cmake [options] path/to/source
        $ make
        $ make install
        
        And as I understand it, using the above cmake commands 
        actually opens a shell and does the above... Why not 
        directly use them?
        
        (c) Concerning the failure of the second build, I am glad 
        you found some options that I have NEVER used -
        -DCMAKE_SKIP_INSTALL_RPATH:BOOL=TRUE  \
        -DCMAKE_SKIP_RPATH:BOOL=TRUE \
        and never particularly understood...
        
        Well if these work then ok, no problems, but what about 
        the simple script I sent you? Does this work the 2nd, 
        3rd, 4th, ... time? It does for me...
        
        I just do not like seeing options added if there are 
        other ways... but whatever works for you ;=))
        
        (d) problem with FGCOMGUI
        
        Wow, it is quite a while since I built that ;=() Back 
        at 2012/06/08 in fact...
        
        Just checking the current source I note the fgcomgui.pro
        file seems to have been removed??? And the build system 
        is just scons, which I do not have in windows...
        
        One idea would be to re-create fgcomgui.pro... It is after 
        all a Qt project, so why not use qmake???
        
        But wait, previously I had used the fgcomgui.pro to 
        generate a CMakeLists.txt so I could use cmake... I have 
        a perl script for that, qt2cmake.pl, and a quick review 
        shows it appears the source list has not changed...
        
        Hmmm, like before had to put a USE_CMAKE_BUILD macro 
        switch around the inclusion of the moc files at the 
        bottom of the main sources files... cmake deals with 
        these in another way...
        
        So using my previous CMakeLists.txt I had it built 
        and running in a few minutes... hmmm, note the server 
        defaults to fgcom.flightgear.org.uk which I understand 
        no longer exists... 
        
        I changed this to delta384.server4you.de to try an 
        echo test... searched to get my last build of fgcom.exe,
        *** AND IT ALL WORKED *** ;=))
        
        And for good measure also tried Clement's voip server,
        clemaez.dyndns.org, and it too worked...
        
        TODO: Feature in fgcomgui - add a dropdown list of 
        voip servers to make the server selection easier...
        
        Anyway, I guess this is NOT much help to you, since 
        it requires using a modified source, and my 
        CMakeLists.txt, but advise if you want to go that 
        way...
        
        I could open a gitorious (cloned) repo, probably in my 
        fgtools, and put this modified source, and CMakeLists.txt 
        there... seems Jacob has done nothing with this code since 
        back in 2010... will think a little about that...
        
        HTH.
        
        Regards,
        Geoff.
        
        On Tue, 2013-08-13 at 19:48 -0400, Pat wrote:
        > Ok,
        > 
        > A couple of problems to solve.
        > 
        > First, the script contains sed commands to do an edit to src/Makefile.
        > Yhat is obsolete and needed to be removed.
        > 
        > Second, the issue with teh failure of the second build is solved by
        > adding  -DCMAKE_SKIP_RPATH:BOOL=TRUE and 
        > -DCMAKE_SKIP_INSTALL_RPATH:BOOL=TRUE
        > 
        > cd $CBD/build
        > rm CMakeCache.txt
        > cmake  \
        > -DCMAKE_SKIP_INSTALL_RPATH:BOOL=TRUE  \
        > -DCMAKE_SKIP_RPATH:BOOL=TRUE \
        > -DFIND_PTHREAD_LIB:BOOL=TRUE  \
        > -D CMAKE_BUILD_TYPE="Release"  \
        > -D "CMAKE_PREFIX_PATH=$INSTALL_DIR_PLIB"   \
        > -D "CMAKE_INSTALL_PREFIX:PATH=$INSTALL_DIR_FGCOM" \
        > "$CBD"/fgcom 
        >   
        > cmake --build . --config Release
        > 
        > cmake -DBUILD_TYPE=Release -P cmake_install.cmake
        > 
        > Whoever put this fgcom CMake routine together seems to have known
        > exactly what they were doing.  
        > 
        > The build for fgcom appears to be entirely
        > built on CMake and apparently uses the makefile in build/fgcom.  It
        > does not use the Makefile in fgcom/src at all, so there's no need to
        > edit it's paths as was done previously.
        > 
        > I think this is working, but I still have a problem with FGCOMGUI,
        > which also does not build.
        
        
        

*AND*

From:   Clement de l'Hamaide <clemaez@hotmail.fr>
To:     Pac1 <pat.callahan1@gmail.com>, TDO Brandano <tdo_brandano@hotmail.com>,
Geoff McLane <ubuntu@geoffair.info>
Cc:     fbrisa@gmail.com <fbrisa@gmail.com>
Subject:    RE: Hi, Introduction and question about FGCOMGUI
Date:   Thu, 15 Aug 2013 04:33:46 +0200


Hi all,

First information: FGCom will be included into FlightGear natively in few next
weeks.
Every settings wil be available at runtime from FlightGear menubar (Multiplayer
> FGCom settings)

So in my opinion FGComGUI will be quickly deprecated since FlightGear users will
no longer need it because FlightGear will provide everything natively.

Second information: because of FGCom integration into FlightGear,
"fgcom.flightgear.org" has been created and is already setup and working. This
server use the last apt.dat data from X-Plane and has multiple features. I'm the
maintainer of the server.

Third information: I plan to send soon a patch for IAXClient in order to fix
this warning message << Ignoring unknown information element 'Unknown IE' (56)
of length 9 >>. Also I plan to send a patch for FGCom which make ATC mode ready
for the new "fgcom.flightgear.org" server.

Once these patch are accepted (or rejected maybe :) it would be great to release
a new version of FGCom. Even, running the build on Jenkins server could be
doable.


Regards,
Clément

*AND*

From:   Clement de l'Hamaide <clemaez@hotmail.fr>
To:     Geoff McLane <ubuntu@geoffair.info>
Subject:    RE: A reworked fgcom
Date:   Thu, 15 Aug 2013 11:43:52 +0200


Hi Geoff !

How are you ?
I'm back in the game :) During June and July I was working at Festival d'Avignon
(I'm a video technician in theater) then 1st August I had a motobike crash
that's why I was particulary silencious until today but now I will have spare
time.

As stated on mailing-list I've finnished FGCom integration, I've done a lot of
test and everything works fine.
That's said, I would say you a big thanks for your involvement in this effort !

It still some work I would achieve like:
- Upgrade IAXClient library
- Fix a warning error in IAXClient (about IE (56) )
- Add ATC feature to FGCom
- Fix the range (currently it's 100km instead of 100nm)

Is merge request is ok for you ? else I would like to ask you a commit access to
FGCom repo and working on "next" branch, in this way we could release FGCom
2.12.0 as currently present in master branch, then once 2.12.0 is released we
could use the same release plan than FG/SG.

Let me know if all of this sound good to you.

Clément


*AND*

From:   Clement de l'Hamaide <clemaez@hotmail.fr>
To:     Geoff McLane <ubuntu@geoffair.info>
Subject:    RE: A reworked fgcom
Date:   Thu, 15 Aug 2013 17:14:52 +0200


Geoff,

I started young with a 125cc then continued with a 650cc but now I will wait
some months :)
I agree that 125cc is sufficient if it's just for local displacement.

> But what about bringing your f-jjth repo up to full fg 
> now 2.99 status, and work in that?

It's already done, if you look at the log of my topics/fgcom branch you will see
that I've merged the current state of flightgear with my branch.
For now, there is no new commit on flightgear side so I don't need to merge
anything again.
I asked James to handle my topics/fgcom branch and merge it in next, I hope it
will be done for the end of the week.

> Is this going to continue to be produced? 

My opinion is YES, we still need of standalone like it's done since many years
for external software (i.e OpenRadar)
Therefore, James doesn't plan to add an "integrated standalone" FGCom.
So FGCom will be available as a standalone (like it's already done from
https://gitorious.org/fg/fgcom) + integrated in FG.

If we look at what we (will) have about FGCom use:
- FlightGear = has it's own FGCom feature with his own GUI so no need of
FGComGUI
- OpenRadar = need of standalone FGCom and provide a simple GUI so no need of
FGComGUI


Are you able to create a "next" branch in fg/fgcom repo then upgrade the
IAXClient like you did with the integrated fgcom ?
Once this is done I will be able to fix the IAXClient warning message and add
the features I'm thinking. I will use this "next" branch and do a merge request.


Regards,
Clément



*AND*

From:   Dirk Dittmann <dirk.dittmann.one@gmail.com>
Reply-to:   FlightGear developers discussions
<flightgear-devel@lists.sourceforge.net>
To:     flightgear-devel@lists.sourceforge.net
Subject:    Re: [Flightgear-devel] FlightGear voice communication
Date:   Thu, 15 Aug 2013 18:06:51 +0200


nice to see fgcom stepping forward.

Installing the fgcom-server(delta384) was my first touch with Asterisk, 
amassing power full tool. Looking back see a lot of bandwith. 

my suggestions for improvement:

- bandwith : 
the fgcom-client(iax) didn't close upstream only the mic, i have deep in mind 
that the iax-client can detect silent and should not send the silent over the 
net.

- Share bandwidth width other servers:
splitting the ground stations to several  server(all we have) could improve 
the load for each. The dialbook could have the server column, so the fgcom can 
dial the ground station on a specific server.
this need a update process for the dialbook(may bee git).

- Dialbook get Nummer  :
the search should not return the first frequency, the nearest in Range is more 
suitable.  

- 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.

- 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.

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.

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.

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.

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.

Hopefully a few interesting points.

Regards,

Dirk

*AND*

From:   Clement de l'Hamaide <clemaez@hotmail.fr>
To:     Geoff McLane <ubuntu@geoffair.info>
Subject:    RE: A reworked fgcom
Date:   Thu, 15 Aug 2013 19:53:14 +0200


Geoff,

Ok now I understand why you are confusing.

> But what I am trying to AVOID is having TWO IAXClient 
> sources -
> 1: fg/flightgear/utils/iaxclient
> 2: fg/fgcom/iaxclient

Unfortunately it seems it's exactly what we are going to do :=/
But it's not yet done and yet time to think about that.


> Remember what I said above - we should NOT be maintain 2 
> iaxclient sources - one for standalone and one for integrated.
> To me the integrated iaxclient source/library should be used 
> for BOTH!
> 
> That is both the fgfs program, and the fgcom program link with 
> the SAME iaxclient library...

Ok now your opinion is clear for me ;)
I admit I've no preference, but since you have one, sure I will follow your
preference (1 iaxclient for both program)

Now it's me who is confusing because taking example on TerraSync:
TerraSync program is only available once FlightGear has been compiled, right ?
This means that I can't download TerraSync on the web (on download page of
flightgear.org for example) and use it. I'm forced to compile FlightGear which
create fgfs program AND this terrasync program. So finally TerraSync is not
really available as a standalone program (= downloadable somewhere on the web)
It will be exactly the same for FGCom if I correctly understood your preference,
right ?

But personnaly I would like to see a downloadable fgcom program on download page
of flightgear.org, so the only solution to do that is to keep our good old
fg/fgcom repo which build a _real_ standalone program. ( _real_ means = don't
need to compile flightgear in order to have fgcom program).
So if I understand correctly: if we decide to use fg/flightgear/utils/fgcom
(which has been removed by James for now)  does it means that fg/fgcom repo will
be no longer used ? and will be finally deleted ?

But maybe I'm ignoring something and my vision is not good because I missing
something.


Regards,
Clément


*AND*

From:   TDO Brandano <tdo_brandano@hotmail.com>
To:     Clement de l'Hamaide <clemaez@hotmail.fr>, pat.callahan1@gmail.com
<pat.callahan1@gmail.com>, ubuntu@geoffair.info <ubuntu@geoffair.info>
Cc:     fbrisa@gmail.com <fbrisa@gmail.com>
Subject:    RE: Hi, Introduction and question about FGCOMGUI
Date:   Thu, 15 Aug 2013 19:10:45 +0000 (08/15/2013 09:10:45 PM)


That's great news, and should get fgcom in the hands of a few more people that
right now might find it a bit difficult to set up. I can see a few possible
annoyances further ahead, mind you, but they'll have to be taken care of when
they show themselves up (who will be the first to fly around in an UH-1 blaring
the Ride of the Valkiryes on the local frequency?). However, in the meantime,
getting fgcomgui to be compiled via cmake would probably be the best option,
since it is a dependency we already have and would get rid of a couple of other
dependencies that are used only by the current build system, namely Scons and
Python. I don't think that the FGCOM integration in FGFS will make it in by the
next release? But it ought to be in by the December release, I guess, and would
also make another nice addition for the switch to 3.0 for the version number.

Best Regards,
Alessandro


From: clemaez@hotmail.fr
To: pat.callahan1@gmail.com; tdo_brandano@hotmail.com; ubuntu@geoffair.info
CC: fbrisa@gmail.com
Subject: RE: Hi, Introduction and question about FGCOMGUI
Date: Thu, 15 Aug 2013 04:33:46 +0200

Hi all,

First information: FGCom will be included into FlightGear natively in few next
weeks.
Every settings wil be available at runtime from FlightGear menubar (Multiplayer
> FGCom settings)

So in my opinion FGComGUI will be quickly deprecated since FlightGear users will
no longer need it because FlightGear will provide everything natively.

Second information: because of FGCom integration into FlightGear,
"fgcom.flightgear.org" has been created and is already setup and working. This
server use the last apt.dat data from X-Plane and has multiple features. I'm the
maintainer of the server.

Third information: I plan to send soon a patch for IAXClient in order to fix
this warning message << Ignoring unknown information element 'Unknown IE' (56)
of length 9 >>. Also I plan to send a patch for FGCom which make ATC mode ready
for the new "fgcom.flightgear.org" server.

Once these patch are accepted (or rejected maybe :) it would be great to release
a new version of FGCom. Even, running the build on Jenkins server could be
doable.


Regards,
Clément


*AND*

From:   Clement de l'Hamaide <clemaez@hotmail.fr>
Reply-to:   FlightGear developers discussions
<flightgear-devel@lists.sourceforge.net>
To:     flightgear-devel@lists.sourceforge.net
<flightgear-devel@lists.sourceforge.net>
Subject:    Re: [Flightgear-devel] FlightGear voice communication
Date:   Thu, 15 Aug 2013 21:52:34 +0200


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


*AND*

From:   Guy Brand <gb@unistra.fr>
Reply-to:   FlightGear developers discussions
<flightgear-devel@lists.sourceforge.net>
To:     flightgear-devel@lists.sourceforge.net
Subject:    Re: [Flightgear-devel] FlightGear voice communication
Date:   Fri, 16 Aug 2013 09:59:00 +0200


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

*AND*

From:   Adrian Musceac <kantooon@gmail.com>
Reply-to:   FlightGear developers discussions
<flightgear-devel@lists.sourceforge.net>
To:     FlightGear developers discussions
<flightgear-devel@lists.sourceforge.net>
Subject:    Re: [Flightgear-devel] FlightGear voice communication
Date:   Fri, 16 Aug 2013 11:25:08 +0300 (08/16/2013 10:25:08 AM)


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

*AND*

From:   James Turner <zakalawe@mac.com>
Reply-to:   FlightGear developers discussions
<flightgear-devel@lists.sourceforge.net>
To:     FlightGear developers discussions
<flightgear-devel@lists.sourceforge.net>
Subject:    Re: [Flightgear-devel] FlightGear voice communication
Date:   Fri, 16 Aug 2013 10:18:29 +0100 (08/16/2013 11:18:29 AM)



On 16 Aug 2013, at 09:25, Adrian Musceac <kantooon@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


*AND*

From:   Dirk Dittmann <dirk.dittmann.one@gmail.com>
Reply-to:   FlightGear developers discussions
<flightgear-devel@lists.sourceforge.net>
To:     FlightGear developers discussions
<flightgear-devel@lists.sourceforge.net>
Subject:    Re: [Flightgear-devel] FlightGear voice communication
Date:   Fri, 16 Aug 2013 12:16:07 +0200


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 ?  

EDDP    119.700 51.421592       12.234473       LEIPZIG APP     Leipzig-Halle
EDDC    119.700 51.12672                13.769712       TWR     Dresden
EDDE    119.700 50.975862       10.962116       GND     Erfurt
EDAH    119.700 53.878399       14.140107       TWR     Heringsdorf

EDDP    124.170 51.421592       12.234473       LEIPZIG APP     Leipzig-Halle
EDBM    124.170 52.077322       11.625983       BERLIN RADAR    Magdeburg


Dirk


*AND*

From:   Holger Wirtz <dcoredump@googlemail.com>
Reply-to:   FlightGear developers discussions
<flightgear-devel@lists.sourceforge.net>
To:     flightgear-devel@lists.sourceforge.net
Subject:    [Flightgear-devel] FGCOM
Date:   Fri, 16 Aug 2013 13:30:09 +0200


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

*AND*

From:   Clement de l'Hamaide <clemaez@hotmail.fr>
Reply-to:   FlightGear developers discussions
<flightgear-devel@lists.sourceforge.net>
To:     flightgear-devel@lists.sourceforge.net
<flightgear-devel@lists.sourceforge.net>
Subject:    Re: [Flightgear-devel] FlightGear voice communication
Date:   Fri, 16 Aug 2013 14:21:05 +0200


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

*AND*

From:   Dirk Dittmann <dirk.dittmann.one@gmail.com>
Reply-to:   FlightGear developers discussions
<flightgear-devel@lists.sourceforge.net>
To:     FlightGear developers discussions
<flightgear-devel@lists.sourceforge.net>
Subject:    Re: [Flightgear-devel] FlightGear voice communication
Date:   Fri, 16 Aug 2013 20:13:24 +0200


> 
> - 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


*AND*

From:   Dirk Dittmann <dirk.dittmann.one@gmail.com>
Reply-to:   FlightGear developers discussions
<flightgear-devel@lists.sourceforge.net>
To:     FlightGear developers discussions
<flightgear-devel@lists.sourceforge.net>
Subject:    Re: [Flightgear-devel] FlightGear voice communication
Date:   Fri, 16 Aug 2013 20:13:24 +0200


> 
> - 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

*AND*

From:   Clement de l'Hamaide <clemaez@hotmail.fr>
Reply-to:   FlightGear developers discussions
<flightgear-devel@lists.sourceforge.net>
To:     flightgear-devel@lists.sourceforge.net
<flightgear-devel@lists.sourceforge.net>
Subject:    Re: [Flightgear-devel] FGCOM
Date:   Sat, 17 Aug 2013 03:02:37 +0200


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

*AND*

From:   TDO Brandano <tdo_brandano@hotmail.com>
Reply-to:   FlightGear developers discussions
<flightgear-devel@lists.sourceforge.net>
To:     Flightgear Devel List <flightgear-devel@lists.sourceforge.net>
Subject:    Re: [Flightgear-devel] FGCOM
Date:   Sat, 17 Aug 2013 13:07:25 +0000 (08/17/2013 03:07:25 PM)

I'd leave to the client the task of distorting the received signal based on the
distance and other environmental parameters. The server should just re-broadcast
the clear signal, maybe culling over a simple range bubble.

From: clemaez@hotmail.fr
To: flightgear-devel@lists.sourceforge.net
Date: Sat, 17 Aug 2013 03:02:37 +0200
Subject: 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

*AND*

From:   Pat <pat.callahan1@gmail.com>
Reply-to:   FlightGear developers discussions
<flightgear-devel@lists.sourceforge.net>
To:     flightgear-devel@lists.sourceforge.net
Subject:    Re: [Flightgear-devel] FGCOM
Date:   Sat, 17 Aug 2013 22:05:11 -0400 (08/18/2013 04:05:11 AM)


For those of us with certain kinds of hearing disabilities, adding any
distortion or reduction in volume might make communication impossible.
Our ears add an incredible amount of distortion and noise already. On
top of that you wouldn't believe the lousy quality of hearing aid sound
at 133Db.

There has to be an option in flightgear to allow clear communication,
even at a distance.

That said, I'd never make it in a real cockpit.  Current real aircraft
 audio is just about impossible to understand.


 On Sat, 17 Aug 2013 13:07:25 +0000 TDO Brandano
<tdo_brandano@hotmail.com> wrote:

> I'd leave to the client the task of distorting the received signal
> based on the distance and other environmental parameters. The server
> should just re-broadcast the clear signal, maybe culling over a
> simple range bubble.
> 
> 
> From: clemaez@hotmail.fr
> To: flightgear-devel@lists.sourceforge.net
> Date: Sat, 17 Aug 2013 03:02:37 +0200
> Subject: 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                                         

*EOF*
