FGCom-mumble

FGCom-mumble
Developed by	Benedikt Hallinger
Initial release	1.0.0 (17.01.2022)
Latest release	see release page
Written in	C++, Lua, Java, PHP
OS	Windows, GNU/Linux, MacOS
Development status	Active
Type	Radio/Communication
License	GNU General Public License v3
	Website

FGCom-mumble simulates radio communication based on the VoIP software Mumble. It integrates fully with the radio stack of your FlightGear plane, allowing you to communicate with other pilots and airspace controllers during your flight. It simulates a global, continuous radio frequency spectrum.

FGCom-mumble is an alternative to the already known FGCom client and FGExtend.

FGCom-mumble leverages the plugin mechanism introduced by Mumble 1.4.0 and just needs a precompiled plugin loaded by a stock Mumble client. You can download the latest release from https://github.com/hbeni/fgcom-mumble/releases.

Servers

The main FGCom-mumble test server is mumble://fgcom.hallinger.org/fgcom-mumble
The status page for that service showing all connected clients is at: https://fgcom.hallinger.org/
On first connection Mumble client will ask whether to trust the certificate presented by the server. Currently the server certificate has following details:

Common Name: Murmur Autogenerated Certificate v2
Valid from: Mon. Dec. 7 21:12:40 2020 GMT
Valid to: Sun. Dec. 2 21:12:40 2040 GMT
Serial: 3031
Public Key: 2048 bits RSA
Digest (SHA-1): E6:9A:FA:62:2C:48:4D:73:95:D7:EE:0E:14:0D:5A:C2:AE:14:1C:31
Digest (SHA-256): 50:CE:17:63:FB:FC:40:03:B4:BF:8F:1F:84:35:4C:BA:5D:5C:BE:E4:AD:F9:8C:D8:45:1F:C7:28:EB:CA:3A:C0

It is always a good idea to verify if the signature matches.

Project main goals

Provide communication with geographic and channel separation
Provide a realistic radio simulation
Ease of use for the end user/pilot
Arbitrary frequency support
ATIS recording and playback
Radio station broadcast support
Landline/Intercom support
RDF detection for clients
Ease of server side installation and operation
Standalone nature (no dependency on FlightGear)
Capability to be integrated into FlightGear, with the option to support third party applications (ATC, but also other flight simulators)
Modularity, so individual component implementations can be switched and its easy to add features
Good and complete documentation

Installation and setup

The latest release can be fetched from GitHub (nightly build also has debug versions).

The provided README has detailed instructions on the needed prerequisites and installation procedures.

Someone even made an install video :) https://www.youtube.com/watch?v=jTRzfVfkgZE and https://www.youtube.com/watch?v=boHsPVTSddk (thanks mate, well done! however HF is actually simulated already :)

In short:

Have a stock Mumble client >= 1.4 running, and load the plugin (mumble settings/plugins page)
Join a channel named `fgcom-mumble` (on a >= 1.4 mumble server)
Add the `fgfs-addon` folder of the client release as FlightGear Addon in your launcher
Start FlightGear and use your plane's radio stack (it uses default FGCom buttons, see below)

Usage

FlightGear's FGCom-mumble protocol uses the default FGCom buttons:

When you want to talk on COM1 you have to press Space. While transmitting you can not hear other pilots trough the used radio (they are half-duplex).
You can also talk on COM2 by pressing ⇧ Shift+Space.
since FGCom-mumble 1.2.0:
- For COM3 you use Alt+Space (previously you need to define a custom keybind),
- Intercom is available in full-duplex with Ctrl+Space

Any radio can also accessed by the COMBar (open from Menu/Multiplayer/FGCom-mumble).

If you want to try it out without FlightGear, you can also start the supplied RadioGUI.

How to test your setup?

First, make sure Mumble is working reliably by talking to other people. Either disable the plugin, or be sure you are outside any radio channel (starting with `fgcom-mumble`).

The plugin alters Mumble's receiving audio stream. It adds static noise depending on the radio signal quality, or cancels out all audio when not in range. The outgoing audio stream is not altered in any way.

If the server supports it (in essence there is a bot-manager running and a `fgcom-recorder-bot` listening) you may do a traditional echo test by tuning `910.00` and start to talk. The recorder-bot will record that (he writes that into mumbles chat) and spawn an echo bot at your position, replaying your message (so you will hear yourself like others will hear you).

Troubleshooting

For troubleshooting, refer to the projects README as it has further suggestions.

If it's nothing setup related, an easy fix is to just restart mumble (the plugin will reinitialize itself).

Compatibility

FGCom-mumble supports the legacy FGCom UDP protocol and thus should be compatible to clients supporting that. However, it also features some new UDP fields.

FlightGear is supported through an FlightGear addon. This assumes the default radio implementation and works with at least the C172P and the C182S.
ATC-pie has built in support already (be sure to activate "FGCom-mumble" instead of just "FGCom" in the settings).
OpenRadar currently supports just COM1 (ticket pending). To use COM2 and more, you need to either start several mumble instances, or use FGCom-mumble's RadioGUI.

