hbeni/fgcom-mumble

A (flightsim) radio communication simulation based on mumble

fgcom-mumble's Issues

Implement plugin output to support RDF

When receiving radio signals, the radio_model should calculate the direction.

• This information should be made available to flightgear (and other clients) via UDP interface so RDF is possible.

• The data format needs to be designed yet, but already identified is:

  • direction
  • vertical angle
  • signal stength
  • callsign
  • frequency

• Introduce a new COM-bound field at the UDP inbound server, so clients can request RDF-data for each radio. Default to off This reduces network spam.

Implement Proof-of-Concept

We need a PoC; it should be developed with the following features:

• Prio 1: basic mumble plugin
  Basic mumble plugin will allow basic pilot radio operation already
  • Write basic plugin (see mumble-voip/mumble#3743; full specification at plugin.spec.md)
    • basic plugin functions/code setup/layout
    • UDP input interface
    • mute/unmute based on selected frequencies (range done may follow shortly later, if its complicated to calculate?)
  • echo "..." | netcat -q1 -u localhost 16661 really is good enough for now. A standalone radio client may be useful in the future tough! followup=Issue #4 implement a very basic PTT/Radio sim client so we can test the plugin easily (a simple UDP command line wrapper tool may be sufficient, and in fact useful for later scripting purposes... simply netcat with some checking logic ontop?)

---

• Prio 2: design and conduct load tests
  Basic mumble load and bandwith requirements are the same, but we should get some test for our usecase (pilot/atc radio situation), as i guess, it is not realistic that n-clients speak and listen concurrently for 100% of the time... But also with constantly broadcasting ATIS stations...
  • Develop load testing infrastructure (custom bots? some existing load test tool? stock or adapted mumble benchmark?)
  • We should make sure that the usability, responsiveness and bandwith-size with higher client counts stays within acceptable limits.
  • We should try to get some numbers for maximum supported clients; this is a main indicator if this project has a future

---

• Prio 3: example FGFS and ATC integration
  see plugin.spec.md#plugin-input-data
  • Flightgear compatibility
    • ensure basic compatibility to current fgcom fgfs protocol (working with default fgcom keybinds and c172p)
      Needs change to core; for the problems see: https://forum.flightgear.org/viewtopic.php?p=370172#p370172
    • implement the new protocol with flightgear (working with c172 and c182s)
  • ATC-Pie compatibility
  • openRadar compatibility

---

• Prio 4: basic ATIS recording support
  see README.md#the-fgcom-mumble-client-plugin
  • write simple recording bot
  • write simple playback bot
  • make ATIS cycle work (record -> playback)
  • make 910.00 work

Proper frequency behaviour

@mickybadia and I just had a talk about the 25/8.33 frequency stuff and i just want to note down briefly what i had taken from it.

We just had a talk about the 25/8.33 frequency stuff and i just want to note down briefly what i had taken from it.

This is a raw reminder for me, so i probably need some time to digest the links and info provided.

Infos:

• Link describing the frequency/channel scheme: https://833radio.com/news/show/7
• Code from ATC-Pie may help to peek: base/comms.py
• ATC-Pie commit 9bb529ba is ready for testing the changes

Needed changes:

• Documentation should state that "carrier wave frequency" is the basic expected format for COM_FRQ fields.
• Documentation for COM_FRQ fields must state that the frequency is converted if its recognized as 25/8.33kHz channel name internally (FGCom compatibility).
• We need to change the frequency handling in the COMn_FRQ fields:
  • if non-numerical: use as-is
    • except for RECORD_<tgtFrq> -> needs to convert too, so replay will happen on the correct real frequency
  • if more significant than 3.4: treat as "real frequency" -> use as-is (ATC-Pie will use this)
  • if numerical but with lower precision: see if it is a channel name in the 25khz or 8.33 scheme; if yes, convert to real frequency (see table in link)
• the frequency equality check need to be changed too: either just compare by precision of 3 decimals (properly rounded, see table) or do it by a bell courve that lowers signal quality when off (depending on radio type; which will help us later for the 25khz radio simulation, see #33)
• RDF output will change (automatically, code is already in place) to the real frequency
• Investigate flightgear if we can get out the real frequency via a property somewhere. It is surely already there somewhere...
  • adjust fgfs protocol file so 25kHz and 8.33kHz is handled correctly

In essence, we get an proper actual real frequency internally that can serve as base for future simulations. Mikey stated truly, that this is the only unambiguous identifier we should use. A strong argument was, that the officials may change the channel naming scheme in the future. With the changes outlined above, we then just need to introduce new conversion rules; or even better, do nothing, because all clients already supply >= 4 decimals (aka real frequencies)

---

Tests:

• ATIS recording on new 8.33 channel still working
• ATIS recording on 25kHz still working
• ATIS replay on 8.33 working
• RDF output gives real wave frequency
• 910.00 echo test still working
• ATC-Pie and c172 can communicate on 25kHz and 8.33kHz
• 25kHz and 8.33 basechannel tuning is receivable (overlap test for #33: 122.00<>122.005 working good; 122.00<>122.010 not simulated yet, that will come in #38)

Implement plugin update detection+download

The mumble client will probably be able to download newer plugins in the future from inside the client.
For this, the two functions mumble_hasUpdate() and mumble_getUpdateDownloadURL() should be implemented.

Support different locations (multi identities)

Mickybadia made a proposal regarding ATCing.
Some ATC people are running different ATC clients in parallel (eg. two Airports and on route ATC in between).
Currently one has to run parallel mumble clients, one for each location, as the plugin only supports one location per session.

Many users indeed start more than one ATC-pie instance to control or monitor multiple airports, or have a separate CTR window connected between airport hops, and presumably soon each with its own radio set-up. This generates more than one stream of FGCom-Mumble control packets in parallel, and your replying to all of them on a single fixed port makes it impossible for the RDF requesters to receive the respective RDF data.

---

We may enhance the plugin so that it supports multiclient usage.

• For that we introduce "identities". Each identity can have the currently known state (a callsign, location, radios, ...)
• Identities are bound and identified by a numeric ID.

This needs a huge rewrite of the plugin code, however:

• local state must be an array of identities instead of a plain single struct
• Remote states must be redesigned so each mumble client-id can have several identities
• UDP input server must be altered:
  • A new Field is introduced: IID=<number>. This switches the ID context. Following Commands are to be applied to the selected ID. If absent, the default identity will be used.
  • plugin spec must be enhanced to reflect current state (callsign beeing mandatory if one want to select other identities)
• the internal plugin-i/o protocol (notification sending/receiving) must be enhanced to differentiate between the selected identity (a good place would probably be the dataID field, we are doing something similar in the COM-selection alredy)
• The radio signal checks need to be recursive on all local and remote identities.
• The server side bots must support this new structure as well
• RDP RDF output must be reconsidered too: RDF-ID field must be enhanced, Callsign should be declared mandatory, protocol scheme must be changed to "ordered": probably the easiest one is to make one line per identity (so if several identities receive in parallel, the output is multilined)
• statuspage needs to handle multiple locations per client (statusbot writing proper data should be enough for this, i think)

This will break backwards compatibility in the internal plugin-io-protocol, so a new version number is needed.

Refactor code based on review

James Turner was so glad to provide some comments on the code:

https://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/3C2C3D58-6F58-4949-879E-261978FD24F0%40flightgear.org/#msg37165208

• Use a class for global stuff
• prefer <STL container>.empty() over <STL container>.size() > 0
• make sure pluginDbg is efficient (noop when debug is not active)
• mumble_onAudioSourceFetched is too long (break down into helper functions; rel #122)
• use ‘const bool' locals to avoid complex if clauses

Excessive plugin messages during live testing

A live testing session using the C182S from FlightGear resulted in lots of dropped plugin messages (with me being the sole client, next to the statusbot and recorder):

from murmur.log:

<W>2020-12-05 20:45:12.285 Dropping plugin message sent from "BeniH" (56)
<W>2020-12-05 20:45:12.396 Dropping plugin message sent from "BeniH" (56)
<W>2020-12-05 20:45:12.609 Dropping plugin message sent from "BeniH" (56)
<W>2020-12-05 20:45:12.690 Dropping plugin message sent from "BeniH" (56)
<W>2020-12-05 20:45:12.913 Dropping plugin message sent from "BeniH" (56)

<W>2020-12-05 20:45:13.028 Dropping plugin message sent from "BeniH" (56)
<W>2020-12-05 20:45:13.238 Dropping plugin message sent from "BeniH" (56)
<W>2020-12-05 20:45:13.291 Dropping plugin message sent from "BeniH" (56)
<W>2020-12-05 20:45:13.533 Dropping plugin message sent from "BeniH" (56)
<W>2020-12-05 20:45:13.721 Dropping plugin message sent from "BeniH" (56)
<W>2020-12-05 20:45:13.792 Dropping plugin message sent from "BeniH" (56)

<W>2020-12-05 20:45:14.016 Dropping plugin message sent from "BeniH" (56)
<W>2020-12-05 20:45:14.091 Dropping plugin message sent from "BeniH" (56)

Those messages appeared reliably over the entire session.

The cause for this is to be found, because such high message bursts are not to be expected from the design.
Messages should only occur on a fixed rate from location updates; other updates trigger new messages but should not yield in such bursts because its not fast changing information.

Prefix sent packets with a fixed byte sequence

This is about the UDP packets that you send. All of your recipient clients will almost certainly be reading them in parallel with traffic packets coming from the FGMS network relay, and presumably on the same socket. These traffic packets all start with a "magic" byte sequence "FGFS" which is useful for separating them in their own queue.
I recommend that you also prefix all of your packets in a way that identifies your service, for cleaner operation on the client side. It will avoid assuming that everything unidentified or junk is from you, and allows for yet more services to be added cleanly.

For example, start all of your packets with "FGCom" on a first line (prettier on its own line since you do multi-line plain text). The equivalent byte sequence if you need it is, in hex: 46 47 43 6f 6d, plus 0a for a new line.

Config: Let users disable radio effects

It would be good to give users the option to disable radio audio effects in case hearing is not so good.

• Allow disable trough UDP
• Allow disable trough mumble plugin config
• make it configurable trough mumble standards see mumble-voip/mumble#3743 (comment)

Bug: Memory leaks reported by mumble

Describe the bug
While debugging #78 we again got some messages reporting memory leaks:

FGCom [2021-02-16 12:44:11.327]: Shutdown plugin
FGCom [2021-02-16 12:44:11.327]: [DBG] stopping threads
FGCom [2021-02-16 12:44:11.327]: [DBG] sending UDP shutdown request to port 16661
FGCom [2021-02-16 12:44:11.327]: [UDP-server] shutdown command recieved, server stopping now
FGCom [2021-02-16 12:44:11.327]: [DBG] waiting for threads to finish
FGCom [2021-02-16 12:44:11.327]: [DBG] [UDP-server] thread finished.
FGCom [2021-02-16 12:44:11.372]: [DBG] ---------DEBUG THREAD FINISHED---------
FGCom [2021-02-16 12:44:11.372]: [DBG] [GC] thread finished
FGCom [2021-02-16 12:44:11.427]: [DBG] mumble_shutdown() complete.
<W>2021-02-16 12:44:11.429 PulseAudio: Forcibly disconnected from PulseAudio
<W>2021-02-16 12:44:11.447 Clearing leaked memory from a plugin
<W>2021-02-16 12:44:11.447 Clearing leaked memory from a plugin
<W>2021-02-16 12:44:11.447 Clearing leaked memory from a plugin
<W>2021-02-16 12:44:11.447 Clearing leaked memory from a plugin
<W>2021-02-16 12:44:11.447 Clearing leaked memory from a plugin

This does not happen always.

• It looks like a clean shutdown without server connection or udp-client connected works without leak.
• Just connected to a server without joining "the channel" yields three messages (lcl and rmt state is emtpy, but two other clients were connected)
• Joining the special channel yields four messages (lcl and rmt state is still emtpy)
• Attaching a radioGUI yields five mesages, but only if mumble gets closed

This needs further research, where the memory is not freed.

Crash when directly joining channel via url

When starting mumble with active plugin and joining the channel from the command line (mumble:// url) the client crashes with segfault

Security: Rate-Limit answers to incoming NTFY_ASK packets

Right now it is theoretically possible to force a remote plugin instance to flood the plugin-io of murmur for that client by sending too many NTFY_ASK packets to the attacked client.

Incoming NTFY_ASK packets provoke an answer to the client with the current state of the local instance. If too many of those answers are sent, murmur will drop excess plugin-messages and thus potentially force murmur to drop important ones, like PTT or frequency changes etc.

Therefore, answering NTFY_ASK packets should be limited per recipient.

Implement web interface for fgfs users

• It would be good to have a web interface like fgcom did, that shows the following information:
• active clients (preferably on a map)
  • callsign
  • location
  • tuned frequencies
  • current approx. radio range
• active ATIS recordings
  • data like above

Several ideas already exist to make this happen:

• integrate into fgfs mp map
• build from scratch using a special bot that exposes this information (maybe to sqlite? Or some protocol?)
• build something around icePHP and mumbles own channel viewer protocol

Windows build won't load

The windows build DLL cannot be loaded.
Mumble says Non-plugin found in plugin directory: "<dir>Mumble/Plugins/fgcom-mumble.dll"

---

• No-SSL DLL could not be loaded
• SSL DLL could not be loaded
  Probably a build time problem including openssl dlls
• RadioGUI can't connect
  • the plugin immediately recognizes an incoming connection from 0.0.0.0 when loading. This may be blocking the port.

Advanced radio wave models

Suggestion from Johan G (see https://forum.flightgear.org/viewtopic.php?p=370416#p370416)
See also: http://wiki.flightgear.org/Radio_propagation

some things for the wish list if you would at some time find interest in them:

• HF frequencies (2.1 - 28.0 MHz [1]) for military and some civilian long range aircraft
• VHF frequencies limited to 118-137 MHz [1]
• UHF frequencies (225-400 MHz [1][2]) , the "NATO UHF Band" for people liking military aircraft
• More advanced, but still approximated, noise and radio propagation modeling. Can be challenging for HF coms. [3]

If you later on (in essence not now) feel for taking a really deep dive into aviation radio, The US FAA Order 6050.32B - Spectrum Management Regulations and Procedures Manual (Nov 2005, 22 MB PDF file) and ICAO Doc 9718-AN/957 - Handbook on Radio Frequency Spectrum Requirements for Civil Aviation (draft?, 2009, 1.5 MB PDF) seem to be good resources.

---

[1] See FAA Spectrum Engineering & Policy - Radio Frequency Bands Supporting Aviation
[2] Channels are 25 kHz. See also 8MIL-STD-188/243 Rev. A - Department of Defense Interface Standard, Tactical Single Channel Ultra High Frequency (UHF) Radio Communications](http://everyspec.com/MIL-STD/MIL-STD-0100-0299/MIL-STD-188_243A_50938/) (May 2014).
[3] See Wikipedia article https://en.wikipedia.org/wiki/Radio_propagation (permalink)

Those have all to do with an advanced radio wave model where frequency is an additional input parameter for calculation signal strength.

• HF for example can travel further via ground waves than VHF (behind the horizon).
  Has also todo with #6 and #38
• When implementing this, it would be good to make the radio model object-oriented, so it can be swapped easily depending on used frequency band.
• as a start, based on the rewritten modular system, we can have a simple HF and UHF model
• We need better code for the channel/frequency spacing for the radio models
• We need better simulation for various things influencing the signal qualtiy and range of the models (use ITM/Longley-Rice? HF specifics like sun flares and day/night cycle?)

Make windows build work

Currently with the poc-branch the plugin cannot be built with mingw for windows.
There are some library issues, and i have no clue how to fix it (all the fixes in the internet seem to not work anymore or on my machine).

make clean-all; make all-win to build

g++ -fPIC -c -o lib/radio_model.o lib/radio_model.cpp -I. -I./lib -pthread 
g++ -fPIC -c -o lib/plugin_io.o lib/plugin_io.cpp -I. -I./lib -pthread 
x86_64-w64-mingw32-g++ -o fgcom-mumble.dll lib/radio_model.o fgcom-mumble.cpp --shared -static-libgcc -static-libstdc++ -I. -I./lib -pthread 
/usr/bin/x86_64-w64-mingw32-ld: /tmp/ccHQPJAy.o:fgcom-mumble.cpp:(.text+0xd5): undefined reference to `void pluginLog<char const*>(char const*)'
/usr/bin/x86_64-w64-mingw32-ld: /tmp/ccHQPJAy.o:fgcom-mumble.cpp:(.text+0x151): undefined reference to `void pluginLog<char const*>(char const*)'
/usr/bin/x86_64-w64-mingw32-ld: /tmp/ccHQPJAy.o:fgcom-mumble.cpp:(.text+0x22a): undefined reference to `void pluginDbg<char const*>(char const*)'
[... to be continued ...]

geolib: fgcom_radiowave_getDirection() is off for some values

There is an issue with the direction finding code. It gives some off values in certain situations, most notably if the target points longitude is western of the base position.
The functions and formula is already checked and yielded nothing obviously wrong.

More details can be found in #8 (@hbeni in #8 (comment))
Affected code starts at lib/radio_model.cpp, line 65.

Angles can be measured easily using openseamap Törnplaner.

Testacase: Munic Tower to Treshold of RWY 08L.
Test tool can be built using make test.

Actual:

./test/geotest 48.35303 11.78616 20  48.36263 11.76609 20 |grep "posA <direction>"
  posA <direction> posB = 326.00°

Expected:

./test/geotest 48.35303 11.78616 20  48.36263 11.76609 20 |grep "posA <direction>"
  posA <direction> posB = 306.00°

Implement watchdog in bot-manager

The botmanager should keep neccessary bot instances alive, resp restarting if they are killed/terminated.

Implement terrain checks

Currently the plugin uses a simple radio model that checks a perfectly round geoid. It would be cool to check line of sight against a digital height model, so mountains will prevent vhf communications.

Maybe we can incorporate the SRTM/ASTER files for this.
Terrain data should be used to check line of sight obstruction by mountains/hills etc.

Probably some changes to the UDP fields HGT and ALT will be needed. the plugin should (remain to) operate internally on AGL[1].
ALT therefore needs to be converted to AGL by querying the terrain model, if possible.
For LOS-Checks both values then firstly need to be converted to real altitude (or the terrain model path values corrected for the difference).

has also todo with #15
See also links there!

---

[1] For two reasons: 1. because this gives better radio horizons when no terrain data could be obtained; 2. to keep backwards compatibility to previous plugin versions

Add info to mumble user comment

The mumble client is able to show comments, and recently the plugin API got new functions that exposes that comment to the plugin.

It would be good, if the plugin would show the following information in the plugin comment:

• FGCom plugin version (so users can detect mismatch situations)
• registered callsigns (for identifiying clients between mumble-name and the inSim-name)
• maybe tuned frequencies (for easier contact making and seeing if the radios have been registered successfully)

☝️ ⛔ Note that we only should show relatively stable data, so no fast changing data like position should be shown here.

No radio effects/limits for landlines

Currently radio limits apply for landlines too.
We may treat the reception on signals on landlines differently:

• No range limit
• No radio effects

For this to work, we need to establish a special common frequency syntax.

Add MSFS 2020 (SimConnect) compatibility

When the new SDK is released, we could (easily?) add support for MSFS 2020.
What is needed is just an interface that takes the simulators plane position and radio configuration and generate UDP packets to the mumble plugin (as per specification).

A quick google said, that maybe msfs2020 is compatible to SimConnect.

That said, it's still open if this compatibility could be reached by this project here, or if it better would be a separate project by its own.
I do not own MSFS2020 so probably will never be able to implement this (Help wanted!)

---

Useful ressources:

• https://www.fsdeveloper.com/forum/forums/simconnect.60/ simconnect forum fsdveloper
• P3D location variables: http://www.prepar3d.com/SDKv3/LearningCenter/utilities/variables/simulation_variables.html#Aircraft%20Position%20And%20Speed%20Variables
• P3D avionics variables: http://www.prepar3d.com/SDKv3/LearningCenter/utilities/variables/simulation_variables.html#Aircraft%20Avionics%20Variables
• P3D general systems variables: http://www.prepar3d.com/SDKv3/LearningCenter/utilities/variables/simulation_variables.html#Aircraft%20Miscellaneous%20Systems%20Variables
  (for elec system?)

It looks like we need:

Field	Comment
ATC ID	is this the multiplayer Callsign?
PLANE LATITUDE	lat
PLANE LONGITUDE	lon
PLANE ALT ABOVE GROUND	altitude AGL
COM ACTIVE FREQUENCY:1 / COM ACTIVE FREQUENCY:2	to get the active frequency
COM TRANSMIT:1 / COM TRANSMIT:2	is this the PTT state?
COM STATUS:1 / COM STATUS:2	to get the COMs status: Radio status flag : -1 =Invalid, 0 = OK, 1 = Does not exist, 2 = No electricity, 3 = Failed (i.E. we could map 0 to COM_PWR=1 and everything else to COM_PWR=0 and leave the serviceable etc at default, which should handle all cases "powered/failed/not-present")

Support more than 8 radios

There is a limit of eight radios currently.
That limit is arbitrary and an undefined number of radios should be supported.

Save bandwith using update throttle and/or binary plugin-io

Currently each update to LOC data (LAT/LON/ALT) triggers a notification to remote clients.
This may yield spamming the server, because for example FGFS updates that data several times per second, and in motion aircraft will change LAT/LON/ALT every time, but in tiny fractions.

Radio distribution model depends not so much on very exact numbers here. As long as the local client data is precise, it is not so important if remote senders are perfectly accurate; especially in normal flying conditions.
Thus, we may implement a throttle that only sends notification if:

• the client never had an update (freshly joined and asking for our data)
• the last update was more than n-milliseonds ago
• the last update was a significant change in data (like very fast flying or teleport)

Bug: radio reception is sometimes choppy

Reported by mill-j:

• Received audio is choppy when the plugin is on.
• This is also testable with the 910 test, and still true when using radioGUI.
• The problem does not occur if the plugin is inactive (but still loaded).
• Audio processing functions seem not to be the problem.
• It looks like a cpu bottleneck problem, because with two radioguis mumble uses 100% of one core alone
• Machine: lenovo G50-45 Quad core amd 8gb ram

Identified mumble branch state:

commit 9a4b659f4242e892f5686185e78fd18fcc93f84a
Author: Robert Adam <[email protected]>
Date:   Fri Dec 25 18:50:22 2020 +0100

    Fix copy&paste error

FGCom-mumble commit is 4b3ed22

---

I could not reproduce this here on my box (on mumble commit deb74a66348 "FIX: C&P error in API implementation" with 4b3ed22).
maybe this is a side effect of client version mismatch?

(This may have been introduced by mumbles commit c7ebe95030 "Synchronized API calls")
may be related to #58 as there are restructuring tips

FGFS-Protocol: add squelch-recv

Some aircraft may define a squelch value. according to http://wiki.flightgear.org/index.php?title=Common_Aircraft_Properties&mobileaction=toggle_view_desktop#Comms it is the property /instrumentation/audio/squelch-recv.

Note: There is no such property at the old fgcom protocol.
The squelch should be mapped to a new generic squelch value, so we leave room for later addition of per-radio squelch values (which should then overwrite the generic setting, if both given).

Config: Make UDP inbound port configurable

Currently the UDP server (16661+10) and client port (19991) is fixed.

Once the mumble plugin framework supports plugin configuration, the plugin should support configuration of ports and hosts.

The udp client specifically should have an option to automatically bind to the dynamic client port that spoke to the udp inbound server.

• make UDP input server bind to user defined port
• make UDP RFD bind to user defined port (switchable trough runtime)
• integrate mumble config interface, so users can define this trough the gui see mumble-voip/mumble#3743 (comment)

Make playback bot replay location and radio state for newly joined clients

If one joins a server where a playback bot already replays its samples, they cannot ever be received: state is missing, because the bot only broadcasts this when joining.

When other users join, the bot should replay the data (ie. react on "icanhazdata" packet)

Cleanup outdated local and remote info (GarbageCollection)

Currently the internal plugin state only grows.
It would be good if stale data would be cleaned out after some time to lower memory consumption, runtime and prevent unwanted side effects.

• Unwanted side effects are to be expected mostly from stale local data (eg. old still registered radios and locations, see also #16)
• Memory consumption should be fairly low already.
• Runtime effects should not be a big problem, but may become so with sesseions bigger playercounts, high volatility and long plugin runtimes.

Currently it's good practise to restart mumble (and with it the plugin) between flights.

Config: support mumble plugin config mechanism

The FGCom-mumble plugin already supports user configuration trough a fgcom-mumble.ini-file in the users home dir (see 0d257c6).

Once the mumble plugin framework pull request is done, Krzmbrzl wants to add a pugin config dir, where plugin configs can be placed (see mumble-voip/mumble#3743 (comment)).
Once this is defined, we should also look for a config file there, so we are standards compliant. The file there should be parsed first, so already established config files in user dirs remain dominant.

Put constrains on UDP/plugin-io input parameters

Currently, it is possible to send arbitary strings to the UDP interface, and consequentially to the plugin-io.
The current max messagesize is fixed server side to 1024 bytes, but it may be good to introduce further limits on the individual fields.

Implement standalone radio client

A standalone radio GUI might be useful that sets all the UDP parameters.
This is useful for testing purposes, as well as ATC'ing or making radio station broadcasts with redirected audio of a mumble client.

Especially useful would be:

• Set location based on mapclick
• Add unlimited number of radios
• Enable parallel transmissions by checking which radios should broacast on PTT

Implement white noise

The radio signal quality is already computed from the radio model.
It would be good to add static white noise depending on signal quality for nicer effects/more realism.

ACRE does this using DSP filters and that seems to be a good approach: https://github.com/IDI-Systems/acre2/blob/master/extensions/src/ACRE2Core/FilterRadio.cpp

Occasional memory leaks and segfaults

When testing i see sporadic(!) memory leaks and segfaults.
Those need to be tracked down and closed.

I currently have a hard time reproducing this, but it's there somewhere.

Bug: Freeze of mumble GUI

Describe the bug
The mumble GUI freezes

• when changing channels
• when joining the server

(Maybe related to #65)

To Reproduce
a) Join the server
b) change channels
The bug does not reliably trigger, but @mill-j seem to be able to reproduce it reliably

Expected behavior
No freeze of the GUI

Additional context

• Maybe related to #65

Implement overlapping of multiple senders on same frequency

Currently, if two (receivable) senders transmit on the same frequency, we can hear both in each individuals signal quality.
The signals however should overlap, like they do in real life, possibly cancelling/degrading each other.

• https://en.wikipedia.org/wiki/Co-channel_interference
• https://en.wikipedia.org/wiki/Capture_effect
  ⚠️ according to this there is no capture effect on the airband: https://en.wikipedia.org/wiki/Airband#Modulation

Missing: How does that actually sound?
(for now we might just null some samples and introduce more static)

(related to #15 and #38)

Allow deregistration of radios: COMn_FRQ=<del>

Currently we can just add new radios. It is not possible to deregister radios, because setting COMn_FRQ will be ignored.

therefore, implement a special setting to delete a radio:

• when frequency is set to the vlaue <del> this should be interpreted as deleted radio.
• The information has to be broadcasted to other plugins remote state as well, so the remote plugins can deregister too.

The benefit of doing this is to free some bytes and save some milliseconds runtime. Long running processes like the bots may survive longer due to freeing memory.

Bug: recorder-bot sometimes doesn't release recording state

Describe the bug
When tuning 910 and talking with PTT, the recording starts.
Once releasing PTT the recorder still is in recording mode and never releases (not even with timeout).

Expected behavior
When releasing PTT the recorder should stop recording. Replay should start.

Logfiles
None produced yet (should probably be in the recorder bot logfile

Additional context
I suspect there is an issue with the lua-mumble modue not reliably detecting the stop-speaking and thus not reliably calling the bot's hook. This should probably be reported to upstream once it is verified.
The recorder bot should however also monitor the change of PTT=on to PTT=off to trigger the end of the recording as a fallback/safeguard.

Make FGFS read and use the RDF data

Make Flightgear able to parse the information and , if tuned to the frequency, make ADF needle move accordingly.
Note: this may be impossible if the property is tied to C++ space (which i assume); this then would need changes in the fgfs core. A Proposal could be another property that is investigated from the RDF/ADF C++ code and also taken into account.

We should look into this once mumble 1.4 is out and we have some pilot feedback on the overall system.

(Followup on the RDF feature #8)

Support 8.3 channel spacing overlap 25khz

(Followup on #28; see also: https://833radio.com/news/show/7)

Currently any frequency is supported. The plugin expects all clients to agree on a shared notion of „frequency“ however.

The radio model should however be adjusted, so slightly misaligned frequencies can be received, as could be the case with some 25khz and newer 8.3 frequencies.

---

From mickybadia at #28 (comment)

However note that now, you have to assume everybody with an 8.33 spacing, the way to test if two freq's (in MHz) are in tune being: abs(frq1 - frq2) < .025 / 3 / 2. Also see comment [*] below.

Good test values to combine are:

122.00 (traditional freq)
122.005 (8.33 name for the same frequency as above; both should be in tune; real freq is not the closest 8.33 freq)
122.010 (distinct 8.33 channel whose real freq is not the closest 25-spaced freq; in real life though, ACFT with older radios might hear it, slightly out of tune; do you want to simulate that? follow-up comment [*] below)
record an ATIS on an 8.33 channel (e.g. the new 132.980 at EHAM); see if a flight sim cockpit can still hear it with an old radio (displaying 132.97)

[*] I think I might add a ticket for that because it is a new feature, still not discussed, but definitely part of real life and quite easy to simulate. The problem is that with real freq values only and with the current info from the clients, you have no way of accounting for the coexisting radio generations ("8.33" vs. older) in the airspace. You cannot know if a radio has a 25 or an 8.33 kHz freq spacing for its tuning. So for real simulation, perhaps a COMn_833=0/1 field would be advised, defaulting to 0 to allow the legacy FGCom integration to work. Then you would be able to adjust the "in-tune" test to know if a radio picks up a signal or not, and even the signal quality :-)

ATC-Pie Frequency parsing

An issue arised, where ATC-Pie client and FGFS Clients could not reach each other, but used the same frequency.

Cause is that frequency is matched a string.
ATC-Pie provides 123.450, whereas fgfs strips the last zero and puts 123.45 to the UDP server.

Solution is to strip trailing zeroes if they occur after the decimal point.
To make it more safe, leading spaces/zeroes and trailing spaces are now stripped as well.

Statuspage: Adjust last db update

• Shorten the string to "last DB update"
• make the time UTC

Show real wave frequency as channel, if possible

The status page and mumble client comment currently display the real wave frequency in case it was provided as such.
It would be good, if the mumble comment and also the status page would show the 8.33 or 25 channel name instead, so users can more easily recognize and tune.

Currently if a 8.33 real wave frequency is supplied (like from ATC-Pie), the given token value from the protocol is supplied to the dialedFrq field.

The place to code this up could be here, probably we should ask the selected radio_model to provide a possible channel name.

fgcom-mumble/client/mumble-plugin/lib/io_UDPServer.cpp

Lines 223 to 226 in cfa1476

	if (std::regex_match(frq_parsed.frequency, std::regex("^\\d+\\.\\d{4,}$") )) {
	// numeric frequency detected with >=4 decimals: treat as real wave frequency
	pluginDbg("[UDP-server] detected real wave frequency format="+token_value);
	finalParsedFRQ = frq_parsed.prefix + frq_parsed.frequency;

The new method should return either the frequency passed into it, or a channel name string if it matches.
Providing the token then would automatically provide the correct information to the status bot and mumble comment.

Revisit fgfs protocol file for frq

Currently the fgfs protocol file transmits two frequency properties in order to be able to suppor both the old 25khz and the newer 8.33 frequency selections.

I want to recheck if there is a usable common frequency property for both modes.

If fgfs transmits but this can lead to stuttering audio output because the frequency internally changes in a fast pace, potentially disrupting the incoming audio stream.

Bots hang when starting: need lua-mumble API update

lua-mumble introduced some new API calls that break backwards compatibility in bkacjios/lua-mumble@407371a6dd6db6
The last known working version is bkacjios/lua-mumble@4856540f6cb4.

The lua bots need to reflect those changes, otherwise they won't work. This shows up by them not joining the appropriate channel and dumping a stack trace to the console like

statuspage/fgcom-status.bot.lua:292: attempt to index field 'user' (a nil value)
stack traceback:
        statuspage/fgcom-status.bot.lua:292: in function <statuspage/fgcom-status.bot.lua:286>
        [C]: in function 'loop'
        statuspage/fgcom-status.bot.lua:333: in main chunk
        [C]: at 0x5611dc3751d0

Bug: Recorder bot does not honor PTT of radio in question

Describe the bug
See #70 #70 (comment):

So far, it appears to work reliable. I did notice something that I'm not sure is intended. If I tune RadioGUI com1 to 910 and com2 to another freq such as 123.00, transmitting on com2 will echo as well. The same is true for the RECORD bot. Is this working as intended?

To Reproduce
Steps to reproduce the behavior:

1. Tune 910 or RECORD frequency on one radio
2. Tune arbitary frequency on another radio
3. PTT on the non-recorder frequency

Expected behavior
Recorder bot should only record when the recording COM is PTTed

Provide 32bit builds in releases

It would be beneficial if the releases would also contain 32bit binaries.

This probably can be achieved by the -m32 compiler flag.

Bug: Mumble hangs on shutdown with fgcom-mumble enabled

Describe the bug
Latest mumble hangs (until manually ended with Ctrl+C) on shutdown with fgcom-mumble enabled. On my computer(Linux Mint 19.3) it's pretty well everytime. This is not a problem when the plugin is not enabled. Although disabling the plugin freezes the mumble settings dialog so I have to edit mumble's config files.

It also does not seem to be a problem with an older build that I think is 80de426

Expected behavior
Quit mumble completely without hanging.

Logfiles
Hangs at:

FGCom [2021-02-14 19:30:25.212]: Shutdown plugin
FGCom [2021-02-14 19:30:25.212]: [DBG] stopping threads
FGCom [2021-02-14 19:30:25.213]: [DBG] sending UDP shutdown request to port 16662
FGCom [2021-02-14 19:30:25.213]: [DBG] waiting for threads to finish

Additional context
Did some debugging and found if I modify the while loop in fgcom-mumble.cpp/mumble_shutdown() to:

// wait for all threads to have terminated
    pluginDbg("waiting for threads to finish");
    int shutdownTimeout = 0;
    while (udpServerRunning || udpClientRunning || fgcom_gcThreadRunning || fgcom_debugthread_running) {
        // just wait for the servers to come down. This should not take long.
        // TODO: this may block forever. We probably should have some kind of timeout here.
        std::this_thread::sleep_for(std::chrono::milliseconds(100));
        
        if(udpServerRunning){pluginLog("Waiting on udpServerRunning");}
        if(udpClientRunning){pluginLog("Waiting on udpClientRunning");}
        if(fgcom_gcThreadRunning){pluginLog("Waiting on fgcom_gcThreadRunning");}
        if(fgcom_debugthread_running){pluginLog("Waiting on fgcom_debugthread_running");} 
        
        if(shutdownTimeout > 20)
			break;
        shutdownTimeout++;
    }

This allows us to see which bool is keeping it from exiting:

FGCom [2021-02-14 19:30:25.212]: Shutdown plugin
FGCom [2021-02-14 19:30:25.212]: [DBG] stopping threads
FGCom [2021-02-14 19:30:25.213]: [DBG] sending UDP shutdown request to port 16662
FGCom [2021-02-14 19:30:25.213]: [DBG] waiting for threads to finish
FGCom [2021-02-14 19:30:25.313]: Waiting on udpServerRunning
FGCom [2021-02-14 19:30:25.313]: Waiting on fgcom_gcThreadRunning
FGCom [2021-02-14 19:30:25.313]: Waiting on fgcom_debugthread_running
FGCom [2021-02-14 19:30:25.413]: Waiting on udpServerRunning
FGCom [2021-02-14 19:30:25.414]: Waiting on fgcom_gcThreadRunning
FGCom [2021-02-14 19:30:25.414]: Waiting on fgcom_debugthread_running
FGCom [2021-02-14 19:30:25.514]: Waiting on udpServerRunning
FGCom [2021-02-14 19:30:25.514]: Waiting on fgcom_gcThreadRunning
FGCom [2021-02-14 19:30:25.514]: Waiting on fgcom_debugthread_running
FGCom [2021-02-14 19:30:25.614]: Waiting on udpServerRunning
FGCom [2021-02-14 19:30:25.614]: Waiting on fgcom_gcThreadRunning
FGCom [2021-02-14 19:30:25.615]: Waiting on fgcom_debugthread_running
FGCom [2021-02-14 19:30:25.624]: [DBG] [GC] thread finished
FGCom [2021-02-14 19:30:25.706]: [DBG] ---------DEBUG THREAD FINISHED---------
FGCom [2021-02-14 19:30:25.715]: Waiting on udpServerRunning
FGCom [2021-02-14 19:30:25.815]: Waiting on udpServerRunning
FGCom [2021-02-14 19:30:25.916]: Waiting on udpServerRunning
FGCom [2021-02-14 19:30:26.016]: Waiting on udpServerRunning
FGCom [2021-02-14 19:30:26.116]: Waiting on udpServerRunning
FGCom [2021-02-14 19:30:26.217]: Waiting on udpServerRunning
FGCom [2021-02-14 19:30:26.317]: Waiting on udpServerRunning
FGCom [2021-02-14 19:30:26.418]: Waiting on udpServerRunning
FGCom [2021-02-14 19:30:26.518]: Waiting on udpServerRunning
FGCom [2021-02-14 19:30:26.618]: Waiting on udpServerRunning
FGCom [2021-02-14 19:30:26.719]: Waiting on udpServerRunning
FGCom [2021-02-14 19:30:26.819]: Waiting on udpServerRunning
FGCom [2021-02-14 19:30:26.920]: Waiting on udpServerRunning
FGCom [2021-02-14 19:30:27.020]: Waiting on udpServerRunning
FGCom [2021-02-14 19:30:27.120]: Waiting on udpServerRunning
FGCom [2021-02-14 19:30:27.220]: Waiting on udpServerRunning
FGCom [2021-02-14 19:30:27.321]: Waiting on udpServerRunning
FGCom [2021-02-14 19:30:27.421]: Waiting on udpServerRunning
FGCom [2021-02-14 19:30:27.421]: [DBG] mumble_shutdown() complete.
<W>2021-02-14 19:30:27.427 PulseAudio: Forcibly disconnected from PulseAudio
<W>2021-02-14 19:30:27.511 Clearing leaked memory from a plugin
<W>2021-02-14 19:30:27.512 Clearing leaked memory from a plugin
<W>2021-02-14 19:30:27.512 Clearing leaked memory from a plugin
<W>2021-02-14 19:30:27.512 Clearing leaked memory from a plugin
<W>2021-02-14 19:30:27.512 Clearing leaked memory from a plugin
<W>2021-02-14 19:30:27.512 Clearing leaked memory from a plugin
<W>2021-02-14 19:30:27.512 Clearing leaked memory from a plugin
<W>2021-02-14 19:30:27.512 Clearing leaked memory from a plugin
<W>2021-02-14 19:30:27.512 Clearing leaked memory from a plugin
<W>2021-02-14 19:30:27.512 Clearing leaked memory from a plugin
<W>2021-02-14 19:30:27.512 Clearing leaked memory from a plugin
<W>2021-02-14 19:30:27.512 Clearing leaked memory from a plugin
<W>2021-02-14 19:30:27.512 Clearing leaked memory from a plugin
<W>2021-02-14 19:30:27.513 Clearing leaked memory from a plugin
<W>2021-02-14 19:30:27.513 Clearing leaked memory from a plugin
<W>2021-02-14 19:30:27.513 Clearing leaked memory from a plugin
<W>2021-02-14 19:30:27.513 Clearing leaked memory from a plugin
<W>2021-02-14 19:30:27.514 Clearing leaked memory from a plugin
<W>2021-02-14 19:30:27.514 Clearing leaked memory from a plugin

A quick fix would obviously be implementing the timeout as I did above, but the indefinite loop is the likely the result of some other problem. I'm guessing another locking issue, which would make sense if something changed in mumble.

Enhanced 25kHz/8.33 overlaps

Followup on #33; related to #15

What is open here is the simulation of 25kHz radios: there the reception band is much broader (3 8.33 channels) and this also affects transmissions. Currently the VHF model simulates tuning bands of 8.33 channels only (which will work on cleanly tuned 25kHz as well as 8.33 channels, but not with overlaps between them aside from matching frequencies):

Old 25kHz Radios should receive all 8.3 channels in the tuned band, low quality (QLY one third at most)
8.33 radios should receive old broader band transmissions when their channel is in that 25kHz band
So the current band match function need to be made aware of the band spectrum of the signal involved, and that depend on the radio types.
Unless we find a way flightgear can give us that information, there is not so much point in stimulating this yet, especially as 25kHz radios are phased out already.

ASL/AGL

Related to Issue #6

Besides that, the plugin currently also expects the provided height as ASL, but treats it as AGL, which results in a further away radio horizon and thus more range than is realistic (the problem decreases with flight altitude tough). ASL can’t be converted to AGL without height model, btw.
A fix may be to enhance the UDP protocol to provide AGL too and preferring that over ASL for now.