Search the Community

Kerbal Interplanetary Probes Presents: KIPSAT DSN Antennas Description This is a work-in-progress mod for Kerbal Space Program (KSP) that aims to add large Deep Space Network (DSN) satellite dishes to enhance long-range communication capabilities. Features - Provides three DSN satellite dishes of increasing size, designed to match the default KSP DSN network antenna power settings. - It is designed to work with the extra ground stations to OFF, otherwise there is no real point :). - Requires a significant budget and attention to launchpad upgrades, introducing a new level of challenge to the game. About - This is my first attempt at creating a mod, so bear with me as I learn the ropes. - The models and textures are a work in progress and may not meet professional standards yet, but they provide the basic functionality needed for the mod to work. Companion Add-ons - It is highly recommended, if not necessary, to have the HyperEdit mod installed to teleport the dishes to their locations. - These dished are massive, so you might want to consider getting the Hangar Extended mod. - I also play with Kerbal Construction Time, effectively halting your rocket production for "months" while you undergo these DSN antenna construction projects. Installation 1. Download the mod ZIP file from the GitHub releases page. 2. Unzip the downloaded file. 3. Place the mod folder in the GameData directory of your Kerbal Space Program installation. Known Issues - None for now Contributing - Any wishes to contribute/help are welcome Wishlist While this mod is a work in progress, there are several features I'd like to implement in the future to enhance the overall experience: 1. Improved Textures and Models: I aim to refine the visual aspects of the satellite dishes, starting with high-quality textures and eventually exploring new 3D models to further enhance their appearance. 2. Contract Pack for Added Value: I'm considering the development of a contract pack that integrates with the mod, providing players with additional missions and objectives centered around the DSN satellite dishes. 3. Integration with Other Mods: I plan to explore compatibility with popular mods like RemoteTech/OPM, enabling a seamless experience for players who wish to incorporate advanced communication systems into their gameplay. 4. Interior Models: While not currently implemented, I aspire to eventually introduce interior models for the satellite dishes, adding an extra layer of immersion for players who enjoy detailed spacecraft interiors. 5. Kerbal Control Requirements: In the future, I aim to introduce a system where Kerbals must be present to provide manual controls, similar to the functionality offered by the RemoteTech mod. Please note that these features are part of a wishlist and may be subject to development feasibility and future updates. License This project is licensed under the MIT License. See the LICENSE file for details. --- Final Note: This project is a work in progress and may be subject to significant updates and changes. I also don't know all the technical details (yet). I made this mod for myself, thought that other could find it cool too. Thanks for understanding :).

Current Release (GitHub) This mod adds long-range antennas using stock assets to facilitate communications networks for planet packs larger than the stock solar system. This allows the player to extend, rather than replace, the stock antenna progression, making long-range relays possible without trivializing inner-system communications. The RA-500 weighs 1.3 tons and has range rating of 500 Gm. It has a 1.25m bottom node and fits in a 5m fairing (i.e. it's a 2x rescaled RA-15.) The RA-2500 weighs 2.6 tons and has a range rating of 2.5 Tm. It has a 2.5m bottom node and fits in a 7.5m fairing (i.e. it's a 2x rescaled RA-100.) The RA-12500 weighs 5.2 tons and has a range rating of 12.5 Tm. It has a 2.5m bottom node and fits in a 10m fairing (i.e. its a 4x rescaled RA-15.) As an incidental benefit, these antennas offer progressively better transmission performance than the stock relay antennas, particularly in terms of ElectricCharge consumed per Mit transmitted. The enormous size of these antennas demands an unconventional approach to deployment. Possibilities include: Off-world manufacturing via mods such as Extraplanetary Launchpads, OSE Workshop, or Ground Construction. Oversized launch vehicles such as AB Launchers (5m), DIRECT (5m & 7.5m), or SpaceY Lifters/SpaceY Expanded (5m, 7.5m, & 10m). To facilitate the simultaneous launch of multiple satellites, this mod adds stock fairings (including interstage trusses) resized to 5m, 7.5m, and 10m diameters. In case none of the above appeal to you, compact deployable versions of all three antennas are provided (via rescaling of the Communotron 88-88 to 0.625m, 0.9375m, and 1.25m.) As the new antennas are substantially more powerful than the stock Deep Space Network, three additional levels of the Tracking Station are provided via the Custom Barn Kit (not included.) These allow the player to choose between launching local relays or simply boosting the DSN. Level 4 of the Tracking Station costs 2,111,000 Funds and boosts the DSN's range rating to 1.25 Tm. Level 5 of the Tracking Station costs 7,916,000 Funds and boosts the DSN's range rating to 6.25 Tm. Level 6 of the Tracking Station costs 29,685,000 Funds and boosts the DSN's range rating to 31.25 Tm. This presents alternatives at several performance points to the excellent JX2 Large Deployable Antenna. These parts are generally cheaper and less massive than the JX2 for their range with the trade-off of being much bulkier and far less visually distinctive. As a bonus, I've included a half-scale version of the RA-2 antenna that has the stats of the HG-5. This alternate handle-free form factor for the HG-5 fits better on compact probe assemblies as small as 0.3125m. Also included for launching miniature relays is a 0.625m fairing; I recommend RLA Stockalike for 0.625m launch vehicles. Installation and Requirements To install, copy the files to your GameData folder. This mod requires ModuleManager (not included.) Custom Barn Kit is required for the extended tracking station progression, but otherwise optional. License CC BY-NC-SA

