I found that the unit of N0 in "Noise" section is dB/Hz, and I think it should be dBm/Hz, just like the N0 in the "Min Link Channel Noise Power" below.

RealAntennas/src/RealAntennasProject/Network/ConnectionDebugger.cs

Well, the "Min Link Channel Noise Power" seems also have some faults.
The two "dB" in {RATools.LogScale(data.minSymbolRate):F1} dB and {channelNoise:F1} dB" should be "dBm" I think.
The unit of "Channel Noise power" in the "Min Link Eb/N0" below is "dBm".
RealAntennas/src/RealAntennasProject/Network/ConnectionDebugger.cs
RealAntennas/src/RealAntennasProject/Network/ConnectionDebugger.cs

DRVeyl said: Appears I was a little sloppy with units in crafting the debugger. Thanks for the dimensional analysis. I'll keep this open and make a change on next release... which has no timeline currently. [Maybe if Egg's Skopos gets some progress, he has some things he wants to PR, and I might return enough for another bugfix update and merge his things.]

You're correct, N0 will be dBm/Hz. Channel noise power should be dBm. Line 129 looks correct. Line 127 I will keep minSymbolRate in dB [it's just the log scale of the bandwidth] but channelNoise at the very end is dBm.

Migrated from DRVeyl#88

Not sure how hard it'd be to disable the hotkey when a text field is selected, but it's mildly annoying when using roman numerals in vessel names

Migrated from DRVeyl#92

Someone who understands the RA codebase should investigate this DRVeyl#90

Feature request, display beamwidth in the PAW alongside gain for those of us who are not well-versed on antennas and gain-to-beamwidth conversions.

Migrated from DRVeyl#93

The use case is RP-1 simulations that happen in far future where a facility upgrade will get completed.

RP-1 will call UpgradeableFacility.SetLevel() which in turn will fire the following events:

• GameEvents.OnKSCFacilityUpgrading

• GameEvents.OnUpgradeableObjLevelChange

• In a coroutine GameEvents.OnKSCFacilityUpgraded

Ref: https://discord.com/channels/319857228905447436/512556346869284864/1144421956649758872

Actually it looks like they do not apply in space center scene either. At least Kerbalism will report wrong data rates until a scene change is done.

Migrated from DRVeyl#94

I have attempted to migrate the more relevant issues from https://github.com/DRVeyl/RealAntennas/issues. The remaining issues appear to pertain to stock, have already been resolved, or are mostly irrelevant. However, some of them may still be worth looking at.

When establishing a link with a ground station, RA does not enforce the encoding and bitrate limits of the ground station.

While a connection from a low TL antenna to a high TL antenna will result in the encoding and bitrate of the worse antenna being used, when establishing a connection between a low TL ground station and a high TL antenna, the encoding and bitrate of the superior antenna will be used, and the limited bitrate of the ground station ignored. This is shown both in the planner and in the antenna debug in flight.

What it says on the tin. There are a lot of launchsite tracking stations cluttering the planner, which make it difficult to find the desired ground station if you want to check one connection in specific. This will probably only be worsened by the addition of new tracking stations with unique characteristics (Skopos, or one of the ground station PRs).

Hiding all antennas except those operating in the same band as the one currently selected on the antenna the planner is focused on would make finding the desired ground station much easier.

Migrated from DRVeyl#98

Just an idle thought that occurred to me.

Several antenna types, notably Yagis and helical antennas, are only effective at one radio frequency. At the moment, an antenna of this type configured to operate in the VHF or UHF band can be switched to higher frequency bands, where they will achieve unrealistically high gain values.

Being able to restrict an antenna to a single band or set of bands would allow for more realistic configuration of Yagi and Helical type antennas.

For modulation values greater than QPSK (2 bits), the planner reported max antenna bitrate is incorrect (although the calculated link speed is correct).

When moving from BPSK to QPSK encoding, antenna reported max bitrate doubles (as expected). However, when moving from QPSK to 8PSK, antenna reported max bitrate only increases by a factor of 1.5 (while actual performance doubles, as expected). This continues with 8PSK -> 16PSK only reporting a 1.33x increase, 16PSK -> 32QAM only reporting a 1.25x increase, and 32QAM -> 64QAM only reporting a 1.2x increase.

Although this doesn't actually have any gameplay effect (connections are still correctly calculated as if bitrate doubled for each modulation step), it results in the planner reporting absurd and confusing connections where the achieved link is several times faster than the reported maximum antenna speed.

See DRVeyl#81 by @tinygrox

See DRVeyl#95

I'd really like to be able to target RA antennas with kOS scripts, but kOS won't let you modify fields of unknown modded components as seen here:

Of course fields like Antenna band etc should stay read-only.

Is there any chance this could be added?

If antennaDiameter is used to set the gain of a ground station, the ground station in map view will report it's gain to many decimal places, which looks rather messy. Gain is truncated to one decimal place in all other instances, so the same should probably done for ground stations in the map view.

For whatever reason, when hitting the "Earth" button in the RA planner, the min and max ranges are set to -2918860 km and 301 Gm, respectively. This is very unhelpful and probably unintended, as neither of these values seem to correspond to anything useful?

Migrated from DRVeyl#99

The RA antenna planner, both in the VAB and in Flight, will ignore the set AMWTemp value for Skopos ground stations, and instead use the default antenna noise temp for the ground station tech level. This results in the antenna planner dramatically underestimating achievable connection speed, especially at low tech levels where the default AMWTemp is very high.

Actual in-flight performance appears to be correct, and the Antenna debugger reports the correct AMWTemp.

From my limited understanding of RA, it appears the Antenna planner checks against some value (I suspect isHome) to determine if an Antenna is a ground station, and therefore has a defined AMWTemp. Since Skopos ground stations do not set this value as expected (all Skopos ground stations have isHome set to False), it uses the default AMWTemp value instead of the one defined in the config.