[1.1.3] AntennaRange 1.11.4 - Enforce and Encourage Antenna Diversity

[BudgetHedgehog]

Can I just say, requiring LOS and everything makes it so much fun for me.. Right now, I'm organising a lander to rdv with the mothership around the Mun - the lander has a Comm 16 and can't reach Kerbin, the mothership (well, it's basically a fuel tank and a lab) has an 88-88 dish. It's actually quite fun to have to wait until the lab can be seen to send all my Science home.. Really made me smile when I saw the "transmitting vis Comm 88-88 on Mun Lab.."

Couple of things though - I've noticed sometimes, the text says '...directly back to Kerbin' and other times it doesn't. What affects this? Also, when the antennae is out of range and you try and transmit some data, it obviously won't work. However, it appears to delete the data entirely, not keep it. I was lucky as it was a gravity scan which can be repeated, but for the materials bay and goo, it might be frustrating.

[toadicus]

@ObsessedWithKSP: Those two issues are the primary reasons I sometimes think about completely rewriting the data transmitter.

To the first, Antennas get activated several different ways. For some of the ways, I have good control over the process and can inject messages. Other ways it's a lot tougher. If you can tell me when it didn't add the "directly back to Kerbin" to the message, I'll see if I can't hunt that down.

To the second, Squad's interface for IModuleDataTransmitters requires a CanTransmit() method, and will correctly not transmit if CanTransmit() returns false (the default Squad ModuleDataTransmitter will never return false). But, since they don't have any cases where that happens it seems like the rest of the experiment system doesn't do a great job of handling things when CanTransmit() returns false. Sometimes experiments are lost forever. Sometimes they appear to get stuck in the transmitter's queue, and will actually transmit if you manually start a transmission later. All of the actual transmitting is done in private methods that I can't change or call and shouldn't look at, so finding meaningful workarounds is tough.

For now, these are known limitations and my best advice is to be careful. Working around Squad's default behavior is tricky and rewriting the whole module would be very time consuming, and if I got something wrong I might really ruin your day.

[BudgetHedgehog]

I see, very interesting... I'll keep my eyes open for when that message doesn't appear and let you know.

And yeah, I've noticed that sometimes, if all antennae's are used up and I want to transmit something, it won't transmit until I manually transmit something else. It used to be put into a queue and automatically transmits once an antennae becomes free and occasionally still does.. but it'd be nice if Squad looked into the handling of false returns on CanTransmit(). Or at least not make the code private.. I would say they should definitely look into it, but I think they have more pressing issues to deal with right now.

I shall indeed be more careful but I think I shall echo gmbigg's suggestion to help inform people of when they could potentially lose unrepeatable Science:

I'm not sure how to code this, but maybe using the toolbar icon to track connections would be a good 'pretty lines' solution?

For example, let's add two new icons; a yellow variant and a red variant of the current green one.

The current green icon symbolizes that your craft is at or below the nominal range; transmissions are as efficient, or better than, Squad's defaults.

The yellow icon symbolizes that your craft isabove the nominal range; transmissions cost more power than normal, but are still possible.

The red icon symbolizes that your craft is out of range entirely; transmissions are not possible at the present time.

If the toolbar icon becomes visible in flight, all you'd have to do is look at the icon to determine your current connection.

tl;dr

Use the Toolbar icons to track how efficient your connection is.

By the way, thank you for the informative answers and helpful advice. It's appreciated

[Scotius]

Well, we can role-play it as data irrepairably corrupted during transmission. Though i't doesn't make much sense, considering that copy of the data should be still onboard transmitting ship. Is it possible to code a small loophole, which will make a "copy" of transmitted data, and keep it until transmission ends successfully? If transfer would fail we could get an option to repeat it.

[NJC2]

The AntennaRange restrictions on line of sight and probe control are independently optional. I have the same feelings as you do regarding probe control, and don't use that limitation in my own career save. The Toolbar button in the space center will pop up a configuration window and let you set those options.

Thanks, I figured that out on my own though. I left the probe LOS requirement on for my test just to see if it needed LOS back to the KSC or the planet itself.

I have intentionally not required a relay back to KSC specifically because, in my view, it's a rather baseless restriction. Back in the days of the first manned spaceflights, NASA was not dependent upon space-based infrastructure to talk to their pilots, but also had more than a 10 minute window to do so while they whizzed over Texas every hour or two. They used surface-based infrastructure to effect these early communications. The Apollo missions going all the way to the Moon also used surface-based infrastructure. IMO it's unreasonable to assume that the Kerbals do not have similar capacities even at the very start of a career save.

Were I to add such a limitation, I probably would actually not allow any artificial point on Kerbin to act as a relay. Instead, I'd require that an antenna be installed suitably close to KSC as "the KSC relay", and thus require the player to develop every single point of communications infrastructure -- even the "home base" antenna. But, IMO, that is not a fun or interesting requirement. Sending suborbital missions comprising an antenna on a parachute isn't challenging enough to be a fun task, and doesn't really contribute to the development of a meaningful skillset in terms of gameplay. If it's not well-founded in the "reality" of the game world, isn't fun, and isn't educational, it's just busywork for its own sake.

I welcome discussion on this topic. Maybe there is a right way to make building a short range communications network in the early game a good addition! I encourage you (and anyone else) to recommend and defend an implementation that meets at least two of the three criteria above: grounded in reality, fun, or educational.

I agree with most of what you've said. It is unreasonable to assume that there would only be one radio transmitter on Kerbin, and I remember there being some discussion about that on the RT2 forum. Early in my career mode I considered building an aircraft with the early dishes and flying them around and landing them at various spots on Kerbin to act as ground transmitters, but it just ended up being easier to launch a few satellites in orbit as a relay network.

What if you made Kerbin only have a limited communication range? Maybe just long enough to do missions to the Mun, so early in career mode users don't need to setup satellite relays until it's time to venture out past the Mun. At the least, perhaps put it in a config file we can edit to suit our taste?

[toadicus]

I agree with most of what you've said. It is unreasonable to assume that there would only be one radio transmitter on Kerbin, and I remember there being some discussion about that on the RT2 forum. Early in my career mode I considered building an aircraft with the early dishes and flying them around and landing them at various spots on Kerbin to act as ground transmitters, but it just ended up being easier to launch a few satellites in orbit as a relay network.

What if you made Kerbin only have a limited communication range? Maybe just long enough to do missions to the Mun, so early in career mode users don't need to setup satellite relays until it's time to venture out past the Mun. At the least, perhaps put it in a config file we can edit to suit our taste?

Well, in general that's already the case. Early tech levels limit you to near-Kerbin missions; the whip antennas can barely make it to KSO. The medium dish gets you out to Minmus, again barely. You don't get the "go anywhere, do anything" antenna until Electronics, which is pretty far down the chain.

OK folks, status update. Since gmbigg's recommendation has been so well-received, I've gone ahead and implemented it. I have it working and will release it soon.

I've also been working on pretty lines. They... work? That is, it does draw pretty lines, and about 90% of the time they start and stop in the right places, they're always the right color and they only sometimes crash the whole process. Anyway, I might push out an experimental build in the not-to-distant future.

Thanks for all the input, folks! Keep it up!

[BudgetHedgehog]

Excellent work! Looking forward to it, sir!

EDIT: have you looked into making more antennas? I've been thinking about getting the RT2 parts and re-purposing them for this mod because it seems a bit odd to have one dish that can transmit through the whole Kerbol system, but the dish below it can barely reach beyond Minmus. Like, have one that can reach a few km, 100km, KSO, the Mun, the edge of Kerbins SoI, then one that can reach like half the Kerbol system, and a final big one that can do the entire thing. I mean, it might be feature creep or just plain old stealing from RT2 (well, its idea and in my personal case, its parts too) so it's entirely up to you if you want to go that route and I can understand if you don't or can't. I think I might do it for myself though, I like challenges and I think 3 antennas is bit limiting.

Edited May 14, 2014 by ObsessedWithKSP

[phoenix_ca]

OK folks, status update. Since gmbigg's recommendation has been so well-received, I've gone ahead and implemented it. I have it working and will release it soon.

Every time I try to look at that post my eyes bleed from the colours.

@Obscessed: Perhaps they'd be more interesting as sidegrades, similar to the decision between engines where one chooses either high thrust and low ISP or high ISP and low thrust. Though it's a little hard to think of something you could change that wouldn't end-up simply creating a "this one is better, period" situation which is not desired (this mod's existence is to squish that).

