Communications overhaul proposal

[MikeOnTea]

First, not sure if RO or RP-0 is the right tracker for this, both are affected i guess, also there's #1965 but i thought a new issue for this proposal might be appropriate.

As i've been wanting to fix vessel to vessel ranges with Commnet, i did some research on real world DSN upgrade levels (one good source). As in the real world alot of the upgrades were driven by the desire for higher data rates, ideally we would have data rates matter in the game as well. So i got to learn Kerbalism already supports attenuating data rates by distance, and although it does not use realistic formulas to do it right now, those would be easy to change in their code. So, how could all of this look like? Let's get to DSN upgrades first.

DSN Upgrades

I extracted the numbers from the source mentioned above, plus put an additional level of 18 m antennas as base level before the creation of the 26 m DSN antennas.

The extracted raw data looks like this:

Year	Upgrade factor	Description
1958	2	Initial DSN 26 m antennas
1962	4	Maser
1967	4.1	64m antennas
1968	4.0	Reduced microwave noise
1969	2.2	Block coding
1971	2.5	Reduced ant surf tolerances
1972	1.58	Improved Antennas
1973	1.5	Improved Coding
1975	7.64	X-band maser
1979	1.5	64 m + 34 m array
1981	1.12	Reduced microwave noise
1987	1.2	70 m antenna
1989	1.17	70m + 2 34m array

There's a problem with this data, while it roughly matches the progression from real reported spacecraft data rates, it is actually too big by a factor of roughly 2 when comparing Mariner 2 and Voyager.
Also, i heard some people don't like that many upgrades, so we could merge some and also fix the factor 2:

Year	Upgrade factor	Description
1958	2	Initial DSN, 26 m antennas
1962	4	Maser
1967	4.1	64m antennas
1968	6.0	Reduced microwave noise
1972	6.0	Improved Antennas
1975	4	X-band maser
1979	1.68	64 m + 34 m array
1989	2	70 m antenna + 2 34m array

Antenna ranges

Given the DSN upgrades, antenna ranges would look like this:

Antenna	Initial DSN	70' DSN	89' DSN
Apollo Omni	4.72E8 m	6.62E9 m	6.09E10 m
Mariner 2	2.97E10 m	4.17E11 m	3.83E12 m
Mariner 4	1.30E11 m	1.82E12 m	1.68E13 m
Pioneer 10	2.16E11 m	3.04E12 m	2.79E13 m
Voyager	4.72E11 m	6.62E12 m	6.09E13 m

Data rates

Data rates at 300 Gm

Antenna	Initial DSN	70' DSN	89' DSN
Mariner 2	-	15 b/s	1,328 b/s
Mariner 4	-	296 b/s	8,000 b/s
Pioneer 10	-	1,638 b/s	16,000 b/s
Voyager	297 b/s	58,411 b/s	120,000 b/s

Data rates at 9.6 AU/Saturn

Antenna	Initial DSN	70' DSN	89' DSN
Pioneer 10	-	71 b/s	6,153 b/s
Voyager	-	2,549 b/s	120,000 b/s

Vessel to vessel communication with omnis works, as well, the Apollo antenna has a vessel to vessel range of 800 km in this example.

This would need a rebalance of all experiment data amounts, of course.

Commnet fallback

As kerbalism uses the stock commnet system, the range values would be used for commnet as well and would automatically provide a fallback if, for example, a user does not install kerbalism for whatever reason. Basically, he would "only" lose attenuated data rates, the ranges and communications itself would still work.

What's still not quite realistic with this system

• We still only use one value for transmit and receive power/sensitivity. This mainly affects vessel to vessel comms though, especially when stacking antennas.
• Early probes IRL had only a select few data rates available, Mariner 2/4 for example had 8 and 33 b/s.
• The X-band maser upgrade for the DSN only benefitted antennas actually using the x-band i guess, while in KSP every antenna benefits from every upgrade.
• IRL spacecraft would have to share DSN time slots, in KSP every s/c can communicate in parallel

How the values are calculated

