Feature Request: Advanced Amateur Radio Propagation Simulation for fgcom-mumble

[Supermagnum]

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

Band-specific channels for 160m, 80m, 60m, 40m, 30m, 20m, 17m, 15m, 10m, 6m
Popular frequency pre-population based on real DX cluster data
Seasonal frequency datasets - scrape DX clusters during mid-winter, spring, mid-summer, mid-autumn, early winter, late winter using: 

https://github.com/Supermagnum/cluster-analyzer
It will take two weeks to get good numbers.

Smart frequency blending using fuzzy logic based on calendar date + real-time solar conditions
Maidenhead grid locator support with distance/bearing calculations

Realistic HF Propagation Model

Solar Flux Index (SFI) integration from NOAA/SWPC
K-index and A-index geomagnetic activity modeling
Day/night path calculation with solar terminator effects
Maximum Usable Frequency (MUF) calculations
Lowest Usable Frequency (LUF) with D-layer absorption modeling
Seasonal ionospheric variations

Optional:
Support for rotateable antennas, and stationary antennas like Yagi,loop, ground plane 1/4 wave, endfed.

All antennas 10 meters above average ground, as standard. If /MM is used, 1/4 GP 3m above sea level or loop 30 meters above sea level.

Power levels: 50,100,150,200 etc up to 1000W.

Bandplans and description of common antennas can be found in: https://github.com/Supermagnum/Supermorse-server/tree/main/Bandplans_and_antennas
Note that the 80 meter loop is a multi-band antenna, usually a square shaped horizontal loop.
Feedpoint on the middle of one of the straight sides.
Its a good antenna!

4NEC2 Pattern File Support ( these provides antenna gain patterns) Antennas described in this folder needs to be simulated to get relevant data.

Native formats:

NEC output files - 4NEC2 can export its calculated patterns as text files Radiation pattern data - Generated from your NEC geometry models Far-field pattern files - ASCII format with angle/gain data

4NEC2 pattern exports typically include:

Theta/Phi coordinates (spherical coordinates) Gain values in dBi Frequency information Polarization components (vertical/horizontal)

Real-time Data Integration

Solar weather data from swpc.noaa.gov

Audio Simulation

Signal strength calculation based on distance, frequency, solar conditions, path
Audio quality effects with realistic fading and QRM/QRN based on propagation
Band-specific characteristics (CW vs SSB behavior)

Implementation Benefits

Transforms fgcom-mumble into the gold standard for amateur radio simulation
Users naturally congregate on realistic frequencies with proper propagation
Educational tool for learning HF propagation physics

Technical Approach

Build on existing fgcom-mumble modular architecture, leveraging established propagation algorithms (VOACAP models, ITU-R standards) with modern real-time data feeds.

This would create an incredibly realistic amateur radio propagation simulator that reflects actual operating patterns and ionospheric physics.

Ps: https://github.com/Supermagnum/Supermorse-server/tree/main/src/murmur/modules
You can use those for starters.

[hbeni]

That sounds interesting and indeed a cool enhancement!

PRs welcome (as always).

Partly this should already be implemented, like channel selection (which need to be done by setting appropriate frequencys from a connected client; radioGUI could/should be enhanced to select good channels, ofc).
Also, time could be relative and not in every case „realtime/now“. Especially for that cases we need some model to fallback to if real time data is not available.

https://github.com/Supermagnum/Supermorse-server/ looks interesting!

---

Related: #6, #15

[Supermagnum]

The server is supposed to be for this app, but on some languages a programming AI is just not mature enough right now. I have a neurological issue related to dyscalculia that makes me "programming blind".
https://gitlab.com/supermag-group/supermorse-app
I managed to more or less whip the AI to produce a working example, it could have something to do with it that its mostly JavaScript. The AI has a tendency to invent API that does not exist, does not produce correct syntax etc..
This is a classic history/example of what a AI should not do:
https://gitlab.com/supermag-group/supermorse-fyn/-/blob/b7b252f2ec46100fc53b8152616a24108cc354d9/claude_migration_errors.md

Anyway,-
The current state of the server is that its really hard to tell if it actually updates the needed solar weather data because it absolutely doesn't log any such activities.
It should do so at server start, then get data every 10 minutes. I left the code up in case it somehow is useful for someone.

My app is here, it will possibly be migrated to HTML5 so I can run a Apache server on my old R720 together with the modified mumble server, it has the capacity to handle around 50 users with full HF simulation.
https://gitlab.com/supermag-group/supermorse-app

PS: The simulation and computing of a HF link has some "fuzzy logic" to its behavior, it can present surprises but then you need to be present at the correct band at the correct time. That usually happens on bands above 14 MHz, lasts anything from 10 minutes to 30 minutes. That happens during daytime and is more or less focused around 18 to 28 MHz. 50 MHz during summer can also surprise people, during the last solar maximum ( 1996 ish ) I heard a Cuban station on that band, he heard me but then the frequency more or less blew up because most of Europe tried to get a confirmed contact. But, at least I was talking to Canada every day on that band.
So, now you have some understanding of how HF can be a bit unpredictable despite what Voacap claims. Thats why we monitor DX clusters to get real time information, IF you could scrape pskreporters API you can get real time propagation data. Im not sure if its a paid service, but ask the owner and explain what it is for. Then you could update every 5 minutes.
That is my tips.
Also, those whip antennas that military trucks,jeeps etc uses needs a proper counterpoise or RF ground to work. On the old coastal radio stations this was usually a huge star shaped network of wires placed on the ground or gigantic copper plates in the salt seawater. For a car or a airplane the fuselage is a RF ground. These antennas has high loss, you can play with eznec to create a box like structure of multiple wires spaced 20 cm, then place a source between that network that is above ground and a wire pointing straight up or in a 45° angle to get a idea of how these radiates.

[Supermagnum]

Nice to know:
Frequency Offset Simulation (Donald Duck Effect)
Basic approach:

Multiply your audio signal by a complex exponential: e^(j2πoffset*t)
Use the Hilbert transform to create an analytic signal from your real audio
Apply the frequency shift by complex multiplication
Take the real part of the result

Alternative method:

Simply resample the audio at a different rate - playing back faster creates higher pitch (classic Donald Duck)
Stretch or compress the time axis while maintaining sample rate

BFO (Beat Frequency Oscillator) Simulation
Core concept:

Generate two sine waves at slightly different frequencies
Multiply them together (heterodyning)
The result contains both sum and difference frequencies
The difference frequency creates the audible "beat" effect

For radio detection simulation:

Create your BFO signal at a frequency close to the received carrier
Mix (multiply) the BFO with the incoming modulated signal
Low-pass filter the result to remove high-frequency components
The remaining signal is your detected audio

Key parameters:

Beat frequency = |f1 - f2| where f1 and f2 are your two oscillator frequencies
For SSB detection, BFO frequency should match the original carrier frequency
Small frequency offsets in BFO create the characteristic "heterodyne whistle"

The BFO essentially recreates the missing carrier frequency needed to demodulate AM or SSB signals back to baseband audio.

Audio filtering: Bandpass filter simulate the narrow bandwidth typical of SSB communications (2.4kHz)

CW filters: 500 or 250Hz Bandpass.

CW (Continuous Wave) Modulation
What CW actually is:

Pure carrier wave that's turned on/off (keyed) to create Morse code
When transmitting: carrier at full power for "dots/dashes", zero power for spaces
No audio modulation - just the RF carrier being switched

Why you need BFO for CW reception:

CW signal by itself produces no audio when received
You only get clicks/thumps when the carrier starts/stops
BFO creates an audible tone by beating against the CW carrier

BFO operation with CW:

Set BFO frequency close to (but not exactly on) the CW carrier frequency
Typical offset: 400-800 Hz produces pleasant audio tone
Mix the CW signal with BFO output
Result: audible tone that follows the on/off keying pattern

The beat note:

Beat frequency = |CW_carrier_freq - BFO_freq|
If CW is at 14.050 MHz and BFO at 14.050.6 MHz → 600 Hz audio tone
Tone only appears when CW carrier is present (key down)
Silence when carrier is off (key up)

Tuning characteristics:

Zero beat: BFO exactly matches carrier → no audio (useless)
Too far apart: beat note too high or creates harsh sound
Sweet spot: 400-800 Hz offset for comfortable copy

This is why CW operators can "tune in" a station by adjusting their BFO until they get a pleasant audio tone pitch.

[Supermagnum]

This should be handy !

HF Propagation Module Implementation Plan

Overview

This document outlines the implementation progress needed to transform fgcom-mumble into a comprehensive amateur radio HF propagation simulator. The implementation focuses on Priority 1 features: Amateur Radio Channel System, Realistic HF Propagation Model, Real-time Data Integration, and Audio Simulation.

Project Status: Ready for Implementation ✅

Current Foundation

• Modular radio model architecture already implemented
• Multi-threading support with 5+ background threads
• Thread safety mechanisms (mutexes, atomic operations)
• Basic HF model with distance-based calculations
• Extensible plugin system for Mumble integration

Target Timeline: 10 weeks for Priority 1, 2 & Weather Integration features

---

Phase 1: Amateur Radio Channel System (Week 1)

1.1 Band-Specific Channel Implementation

Data Structure Extensions

// Add to radio_model.h
struct fgcom_amateur_radio : public fgcom_radio {
    std::string band;           // "160m", "80m", "40m", "20m", etc.
    std::string mode;           // "CW", "SSB", "AM"
    std::string grid_locator;   // Maidenhead grid square
    float power_watts;          // Transmit power (50W-1000W)
    bool is_amateur;            // Amateur radio flag
    int itu_region;             // ITU Region (1, 2, 3)
};

Band Plan Integration

