elevationAdjust does not take effect under certain conditions

[Hsymbol-511]

When the JSON signal power configuration is as follows, all satellites in the generated signal have the same carrier-to-noise ratio, and power adjustment based on elevation angle does not work:

json
"power": {
"noiseFloor": -172,
"initPower": {
"unit": "dBHz",
"value": 56
},
"elevationAdjust": true
}
After consulting DeepSeek, I found that the issue lies in CSatelliteParam::UpdateCN0 within SatelliteParam.cpp. This function only updates CN0 when PowerListCount > 0 and a matching power control entry exists. Since my configuration lacks a powerControl array, the PowerControlArray inside the CPowerControl object is empty. In the call chain StepToNextMs() → UpdateSatParamList() → UpdateCN0(), PowerListCount equals 0, causing the for loop to be skipped. As a result, CN0 remains at the initial value of 56 dB-Hz, and elevation attenuation is never applied.

The correct behavior should be: if there is no power control list or no matching entry is found, the configured CN0 should be used with elevation attenuation applied.

However, the specification manual (Section 7. Signal Power Configuration) states that if a specific satellite signal power is set, power adjustment based on elevation angle will not be applied. If the default value is used, then the adjust setting determines whether elevation-based power adjustment takes effect. I also asked DeepSeek about this and received an answer referenced in this link:
https://chat.deepseek.com/share/cfeyc9f3uub1aj2ci7

After following the steps suggested by DeepSeek and making the modifications, the CN0 for each satellite does indeed attenuate according to its elevation angle.

Additionally, I noticed that almost all AI assistants recommend the elevation-based power attenuation formula as:
(1 - sqrt(sin(Elevation))) * 25
rather than:
(1 - sqrt((Elevation))) * 25
I'm not sure which one is correct.

[khan-hannan]

adding a sin would be a better option, since we see that in case of 90 degrees (or pi/2 since that is what will be stored in elevation here after SatElAz()) elevation we would get the correct value of sqrt(sin(elevation)) == 1 rather than the 1.25 we will get otherwise. i would go one step ahead and place a clamp as well since i had added some satellites which might drift below the horizon and cause negative elevation values. This cause random clippings and reduced the agc gain to 0. this is what i am currently using
(1 - sqrt(std::max(0.0, sin(Elevation)))) * 25;

[globsky]

Thanks for all the feedback. Actually I am now reconsidering the elevation adjustment method. The square-root sin power fading is only for atmospehere, but on the satellite side, the antenna has extra gain to compensate lower elevation. I am going to make a quick fix on above issue, and redesign the method according to real scenario and commertial simulator design later.