Oh wait, no. You could balance that with mass and size. Yeeeeessss. So perhaps you could have an ultra-long range and very effective transmitter, but have the thing be big and heavy. That could work. Realistic? Not really. But more interesting.

If you do repurpose a few dishes I hope you'll share them.

Edited May 14, 2014 by phoenix_ca

[NJC2]

Well, in general that's already the case. Early tech levels limit you to near-Kerbin missions; the whip antennas can barely make it to KSO. The medium dish gets you out to Minmus, again barely. You don't get the "go anywhere, do anything" antenna until Electronics, which is pretty far down the chain.

My idea of having a limited range for Kerbin is so that a ship out past this distance can't transmit back to Kerbin without longer range relay satellites in orbit to receive and relay it to the ground.

[Tortoise]

Very nice mod, and nice developer.

[toadicus]

Excellent work! Looking forward to it, sir!

EDIT: have you looked into making more antennas? I've been thinking about getting the RT2 parts and re-purposing them for this mod because it seems a bit odd to have one dish that can transmit through the whole Kerbol system, but the dish below it can barely reach beyond Minmus. Like, have one that can reach a few km, 100km, KSO, the Mun, the edge of Kerbins SoI, then one that can reach like half the Kerbol system, and a final big one that can do the entire thing. I mean, it might be feature creep or just plain old stealing from RT2 (well, its idea and in my personal case, its parts too) so it's entirely up to you if you want to go that route and I can understand if you don't or can't. I think I might do it for myself though, I like challenges and I think 3 antennas is bit limiting.