Currently i use the Apollo VHF omni and the Mariner 2 antennas as reference. The Apollo antenna is used as reference for the spacecraft antenna strengths so it has a vessel to vessel range of 800 km, the mariner 2 antenna is used to balance DSN strengths so it is capable of communicating with the DSN at the time at distances of up to ~0.56 AU. I did a script for this that calculates the antenna/dsn strength values plus the values in the tables above. To add new antennas, i simply need to specify antenna gain, transmit power and minimum data rate.

A note about antenna stacking

Currently we use a CombinableExponent of 2.0. This leads to double the comms range when doubling antenna count. It is the theoretical optimum when considering comms with the DSN. It is however a bit overpowered for vessel to vessel comms -- for these, a CombinableExponent of 1.5 would yield realistic optimum values when both vessels stack equally. Now we should probably balance for DSN communication as that is the usual case, but maybe we can find a more realistic/real world value here.

Antenna data collection

We collect data on google docs.
What we currently have:

Antenna/Probe	Diameter (m)	Gain (dB)	Eff. TX Power (W)	Gross TX Power (W)	Data Rates (bps)	Year Launched	Freq. Band
Mariner 2		20	3		8, 33	1962	L
Mariner 4	1.17	27.6	10		8, 33	1964	S
Mariner 5	1.17 * 0.54	23	10.5		8, 33	1967	S
Mariner 6	1.02		20		66-16.2K	1969	S
Mariner 8	?		20	90	66-16.2K	1971	S
Pioneer 10	2.74	36	8		16-2048	1972	S
Mariner 10	1.37		20		7.35K-117.6K	1973	X
Voyager	3.66	48	18	53-73?	160-115K	1977	X
Apollo VHF Omni		6	7.6		1.6K	1968	VHF

[leudaimon]

This looks very nice!
Any ideas on how relay capability would work here? Every antenna always works as relay, or do you think we add relay capability as a separate part or only to some antennas?

[MikeOnTea]

Relay is kind of a separate issue i think. We could require electronics/avionics/an extra part to support relay capability, which then maybe could even require 2 mounted antennas if we want that. A simple solution until something more complex is agreed upon/implemented might be phineas' proposal IIRC: Make early tech antennas not relay capable, while later tech antennas would be relay capable.

[leudaimon]

Seems a good strategy. I think adding a special part for relay capability + 2 antennas might be the best way to implement it later on.

[Bornholio]

Most of this might be good for RP0/1 but simplifying to Comnet fixes and thus basic Kerbalism support is good in RO. Physical values and hardware need to be set here. entry costs and alternate tech tree in RP.

Make a matching issue there or a pointer in the next release issue KSP-RO/RP-1#976

[NathanKell]

This sounds very good to me.

Oh, a note: "The X-band maser upgrade for the DSN only benefitted antennas actually using the x-band i guess, while in KSP every antenna benefits from every upgrade." <<< we should be able to get around this with partupgrades. A small plugin, when you buy the DSN upgrade to x-ray, it applies a hidden (i.e. in an orphan technode, but we can force-activate it) partupgrade that increases antenna range on all x-band-capable antennae.

One additional thought here. I would suggest that we do something like fully blocking control if the data rate is < x bits/sec, and partially locking control (i.e. allowing only SAS control, not WASD) if it's between x and y bits/sec, only allowing full control if > y bits/sec.

[MikeOnTea]

One additional thought here. I would suggest that we do something like fully blocking control if the data rate is < x bits/sec, and partially locking control (i.e. allowing only SAS control, not WASD) if it's between x and y bits/sec, only allowing full control if > y bits/sec.

I'm unsure about the out of connection handling for reasons stated before. Anyway, every antenna has a minimum data rate (this is used to calculate their maximum range), below which the connection breaks and control should become locked/limited depending on Commnet settings, i don't think kerbalism adds anything on top here.

[siimav]

I like NK's idea of locking control based on currently available data rate. It should be pretty easy to implement inside our current avionics code if we can just get the data rate value from Kerbalism. Mike, do you know whether this is internal to Kerbalism or is it also exposed through stock APIs?

[MikeOnTea]

Without a flight computer available, i think i would probably prefer control even without a connection.
That said, the data rate is internal to kerbalism, but we will have to touch some kerbalism code anyway to change formulas.

[DRVeyl]

