Board index FlightGear Support Tools FGCom

FGCom-mumble

FGCom is a realtime voice communication system specially designed for FlightGear.

Re: FGCom-mumble

Postby benih » Tue Jul 14, 2020 12:24 pm

Today, i conducted a load test with a little more than 100 bots flying around (i think, more can't be handled by my computer).
From time to time i did check and all was still well after i finally shut it down 5 hours later.
This currently really seem to scale well enough already :)
User avatar
benih
 
Posts: 253
Joined: Tue Aug 15, 2017 9:34 am
Callsign: D-EBHX

Re: FGCom-mumble

Postby benih » Tue Jul 21, 2020 7:01 am

New release: https://github.com/hbeni/fgcom-mumble/r ... tag/v0.2.0

Aside from a (hopefully) fully working radio simulation, this release brings various bugfixes and small enhancements.

Most notably, this release brings RDF client support (ATC-Pie as reference client!), allows clients to set the radios squelch setting, and bandwith usage of plugin communication has been reduced. The radio effects like static/noise can be disabled now.

On the server side, the bots are now more stable and set useful mumble client comments. They also will report their release version when called (--version too), so its a little more easy to detect if updates are needed.
We now also have a nice live-status page written in PHP, showing the clients locations and frequencies on a dynamic map!

The windows version is now statically linked against pthreads, so i hope it will run in windows. As there is no mumble windows build available so far, i had no chance of testing. It would be cool if someone having the capability could look into this, and see if it loads and if it accepts UDP messages.


Now we basically have to wait for the mumble project to release the plugin framework version, and for us to see if we have some hardware to run this on.
For testing i may can use my server, however i'm not sure this is the right choice for final installation.
User avatar
benih
 
Posts: 253
Joined: Tue Aug 15, 2017 9:34 am
Callsign: D-EBHX

Re: FGCom-mumble

Postby benih » Mon Aug 03, 2020 12:11 pm

New release 0.3.0: https://github.com/hbeni/fgcom-mumble/releases/tag/v.0.3.0

This release brings various improvements and bug fixes:

  • Frequency handling was improved: the plugin operates on the real wave frequency internally now. That also affects the expected UDP COMn_FRQ field, which now assumes the value is a real wave frequency if its precision is >= 4 decimals. <4 decimals is tried to be parsed as 25/8.33kHz channel name. In essence the plugin is now capable of establishing comms with the 8.33 channel names, as well as basic frequency overlap for the 25kHz channels.
  • RDF output was improved and is compatible to ATC-Pie dev branch
  • The plugin now supports several clients. For distinguishing the clients, the client's UDP sending port is used. For special cases there is also a new IID field in the UDP protocol that can ovverride this.
  • The plugin (and the server bots) have an garbage collector now, that will clean out data from stale clients
  • Some bugs where fixed in the radio model and the plugin behaviour
  • The serverside botmanager now has a watchdog that restarts died bots
  • German translation for some readmes
User avatar
benih
 
Posts: 253
Joined: Tue Aug 15, 2017 9:34 am
Callsign: D-EBHX

Re: FGCom-mumble

Postby benih » Thu Aug 06, 2020 5:04 pm

I added some commits yesterday that split the IO code out a bit, so catching up on this later should be more easy now., because the plugin_io.cpp is not a novel anymore.

I just did a sloccount analysis for fun (wow that was a lot of work - i used kate to write all of this).
Code: Select all
github.com/AlDanial/cloc v 1.86  T=0.13 s (719.2 files/s, 149219.7 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
C/C++ Header                    34           1403           1883           4631
C++                             27           1212           1598           4018
Lua                             12            468            633           1550
Markdown                         8            296              0            687
Bourne Shell                     4             44             52            246
CSS                              1             22              9            179
PHP                              1             41             84            163
XML                              1             29             24            163
SVG                              1              0              0            128
make                             2             27             18             88
C                                1             22             39             66
JavaScript                       3              8             12             44
INI                              1              7             14             10
-------------------------------------------------------------------------------
SUM:                            96           3579           4366          11973
-------------------------------------------------------------------------------


Ok, and the markdown documentation is a short novel already: 9211 words. :P
User avatar
benih
 
Posts: 253
Joined: Tue Aug 15, 2017 9:34 am
Callsign: D-EBHX

Re: FGCom-mumble

Postby Johan G » Thu Aug 06, 2020 8:18 pm

I remember this parenthesis from your first post that in depth discussed the features you would like to see.
benih wrote in Fri Jun 05, 2020 7:20 am:(Please note that sadly my c++ programming skills lack the means to implement most of this that stuff myself).

And that was just a month ago. :mrgreen:

I am looking forward to seeing your work getting used when production Mumble can use plugins. And I think this will help a lot with that: :D
benih wrote in Thu Aug 06, 2020 5:04 pm:[...] the markdown documentation is a short novel already [...]
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Johan G
Moderator
 
Posts: 6021
Joined: Fri Aug 06, 2010 5:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 2020.3.2
OS: Windows 10, 64 bit

Re: FGCom-mumble

Postby benih » Thu Aug 06, 2020 8:48 pm

Thanks Johan, i learned alot in the process!

But its far from perfect and could use professionals looking over the code.
User avatar
benih
 
Posts: 253
Joined: Tue Aug 15, 2017 9:34 am
Callsign: D-EBHX

Re: FGCom-mumble

Postby benih » Mon Aug 10, 2020 1:33 pm

Hi again, another small addition.

I recently rewrote the radio model to be object oriented, so now we can swap/add models easily.
I took the opportunity and added a very basic HF and UHF simulation in addition to the just ported VHF model.
So now we can now tune HF frequencies and chatter over the horizon :)