Every time I try to look at that post my eyes bleed from the colours.

@Obscessed: Perhaps they'd be more interesting as sidegrades, similar to the decision between engines where one chooses either high thrust and low ISP or high ISP and low thrust. Though it's a little hard to think of something you could change that wouldn't end-up simply creating a "this one is better, period" situation which is not desired (this mod's existence is to squish that).

Oh wait, no. You could balance that with mass and size. Yeeeeessss. So perhaps you could have an ultra-long range and very effective transmitter, but have the thing be big and heavy. That could work. Realistic? Not really. But more interesting.

If you do repurpose a few dishes I hope you'll share them.

I have considered adding a few antennae. I'm not a modeler or an animator and have no time to become one, but I've considered asking carmics (the AIES developer) if he'd let me distribute a few parts with MM patches to make them AR relays. But, I have a little trouble deciding what to do with it, and I'd need to do some research into different space-based communicators. In real life we can still talk to the Voyager probes using nothing but their radio and a ground station... and those have tech from what would probably be the "middle" of Earth's progression. Since then we've primarily been increasing bandwidth (and with bandwidth, security and quality) as far as I know... which is not very far, because radio is not actually my thing.

All that to say, such a notion is on my radar, but I don't have a good bearing on how to proceed with it, so for right now it's not at the top of the stack. I very much encourage you to share MM patches for any antennas that you do repurpose. I know MeCripp's already got some; you might all work together to find a compelling solution.

My idea of having a limited range for Kerbin is so that a ship out past this distance can't transmit back to Kerbin without longer range relay satellites in orbit to receive and relay it to the ground.

To make that work I'd need to implement additive ranges. And even then that would only matter until you got the big dish, which would add up to a very large number with whatever I set Kerbin's default to. I do know what you're saying, I'm just not sure if there's a "right way" to implement it, and I don't think it feels very realistic. See above about Earth's comms to the Voyager probes.