Doubling an antenna's aperture increases gain by 3dB => increases distance for the same received signal level by sqrt(2). So the real right number for CombinableExponent is always <= 1.414.

[Edit: .... derp. Thanks, MikeOnTea, I managed to forget you're also paying an EC cost for tx power.]

This works properly for directional antennas. It is awkward to extend the range of omnidirectional antennas in this manner, since any array of omnidirecitonal antennas by definition has directionality. We assume, for the sake of sanity & gameplay QoL, that some arbitrary array of omni antennas always align properly to have gain in the direction we desire.

[MikeOnTea]

Doubling an antenna's aperture increases gain by 3dB => increases distance for the same received signal level by sqrt(2). So the real right number for CombinableExponent is always <= 1.414.

No it is not, because by doubling the antennas, you not only double the antenna area but also the transmission power (in KSP), which gains you another 3 dB, so the right number is <= 2.

[Bornholio]

Thats why outgoing gain for the DSN is higher than receiver gain. the receiver gain on probe side is sqrt(2)/mass since you can't power more reception

[DRVeyl]

I think it boils down to because stock invented their own link budget formula (geometric mean of two range values?!) you are forced into getting either reasonable ranges to the DSN, or reasonable ranges between vessels, but never both. This falls out directly from KSP ignoring that the power term only applies to the transmitter, never the receiver.

At least you can get correct ranges for any vessel communicating to any DSN upgrade level. The "range value" you'll use for the DSN is a complete fabrication, but their geometric mean formula at least makes it easy to define one antenna range value as a multiple of another's. An antenna system with a 6dB advantage ~= double the distance will use a range value of 4x instead of 2x, because of the square root in KSP's formula, but you'll get the right result to the DSN. Similarly, once you fix one DSN level, all other levels scale this same way.

Basically, we factor out the mistake of including the DSN's Tx power, but we can't fix this for vessel-vessel.

Not that RT does this correctly, either. So if part of the discussion is retaining RT as a required mod, or moving to Kerbalism, or just defaulting to stock... the current calculations are broken the same way in all cases, right?

[Bornholio]

but sqrt(A2+B2) is the correct range. you can't have two voyager class antenna talk between outer planets unless they have kilowatts of power and multiple tens of meters of antenna area

[MikeOnTea]

Yeah, the formula works fine, and you do even get reasonable vessel to vessel range for one antenna ('s transmitting power), the one you use for balancing vessel to vessel range. The problem is that antennas only have one combined power/sensitivity value, which leads to antennas with a higher transmit power getting more vessel to vessel range than they should, antennas with less transmit power will get less range than they should. For example, i currently use a 3.5 W antenna for balancing vessel to vessel range. That means that the vessel to vessel range of antennas with 20 W transmitters is 2.4 times as high as it should be. Could be fixed by replacing (parts of) commnet with something more realistic, but that would be more work. Maybe later. Another problematic topic is relaying etc...

[DRVeyl]

Ok, maybe I'm mathing badly. Been rewriting these a few times before posting. But I don't believe so.

@Bornholio: Using that form, solving for R gives the max distance between two antennas given both antenna gains, the transmitter's power, and a chosen minimum receive power to close the link. Substituting k for the parts we don't care about, R = k * sqrt(Pt * Gt * Gr / Prmin). If it were * Prmin then I'd accept Pt * Gt is a valid "range" replacement and R = k * the geometric mean of those range values. But it isn't. And it certainly isn't symmetrical between choice of T and R antennas. That formula is NOT what KSP implements.

@MikeOnTea: Ok. We are indeed saying the same thing, just very differently. 100% agree the combined power/gain value leads to the problem. I'm apparently arguing this awkwardly, by challenging the formula they created instead of a correct link budget analysis. Yes, I accept that you can normalize all the values with KSP's formula to make all antennas have the right DSN range, and one specific antenna also the right vessel-vessel range when communicating with itself. And then all other antennas will be wrong for vessel->vessel.

[MikeOnTea]

And then all other antennas will be wrong for vessel->vessel.

Yes, we know about that problem, but as most comms is vessel -> DSN that's not too bad, and solving it would take quite a bit of extra work, not sure if that's worth it. Could be attempted though.

[Bornholio]

Except Gain(T and R) is a non linear compound function, but once again its a G*G so other than doing an obscene amount of gymnastics Range^2 is still the simplest correct form for antenna pairs

[PhineasFreak]

From some limited testing that i did i found that the following DSN ranges give very good overall results for most of the antenna types (omnis and directionals):

• Level 1: 2.0E11 m
• Level 2: 8.0E13 m
• Level 3: 7.0E15 m

The first level, combined with a 800 km antenna, will give us a 400 Mm range (early lunar comms). The second level, combined with a 2 Gm antenna, will give us a 400 Gm range (interplanetary comms) and the third one, combined with a 50 Gm antenna, will give us a 19 Tm range (interstellar comms).

That last level is something that i am not completely sure it is realistic. Maybe 3 m Cassegrains are really what it takes for vessel-vessel communications over a 50 million meter range (still very short compared to the vessel-ground link and the average interplanetary distances) so who knows?

Edit: i also like the fact that CommNet supports telemetry-only connections (RT also supports it but for some reason this feature is absent from RO). No more using a generic guidance unit to transmit science/relay signals from other vessels!

[MikeOnTea]

So i've been distracted by other stuff again but continued to work a bit on this now, and have a basic prototype implementation which seems to be working. What i have in mind is the following:
We change the way antennas are set up in RO. Instead of giving stuff like range, data rate and power, we just give a (reference) gain, antenna type (dish or omni, giving this is optional, default is inferred from gain) and, for dishes, a reference frequency. Example from the Voyager HGA:

    MODULE
    {
	name = ModuleDataTransmitterRO
	referenceGain = 48
	referenceFrequency = 8415
    }

All the missing parameters are calculated from tech levels, which are unlockable in the tech tree, and from antenna configuration in the VAB. You can configure tx power, tech level (new tech levels are sometimes heavier so you can opt to stay on an older one), and data rate. Everything is within limits defined by your tech level. Example (early prototype, would give a useful range for release):

This means the electronics side of communications is totally handled by tech levels, including masses. The part configs merely contain the characteristics of the physical antennas, so we'd have to reduce their masses as well to remove electronics/amplifier masses.
This has the big advantage that we don't need tons of different antennas in the tree, each antenna's electronics can be upgraded/configured, and we'd just need some different shapes/gains. This also makes balancing the underlying commnet values easier, because we don't need to adjust every single antenna but just the calculation or the tech level values.

This setup would also make it easier to support a more realistic comms model by using/integrating RealAntennas.

What's currently not yet handled in my prototype is distance dependent bandwidth and comms for unloaded vessels (I assume Commnet doesn't support this without mods but i don't actually know), both of which could either be done by adding Kerbalism on top or using something like RealAntennas once that supports everything what's needed.

Thoughts? Have i missed anything? :)

[DRVeyl]

RealAntennas in current prototype form supports distance-dependent bandwidth, limited by bandwidth through the entire comms path.

Does "Comms for unloaded vessels" mean background transmission of science when unloaded? RA doesn't have a mechanic for that currently. If we're looking to Kerbalism for (lightweight?) background resource processing, that might be a path, either using their science transmission handling, or if we roll our own and use them for resource consumption.

CommNet will constantly re-determine the best antenna for an unloaded vessel for purposes of comms link. So will RA.

Should include some notes about how much mass the tech levels apply, both for the amplifier (TxPower) and the electronics (DataRate). We may also want to look at how we are scaling DataRate and ScienceData sizes. Especially if we want to create a need for background science transmission, and then implement it.

[MikeOnTea]

@raidernick so we have a basic implementation of this working (newComms branch). As said, this system needs new configs though, using realistic values (usually gain in dBmW for omni antennas, and diameter (or gain & frequency) for dishes. There's a mode specifying default values for tech level and transmit power for integrated antennas:

    MODULE
    {
		name = ModuleConfigurableAntenna
		referenceGain = 3.0
		txPowerDbmw = 36
		techLevel = 5
    }

This won't add any mass or cost to the part unless the default values are changed in the editor, which you currently still can do. The PAW in the editor might give a little too much info, not sure though how to best go about this:

Any thoughts?

[Capkirk123]

The creation, and abandonment(?) of newComms, and creation Real Antennas means this should be resolved.