• Import band segments from Supermorse-server CSV
• Implement regional detection (auto-detect user's ITU region)
• Add mode validation (CW vs SSB frequency separation)
• Create band-specific characteristics for each amateur band

Frequency Validation System

• Band compliance checking (prevent out-of-band operation)
• Mode separation enforcement (CW/SSB frequency allocation)
• Regional restriction handling (60m band limitations)
• Channel spacing validation (3kHz SSB, 500Hz CW)

1.2 Maidenhead Grid Locator Support

Grid Square Calculations

• Add grid locator parsing (e.g., "FN31pr")
• Implement distance calculations between grid squares
• Add bearing calculations for directional information
• Extend position data structure to include grid locators

Integration Points

• Update UDP protocol for grid locator transmission
• Modify Mumble plugin interface for grid data
• Add grid-based range calculations for amateur contacts
• Implement grid validation and error handling

---

Phase 2: Solar-Terrestrial Physics Integration (Week 2)

2.1 NOAA/SWPC Data Integration

Solar Data Provider Module

// New file: solar_data.h
class FGCom_SolarDataProvider {
private:
    std::string noaa_api_url;
    std::chrono::system_clock::time_point last_update;
    std::chrono::minutes update_interval;
    std::mutex data_mutex;
    
public:
    fgcom_solar_conditions getCurrentConditions();
    bool updateFromNOAA();
    void startBackgroundUpdates();
};

Data Fetching Implementation

• HTTP client integration using existing httplib.h
• JSON parsing using existing json.hpp
• Background update thread (15-minute intervals)
• Fallback mechanisms for offline operation

Solar Data Structure

struct fgcom_solar_conditions {
    float sfi;                  // Solar Flux Index
    float k_index;              // Geomagnetic K-index
    float a_index;              // Planetary A-index
    double solar_zenith;        // Solar zenith angle
    bool is_day;                // Day/night flag
    int day_of_year;            // Seasonal calculations
    std::chrono::system_clock::time_point timestamp;
};

2.2 Solar Condition Effects

Day/Night Path Calculations

• Solar zenith angle computation based on time/location
• Solar terminator effects on propagation
• Seasonal variations using solar declination
• Geomagnetic storm effects on signal quality

Integration with Existing HF Model

• Extend FGCom_radiowaveModel_HF with solar parameters
• Modify signal calculations to include solar conditions
• Add solar-dependent propagation characteristics
• Implement real-time solar updates in propagation engine

---

Phase 3: Advanced Propagation Modeling (Week 3)

3.1 MUF/LUF Calculations

Maximum Usable Frequency (MUF)

class FGCom_PropagationEngine {
public:
    float calculateMUF(double lat1, double lon1, double lat2, double lon2, 
                       const fgcom_solar_conditions& solar);
    float calculateLUF(double lat1, double lon1, double lat2, double lon2, 
                       const fgcom_solar_conditions& solar);
    float calculatePathLoss(double dist, float freq, 
                           const fgcom_solar_conditions& solar);
    float calculateSkipDistance(float freq, const fgcom_solar_conditions& solar);
    float calculateMultiHopMUF(float dist, int hops, const fgcom_solar_conditions& solar);
};

ITU-R MUF Calculation Formulas

Basic MUF Formula (ITU-R P.1239)

float FGCom_PropagationEngine::calculateMUF(double lat1, double lon1, double lat2, double lon2, 
                                           const fgcom_solar_conditions& solar) {
    // Calculate great circle distance
    double distance = getSurfaceDistance(lat1, lon1, lat2, lon2);
    
    // ITU-R P.1239 MUF formula for F2 layer
    float muf_f2 = 0.0;
    
    // Basic F2 MUF calculation
    if (distance <= 4000.0) {
        // Short distance (≤ 4000 km) - single hop F2
        muf_f2 = 149.0 + (distance / 16.0) + (solar.sfi - 70.0) * 0.1;
    } else {
        // Long distance (> 4000 km) - multi-hop F2
        int hops = static_cast<int>(ceil(distance / 4000.0));
        muf_f2 = 149.0 + (4000.0 / 16.0) + (solar.sfi - 70.0) * 0.1;
        muf_f2 *= sqrt(static_cast<float>(hops));
    }
    
    // Apply solar activity corrections
    muf_f2 *= (1.0 + (solar.sfi - 100.0) * 0.002);
    
    // Apply geomagnetic activity corrections (K-index effect)
    float k_correction = 1.0 - (solar.k_index * 0.05);
    muf_f2 *= k_correction;
    
    // Apply seasonal variations (day of year effect)
    float seasonal_factor = 1.0 + 0.1 * sin(2.0 * M_PI * (solar.day_of_year - 80) / 365.25);
    muf_f2 *= seasonal_factor;
    
    return muf_f2;
}

Multi-Hop MUF Calculation

float FGCom_PropagationEngine::calculateMultiHopMUF(float dist, int hops, 
                                                   const fgcom_solar_conditions& solar) {
    // ITU-R multi-hop MUF formula
    float single_hop_muf = 149.0 + (dist / hops / 16.0) + (solar.sfi - 70.0) * 0.1;
    
    // Multi-hop efficiency factor
    float hop_efficiency = 1.0 / sqrt(static_cast<float>(hops));
    
    // Apply hop efficiency
    float multi_hop_muf = single_hop_muf * hop_efficiency;
    
    // Apply layer-specific corrections
    if (hops == 1) {
        // F2 layer
        multi_hop_muf *= 1.0;
    } else if (hops == 2) {
        // E layer contribution
        multi_hop_muf *= 0.8;
    } else {
        // Multiple hops with decreasing efficiency
        multi_hop_muf *= pow(0.8, hops - 1);
    }
    
    return multi_hop_muf;
}

Lowest Usable Frequency (LUF) Calculation

D-Layer Absorption Model (ITU-R P.1239)

float FGCom_PropagationEngine::calculateLUF(double lat1, double lon1, double lat2, double lon2, 
                                           const fgcom_solar_conditions& solar) {
    double distance = getSurfaceDistance(lat1, lon1, lat2, lon2);
    
    // Base LUF calculation
    float luf_base = 2.0 + (distance / 1000.0) * 0.5;
    
    // Solar activity effect on D-layer
    float solar_effect = 1.0 + (solar.sfi - 100.0) * 0.003;
    luf_base *= solar_effect;
    
    // Geomagnetic activity effect (K-index)
    float k_effect = 1.0 + (solar.k_index * 0.1);
    luf_base *= k_effect;
    
    // Day/night effect on D-layer absorption
    float day_night_factor = solar.is_day ? 1.5 : 1.0;
    luf_base *= day_night_factor;
    
    // Seasonal variation
    float seasonal_luf = 1.0 + 0.2 * sin(2.0 * M_PI * (solar.day_of_year - 172) / 365.25);
    luf_base *= seasonal_luf;
    
    return luf_base;
}

Path Loss Calculation (ITU-R P.1239)

Free Space Path Loss + Ionospheric Effects

float FGCom_PropagationEngine::calculatePathLoss(double dist, float freq, 
                                                const fgcom_solar_conditions& solar) {
    // Free space path loss (dB)
    float free_space_loss = 32.45 + 20.0 * log10(freq) + 20.0 * log10(dist);
    
    // Ionospheric absorption (dB)
    float ionospheric_loss = calculateIonosphericAbsorption(freq, solar);
    
    // Ground reflection loss (dB)
    float ground_loss = calculateGroundReflectionLoss(freq, dist);
    
    // Total path loss
    float total_loss = free_space_loss + ionospheric_loss + ground_loss;
    
    return total_loss;
}

Ionospheric Absorption Calculation

float FGCom_PropagationEngine::calculateIonosphericAbsorption(float freq, 
                                                             const fgcom_solar_conditions& solar) {
    // ITU-R ionospheric absorption model
    
    // Frequency-dependent absorption coefficient
    float absorption_coeff = 0.0;
    if (freq < 4.0) {
        // D-layer dominant absorption
        absorption_coeff = 0.15 * (4.0 - freq) * (4.0 - freq);
    } else if (freq < 10.0) {
        // E-layer absorption
        absorption_coeff = 0.05 * (10.0 - freq);
    } else {
        // F-layer minimal absorption
        absorption_coeff = 0.01;
    }
    
    // Solar activity effect
    float solar_factor = 1.0 + (solar.sfi - 100.0) * 0.005;
    absorption_coeff *= solar_factor;
    
    // Geomagnetic activity effect
    float k_factor = 1.0 + (solar.k_index * 0.2);
    absorption_coeff *= k_factor;
    
    // Day/night effect
    float day_night_factor = solar.is_day ? 1.0 : 0.3;
    absorption_coeff *= day_night_factor;
    
    return absorption_coeff;
}

##### **Ground Reflection Loss Calculation**
```cpp
float FGCom_PropagationEngine::calculateGroundReflectionLoss(float freq, double dist) {
    // ITU-R ground reflection model
    
    // Frequency-dependent ground reflection coefficient
    float ground_reflection = 0.0;
    
    if (freq < 4.0) {
        // Low frequencies - ground wave dominant
        ground_reflection = 0.1 * (4.0 - freq);
    } else if (freq < 10.0) {
        // Medium frequencies - mixed ground/skywave
        ground_reflection = 0.05 * (10.0 - freq);
    } else {
        // High frequencies - skywave dominant
        ground_reflection = 0.02;
    }
    
    // Distance effect on ground reflection
    float distance_factor = 1.0 + (dist / 1000.0) * 0.1;
    ground_reflection *= distance_factor;
    
    return ground_reflection;
}

Solar Zenith Angle Calculation

float FGCom_PropagationEngine::calculateSolarZenithAngle(double lat, double lon, 
                                                        const std::chrono::system_clock::time_point& time) {
    // Convert time to Julian Day
    auto time_t = std::chrono::system_clock::to_time_t(time);
    struct tm* tm_info = gmtime(&time_t);
    
    int year = tm_info->tm_year + 1900;
    int month = tm_info->tm_mon + 1;
    int day = tm_info->tm_mday;
    int hour = tm_info->tm_hour;
    int minute = tm_info->tm_min;
    
    // Calculate Julian Day Number
    int a = (14 - month) / 12;
    int y = year + 4800 - a;
    int m = month + 12 * a - 3;
    double jdn = day + (153 * m + 2) / 5 + 365 * y + y / 4 - y / 100 + y / 400 - 32045;
    
    // Convert to Julian Day Fraction
    double jdf = jdn + (hour - 12) / 24.0 + minute / 1440.0;
    
    // Calculate time since J2000.0
    double t = (jdf - 2451545.0) / 36525.0;
    
    // Mean longitude of the Sun
    double L0 = 280.46645 + 36000.76983 * t + 0.0003032 * t * t;
    
    // Mean anomaly of the Sun
    double M = 357.52910 + 35999.05030 * t - 0.0001559 * t * t;
    
    // Eccentricity of Earth's orbit
    double e = 0.016708617 - 0.000042037 * t;
    
    // Sun's equation of center
    double C = (1.914600 - 0.004817 * t - 0.000014 * t * t) * sin(M * M_PI / 180.0) +
               (0.019993 - 0.000101 * t) * sin(2 * M * M_PI / 180.0) +
               0.000290 * sin(3 * M * M_PI / 180.0);
    
    // True longitude of the Sun
    double L = L0 + C;
    
    // Apparent longitude of the Sun
    double L_apparent = L - 0.00569 - 0.00478 * sin((125.04 - 1934.136 * t) * M_PI / 180.0);
    
    // Obliquity of the ecliptic
    double epsilon = 23.439 - 0.0000004 * t;
    
    // Right ascension of the Sun
    double alpha = atan2(cos(epsilon * M_PI / 180.0) * sin(L_apparent * M_PI / 180.0), 
                         cos(L_apparent * M_PI / 180.0)) * 180.0 / M_PI;
    
    // Declination of the Sun
    double delta = asin(sin(epsilon * M_PI / 180.0) * sin(L_apparent * M_PI / 180.0)) * 180.0 / M_PI;
    
    // Calculate local solar time
    double lst = (hour + minute / 60.0) + lon / 15.0;
    
    // Hour angle
    double h = (lst - 12.0) * 15.0;
    
    // Solar zenith angle
    double cos_zenith = sin(lat * M_PI / 180.0) * sin(delta * M_PI / 180.0) +
                        cos(lat * M_PI / 180.0) * cos(delta * M_PI / 180.0) * cos(h * M_PI / 180.0);
    
    double zenith_angle = acos(cos_zenith) * 180.0 / M_PI;
    
    return static_cast<float>(zenith_angle);
}

##### **Skip Distance Calculation**
```cpp
float FGCom_PropagationEngine::calculateSkipDistance(float freq, const fgcom_solar_conditions& solar) {
    // ITU-R skip distance model
    
    // Critical frequency for F2 layer
    float f0f2 = 149.0 + (solar.sfi - 70.0) * 0.1;
    
    // Skip distance formula
    float skip_distance = 0.0;
    
    if (freq > f0f2) {
        // Frequency above critical frequency - no skip
        skip_distance = 0.0;
    } else {
        // Calculate skip distance using ITU-R formula
        float muf_factor = freq / f0f2;
        skip_distance = 2000.0 * sqrt(1.0 - muf_factor * muf_factor);
        
        // Apply solar activity correction
        skip_distance *= (1.0 + (solar.sfi - 100.0) * 0.001);
        
        // Apply geomagnetic activity correction
        skip_distance *= (1.0 + (solar.k_index * 0.02));
    }
    
    return skip_distance;
}

Implementation Requirements

• Distance-based MUF calculations using ITU-R P.1239 formulas
• Multi-hop propagation modeling (E, F1, F2 layers)
• Solar condition dependencies (SFI, K-index effects)
• Seasonal variations based on day of year
• D-layer absorption modeling for LUF calculations
• Ground reflection losses for realistic path modeling

Lowest Usable Frequency (LUF)

• D-layer absorption modeling for low frequencies
• Signal-to-noise considerations based on power
• Atmospheric noise modeling for realistic conditions
• Power level effects on LUF calculations

3.2 Propagation Path Modeling

Multi-path Propagation

• Ground wave vs skywave path selection
• Skip zone calculations for HF bands
• Polarization effects (vertical vs horizontal)
• Multi-hop path modeling for long-distance contacts

Band-Specific Characteristics

• 160m: Ground wave dominant, night propagation
• 80m: Mixed ground/skywave, regional coverage
• 40m: Excellent day/night transition band
• 20m: Primary DX band, solar dependent
• 10m: Solar maximum dependent, sporadic E
• 6m: Tropospheric and sporadic E propagation

---

Phase 4: Audio Simulation & Integration (Week 4)

4.1 Signal Quality Effects

Realistic Fading Implementation

// Extend existing audio.cpp
void FGCom_radiowaveModel_HF::processAudioSamples(
    fgcom_radio lclRadio, 
    float signalQuality, 
    float *outputPCM, 
    uint32_t sampleCount, 
    uint16_t channelCount, 
    uint32_t sampleRateHz) {
    
    // Add propagation-based audio effects
    applyPropagationFading(outputPCM, sampleCount, signalQuality);
    applyBandSpecificEffects(outputPCM, sampleCount, lclRadio.band);
    applySolarConditionEffects(outputPCM, sampleCount, getCurrentSolarConditions());
}

Implementation Requirements

• Propagation-based fading based on signal quality
• QRM/QRN simulation (man-made and natural noise)
• Band-specific characteristics (CW vs SSB behavior)
• Signal strength variations based on solar conditions

4.2 Audio Processing Integration

Extend Existing Audio Pipeline

• Modify processAudioSamples() in HF model
• Add propagation effects to audio samples
• Implement realistic noise based on frequency/conditions
• Add signal quality indicators in user interface

Band-Specific Audio Effects

• CW mode: Narrow bandwidth, good for weak signals
• SSB mode: Wider bandwidth, more affected by QRM
• Frequency-dependent noise characteristics
• Solar condition audio effects (fading, distortion)

---

Phase 5: Advanced Antenna System & GPU Acceleration (Week 5-6)

5.1 Antenna Pattern Support

4NEC2/EZNEC Pattern File Import

// New file: antenna_pattern.h
class FGCom_AntennaPattern {
private:
    std::string pattern_file;
    std::vector<AntennaGainPoint> gain_pattern;
    float frequency_mhz;
    std::string polarization;
    
public:
    bool loadFrom4NEC2(const std::string& filename);
    bool loadFromEZNEC(const std::string& filename);
    float getGainAtAngle(float theta, float phi);
    void optimizeForGPU();
    
    // Antenna gain interpolation methods
    float interpolateGain(float theta, float phi);
    float calculateEffectiveGain(float elevation_angle, float azimuth_angle);
    void applyGroundReflection(float height_above_ground, float ground_conductivity);
};

Antenna Gain Pattern Calculation

Gain Interpolation from Pattern Data

float FGCom_AntennaPattern::interpolateGain(float theta, float phi) {
    // Bilinear interpolation of antenna gain pattern
    
    // Normalize angles
    theta = fmod(theta + 360.0, 360.0);
    phi = fmod(phi + 360.0, 360.0);
    
    // Find nearest pattern points
    float theta_step = 360.0 / (gain_pattern.size() - 1);
    float phi_step = 360.0 / (gain_pattern[0].size() - 1);
    
    int theta_idx = static_cast<int>(theta / theta_step);
    int phi_idx = static_cast<int>(phi / phi_step);
    
    // Bilinear interpolation weights
    float theta_weight = (theta - theta_idx * theta_step) / theta_step;
    float phi_weight = (phi - phi_idx * phi_step) / phi_step;
    
    // Get four surrounding points
    float g00 = gain_pattern[theta_idx][phi_idx];
    float g01 = gain_pattern[theta_idx][(phi_idx + 1) % gain_pattern[0].size()];
    float g10 = gain_pattern[(theta_idx + 1) % gain_pattern.size()][phi_idx];
    float g11 = gain_pattern[(theta_idx + 1) % gain_pattern.size()][(phi_idx + 1) % gain_pattern[0].size()];
    
    // Interpolate
    float gain = g00 * (1.0 - theta_weight) * (1.0 - phi_weight) +
                 g01 * (1.0 - theta_weight) * phi_weight +
                 g10 * theta_weight * (1.0 - phi_weight) +
                 g11 * theta_weight * phi_weight;
    
    return gain;
}

Effective Gain with Ground Reflection

float FGCom_AntennaPattern::calculateEffectiveGain(float elevation_angle, float azimuth_angle) {
    // Calculate effective gain including ground reflection
    
    // Direct path gain
    float direct_gain = interpolateGain(elevation_angle, azimuth_angle);
    
    // Ground reflection gain (image antenna)
    float reflection_gain = interpolateGain(180.0 - elevation_angle, azimuth_angle);
    
    // Ground reflection coefficient
    float ground_reflection_coeff = 0.3; // Typical for average ground
    
    // Effective gain = direct + reflected
    float effective_gain = sqrt(direct_gain * direct_gain + 
                               ground_reflection_coeff * ground_reflection_coeff * 
                               reflection_gain * reflection_gain);
    
    return effective_gain;
}

#### **Complete Signal Quality Calculation**

##### **Integrated Propagation Model**
```cpp
fgcom_radiowave_signal FGCom_radiowaveModel_HF::getSignal(double lat1, double lon1, float alt1, 
                                                          double lat2, double lon2, float alt2, float power) {
    struct fgcom_radiowave_signal signal;
    
    // Get current solar conditions
    fgcom_solar_conditions solar = getCurrentSolarConditions();
    
    // Calculate distance and angles
    double dist = this->getSurfaceDistance(lat1, lon1, lat2, lon2);
    double height_above_horizon = this->heightAboveHorizon(dist, alt1, alt2);
    
    // Get antenna patterns for both stations
    FGCom_AntennaPattern* ant1 = getAntennaPattern(lat1, lon1);
    FGCom_AntennaPattern* ant2 = getAntennaPattern(lat2, lon2);
    
    // Calculate elevation and azimuth angles
    double elevation = this->degreeAboveHorizon(dist, alt2 - alt1);
    double azimuth = this->getDirection(lat1, lon1, lat2, lon2);
    
    // Get antenna gains
    float gain1 = ant1 ? ant1->calculateEffectiveGain(elevation, azimuth) : 0.0;
    float gain2 = ant2 ? ant2->calculateEffectiveGain(elevation, azimuth) : 0.0;
    
    // Calculate MUF and LUF for this path
    float muf = calculateMUF(lat1, lon1, lat2, lon2, solar);
    float luf = calculateLUF(lat1, lon1, lat2, lon2, solar);
    
    // Get frequency from radio
    float freq = getFrequencyFromRadio();
    
    // Check if frequency is usable
    if (freq < luf || freq > muf) {
        signal.quality = 0.0; // Frequency not usable
    } else {
        // Calculate path loss
        float path_loss = calculatePathLoss(dist, freq, solar);
        
        // Calculate received power
        float received_power = power + gain1 + gain2 - path_loss;
        
        // Convert to signal quality (0.0 to 1.0)
        signal.quality = pow(10.0, (received_power + 120.0) / 20.0); // +120 dBm reference
        signal.quality = std::max(0.0f, std::min(1.0f, signal.quality));
        
        // Apply additional propagation effects
        if (height_above_horizon < 0) {
            // Behind horizon - skywave only
            signal.quality *= 0.7;
        }
        
        // Apply solar condition effects
        if (solar.k_index > 5) {
            // High geomagnetic activity
            signal.quality *= (1.0 - (solar.k_index - 5) * 0.1);
        }
        
        // Apply seasonal variations
        float seasonal_factor = 1.0 + 0.2 * sin(2.0 * M_PI * (solar.day_of_year - 172) / 365.25);
        signal.quality *= seasonal_factor;
    }
    
    // Set direction and elevation
    signal.direction = azimuth;
    signal.verticalAngle = elevation;
    
    return signal;
}

Supported File Formats

• 4NEC2 output files - Calculated patterns as text files
• EZNEC radiation pattern data - Generated from NEC geometry models
• Far-field pattern files - ASCII format with angle/gain data
• Theta/Phi coordinates (spherical coordinates)
• Gain values in dBi with frequency information
• Polarization components (vertical/horizontal)

Antenna Types Implementation

• Rotatable antennas (Yagi, directional arrays)
• Stationary antennas (Loop, Ground Plane 1/4 wave, End-fed)
• Multi-band antennas (80m square loop - less noise sensitive)
• Military/Commercial antennas (Whip antennas with proper counterpoise)

5.2 Antenna Height & Environment Modeling

Standard Antenna Heights

struct AntennaEnvironment {
    float height_above_ground;      // Standard: 10m above average ground
    float height_above_sea_level;   // For /MM (maritime mobile) operations
    bool is_maritime_mobile;        // /MM flag for special height rules
    std::string ground_type;        // "average", "saltwater", "urban", "rural"
    float ground_conductivity;      // Ground conductivity for RF calculations
};

Height Rules Implementation

• Standard operation: 10m above average ground
• Maritime mobile (/MM): 1/4 GP 3m above sea level
• Maritime mobile loop: 30m above sea level
• Ground type effects on propagation and antenna performance

5.3 Power Level System

Transmit Power Management

struct PowerLevels {
    std::vector<int> available_powers = {50, 100, 150, 200, 250, 300, 400, 500, 600, 750, 1000};
    int current_power;
    float power_efficiency;         // Antenna efficiency at current power
    bool power_limiting;            // Automatic power limiting for safety
};

Power Effects Implementation

• Power-dependent propagation calculations
• Antenna efficiency variations with power levels
• Safety power limiting for realistic operation
• Power vs distance relationships for different bands

5.4 GPU Acceleration for Complex Calculations

GPU Computing Framework

// New file: gpu_accelerator.h
class FGCom_GPUAccelerator {
private:
    bool gpu_available;
    std::string gpu_vendor;         // "NVIDIA", "AMD", "Intel"
    size_t gpu_memory;
    
public:
    bool initializeGPU();
    void accelerateAntennaPatterns(std::vector<AntennaGainPoint>& patterns);
    void acceleratePropagationCalculations(const std::vector<PropagationPath>& paths);
    void accelerateAudioProcessing(float* audio_buffer, size_t samples);
};

GPU-Accelerated Operations

• Antenna pattern calculations using CUDA/OpenCL
• Propagation path modeling for multiple frequencies
• Real-time audio processing with GPU compute shaders
• Batch processing of multiple QSO calculations

Performance Optimizations

• Memory management for large antenna pattern datasets
• Parallel processing of multiple propagation paths
• GPU memory caching for frequently used patterns
• Fallback to CPU when GPU is unavailable

---

Phase 6: Extended HF Frequency Support (Week 7)

6.1 Non-Amateur HF Bands

Aviation HF Communications

• Aircraft HF bands (2-30 MHz for long-range communication)
• Whip antenna modeling with fuselage as RF ground
• High-altitude propagation effects for aviation
• 6kHz AM filter bandwidth for aviation voice communications
• AM modulation support for aircraft HF systems

Maritime HF Communications

• Ship-to-shore communications (2-30 MHz)
• Coastal radio stations with massive ground systems
• Saltwater ground effects on antenna performance
• Maritime mobile propagation characteristics
• 3kHz filter bandwidth for maritime voice communications
• SSB modulation for ship-to-shore systems

Military HF Communications

• Military vehicle antennas (jeeps, trucks, tanks)
• Proper counterpoise requirements for whip antennas
• RF ground network simulation (star-shaped wire networks)
• Tactical communication frequency bands
• Variable filter bandwidths based on communication requirements
• Secure communication modes with appropriate filtering

6.2 Antenna Ground System Modeling

Ground System Types

struct GroundSystem {
    std::string type;               // "star_network", "copper_plate", "fuselage"
    float conductivity;              // Ground conductivity in S/m
    float area_coverage;            // Coverage area in square meters
    bool is_saltwater;              // Saltwater ground effects
    float depth;                    // Ground system depth
};

Ground System Effects

• Star-shaped wire networks for coastal stations
• Copper plates in saltwater environments
• Vehicle fuselage as RF ground for aircraft
• Ground conductivity effects on antenna performance

---

Phase 7: Advanced Audio Simulation Features (Week 8)

7.1 Frequency Offset Simulation (Donald Duck Effect)

Complex Exponential Method

// Advanced audio processing for frequency offsets
void applyFrequencyOffset(float* audio_buffer, size_t samples, float offset_hz) {
    // Create analytic signal using Hilbert transform
    std::complex<float>* analytic_signal = createAnalyticSignal(audio_buffer, samples);
    
    // Apply frequency shift by complex multiplication
    for (size_t i = 0; i < samples; i++) {
        float time = static_cast<float>(i) / sample_rate;
        std::complex<float> shift = std::exp(std::complex<float>(0, 2 * M_PI * offset_hz * time));
        analytic_signal[i] *= shift;
    }
    
    // Extract real part for output
    extractRealPart(analytic_signal, audio_buffer, samples);
}

Alternative Resampling Method

• Time-axis stretching while maintaining sample rate
• Variable playback speed for frequency effects
• Quality preservation during resampling operations

7.2 BFO (Beat Frequency Oscillator) Simulation

BFO Implementation for CW/SSB

class FGCom_BFO {
private:
    float bfo_frequency;
    float carrier_frequency;
    float beat_frequency;
    
public:
    void setBFOFrequency(float freq);
    void setCarrierFrequency(float freq);
    float getBeatFrequency() const;
    void processSignal(float* input, float* output, size_t samples);
};

BFO Operation Details

• CW detection with 400-800 Hz beat frequency
• SSB demodulation with carrier reconstruction
• AM demodulation for aviation and commercial communications
• Heterodyne mixing for signal detection
• Beat frequency tuning for optimal audio quality
• Mode-specific BFO settings for different communication types

7.3 Advanced Audio Filtering

Bandpass Filter Implementation

// Multi-mode audio filtering system
class FGCom_AudioFilter {
public:
    void applySSBFilter(float* audio, size_t samples);      // 2.4kHz bandwidth
    void applyAMFilter(float* audio, size_t samples);       // 6kHz bandwidth for aviation
    void applyCWFilter(float* audio, size_t samples);       // 500Hz or 250Hz bandwidth
    void applyAviationFilter(float* audio, size_t samples); // 6kHz for aircraft HF
    void applyMaritimeFilter(float* audio, size_t samples); // 3kHz for ship communications
    void applyNotchFilter(float* audio, size_t samples, float notch_freq);
    
    // Dynamic filter selection based on communication mode
    void applyModeSpecificFilter(float* audio, size_t samples, const std::string& mode);
};

Filter Characteristics

• SSB filters: 2.4kHz bandwidth for amateur voice communications
• AM filters: 6kHz bandwidth for aviation and commercial voice
• CW filters: 500Hz or 250Hz for Morse code
• Aviation filters: 6kHz for HF aircraft communications
• Maritime filters: 3kHz for ship-to-shore communications
• Notch filters: Interference rejection
• Adaptive filtering based on signal conditions and mode

---

Phase 8: Real-Time Propagation Monitoring (Week 9)

8.1 DX Cluster Integration

PSKReporter API Integration

// Real-time propagation data from PSKReporter
class FGCom_PSKReporter {
private:
    std::string api_endpoint;
    std::string api_key;
    std::chrono::minutes update_interval;
    
public:
    bool connectToAPI();
    std::vector<PropagationReport> getRecentReports();
    void updatePropagationModel(const std::vector<PropagationReport>& reports);
};

Real-Time Updates

• 5-minute update intervals for current propagation
• Live QSO reports from active stations
• Band opening detection for rare propagation events
• Automatic model updates based on real data

8.2 Fuzzy Logic Propagation Modeling

Unpredictable HF Behavior

// Fuzzy logic for HF propagation surprises
class FGCom_FuzzyPropagation {
private:
    float unpredictability_factor;
    std::vector<PropagationAnomaly> recent_anomalies;
    
public:
    void addAnomaly(const PropagationAnomaly& anomaly);
    float calculateUnpredictabilityFactor();
    void adjustPropagationModel(float factor);
};

Anomaly Detection

• Sporadic E-skip on 18-28 MHz (10-30 minutes duration)
• Summer 50 MHz openings during solar maximum
• Unexpected band openings despite VOACAP predictions
• Real-time adjustment of propagation models

---

Phase 9: Real-Time Weather & Lightning Integration (Week 10)

9.1 Lightning Strike Data Integration

Real-Time Lightning API Integration

// Lightning data provider for atmospheric noise simulation
class FGCom_LightningDataProvider {
private:
    std::string api_endpoint;
    std::string api_key;
    std::chrono::minutes update_interval;
    std::vector<LightningStrike> recent_strikes;
    
public:
    bool connectToAPI();
    std::vector<LightningStrike> getRecentLightningStrikes();
    float calculateAtmosphericNoiseLevel(double lat, double lon);
    void updateLightningDatabase(const std::vector<LightningStrike>& strikes);
};

Lightning Strike Data Structure

struct LightningStrike {
    double latitude;
    double longitude;
    std::chrono::system_clock::time_point timestamp;
    float intensity;           // Peak current in kA
    float distance;            // Distance from target location
    std::string type;          // "cloud-to-ground", "cloud-to-cloud"
    bool is_nearby;            // Within 100km for noise effects
};

Free Lightning Data Sources

• Blitzortung.org API - Community-driven lightning detection network
• OpenWeatherMap Lightning API - Free tier with lightning data
• WeatherAPI.com - Free lightning strike data
• NOAA Lightning Detection Network - Government lightning data
• Blitzortung WebSocket - Real-time lightning feed

9.2 Atmospheric Noise Simulation

Static Crash Generation

// Atmospheric noise simulation based on lightning data
class FGCom_AtmosphericNoise {
private:
    std::vector<LightningStrike> nearby_strikes;
    float base_noise_level;
    
public:
    void addLightningStrike(const LightningStrike& strike);
    float generateStaticCrash(float signal_strength, const std::string& mode);
    float calculateNoiseFloor(double lat, double lon, float freq);
    void applyAtmosphericNoise(float* audio_buffer, size_t samples, const std::string& mode);
};

Mode-Specific Noise Effects

float FGCom_AtmosphericNoise::generateStaticCrash(float signal_strength, const std::string& mode) {
    float noise_level = 0.0;
    
    if (mode == "AM") {
        // AM is most affected by atmospheric noise
        noise_level = base_noise_level * 2.0;  // Double the noise impact
    } else if (mode == "CW") {
        // CW is second most affected
        noise_level = base_noise_level * 1.5;  // 1.5x noise impact
    } else if (mode == "SSB") {
        // SSB has some noise immunity
        noise_level = base_noise_level * 0.8;  // 0.8x noise impact
    }
    
    // Add random static crash bursts
    if (rand() % 100 < 5) {  // 5% chance of static crash
        noise_level *= (3.0 + (rand() % 100) / 100.0);  // 3-4x burst
    }
    
    return noise_level;
}

Real-Time Lightning Integration

// Real-time lightning data processing
void FGCom_LightningDataProvider::processLightningWebhook(const std::string& webhook_data) {
    // Parse incoming lightning strike data
    auto strikes = parseLightningWebhook(webhook_data);
    
    for (const auto& strike : strikes) {
        // Check if strike affects current location
        if (isStrikeRelevant(strike)) {
            // Add to nearby strikes database
            addNearbyStrike(strike);
            
            // Trigger immediate noise update
            updateAtmosphericNoise();
            
            // Log for debugging
            pluginDbg("Lightning strike detected: " + std::to_string(strike.intensity) + "kA at " + 
                     std::to_string(strike.latitude) + "," + std::to_string(strike.longitude));
        }
    }
}

9.3 Weather Data Integration

Weather API Providers

// Weather data integration for propagation effects
class FGCom_WeatherDataProvider {
private:
    std::string openweather_api_key;
    std::string weatherapi_key;
    
public:
    WeatherConditions getCurrentWeather(double lat, double lon);
    float getAtmosphericPressure(double lat, double lon);
    float getHumidity(double lat, double lon);
    bool isThunderstormActive(double lat, double lon);
};

Free Weather Data Sources

• OpenWeatherMap API - Free tier: 1000 calls/day
• WeatherAPI.com - Free tier: 1,000,000 calls/month
• Open-Meteo - Completely free, no API key required
• NOAA Weather API - Government weather data
• [ Tomorrow.io - Free tier with lightning data

Weather Effects on Propagation

struct WeatherConditions {
    float temperature;          // Temperature in Celsius
    float humidity;             // Relative humidity %
    float pressure;             // Atmospheric pressure hPa
    float visibility;           // Visibility in km
    std::string conditions;     // "clear", "rain", "thunderstorm"
    bool lightning_active;       // Lightning activity flag
    float noise_floor;          // Atmospheric noise floor
};

9.4 Audio Processing Integration

Static Crash Audio Effects

// Integrate atmospheric noise into audio processing
void FGCom_radiowaveModel_HF::processAudioSamples(fgcom_radio lclRadio, float signalQuality, 
                                                  float *outputPCM, uint32_t sampleCount, 
                                                  uint16_t channelCount, uint32_t sampleRateHz) {
    
    // Apply basic propagation effects
    applyPropagationFading(outputPCM, sampleCount, signalQuality);
    
    // Apply atmospheric noise based on lightning data
    if (lclRadio.mode == "AM" || lclRadio.mode == "CW") {
        float atmospheric_noise = getAtmosphericNoiseLevel(lclRadio.latitude, lclRadio.longitude);
        applyAtmosphericNoise(outputPCM, sampleCount, lclRadio.mode, atmospheric_noise);
    }
    
    // Apply band-specific effects
    applyBandSpecificEffects(outputPCM, sampleCount, lclRadio.band);
}

Noise Floor Calculation

float FGCom_AtmosphericNoise::calculateNoiseFloor(double lat, double lon, float freq) {
    float base_noise = -120.0;  // Base noise floor in dBm
    
    // Add lightning strike effects
    for (const auto& strike : nearby_strikes) {
        float distance = calculateDistance(lat, lon, strike.latitude, strike.longitude);
        if (distance < 100.0) {  // Within 100km
            float strike_effect = strike.intensity * (100.0 - distance) / 100.0;
            base_noise += strike_effect * 0.1;  // 0.1 dB per kA per km
        }
    }
    
    // Frequency-dependent noise (lower frequencies = more noise)
    if (freq < 4.0) {
        base_noise += 10.0;  // +10 dB for 160m band
    } else if (freq < 10.0) {
        base_noise += 5.0;   // +5 dB for 80m/40m bands
    }
    
    return base_noise;
}

9.5 Configuration & API Keys

Add to fgcom-mumble.ini

[weather_integration]
enable_lightning_data=true
enable_weather_data=true
lightning_update_interval=30
weather_update_interval=300

[lightning_api]
provider=blitzortung
api_key=
webhook_url=
max_distance_km=100

[weather_api]
provider=openweathermap
api_key=
update_interval=300

Webhook Configuration

// Webhook endpoint for real-time lightning data
void FGCom_APIServer::handleLightningWebhook(const httplib::Request& req, httplib::Response& res) {
    std::string webhook_data = req.body;
    
    // Process incoming lightning data
    lightningProvider.processLightningWebhook(webhook_data);
    
    res.status = 200;
    res.set_content("Lightning data received", "text/plain");
}

9.6 Implementation Benefits

Realistic HF Simulation

• Static crashes from nearby lightning strikes
• Mode-specific noise effects (AM/CW most affected)
• Real-time atmospheric conditions affecting propagation
• Weather-dependent noise floors for different bands

Educational Value

• Learn about atmospheric noise effects on HF
• Understand mode selection for different conditions
• Real-time weather integration for propagation modeling
• Practical experience with lightning interference

Performance Considerations

• Efficient lightning data processing with spatial indexing
• Background weather updates without affecting audio
• Caching of weather data to minimize API calls
• GPU acceleration for noise generation algorithms

---

Technical Implementation Details

1. Threading Architecture Extensions

New Background Threads

// Add to existing thread management in fgcom-mumble.cpp
std::thread solarDataThread(fgcom_spawnSolarDataManager);
std::thread propagationThread(fgcom_spawnPropagationEngine);
std::thread apiServerThread(fgcom_spawnAPIServer);
std::thread gpuComputeThread(fgcom_spawnGPUComputeEngine);

// Solar data manager (15-minute updates)
void fgcom_spawnSolarDataManager() {
    while (!fgcom_solarDataShutdown) {
        updateSolarConditions();
        std::this_thread::sleep_for(std::chrono::minutes(15));
    }
}

// Propagation calculation worker
void fgcom_spawnPropagationEngine() {
    while (!fgcom_propagationShutdown) {
        processPropagationQueue();
        std::this_thread::sleep_for(std::chrono::milliseconds(100));
    }
}

// GPU compute engine for heavy calculations
void fgcom_spawnGPUComputeEngine() {
    while (!fgcom_gpuComputeShutdown) {
        processGPUComputeQueue();
        std::this_thread::sleep_for(std::chrono::milliseconds(10));
    }
}

Thread Safety Extensions

// Add to globalVars.h
extern std::mutex fgcom_solar_data_mtx;
extern std::mutex fgcom_propagation_cache_mtx;
extern std::shared_mutex fgcom_band_plan_mtx;
extern std::mutex fgcom_gpu_compute_mtx;
extern std::mutex fgcom_antenna_pattern_mtx;

// Solar data cache with thread safety
struct SolarDataCache {
    std::mutex data_mutex;
    std::atomic<time_t> last_update;
    fgcom_solar_conditions current_data;
    std::vector<fgcom_solar_conditions> historical_data;
};

// GPU compute queue with thread safety
struct GPUComputeQueue {
    std::mutex queue_mutex;
    std::queue<GPUComputeTask> pending_tasks;
    std::atomic<bool> gpu_busy;
    std::condition_variable task_available;
};

2. Configuration System Extensions

Add to fgcom-mumble.ini

[amateur_radio]
enabled=true
itu_region=auto
strict_band_compliance=true
default_power=100
antenna_height=10

[solar_data]
noaa_api_url=https://services.swpc.noaa.gov/json/
update_interval=900
fallback_data_path=/usr/share/fgcom-mumble/solar_fallback.json

[propagation]
enable_muf_luf=true
enable_solar_effects=true
enable_seasonal_variations=true
cache_propagation_results=true

[antenna_system]
enable_4nec2_patterns=true
enable_gpu_acceleration=true
antenna_pattern_cache_size=1000
default_ground_type=average

[gpu_acceleration]
enable_cuda=true
enable_opencl=true
gpu_memory_limit=2048
fallback_to_cpu=true

3. API Integration for External Clients

RESTful Endpoints

// New API server module
class FGCom_APIServer {
public:
    void startServer(int port);
    void handlePropagationRequest(const httplib::Request& req, httplib::Response& res);
    void handleSolarDataRequest(const httplib::Request& req, httplib::Response& res);
    void handleBandStatusRequest(const httplib::Request& req, httplib::Response& res);
    void handleAntennaPatternRequest(const httplib::Request& req, httplib::Response& res);
    void handleGPUStatusRequest(const httplib::Request& req, httplib::Response& res);
};

WebSocket Real-time Updates

// Real-time propagation updates
void FGCom_APIServer::broadcastPropagationUpdate(const fgcom_solar_conditions& solar) {
    std::string json = solarConditionsToJSON(solar);
    for (auto& client : connectedClients) {
        client->send(json);
    }
}

---

Testing Strategy

1. Unit Testing

• Individual propagation models with known inputs/outputs
• Solar data parsing with sample NOAA responses
• Frequency calculations across amateur radio bands
• Grid locator calculations with known coordinates

2. Integration Testing

• End-to-end propagation from simulator to audio output
• Real-time solar data integration
• Performance testing under various load conditions
• Compatibility testing with existing flight simulator setups

3. Performance Testing

• Multi-threaded propagation calculations
• Memory usage during high-load scenarios
• CPU utilization across multiple cores
• Response time for API requests

---

Success Criteria

1. Functional Requirements

• All 10 amateur bands (160m-6m) are fully functional
• Maidenhead grid locators provide accurate distance/bearing
• Real-time solar data from NOAA/SWPC is integrated
• MUF/LUF calculations work for amateur radio paths
• Audio simulation reflects realistic propagation conditions
• 4NEC2/EZNEC antenna patterns are fully supported
• GPU acceleration for complex calculations
• Extended HF bands for aviation, maritime, and military
• Advanced audio features (BFO, frequency offset, filtering)

2. Performance Requirements

• Real-time audio processing without latency
• Background solar updates don't affect audio quality
• API response times under 100ms for simple requests
• Memory usage stays within reasonable limits
• GPU acceleration provides 5-10x speedup for complex calculations
• Antenna pattern processing under 50ms for real-time updates
• Multi-threaded propagation calculations utilize all CPU cores

3. Integration Requirements

• Seamless integration with existing HF model
• Backward compatibility with current configurations
• External client support via REST API
• Real-time updates via WebSocket connections
• GPU driver compatibility across NVIDIA, AMD, and Intel platforms
• 4NEC2/EZNEC file format support for antenna patterns
• Real-time propagation monitoring via PSKReporter API

---

Risk Mitigation

1. Technical Risks

• Solar data API failures: Implement fallback data and offline mode
• Performance issues: Use existing multi-threading infrastructure
• Memory leaks: Leverage existing garbage collector thread
• Audio quality degradation: Maintain existing audio processing pipeline

2. Timeline Risks

• Complex propagation calculations: Start with simplified models, enhance iteratively
• External API integration: Use existing HTTP client library
• Testing complexity: Leverage existing test framework and multi-threading support

3. Compatibility Risks

• Existing functionality: Extend rather than replace current systems
• User configurations: Maintain backward compatibility
• Platform support: Use existing cross-platform threading support

---

Next Steps

Immediate Actions (Week 1)

1. Set up development environment with existing codebase
2. Import band plan data from Supermorse-server CSV
3. Extend HF radio model with amateur radio structures
4. Implement basic band validation and frequency checking

Week 2 Goals

1. Complete solar data integration with NOAA/SWPC
2. Implement day/night calculations and seasonal variations
3. Add solar condition effects to existing HF model
4. Begin MUF/LUF calculation framework

Week 3 Objectives

1. Complete MUF/LUF calculations with ITU-R formulas
2. Implement multi-path propagation modeling
3. Add band-specific characteristics for all amateur bands
4. Begin audio effects integration

Week 4 Deliverables

1. Complete audio simulation with propagation effects
2. Finish API server for external client support
3. Comprehensive testing across all features
4. Documentation and user guides for new capabilities

Week 5-6 Deliverables

1. 4NEC2/EZNEC antenna pattern support
2. GPU acceleration framework implementation
3. Advanced antenna system with height/environment modeling
4. Power level system with realistic effects

Week 7 Deliverables

1. Extended HF frequency support for aviation/maritime/military
2. Ground system modeling for various environments
3. Antenna counterpoise requirements implementation

Week 8 Deliverables

1. Advanced audio features (BFO, frequency offset, filtering)
2. CW/SSB demodulation simulation
3. Audio filtering system for different modes

Week 9 Deliverables

1. PSKReporter API integration for real-time propagation
2. Fuzzy logic modeling for unpredictable HF behavior
3. Final testing and optimization across all features

Week 10 Deliverables

1. Real-time lightning data integration for atmospheric noise
2. Weather API integration for propagation effects
3. Static crash simulation with mode-specific effects
4. Complete weather-dependent propagation modeling

---

Conclusion

The fgcom-mumble project provides an excellent foundation for implementing advanced amateur radio HF propagation. The existing multi-threading architecture, modular design, and thread safety mechanisms make this implementation straightforward and efficient.

By following this 9-week plan, we can deliver a professional-grade amateur radio propagation simulator that integrates seamlessly with the existing system while providing the advanced features requested in the GitHub issue.

The implementation leverages existing strengths:

• ✅ Proven multi-threading architecture
• ✅ Extensible radio model system
• ✅ Thread-safe data structures
• ✅ Cross-platform compatibility
• ✅ Existing audio processing pipeline

GPU Acceleration Benefits

• 🚀 5-10x speedup for complex antenna pattern calculations
• 🚀 Real-time processing of large propagation datasets
• 🚀 Efficient memory usage for antenna pattern caching
• 🚀 Cross-platform GPU support (CUDA, OpenCL, DirectX)

Advanced Features Delivered

• 📡 Professional antenna modeling with 4NEC2/EZNEC support
• 🌊 Extended HF frequency coverage for aviation, maritime, military
• 🎵 Advanced audio simulation with BFO, filtering, and effects
• 📊 Real-time propagation monitoring via PSKReporter API
• 🎯 Fuzzy logic modeling for unpredictable HF behavior

This approach minimizes risk while maximizing the value delivered to users, creating a system that can compete with commercial amateur radio simulation software and provide educational value for learning HF propagation physics.

[hbeni]

I did a quick scan over the ai generated document and I think some aspects are „out of scope“ for the framework.

For example:

• Maidenhead grid locator
  Unless I get this wrong, this should be done in client space. There the grid coordinates need to be converted to lat/long geo coordinates (which can be based on 0/0 for „local grids“) and calculations can be done correctly with a spherical body, which is already implemented. No need to add protocol fields for this.
• The same goes for the bands.
  These are essentially „channel names“. We can easily add code to parse FRQ fields using the string10m into the proper real HF „center“ freqency for internal calculations. No need to change the udp Protocol. (A live example of this is the 8.33 VHF airband channel names).
• Freqency validation
  This should also be implemented in the client, not the framework.

Also, architecture wise we should not do data lookups in the mumble plugin. I think a better approach would be to just implement the logic/simulation aspects here (receivability, signal quality, audio distortion, …). Then we should invent a new UDP protocol stream for weather (+solar, +etc) data which updates the internal simulations state. This way, the client can easily add for example a lightning strike. For VFH, I already tought of adding such a protocol for terrain sampling. The source of the UDP updates can be arbitary this way, for example the online sources you mentioned - reading that and generating updates for the framework is the clients job. (The reason to do it this way is an architectural decision made at the start of the project, the goal here is that the framework/plugin should be as simple as well as detached from internet as possible)

[Supermagnum]

I did a quick scan over the ai generated document and I think some aspects are „out of scope“ for the framework.

For example:

* Maidenhead grid locator
  Unless I get this wrong, this should be done in client space. There the grid coordinates need to be converted to lat/long geo coordinates (which can be based on 0/0 for „local grids“) and calculations can be done correctly with a spherical body, which is already implemented. No need to add protocol fields for this.

* The same goes for the bands.
  These are essentially „channel names“. We can easily add code to parse `FRQ` fields using the string`10m` into the proper real HF „center“ freqency for internal calculations. No need to change the udp Protocol. (A live example of this is the 8.33 VHF airband channel names).

* Freqency validation
  This should also be implemented in the client, not the framework.

Also, architecture wise we should not do data lookups in the mumble plugin. I think a better approach would be to just implement the logic/simulation aspects here (receivability, signal quality, audio distortion, …). Then we should invent a new UDP protocol stream for weather (+solar, +etc) data which updates the internal simulations state. This way, the client can easily add for example a lightning strike. For VFH, I already tought of adding such a protocol for terrain sampling. The source of the UDP updates can be arbitary this way, for example the online sources you mentioned - reading that and generating updates for the framework is the clients job. (The reason to do it this way is an architectural decision made at the start of the project, the goal here is that the framework/plugin should be as simple as well as detached from internet as possible)

Yes, but remember that maidenhead locators are squares, precision depends on number of characters.
Example:
Precision of JP88il

Grid Size: The Maidenhead grid is divided into squares that are 1 degree of latitude by 2 degrees of longitude. Each square is further divided into smaller squares.
Specifics of JP88il: The "JP" indicates the grid square, while "88" specifies the numerical part of the grid. The "il" further divides this square into a smaller area.
Location: The JP88il square covers an area of approximately 1 km² (1,000,000 m²) in size.

In summary, the JP88il grid square provides a location with a precision of about 1 kilometer in both latitude and longitude. Radio amateurs uses 6 characters, good enough.

[Supermagnum]

Much of the propagation simulation is pretty resource intensive,- so it could be possible to use the users GPU for that,

[Supermagnum]

This compiles, but some antenna radiation patterns are missing. Example is the Cessna at 200 meters altitude with a +45° roll, -45° roll, +25°, -25° roll etc.
I will add those in a couple of days.
The modified code then uses that data to interpolate between those, as if will affect radio wave propagation . It also has the possibility to either use a GPU if the server has one, or offload that to the users, or both users and the server.
It will need proper debugging and testing.
There are documentation on API usage etc..
https://github.com/Supermagnum/fgcom-mumble