Very nice mod, and nice developer.

Thanks! You guys are nice, too.

[rkman]

In real life we can still talk to the Voyager probes using nothing but their radio and a ground station...

The ground stations have high output power (several kiloWatt) and very large dish antennas with a gain in the range 100,000 or so. The dish amplifies the output signal and also the incoming signal. In spite of all that, the data rate of the incoming signal from Voyager is a few 100 bits/s. See deep space network live: http://eyes.nasa.gov/dsn/dsn.html

My idea of having a limited range for Kerbin is so that a ship out past this distance can't transmit back to Kerbin without longer range relay satellites in orbit to receive and relay it to the ground.

To make that work I'd need to implement additive ranges.

As you noted, in reality there is no need for relay satellites for deep space communication, ground stations take care of that.

In practice the max range at which a probe can send data back home depends not on the ground stations but on transmitter power of the probe and the gain of its antenna. Whatever kind of radio power one could get in space on a relay satellite, you can get many times that power for much lower cost on the surface of the home planet.

Antenna range is not additive but multiplicative (taking square root law into account): if in an existing connection one antenna is replaced by an antenna that has 4 times the gain, the maximum range for that connection is doubled. It works the same way with transmitter output power.

[toadicus]

The ground stations have high output power (several kiloWatt) and very large dish antennas with a gain in the range 100,000 or so. The dish amplifies the output signal and also the incoming signal. In spite of all that, the data rate of the incoming signal from Voyager is a few 100 bits/s. See deep space network live: http://eyes.nasa.gov/dsn/dsn.html

As you noted, in reality there is no need for relay satellites for deep space communication, ground stations take care of that.

In practice the max range at which a probe can send data back home depends not on the ground stations but on transmitter power of the probe and the gain of its antenna. Whatever kind of radio power one could get in space on a relay satellite, you can get many times that power for much lower cost on the surface of the home planet.

Antenna range is not additive but multiplicative (taking square root law into account): if in an existing connection one antenna is replaced by an antenna that has 4 times the gain, the maximum range for that connection is doubled. It works the same way with transmitter output power.

Do you know how the 100s baud bandwidth from the Voyager probes compares to their original throughput? I know 100 baud sounds really slow today, but in 1977 that might not have been so bad. That said, I am aware that their output is really, really low and that the DSN is leveraging much newer tech than 1977 to boost and process the signals from the Voyager probes on its way in.

AntennaRange does respect the square root law as distance changes (using D² α P/R as the nominal relationship), but does not model antenna gain directly. Currently the only available behavior increases bandwidth along the square-root law as antennas come "inside" their nominal range, and increases the power use as they go "outside" their nominal range. The next update will allow the power draw to be fixed, reducing bandwidth instead, as in Real Life.

I looked in to modeling gain early in development and concluded that I didn't know enough about radio to do that. Now that the plugin actually works, maybe I could revisit it. That could help me make diversity in antennas more meaningful, too.

[rkman]

Do you know how the 100s baud bandwidth from the Voyager probes compares to their original throughput? I know 100 baud sounds really slow today, but in 1977 that might not have been so bad.

NASA says 7.2 kbit/s, google says it was 115k/s when the probe was near Jupiter, by the time it was near Saturn it had dropped to 44.8k/s. Not sure how that figures, but those are respectable data rates anyway. http://voyager.jpl.nasa.gov/spacecraft/instruments_hga.html http://www.honeysucklecreek.net/dss44/voyager.html

In first approximation data rate is directly related to radio channel bandwidth (assuming fixed compression, error correction etc), as long as background noise is a lot weaker than the signal. New encoding and error correction techniques probably have increased the effective data rate, not by a huge amount but still significant.

Main reason for the slow data rate of Voyager is the weak signal caused by the insane distance: 15 billion km (your "ping" time would be 1.2 days). Square root law is a *****. The signal is so weak it is almost lost in the background noise so a lot of error correction is needed, greatly reducing effective data rate.

