fgcom-mumble is now a comprehensive propagation simulator with realistic frequency usage patterns and solar-terrestrial physics modeling.

[Supermagnum]

Enhance fgcom-mumble to become a comprehensive amateur radio HF propagation simulator with realistic frequency usage patterns and solar-terrestrial physics modeling.

All tests passes, and the install system works.
Note: there may be undiscovered bugs.

relevant to:
#228

[Supermagnum]

But why are the HF an String radio models be removed?
Why has the fgcom-mumble.ini been moved „centrally“ - it solely belongs to the mumble plugin.
What is the ATIS server component, how does it work? Why was it neccesary, ATIS recording and playback was already there and functional?

Let me explain:
Why was fgcom-mumble.ini moved "centrally"?
The file was moved from client/mumble-plugin/fgcom-mumble.ini to configs/fgcom-mumble.ini as part of centralizing configuration.
However, the plugin searches for the config in multiple locations (from fgcom-mumble.cpp):
~/.fgcom-mumble.ini (user home)
/etc/mumble/fgcom-mumble.ini (system-wide)
Windows: %USERPROFILE%\fgcom-mumble.ini
The file in configs/ is a template/example, not the runtime config. The plugin doesn't read from configs/ at runtime; it reads from the standard locations above.
The move was organizational: keeping example/template configs in configs/ rather than inside the plugin directory. The plugin's behavior is unchanged.

HF Radio Model (FGCom_radiowaveModel_HF)
Purpose: High Frequency (HF) radio propagation model for frequencies 3-30 MHz.
Characteristics:
Skywave propagation: signals can travel beyond line-of-sight via ionospheric reflection
Solar conditions: uses FGCom_SolarDataProvider for day/night, solar flux, and geomagnetic effects
Long range: supports intercontinental communication
Audio processing: bandpass filter 300-3000 Hz (typical HF voice)
Power/distance calculation: includes free space path loss and ionospheric losses
When it was used:
Automatically selected for frequencies ≤ 30 MHz (if not aviation/maritime/amateur)
Fallback for generic HF frequencies

Why it was removed:
Replaced by specialized models:
FGCom_radiowaveModel_AviationHF for aviation HF
FGCom_radiowaveModel_MaritimeHF for maritime HF
FGCom_radiowaveModel_Amateur for amateur radio
The generic model lacked domain-specific features

String Radio Model (FGCom_radiowaveModel_String)
Purpose: Simple model for non-numeric frequency names (special channels).
Characteristics:
Perfect worldwide signal: always returns quality = 1.0 (scaled by power)
No distance/range limits: works globally regardless of location
String matching: frequencies match if strings are identical (case-sensitive)
Audio processing: delegates to VHF model for audio effects
No propagation physics: no path loss, terrain, or atmospheric effects

When it was used:
Automatically selected for non-numeric frequency strings
Examples: "GUARD", "EMERGENCY", "TAC", "PHONE:EDDM:TWR", "IC:ATC:1"

There isn't a new "ATIS server component." ATIS recording and playback still works the same way:
Recording: fgcom-radio-recorder.bot.lua records when users transmit on RECORD_
Playback: fgcom-radio-playback.bot.lua plays back recordings at the specified location/frequency
Management: fgcom-botmanager.sh coordinates these bots
What changed:
The test module was moved from test-modules/atis_module_tests/ to server/test/atis_module_tests/ to align tests with the server component structure.
The functionality is unchanged; only the test location was reorganized. The "ATIS server component" in the summary refers to the test module reorganization, not new functionality.

[hbeni]

Hi,
just looked at 9f86ca8 and I really like the idea/feature.
I think it would be a good experiment to try to isolate that and apply it to the current main head, so we can ship this before everything else is ready.

Suggestions:

• mumble plugin:
  • Make the implementation much simpler, as in: don't factor location into the generation. This will also relieve the burden of a needed cache.
  • Move all the noise handling into audio.cpp, just linking other code to it (fgcom_audio_addNoise is already there)
  • make the feature toggleable (flightgear creates its own noise, we need this to be selectable from the client)
    • globalVars.cpp needs a addNoiseSquelch = true; into the fgcom_config struct
    • io_UDPServer.cpp needs a new protocol field AUDIO_FX_NOISES that adjusts that value; handling like the already existing AUDIO_FX_RADIO protocol field
    • Field must be documented in plugin.spec.md
    • the debug thread must log the state of the addNoiseSquelch field