There is a patched version of OpenRadar with FGCom-mumble and 8.33 channel tuning support available here: http://fgcom.hallinger.org/OpenRadar_fgcom-mumble.jar

Known incompatibilities

The UFO aircraft rebinds Space so you can't transmit on the radio. As a workaround you can use the COMBar that comes integrated with the FGFS addon.

RadioGUI

The FGCom-mumble RadioGUI is a small Java 8 application that can send the FGCom-mumble UDP messages to the Mumble plugin.

Inside the GUI, you can pick your location from a map and then setup and use your radio stack. That said, the RadiGUI can be used instead (or additionally to) FGFS to participate on the simulated radio net.

Server side

By design, all that is needed is a standard Murmur server (version 1.4.0 or later) and a specially named channel (it has to start with `fgcom-mumble`). This is enough to let the plugin do its work. The entire channel is treated as a single, worldwide continuous radio frequency spectrum.

Additional features are implemented using server side Lua bots (which may run somewhere else):

ATIS recording and broadcasting
Radio program broadcasting (OGG playback on a frequency), Custom NDB beacons
Status page data collection

A status page showing client details is available as a PHP website, that gets its data fed from the fgcom-status-bot.

Detailed installation and operation documentation is shipped with the releases, but is also online.

How does it work? (technical information)

The technical details are specified and described in the various readme files of the projects source code (as a starter read the Readme.architecture.md).

Basicly, all users join the same mumble channel and run the fgcom-mumble plugin. The plugin knows everything necessary from the participating users (like radios used, frequencies tuned, locations, etc) and based on that information mutes or plays incoming voice messages from the other users. Based on signal quality, static noise is mixed in for more fun and a more realistic experience. Because the voice of other users is muted, it is a design wise out-of-the-box feature that brings frequency and location separation but allows everyone to stay in the same mumble channel.

Screenshots

Statuspage 0.6.0
RadiGUI 0.6.0

Idea to integrate into FGFS

Pending

ML Discussion: https://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/1919A28D-44D8-46F0-8A65-A5633A8AB743%40hallinger.org/#msg58717212

Using libmumble, a standalone mumble c++17 library, we could integrate FGCom-mumble directly into FlightGear. This way, FGFS would talk "mumble" to a mumble server and the plugins functions would be integrated into the core. For pilots, a simple "click" to connect in the multiplayer would be enough to participate, while having all the advanced features of fgcom-mumble available (like custom NDBs, radio stations; as well as the possibility for other clients (ATC!) to participate easily on the radio spectrum).

A main idea is also to use the existing fgcom-mumble code to avoid double work. But otoh maybe a direct rewrite of the core stuff may be cleaner; most of the magic is in the fgcom-mumble radio model code anyway, so we might just use some bits, if that is possible?

libmubmble is not yet API-stable, but there was already a first dicussion about feasability and basic mechanics:

From FGCom-mumbles side, we need to integrate the data structures into the core. So radios need to be registered, etc. This should not be too hard
- we probably just need to not run the UPD-Server but send the needed data directly into the decoding function of it. At a later stage, we might better integrate that part, but for a first working solution, just creatig a FCGOM-mumble UDP-Packet string in FGFS and sending it periodically (or already on-demand?) into the udp-servers decoder function should be enough - it just creates some CPU overhead which should not be too bad and will establish the needed local data structure.
- Note, that we cannot rely on the mpservers data structures (even if there is radio data), because in FGCom-mumble potential other clients are also participating (like radio-playback bots for ATIS etc!). So we really need to use mumbles plugin messages.
Basicly the libmumble will run its own threads for networking. Upon receiving mumble audio or mumble-plugin data, callback functions would be called from the lib:
- Incoming audio data need to be processed by the fgcom-mumble plugin functions, and then the result handed over into fgfs audio out handling.
- Incoming plugin data needs to be fed into the fgcom-mumble internal remote data struct (just hand the data into the existing data parser).
Pressing the already existing fgfs PTT button
- would need to send plugin data to mumble, to inform other clients. This is currently done by calling a mumble client function, but that is surely not available from libmubmble. It would probably be enough, if fgfs core supplied an implemention that calls the appropriate libmumble function and hands over the data.
- also, the audio data needs to be fetched from the mic, and then handed over to libmumbles audio encoding and sending routine. This probably can somewhat be partly copied from the legacy fgcom implementation.
Questions regarding fgfs currently are:
- (Answer: use Subsystem) how to exactly the integration on fgfs side works. That needs peeks on fgcoms code as well as some discussion at the mailing list.
- how to integrate the libmubmle code into the fgfs build chain (its cmake).
  - legally: libmubmle has a BSD 3-clause licence, is that compatible?
  - And what about libmubmles dependencies, like OpenSSL?
  - technically, how to include that all into the existing build system?

FGCom-mumble

Contents

Servers

Project main goals

Installation and setup