AntennaRange does respect the square root law as distance changes (using D² α P/R as the nominal relationship), but does not model antenna gain directly. Currently the only available behavior increases bandwidth along the square-root law as antennas come "inside" their nominal range, and increases the power use as they go "outside" their nominal range. The next update will allow the power draw to be fixed, reducing bandwidth instead, as in Real Life.

Which goes a long way toward doing it right, but in reality data rate does not scale with the cube of the distance all the way from nearby to far away. Nearby the data rate would be constant (e.g. wifi throughput is constant while within range), at long range the data rate drops with distance roughly following square root law.

The only thing that directly scales with (the inverse of) the cube of the distance is the strength of the signal, meaning that background noise becomes an ever greater factor which reduces the data rate. The range at which data rate starts to drop would typically be quite a bit shorter than what you now have as "nominal range".

Looking at the Voyager numbers, the data rate when near Saturn was about half what it was when at about half the distance (near Jupiter) - it does not follow square root law, but it does drop off so it is outside of nominal range. I would not be surprised if at shorter distance than Jupiter the data rate was pretty much the same as it was at Jupiter.

I looked in to modeling gain early in development and concluded that I didn't know enough about radio to do that. Now that the plugin actually works, maybe I could revisit it. That could help me make diversity in antennas more meaningful, too.

In a given comms link the effective max range is derived from /dictated by the gain of both antennas (multiplied, taking sqrt into account) and the output power of the weakest transmitter. That is assuming identical receiver sensitivity, so that we can conveniently ignore that factor.

The gain of a dish antenna scales with the surface area: twice the diameter = 4 times the surface area = 4 times the gain = 2 times the effective max range for a given comms link. Just as crude examples: a small dish could be 20cm diameter and have a gain factor 100, at the high end could be a 2m dish with a gain of 10.000 (10 times the diameter, 10² =100 times the surface area = 100 times the gain).

In its simplest form mass (volume) scales with the cube of the size increase (diameter), but in practice it is not worth it to save a large fraction of mass if the antenna is small (low mass) to begin with, while that is worth it if the antenna is large. So in practice antenna mass does not scale with the cube of the size increase, though the scale factor is larger than just diameter squared.

The range of transmitter output power is smaller, from a few Watts to several 10's of Watts. Mass and size of the transmitter only really matter if the dish is small. For transmitters the main consideration is electric power draw, dictated by transmitter output power.

I think it would be nice if eventually (max) transmitter power would be a tweakable which would affect range and electric power draw, and have some small effect on mass (which would only really matter for small dishes), part size (and antenna gain) would not be affected.

Edited May 16, 2014 by rkman

[toadicus]

AntennaRange has been updated to version 1.3! This version adds the much-requested colorful toolbar button, and an option to fix power consumption at long range, degrading data instead. I'm also working with rkman to come to a better understanding of antennas, and am considering developing a slightly more realistic antenna degradation model for that option in future releases. Thanks for your patience, rkman!

CHANGELOG:

v.1.3 [2014-05-30]
* Added otherwise-nonfunctional Toolbar button in flight that will change colors to indicate current connection status (hint: red is bad)
* New option allows power costs to be fixed even at long range, reducing data rate instead.

[BudgetHedgehog]

Yaaaaaay, updates! And just as I'm setting out for Duna Thankfully, I have the 88 on like, every craft so I should be safe. Thanks man!

[Mecripp]

Nice will give it a try.

[Parkaboy]

This sounds like a great alternative for RemoteTech. I'm hoping the devs will someday implement some of these ideas on the stock parts!

[NJC2]

@NJC2 If you want to convert your career from RT2 to AntennaRange goto you RT2 folder and zipup or move out the CFG files and the plugin folder goto this post http://forum.kerbalspaceprogram.com/threads/56440-0-23-5-AntennaRange-1-2-Enforce-and-Encourage-Antenna-Diversity?p=1144076&viewfull=1#post1144076 download the one that as % by it put it anywhere in KSP/GameData and have fun.