• fgfs addon:
  • in addon-main.nas we need a new field audioNoiseSquelch:
    • audioNoiseSquelch: 0, # adding noise with open squelch is assumed to be handled by FGFS radio inmpementation! (I would put it to line 26, directly below audioEffectsEnabled)
    • initialize the node with a proper default in line 140ff:

    me.configNodes.audioNoiseSquelchNode.setAttribute("userarchive", "y");
    if (me.configNodes.audioNoiseSquelchNode.getValue() == nil) {
      me.configNodes.audioNoiseSquelchNode.setBoolValue(me.defaults.audioNoiseSquelch);
    }
    

  • the FGFS protocol definition need to transfer it, add a chunk like:

    <name>audio-noise-squelch</name>
    <type>bool</type>
    <format>AUDIO_FX_NOISES=%d</format>
    <node>/addons/by-id/org.hallinger.flightgear.FGCom-mumble/audio-noise-squelch</node>
   </chunk>
  

• RadioGUI:
  • Add variable to the config variables
  • Add option to the option dialog for the user to select, defaulting to true
  • Add the value to the generated UDP string, so the mumble plugin receives it.

This way, the feature is opt-out, while RadiGUI defaults to enabled: and FGFS (and other sims) can still disable it because it has its own noise.

[Supermagnum]

Suggestions:

* _mumble plugin:_
  
  * Make the implementation much simpler, as in: don't factor location into the generation. This will also relieve the burden of a needed cache.
  * Move all the noise handling into `audio.cpp`, just linking other code to it (`fgcom_audio_addNoise` is already there)
  * make the feature toggleable (flightgear creates its own noise, we need this to be selectable from the client)
    
    * globalVars.cpp needs a `addNoiseSquelch = true;` into the fgcom_config struct
    * io_UDPServer.cpp needs a new protocol field `AUDIO_FX_NOISES` that adjusts that value; handling like the already existing `AUDIO_FX_RADIO` protocol field
    * Field must be documented in plugin.spec.md
    * the debug thread must log the state of the `addNoiseSquelch` field

One could make the location based noise a toggle-able option.
Currently there is white noise , but it sounds a bit fragmented. I Will look at it in a couple of days.

[hbeni]

Thank you.

Is it possible to create that feature in a separate branch, based on current master?
This way I can apply it without cherry-picking, and also fine tuning it until its ready to merge is way easier.

[Supermagnum]

Thank you.

Is it possible to create that feature in a separate branch, based on current master? This way I can apply it without cherry-picking, and also fine tuning it until its ready to merge is way easier.

Its already done, in Master. But,- I could push it to dev.

[hbeni]

Thank you.
Is it possible to create that feature in a separate branch, based on current master? This way I can apply it without cherry-picking, and also fine tuning it until its ready to merge is way easier.

Its already done, in Master. But,- I could push it to dev.

Great, then just file a separate PR for the feature 👍

[Supermagnum]

Thank you.
Is it possible to create that feature in a separate branch, based on current master? This way I can apply it without cherry-picking, and also fine tuning it until its ready to merge is way easier.

Its already done, in Master. But,- I could push it to dev.

Great, then just file a separate PR for the feature 👍

Maybe, but master now has:
Added addNoiseSquelch config field (default: true) to control squelch noise

• Added AUDIO_FX_NOISES UDP protocol field for runtime control
• Added useLocationBasedNoise config flag to toggle location-based noise calculations
• Updated FGFS addon: added audioNoiseSquelch field (default: 0 for FlightGear)
• Updated RadioGUI: added checkbox option for audioNoiseSquelch (default: true)
• Added debug logging for addNoiseSquelch state
• Updated documentation: plugin.spec.md and FLIGHTGEAR_LIGHTNING_DATA.md
• FlightGear creates its own noise, so the plugin noise can be disabled via AUDIO_FX_NOISES=0

[hbeni]

but master now has

The problem is, that I cant cherry pick the feature, because it is based on altered codebase.
And master is not mergeable due to lacking testing/codeverification.

Hence my pledge:

• make a new feature branch based on upsream (my) master branch
• implement (port?) the feature to that branch

the result is a concise branch just containing that feature. It is probably small enough so I can find time to test and verify. And finally merge.

After that, you can rebase this PR here to the new codebase (my master with your change merged)

[Supermagnum]

Please send me a message on discord,- I am a bit confused about exactly what features you want.

[Supermagnum]

Note:
Why CI/CD Isn't Necessary with my branch.
94.8% success rate across 2,395 tests githubusercontent
Zero crashes found across 8+ billion fuzzing executions githubusercontent
Total execution time is only 16.75 minutes for the full test suite githubusercontent

CI/CD adds overhead that is not needed.

[hbeni]

Closed as per #240 (comment)