INTRODUCTION: The stock communications system in 1.2 is like a cross between RemoteTech and AntennaRange. It has (optional) control issues similar to RT but the network itself links up pretty much like AR. If you've never played with either of those mods, then hopefully this tutorial will demystify the whole communications network thing. It's really not that complicated. If you're used to playing with AR, then you'll find stock pretty much the same except for the new antennae and the different performances of the old ones. If you're used to playing with RT, then you'll probably welcome the vast reduction (to nearly zero) of the micromanagement, but might have to learn new habits depending on how you did RT. GENERAL STOCK NETWORK FACTOIDS: Stuff to understand before you get started. 1. No Perfect Networks There is no such thing as a network that allows 100% uninterrupted coverage to every square inch of every planetary surface. So don't lose any sleep over that. No matter what you do, something will always get in the way periodically. The best you can do is make something that works everywhere most of the time, and then time your activities to happen when you've got a link, waiting the minutes to hours when you sometimes don't. 2. You Don't Need Perfection You really only need the network in 2 situations: 1) when you're trying to control a ship/probe without a Kerbal pilot aboard (assuming you selected that option); and 2) when you're transmitting science. The rest of the time, the network doesn't matter. Thus, you only need to design the network to handle these situations. This means you need a network to allow landing on the far side of Mun/Minmus, to cover the mid-course tweaks of interplanetary trips, and to land on other planets. Once you're on the ground, you can wait a bit if necessary to transmit your science and take off again. That's all you really need, so don't sweat trying to do more unless you just want to. Also keep in mind the duration of the mission. Are you ever going back to this planet again, or is your main focus elsewhere and you're just here for some quick science? There's no point in getting too elaborate for a 1-and-done mission. 3. Getting Acceptable Coverage To do this, you have to minimize the impact of the 2 things that break links: 1) celestial bodies in the way; and 2) distance in excess of antenna range. You can pretty much eliminate the 1st problem with the network design described below. The distance thing is another matter. Right now, the biggest stock relay antennae barely work between Kerbin and Jool when they're on the same side of the sun, and only hit Eeloo when it's at or inside Jool's orbit. You can reduce this problem somewhat by using intermediate relays at Eve, Duna and/or Dres, although certain planetary alignments over time will still be problematic. And that's just with the stock solar system. If you use something like the Outer Planets Mod, where the closest new planet is twice as far from the sun as Jool (as in, you get just as bad a link from Jool to Sarnus as from Kerbin to Jool and the distances between the rest get worse from there on out,, the stock communications system just flat won't work much if at all (EDIT without jacking up the DSN range a LOT). So for that you'll need a mod. Surely somebody will make a bigger mod relay antenna to work with OPM, or you can use a ModuleManager patch to change the stats of the stock antennae for longer range. Thus, this tutorial will just worry about the stock solar system, where distance isn't THAT much of a problem (except for Eeloo) most of the time. Then it's just a matter of avoiding blocking by celestial bodies, which is relatively easy. 4. Forget Geostationary Networks Kerbin now has a number of communications centers scattered all around its surface and your network can link back to any one of them, not just KSC. IOW, as in AR, your distant ships essentially talk to Kerbin as a whole, not just 1 spot on its surface. This also means that Kerbin by itself covers the near sides of both Mun and Minmus, plus anything within Kerbin's SOI not blocked by Mun or Minmus. The only reason anybody ever built a geostationary network before was because in RT, you could only talk to KSC itself, so you needed the geostationary constellation to handle the 50% of the time when KSC was facing away from your ship, which happened even in LKO. Because in the stock system you can talk to Kerbin regardless of which way KSC is facing, you don't need a geostationary network. You can build one if you want, but it's really just a waste of time and money. And FWIW, you can't build a geostationary network at most other planets and moons anyway because the required altitude is beyond their SOIs. So just ignore geostationary networks as the archaic "back in the day" things they are and move on. 5. Redundancy is Good It's a good idea to provide multiple possible link paths between any 2 points. That way, if one path is blocked, hopefully another will be open. It's easy to go overboard with this, but it can be done with a fairly minimalist approach. This tutorial will show how to do that. AVOIDING BLOCKING BY CELESTIAL BODIES: There are 3 types of blocking by celestial bodies. 1. Blocking by the Planet/Moon You're At This happens whether you're in orbit or landed. This is the most troublesome type of blocking because it will happen the most often (like 30-50% of the time), and you can't do much about it without going to a lot of trouble and expense. Often, this is more trouble than it's worth because, as mentioned above, it's actually pretty easy to make a simple network that provides coverage when you actually need it. Normally, there will be some time (minutes to hours, perhaps a few days even at very tiny moonlets) when you have to wait for a satellite to pass over before you have a link, but the wait shouldn't ever be long so long as to cause a real problem. Just warp through it. Going beyond a minimalist approach doesn't really gain you anything that's actually useful in real game terms, although you might want to for purely role-playing purposes. 2. Blocking by an Intervening Planet/Moon: Statistically, this happens quite infrequently. It's also the easiest type of blocking to overcome, to the point where it'll never be a factor. Just put your relays in highly eccentric polar orbits so they talk across interplanetary distances well above or below Kerbin's ecliptic and you're golden. That's the method recommended here (detailed below). 3. Blocking by the Sun: This is only a problem on interplanetary missions, but it is certain to happen during them at some point, usually between arrival and waiting for the return window. In purely game terms (ignoring the role-playing aspect of needing to phone home every day), this is only a problem if you're still wandering around in the system doing science when the sun gets in the way. And that's usually only an issue at Jool because the system is so large it takes months to explore it all. Problem is, the sun is too big to talk over/under with your highly elliptical relays, so you have to talk around it. You do that by creating relays at all planets except Moho. Eve is especially important because it's far enough from the sun usually to have an LOS from Kerbin to Eve to wherever, and it move faster than Kerbin so will provide these links more often. When Kerbin is opposite the sun from wherever your ship is, Eve is often placed to bounce a signal around the sun. This is especially important for communications with Jool . Anyway, as mentioned above, you need redundancy and multiple possible paths, and Eve is often a key step in that alternate path. Moho, not so much because it's so close to the sun that most of the time it can't provide a bank shot around it. Also, it's way expensive to get to Moho compared to Eve. NETWORK DESIGN: OK, so that's the underlying principles and realistic objectives. Now, how do you accomplish all this? Finally, we get into the nuts and bolts of the network. 1. Relay System: The basic unit of the system is a set of 2 long-range relay satellites in highly elliptical polar orbits around the central planet. One goes up, the other goes down, and they're 180^ out of phase with each other, so that when one of them is at Pe, the other is at Ap. Because their orbits are highly elliptical (like 2000m/s worth above low orbit), the relay satellites will spend the bulk of their time high enough above or below the ecliptic to be able to talk over or under any intervening body except the sun. Putting a pair like this at each planet (except Moho) will then provide a path around the sun to any other planet ALMOST all the time. These relays also cover nearly all the surface of the central planet most of the time. One will get most of the northern hemisphere, the other most of the southern. There will be a blind spot centered on the equator on the opposite side from where the satellites are (both orbit in the same direction so will both be on the same side of the polar axis most of the time), but central planets all rotate fast enough that a ship on the ground in the blind area will rotate into coverage soon enough. Every week or 2, there will be a few minutes when both satellites are over the same pole, one at Ap and the other at Pe, so that the whole opposite hemisphere is blind, but this won't last long because the one at Pe will be moving so fast, so don't sweat it. For most of the time, these relays will also cover much of any moons of the central planet. There will be a gap on the far side, however, wider than on the central planet, which you fill with other component of the network, the moonsat. The relay satellites should always have the biggest relay antennae you have. This is so they can provide alternate paths around the sun in as many ways as possible. As you unlock the bigger antennae, you might have to replace some of your early relays. Kerbin should definitely always have the biggest available. 2. Moonsats For each moon of the central planet, you'll need something in equatorial orbit. The purpose of a moonsat is to cover the gap on the far side of the moon left by the relay sats. The "moonsat" MAY be a dedicated commsat if you're doing something long-term on the far side, but for a 1-and-done mission, you can do things Apollo-style so that the ship left in orbit serves fills this role. The moonsat should orbit at a conveniently low orbit so that it passes over a ship landed on the far side often enough that blackouts aren't a bother, and for long enough that it can land while still in contact. But it also must be high enough that the relays can see over/under the moon to it most of the time. If being high enough for this makes the moonsat's orbital period (and thus blackouts for farside landers) longer than desired, you can use multiple moonsats spaced more or less evenly around the moon's equator. But most of the time you'll only need 1 for gameplay purposes. Munsats need an antenna big enough to reach the local relays at their Aps. 3. Modular System So, putting this together, for each planet, you have 2 relays satellites in highly elliptical polar orbits and for each moon you care about, you have (at least) 1 satellite in a relatively low equatorial orbit. It looks like this: CREATING THE NETWORK Setting up this sort of network is pretty simple. At Kerbin, you can launch each relay on a separate rocket but everywhere else, it's best to send them both out on the same carrier vehicle. If you want multiple moonsats somewhere, they should always go out on 1 ship. Using 1 ship to carry multiple satellites facilitates spacing them out evenly. Thus, this description will always use single ships even at Kerbin. The mechanics go like this: 1. The Kerbin Relays These have to be set up first because they're the essential link from other planets and the farside of Mun/Minus. Design a probe with the biggest relay antenna you have, enough juice to run it, and about 2000m/s dV in its own little tank. Save this as a subassembly. Then start the carrier vehicle. Make it so you can mount 2 of these relay probes under the same fairing and then add the subassembly probes. Launch into a polar orbit of about 150km. This will be the Pe altitude of the relays, high enough to avoid stuff in 80-100km parking orbits but low enough to whip by Pe in no time. Detach one of the probes and switch to it. Plot a maneuver node for when the probe is directly over one of Kerbin's poles, burning all or most of the probe's fuel to reach an Ap out near the edge of Kerbin's SOI, then do this burn. You should have a few hundred m/s left in the tank to tweak the orbit later if needed and to deorbit the relay when it needs replacing. Then you wait about a week for the 1st relay to reach its Ap. When it's starting to get close, switch back tot the carrier vehicle, detach the 2nd relay, and switch to it. Plot a similar burn for it, but located above the other pole so this relay will go in the opposite direction as the 1st. Adjust the number of orbits into the future when you actually do this burn as needed until it's as close as possible to when the 1st relay reaches Ap. It doesn't have to be exact, just close enough. Do this burn, then switch back to the carrier vehicle and de-orbit it. NOTE: It could be that the 1st relay won't have its own link back to Kerbin's surface when it's time for it to burn. This could require putting a "0th" relay in equatorial orbit first, if nothing you already have in Kerbin orbit can do this. 2. Munsats and Minmussats Until you have the Kerbin relays up, you'll need at least 2, unevenly spaced (or 3 evenly spaced) commsats in Munar orbit to talk to the farside. Minmus isn't tidelocked but rotates slowly, and orbital velocity is pretty slow, too, so you might want the same there to avoid long blackouts. By unevenly spaced, I mean 120^ apart, like a formation of 3 with a missing satellite. Having 2 spaced like this will give farside coverage 2/3 of the time---3 will give full-time coverage. But remember, you'll be putting relays up, at which point you only need 1 moonsat to give farside coverage 50% of the time, so don't spend money you don't need to. The basic technique is the same whether you drop 2 or 3 moonsats off the same carrier vehicle. The basic method for spacing multiple moonsats is as follows: First, decide on the altitude you want the moonsat to be so it can usually talk over/under the moon to one of the relays. Use math to determine what the orbital period is for a circular orbit at that altitude at that moon. Send the carrier vehicle to the moon and capture into an elliptical orbit with this altitude for the Pe. As for its Ap, again use the math to determine what altitude would give the carrier vehicle in an elliptical orbit an orbital period 1.33 (or some whole multiple of that number) times as long as for the circular orbit at Pe altitude. The idea is, every time the carrier vehicle reaches Pe, it will be 1/3 of a circular orbit behind any moonsat previously released. The carrier vehicle thus makes 1 elliptical orbit for every moonsat carried. Each time it reaches Ap, it releases a probe. You switch to the probe and plot a burn to circularize its orbit at its Pe. Tweak the probe's orbit as needed with RCS to fine-tune its orbital period to be within 1 second on the calculated circular period. Once all the moonsats are in position, de-orbit the carrier vehicle. NOTE: Generally, you'll need a mod like KER or MJ that will give you a display of your orbital period. As mentioned, using a tiny amount of RCS prograde or retrograde as required will allow for very fine control of your orbital period. 3. Expanding the Network Repeat the above process with the relays for every other planet. Send at least 1 moonsat to every moon you expect to visit regularly, but those can wait until you actually send out such expeditions. The relays are the important thing, to be able to talk around the sun and to give a better connection out to Jool, and should be set up as soon as you have the antenna to make them worthwhile. NOTE: Relays require a lot of EC/sec, but only when you're actually using them. Solar power is practically useless at Jool for any purpose other than slowly recharging batteries between widely separated uses. RTGs aren't any more powerful and are quite expensive, while fuel cells run out of fuel. Thus, relays for Jool, Eeloo, and even Dres should have rather huge battery capacity to cover their periods of infrequent activity. It might also be a good idea to have a fuel cell for emergency instances of prolonged or frequent use, remembering to turn them off as soon as possible afterwards.

I landed a rover on Duna with a platform that has a Communotron 88-88 attached. This platform can reach Kerbin just fine, however the rover (which has two Communotron 16-S antenna) can't make contact to Kerbin through this platform after I decoupled it from the platform. Is this intended behavior, or do I have a more serious problem on my hands? Here's a screenshot to show the proximity. Any ideas or is my rover dead on arrival here?

Update 20Oct2018: the original post below was a basic complaint that the developers blogs were so rare that the comms channel was basically useless. Just a few weeks ago our friends at squad announced they were killing the weekly updates and that "other" channels will be used - including the very nearly dead defunct devblog. Why? Let us peacefully discuss... --------------------- Back in mid-February @SQUAD indicated... /Snip "We’re planning to continue which the Developer Articles to let developers talk about their work and experiences in greater detail and to give you more insight about some of the challenges we face when developing KSP. These won’t be scheduled as regular forum posts, as we’ll be having multiple authors sharing info whenever they are willing and able. Nevertheless we will let you know when these come out, so you don’t miss any and keep your eyes peeled on the DevBlogs section of the forum for when they do." /End Snip And we have had only two devblog entries ( @RoverDude before and @TriggerAu after the above statement) and that's it. Is the Devblog dead? Or is it just not a priority for anyone? They have a fair sized team. I find it hard to believe not a single person on the team has the time to highlight and share their workflow or experiences through a devblog entry. I gather from the above snipped quote that: 1) They are not scheduled (Fair enough) 2) Info will be shared when devs are willing and able (Aha!) 3) @Squad will notify us of an any entries in the Blog (Again, fair enough) SO --> As it stands, our Dev team is not willing and/or is not able to share anything for what is approaching the past 4 months??? Thoughts? Discussion? (Perhaps the office intern can write something... ) EDIT: It seems that in recent weeks/months there has been a resurgence in @SQUAD's ability to produce viable Dev-Blog posts. Well Done! Enjoy this thread to experience the journey from death to life.

So, the idea is to get the longest communication path from vessel to KSC. You can send the signal through as many antennas as you want. The challenge can have different difficulties: Normal - Get the path from vessel to KSC throug TWO OTHER planet systems, vessel cannot be in these two systems. Example: vessel is on Eeloo, singal path goes Eeloo(vessel) - Jool - Duna - Kerbin(KSC) Impossible mode - make the signal go through all the SEVEN planets.

Hi guys, I made a short video yesterday that hopefully explains how to evenly space out satellites around an orbit when creating communication satellite constellations. I've also written a short document that covers the maths in more detail, but still at a high school level to help people create their own commsat constellations. I'd love it if I could get some feedback on both (I've already realised that I should have used the term transfer orbit in the video rather than parking orbit).

Probe Locations for the Kerbol System So I recently just came back from a Holiday in Tasmania, and I hear about the new updates, more importantly, the new CommNet network added in the game. So in game and in the tracking station, there is a green line connecting to all the online probes, landers, bases, rovers, space stations etc. The KSP team have also added in a bunch of new transmitters in the game as well. So the green line gets darker when you lose more and more connection with kerbin. This means that it is important to have probes everywhere in the kerbol system. You can also map planets and Moons with the new update. So then that is another few probes on each and every moon to make it easier to find better landing spots and to see where lakes and oceans are if your looking at Laythe or Eve. So my challenge is for someone to post a photo with all satellites and Probes connecting each and every other probe. To comeplete the challenge, you must show proof of: A minimum of 2 probes around each planet At least 3 probes orbiting any of the planets moons 2 probes orbiting around the sun between each planet 10 probes orbiting Kerbin and the Mün All the probes must be connected to each other and must connect to kerbin with a 100% status. 3 screenshots of you mapping the following : Laythe, Kerbin, Jool. Please post a commentl if you think this is a reasonable challenge or you think this is way to overpowered and would take up any of your own ksp time. I will be with you as I have notifications turned on... I don't care if you use cheats or not, I don't care if you use the same probe, just do the 6 steps. And you must show photographic proof of all the probes in their orbits. Good luck, and have fun! P.S. not rccomended for Career mode...

You can put any booster you want on there, but i provided one that can get it out of kerbin SoI. Check the fairing release settings. If it's only 2 parts it may bump the satellite. https://kerbalx.com/transitbiker/kerbnik-4a More to come soon from the kerbnik (unmanned) and kermnik (manned) family of spacecraft! Enjoy! - Andy

For people who are unaware, the Pentagon currently uses its own satellite communications system, the WGS (Wideband Global Satcom) for remote communications. However, the DOD is considering ending that program, instead using commercial satellite communications systems to do so- their budget is limited, and bandwidth demand is increasing. Though commercial comsats seem like a good way to do extend capabilities for lower cost, (not to mention increase redundancy) and studies to do so have been made, but the process has been going very slowly so far. Obviously, there are people against this, but some believe that commercial comsats cannot deliver for specialized DOD needs. There is also the possibility that such a system would undermine the security of a currently very secretive system (something the DOD wants, for the obvious reasons that they are a military service, and communications are essential).