I haven't been able played KSP in a while, but I'm now ready to get back to my career game. I only have a couple of probes out there with RT2 dishes on them, and once I recover or get done with them, I will completely remove RT2. I backed up my save directory and here's what I've done:

I removed everything except the Parts directory from the RT2 directory. When I load my game, all my saved craft are greyed out saying "Contains locked or invalid parts." I'm using your .cfg file, and the first thing I noticed is the RT2 antennas and dishes are no longer in the VAB. Looking at your config, it is missing the TechRequired field, so I added that in myself. The dishes now show up in the VAB, but my craft are still locked. The debug console doesn't show any reason.

I noticed that KSP auto-created a directory called saves_backup that automatically backed up my profile, and has a log file in it. According to the log it seems RT2 inserts modules into all of the antennas and probe cores and the launch clamps called "ModuleRTAntenna" and "ModuleSPUPassive." I restored RT2, deleted the .cfg files that modify the parts, loaded the game, quit and it auto-removed those modules from my craft, but I still can't load any of my saved craft. The debug console shows no reason and the ksp.log file doesn't say why either.

I copied one of the craft files that I can't load to a sandbox save and loaded it. It's all stock parts, I see nothing on it that would cause it to not let me load it in my career save.

Am I doing things the hard way? Is there an easier way to remove RT2 and install this mod so I can load my saved craft?

Never mind. I updated all of my other mods at the same time, and it turned out to be Procedural Fairings causing the problem with not being able to load saved craft. I reverted to the old version of PF while I sorted outt RT2 and this mod. Now I have to figure out what's up with PF.

Edited June 6, 2014 by NJC2

[Tortoise]

This mod is a great, and has a great developer. I've used this mod for quite some time. Sort of the 'slightly easier' alternative to remotetech.

[toadicus]

This sounds like a great alternative for RemoteTech. I'm hoping the devs will someday implement some of these ideas on the stock parts!

This mod is a great, and has a great developer. I've used this mod for quite some time. Sort of the 'slightly easier' alternative to remotetech.

Glad you're enjoying it! If I can ever stop working, moving, and visiting family, I've got some pretty cool things in the works for future development, I think. All still optional, too!

[Javster]

Could be interesting for career mode!

It looks like a very well thought-out mod, which means I will probably install it (Checking for any active flights first)

[Probus]

Toad,

Has anyone updated your config file to include antennas from different part packs?

Just found it: https://www.dropbox.com/s/xv2153q8ybfl1s6/AntennaRange2.cfg

Edited July 8, 2014 by Probus
Found it...

[NJC2]

I don't think LOS is working right. I have a science station in orbit around the Mun with a manned rover that goes down to the surface to collect science and return to the station. The rover only has a communitron 16 on it, and thought I would need to wait for the science station to pass overhead to relay transmissions back to Kerbin. I happened to land near my first unmanned probe I sent to the Mun. I waited for the station to pass overhead to transmit a crew report, and when I did, it relayed through the old probe instead of the station. They were both in the Northwest Crater. While there wasn't clear LOS between the two, it was close enough that I figured the mod couldn't quite tell. Now the rover has moved on and is over 100km away and there definitely is no LOS between the two, yet it continues to relay through this probe.

The view from above:

The view rotated to line the two craft up to show there is no way they have LOS:

[toadicus]

The LOS code has a 5% "grace" figure in it to make satellite constellations easier with stock tools. That is, line of sight will be granted when the distance from the center of a body to the line ended by both relays is greater than 95% of the radius of the body. On Mun, that should mean that two vehicles at "zero" level on the surface can contact each other from about 127 km apart, or more if the antennas are raised above the surface. Also, terrain is not considered whatsoever: if one antenna is up on the highlands a few kilometers above "zero" level, you'll get even more distance out of the grace number. Considering terrain is complicated and expensive from a calculations standpoint, and pretty much completely useless for orbiting vessels, so at this point I'm not planning to add such a function.

I will make the grace figure configurable in config.xml in the next release, though, so you can make things tougher on yourself.