(Please note, the models are still very basic, for example HF does not simulate time-of-day effects or sunspots; the UHF one is just an VHF with reduced range, so no detection of buldings/trees etc. Refining this would need radio comms knowledge i don't possess yet.)
User avatar
benih
 
Posts: 253
Joined: Tue Aug 15, 2017 9:34 am
Callsign: D-EBHX

Re: FGCom-mumble

Postby benih » Tue Aug 18, 2020 12:59 pm

Just released 0.4.0: https://github.com/hbeni/fgcom-mumble/r ... tag/v0.4.0



This release brings some internal code cleanups and some enhancements:
  • radio wave model framework is now object oriented, making enhancing it easy
  • a new simple HF and UHF model has been added. The HF model has a simple skywave propagation model, so with that you can now talk over the horizon. Output power determines range then but don't expect realistic range numbers yet (i think it goes too far). UHF is LOS like VHF, but with more limited range.
  • mumble 1.4.0 can check if a new version for a plugin is available. This has been implemented, the updater now checks the github tags page for updates.

As with the previous versions, you need the lua mumble module compiled for the server side, as well as a build of mumble development branch 1.4.0 with plugin support. I precompiled that for debian bullseye/sid, see 0.3.0 release: https://github.com/hbeni/fgcom-mumble/r ... nux.tar.gz
User avatar
benih
 
Posts: 253
Joined: Tue Aug 15, 2017 9:34 am
Callsign: D-EBHX

Re: FGCom-mumble

Postby mickybadia » Tue Sep 01, 2020 10:28 pm

Hi,
Just a thought as I have just released an ATC-pie version featuring this: have you looked into hosting, or for a volunteer (perhaps somebody already providing a Mumble service) to host a server running this plug-in?
I think users *might* just be willing to try, but also that nothing will happen if no server is running for them to connect to. They already have to install a "future" Mumble client and a plug-in on their side...
Anyway, my job is done :lol: :-p
mickybadia
 
Posts: 444
Joined: Tue Sep 24, 2013 9:12 am

Re: FGCom-mumble

Postby benih » Wed Sep 02, 2020 7:05 am

Well, technically "any" already running mumble server is sufficient, as long as it's >= v1.4.0 with plugin support and features a channel named "fgcom-mumble" (that can also be a temporary one).
There is no need for any special server side setup, the radio stuff is handled client side only.

The bots can run on different machines too, and connect to an arbitary server (but the radio system is not depending on that, the bots just add some functionality: ATIS, Echotest, Statuspage).

I already asked about volunteers hosting this permanently in the newsletter (and this thread here), but no one responded so far.
I have a small internet server available that may be sufficient for testing, but here i failed to run murmur and the bots - i suppose i cannot run the stuff i compiled locally because of library issues (the OS is debian/stable, but needs testing, but thats a production machine), so at least i have to wait for 1.4.0 to come to debian unfortunately; or at least the next stable debian release so i can use my binarys.
User avatar
benih
 
Posts: 253
Joined: Tue Aug 15, 2017 9:34 am
Callsign: D-EBHX

FGCom 2020.1

Postby benih » Sun Sep 06, 2020 6:07 pm

The release news (http://wiki.flightgear.org/Changelog_2020.1) mentiones:

FGComm now supports both COM1 and COM2, as well as volume settings.

What exactly does this mean, in technical terms; for example changes of behaviour at the property tree level?
User avatar
benih
 
Posts: 253
Joined: Tue Aug 15, 2017 9:34 am
Callsign: D-EBHX

Re: FGCom 2020.1

Postby Johan G » Sun Sep 06, 2020 8:46 pm

Sorry in advance for the long winding answer. :?

This is older than that. In fact you have likely developed FGCom-Mumble using the behavior. :)

This was apparently introduced with commit 4c6b10 in Mars 2019:
Add support for FGCom multiple radio support

PTT now in

/controls/radios/comm-ptt as an int; non zero indicates which comm radio to use

/comm-radio-selected is the default comm channel to use. This should usually be the same as will be set by PTT into /controls/radios/comm-ptt

NOTE: that PTT will switch the FG comm inbound and outbound frequency to whichever radio was PTT'd.

There are some commits with fixes following that one though.

AFAIUI fgdata/defaults.xml build large parts of the property tree when FlightGear starts. Looking at flightgear/fgdata/version/2020.1.2/defaults.xml (commit 7309ff), it seems that there per default are two COM radios set up, with property subtrees "/instrumentation/comm[0]/" and "/instrumentation/comm[1]/", selected and keyed through the properties "/controls/radios/comm-radio-selected" (int) and a common PTT "/controls/radios/comm-ptt" (int). Note that aircraft developers can overwrite this in the PropertyList XML files in their aircraft (usually in the <Aircraft>-set.xml file).

Code: Select all
<?xml version="1.0"?>
<!-- ... -->
<PropertyList include="location-presets.xml">
  <!-- ... -->
  <controls>
    <!-- ... -->
    <radios>
      <!--New for 2019.1 - the ability to select the comm radio frequency used by fgcom.
      comm-radio-selected should be set to appropriate comm radio (idx + 1)
          0 : off (no FGcom call)
          1 : /instrumentation/comm[0]
          2 : /instrumentation/comm[2]

      comm-ptt should be set to non zero request PTT - which will transmit via FGCom when FGCom is enabled
      The active (transmitting frequency) and normalised power will also be sent over MP to allow RDF by other MP models.
      -->
      <comm-ptt type="int">0</comm-ptt>
      <comm-radio-selected type="int">1</comm-radio-selected>
    </radios>
  </controls>
  <!-- ... -->
  <instrumentation>
    <!-- Radio settings -->
    <comm n="0">
      <volume type="double">0.6</volume>
      <serviceable type="bool">true</serviceable>
      <ptt type="int">0</ptt>
    </comm>
    <comm n="1">
      <volume type="double">0.6</volume>
      <serviceable type="bool">true</serviceable>
      <ptt type="int">0</ptt>
    </comm>
  <!-- ... -->
  </instrumentation>
  <!-- ... -->
</PropertyList>


Looking at the commit diff there are some other changes as well. Most of them seem to be about making it possible to have PTT bindings for each of the two radios, switching the value of the "/controls/radios/comm-radio-selected" property in the background when you key the other radio than the currently selected one.

Edit: Corresponding changes in the integrated FGCom seem to mainly be in commits b42969 and 8db784:
Add support for FGCom multiple radio support

PTT now uses an int channel number (0 means not pressed, 1 = comm radio 1 (index [0]),etc...)

/comm-radio-selected is the default comm channel to use. This should usually be the same as will be set by PTT into /controls/radios/comm-ptt

However PTT will switch the FG comm inbound and outbound frequency to whichever radio was PTT'd.

New properties also set in multi-player to indicate the transmission frequency and normalised power (currently just set to 1.0)

13001(int) : sim/multiplay/comm-transmit-frequency-hz
13002(short-norm) : sim/multiplay/comm-transmit-power-norm

FGcomm: PTT usage and volume

- PTT will now use whatever channel is selected; non zero simply means PTT active.
- The volume as set in the comm[]/radio will now be used as a factor on the FGComm volume
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Johan G
Moderator
 
Posts: 6021
Joined: Fri Aug 06, 2010 5:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 2020.3.2
OS: Windows 10, 64 bit

Re: FGCom 2020.1

Postby benih » Fri Sep 11, 2020 12:21 pm

Ah thank you very much.
Indeed, i looked at that already for FGCom-mumble. Good to know i didn't miss something :)
User avatar
benih
 
Posts: 253
Joined: Tue Aug 15, 2017 9:34 am
Callsign: D-EBHX

Re: FGCom-mumble

Postby benih » Fri Sep 11, 2020 4:22 pm

...Well, there isn't someone with experience in SimConnect coding, isn't it?
-> https://github.com/hbeni/fgcom-mumble/issues/45
User avatar
benih
 
Posts: 253
Joined: Tue Aug 15, 2017 9:34 am
Callsign: D-EBHX

Re: FGCom-mumble

Postby Johan G » Sat Sep 12, 2020 6:22 am

I merged the topic "FGCom 2020.1", that seemed to be about if FGCom-Mumble would be compatible with changes in FlightGear to accommodate for two radios, with this topic.
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Johan G
Moderator
 
Posts: 6021
Joined: Fri Aug 06, 2010 5:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 2020.3.2
OS: Windows 10, 64 bit

PreviousNext

Return to FGCom

Who is online

Users browsing this forum: No registered users and 1 guest