wmheric

Yes, you're right. Molniya orbits are for reducing the down time by lowering the proportion of time a probe spends close to (and behind) Kerbin, the relay satellite eventually goes into the "dark" side from time to time anyway. IMO Molniya constellations are much more tedious to set up/maintain/upgrade, and I always use equatorial circular orbits for relay outside the Kerbin system, unless I want low-orbit or ground coverage in the polar regions. I'd like to talk more about the single-antenna case, as the OP tries to use. A simple answer is no, you cannot. You'll need at least 2 antennas to guarantee zero down time anywhere in the Kerbol system. But as I often did, you can keep the probes with only one dish pretty safe if the down time is small. You can calculate the portion of the orbit in the "shadow", or more precisely, the angle (theta) that the "shadow" subtends with respect to the center of Kerbin: sin (theta/2) = R_K / r where R_K = radius of Kerbin = 600 km, and r = radius of the orbit (now we only look at circular orbits) (Here we assume that your probe is far away from Kerbin. You can treat "far" as the distance being much greater than R_K.) From a period T = 2 hr given in your sketch (nice use of the compass!), the corresponding radius (the distance from the center, not the altitude) of the orbit is r = 1667.6 km, and the angle subtended is 42.2 degrees, or 11.7% of the orbit, so the down time is 2 hr * 11.7% which is about 14 min. Moving a maneuver node 14 min ahead/behind is not really a big deal compared to the whole interplanetary flight. It might become an issue in critical moments like a capture burn / landing, but you can always plan ahead to arrive earlier or later. On the other hand, as Starstrider42 has pointed out, if the probe gets far enough away from Kerbin, you can switch the pointing to a single satellite to just Kerbin (always quicksave first…) and still have the dish covering everything, and now you have zero down time! The distance (d) required can be found in a similar way: tan (theta/2) = r / d where theta = cone angle of the dish, and r = radius of the orbit For example, for a Communotron 88-88 dish, theta = 0.06 deg, using r = 1667.6 km, we get d = 3185 Mm, which is smaller than the semi-major axis (5263 Mm) of Moho, or even the closest Eve can ever be from Kerbin (~3700 Mm). (I hope I didn't make any mistakes, but I think you can figure out the geometry by yourself It works similarly for other planets as well!)

This. According to the Wiki, whether a vessel has orbited around a body has an effect on the amount of science obtained upon recovery. Although the formula given is not a confident statement, I recall from my mission reports that orbiting a body returns more science points. How KSP determines whether a full orbit has been completed is also interesting to learn about.

Hmm I'm not sure what kind of answer OP is expecting, but I kind of treat it as a physics question. Most have responded with explanations on ellipses / circles, yet why is a deeper question. In KSP, gravity is based on Newton's Law of Universal Gravitation, and in this classical picture of gravitation, a closed orbit is a perfect, eternal ellipse. It is a good description (an approximation) except in some special cases such as the precession of the orbit of Mercury, which later led to Einstein's General Relativity, which is a better description of gravity. Newton's gravitation does predict precession (of elliptical orbits) but attributes it to the perturbation of other planets and the oblateness of the Sun, but this is not enough; General Relativity says that there will still be precession if there are only two bodies (say, the Sun and Moho only). Or to put it loosely, gravity is not just gee-em-em-over-ar-squared. So, orbits are circular/elliptical because we (KSP) are adopting simplifications such as ignoring effects of other planets assuming perfectly spherically symmetric gravity wells using Newton's gravitation and orbits are not really perfectly circular/elliptical because they just aren't. Given a velocity vector and an acceleration vector, you can always work out the whole orbit in a uniform circular motion. In general for an ellipse, you can still work it out by realizing the vectors are just the vis-viva equation in disguise.

I think what Blizzy was trying to say is that fuel requirement and a physics "effect" have no relation to each other. You do not "end up using less fuel for the same dv change". Given the same rocket design, the fuel requirement is always the same for a certain delta-v requirement. You save fuel because the delta-v requirement is less, the phenomenon that delta-v requirement is less at a higher speed is termed the Oberth effect; it isn't really something that pops up when you thrust -- it is just there. The answer to the question "do maneuver nodes take the Oberth effect into account?" is no, because it doesn't take into account some physics. It is like asking "do engine burns take the Newton's Second Law into account?". KSP implements classical mechanics, so any physics consequence is just there in the game. I'm not trying to be picky here. I want to fight physics misconceptions

My understanding is that after the plane change at Ap you come down to the periapsis to push Pe out to Minmus' orbit? The efficiency of the plane change burn depends on how far out the AN/DN is but is better than one at low-Kerbin orbit, although Minmus would have displaced some distance by the time you go back to the Pe so you may have to delay your burn. Burning at points other than the AN/DN would actually change the positions of AN/DN; you can still minimize the relative inclination but if you want it zero you have to burn at AN/DN. I usually do my plane change at AN/DN on the way to Minmus like what Scott Manley did in his tutorial. Looking solely at the plane change, doing it at apoapsis should be optimal, but considering things like the displacement of Minmus it gets a little bit complex (for example, whether it is still beneficial given now we have a delayed burn being non-optimal as we can't burn at Pe because Minmus has moved) and practically we might as well just do a plane change on-the-way. This is quite interesting as a general plane change problem and it definitely deserves to be a sequel to this thread if I have the time

Noticed you have more Keostationary satellites than you need and want to convert some into polar orbits to extend the network coverage? Having launched a probe mindlessly firing eastward into space just to find out that you actually need a polar orbit? Burning normal does help you change the inclination of an orbit, but if you have some experiences in orbital maneuvers, you probably already know that it is one of the most fuel-consuming one, and you probably also know, either from your own experience or from other players, that it is a fuel eater because you are burning perpendicular to your velocity, which requires a lot more delta-v than other common maneuvers. Are there any other ways than just burning directly to achieve the same goal with a smaller delta-v (fuel) requirement? In this thread we will cover a simple type of such maneuver: a plane change of a circular orbit by 90 degrees into another circular orbit of the same radius. It is possible to get the idea by doing a number of experiments, but a bit of math is certainly needed to have a complete picture. Nevertheless, if the math is too much for you, a simple answer to the question above is: If we limit ourselves to (1) 90 deg changes, (2) circular initial and final orbits, and (3) same radius for both orbits, then the delta-v requirement is always less if we raise the other part of the orbit and burn normal at the apoapsis, and finish by circularizing the orbit when you return to the periapsis. Qualitatively speaking, this maneuver exploits the fact that an acceleration perpendicular to the direction of motion is the most efficient when the speed is the smallest, and it turns out that while some delta-v is needed to raise/lower the apoapsis, the amount you save for the plane change at lower speeds is greater and outweighs what you spend to change the eccentricity. So at this point it is perfect to just have this in mind and go ahead with your missions; but if you want to know more, here comes the math. Before writing down equations I would like to emphasize that everything that follows is a result purely from physics/math and has nothing to do with rocket designs (efficiency of engine, TWR optimization and so on). One important separation between the theory and practice, though, is that the changes in velocities are assumed to be instantaneous so you might find deviations if the thrust of the engine you are using is very small. Let's first consider the "direct burn" way: Say the initial (eastward) orbit is circular and equatorial marked in green, and the orbital velocity (the prograde vector) is the black arrow labeled v1. The final orbit, our goal, is also circular but polar marked in orange, then right after you finish the plane change burn, your velocity, labeled as v2, should be to the north (or the south but it doesn't really matter here) in the +z-direction. For our simplification that the orbits have the same radius we have v1 = v2 = v. The change in velocity, delta-v, is then the subtraction of v1 from v2, and can be drawn by connecting the tips of the vectors, as shown in red. The amount of delta-v is its magnitude, easily found by the Pythagoras' Theorem: One interesting thing to note here is that the delta-v vector does not point entirely to the north, but inclined to the west; it is because to complete the maneuver, you have to not only obtain a northward velocity, but also cancel all of your eastward motion. It is the combination of the northward and the westward components that makes the required delta-v inclined. We are basically done with the direct-burn case! The delta-v you need is the square root of 2 times, or about 140% (yes, 140...) of, your initial (and also final) orbital speed. Now, let's look at the more complex, alternative way: This scheme involves 3 burns in total, as marked by red dots in the figure. The first one is burning prograde to raise the other side of the orbit to a certain apoapsis altitude. The second one is performing the actual plane change maneuver at the apoapsis. The last one, taking place at the same location where the first maneuver was, is burning retrograde to recover a circular orbit. There are more velocities we need to take care of here. Let's take a closer look with a "top view" from the north: It is time to bring up the prime equation we need to deal with orbital velocities, the vis-viva equation: This equation is the direct result of the conservation of energy and momentum, although we will not go into the details here. Once we fix the gravitational parameter µ, which is just a constant related to the parent body, and the periapsis a, the equation tells us the speed v at whatever position r we are interested in. The first maneuver (we call it maneuver I) takes place at the leftmost position in the figure. Let's say your orbital velocity in the green, circular orbit is v1I, and after burning prograde, the velocity is v2I. Using the vis-viva equation we get Remember that after the prograde burn, the orbit is no longer the green one -- it becomes the blue ellipse. v2I is a part of this elliptical orbit, and the corresponding semi-major axis a is half the sum of r1 and r2. Therefore, the speed right after the prograde burn is The delta-v of the first maneuver is Maneuver II takes place at the apoapsis of the elliptical orbit, in the right hand side of the figure. The vis-viva equation again gives This maneuver ends up with a orbit perpendicular to the screen, with a velocity pointing out of the screen in the +z-direction. In the figure we use the arrow head/tail symbols: where a cross represents a vector pointing into the screen and a dot represents a vector out of the screen. This maneuver is a plane change, so the delta-v is the square of two times the speed: The final step is circularization of the orbit when we reach the periapsis. Since the only difference between the two elliptical orbits before and after the plane change burn is the inclination, the situation is exactly the same except that we are burning retrograde this time: The total delta-v is then the sum of all for the three maneuvers: which is not something very good to look at, but to know how much delta-v has been saved, we need to subtracted the delta-v for a direct burn from the total of the three maneuvers (recalling that in the direct-burn case, the orbital speed is equal to v1I): This is an expression that depends on r1 and r2, the distances to the periapsis and the apoapsis. If the difference turns out to be negative, then we can indeed save some delta-v via the 3-maneuver scheme. So when is it negative? The difference is negative if the expression in the square brackets is: The two parameters r1 and r2 are a bit too much to handle, though we can transform it into a simpler one by dividing by r1 and letting and get Rearranging by a bit we get a quadratic inequality in s: Solving this for s gives: Recall that s is the ratio between the periapsis and the apoapsis distances, so the negative solution here is meaningless and is discarded. We are left with s > 1, or, in other words, We got a very simple solution here: as long as r2 is bigger than r1, the delta-v requirement for the 3-step maneuver is smaller; the delta-v needed to bring up (and down) the apoapsis is worth it -- you will always (90-degree plane change between circular orbits of the equal size) save some delta-v by doing so. It is also very useful to know, after all these calculations, that how much delta-v we can actually save. If we express the total delta-v budget in terms of a fraction, f, of that for the direct plane change: we can work out that which is not very illuminating to look at as well. But let's ask a question: "How much can we save at most?" It turns out that if we push out the apoapsis extremely far away, that is, as s grows indefinitely large, f approaches the number 0.586, which means that the total delta-v can only get as small as ~58.6% of that in the direct-burn case (or we can say we save ~41.4%). If you want to cut, say, 50% of the delta-v requirement, there is no way you can get there. This is a very interesting result; you cannot cut your budget indefinitely by pushing out your apoapsis as far as you want. But we knew this already, didn't we? Let's pause a bit to recover ourselves from the tedious math. We knew that there is a minimum amount of delta-v we need to deal with -- to bring the apoapsis up and down! In the case where the apoapsis is indefinitely far away, we are just barely escaping the parent object's gravity, and at that very-far-away place, our velocity reaches zero exactly. The plane change actually takes no delta-v at all to complete; the budget will entirely be spent for the prograde burn to "ellipticize" the orbit, and after a very long period of time when we finally come back, the retrograde burn to circularize the orbit. The speed we need to achieve to reach the very-far-away apoapsis is, of course, the escape velocity ve: The total budget then comes from the two burns (one prograde, one retrograde), which require an identical amount of delta-v: This is exactly what we got above! Knowing that we are indeed getting consistent results, we may as well look at some "experiments". Using Kerbin as the central body, some tests were carried out to verify our calculations with the help of Jebediah (in fact he was issuing commands to MechJeb to ensure that the burns were accurately performed). The craft was first HyperEdited to a circular, equatorial orbit at an altitude of 100 km. It turns out that FL-T800 + FL-T100 has just enough fuel for an LV-T45 engine to achieve (3288 m/s) a delta-v of 3177 m/s (we also have a couple of solar panels to survive long eclipses in highly eccentric orbits) in the direct-burn case. Next, the three-step maneuver was carried out with an apoapsis at 200 km. This is repeated for 300, 500, 1000, 2000, 5000 and 10000 km. Finally another run was done the apoapsis at 80000 km, near the edge of Kerbin's SOI. Some example screenshots are shown below and f was calculated for each ratio s and plotted along with the red curve from the theoretical point of view. (please open this in a new tab) The plot: As you may have noticed, the delta-v requirements for the first and the third maneuvers were not exactly the same. This comes from the imperfectness of the burns and pointing even with MechJeb, although the error is practically negligible. The 3-step maneuver is evidently advantageous, from the point of view of delta-v. One sacrifice of this method is the time to complete the objective -- the orbital period of the elliptical orbit. Nevertheless, as seen from the plot, you don't actually have to go for a highly eccentric orbit; a value of 10 for s already gives an f less than 65%; in fact, it doesn't make a lot of difference (in the amount of delta-v saved) if we go from s = 40 to over a hundred.

I wouldn't consider this as a bug/feature. It is the nature of floating-point arithmetics. I think the objective of the mod is to add realistic features to the game by introducing possible communication blackout. It does gives the player more stuff to manage (to set up networks, to plan ahead, etc.). In reality, although there are no floating-point errors, there are perturbations (from the Moon, the Sun and other planets; from the asymmetry of the gravitational field, etc.) and engines have to be fired from time to time to keep a satellite in a stable orbit, though everything is controlled by computers. In this case the mod shouldn't give too much of a burden as the player can control only one vessel at a time. I think the ability to somehow "snap" a satellite into some preset orbits so that the position of a satellite is reset regularly is a good workaround.

IMO the most important point in KSP: it is orbital mechanics, not driving on the road. If you want to get to a place, you can't just hit the pedal and get there; you don't change direction by just steering; we don't really have much "control" in this case, and indeed we don't -- essentially we are all slaves of gravity, we make a small change here, and hope that gravity will gradually bring you to the correct place. In the atmosphere, you may be flying a plane, but once in orbit, strictly speaking you are not flying anything; you just change something at a certain point, and you can only let gravity does its job. Everything takes time in this game; the only thing you can control is how well you perform your maneuver, and once it is done you can only wait (time-warp) for it to happen. It's not like a car racing game. So it is very important to invest time to perfect your maneuver, and it is the nature of space travel. Knowing some maths does open up a lot of possibilities, but KSP does provide enough info readouts for most basic missions. And in fact, understanding how your action affects your orbit is more important than knowing a lot of jargons and just plugging numbers in each of them.

Derp. Thanks! You save more delta-V by pushing the apoapsis higher.

Alistone is right: for a 90 deg plane change, the delta-V required is always smaller when you bright up the apoapsis and burn normal there, and it turns out that the amount of delta-V "saved" is smaller [EDITED: greater] for a higher apoapsis. The tradeoff is of course the total time (the period of the elliptical orbit) needed to finish the maneuver. Gravity assist by the Mun is an challenging and an exciting idea

lodestar has a nice procedure above on how to do it with a probe carrying all the satellites in one single mission. For a 3-satellite configuration using a 4-hr transfer orbit, 1225.553 km is the number to go; for a 4-satellite configuration... A short answer: If you're using a 4.5-hour transfer orbit, 1658.030 km is the altitude you're looking for. A long answer: You need Kepler's Third Law, I wrote a tutorial to explain it. Yes it is quite long, but I hope that by the end you will know how to do the same thing with any configuration around any planet, because you understand the principle. If you're launching them one by one, you can do the "rendezvous" thing mentioned above because now you have the closest approach markers. Hope this helps!

I think I get what the OP means by people missing the point. Speaking of the impossibility of perfectly circular orbits, orbits exactly matching a desired semi-major axis or a period, even with readouts from mods like Engineer Redux or MechJeb, are also, in principle, impossible because of the floating-point calculations. The issue is negligible in the beginning but if the player spends long enough with a save (e.g., multiple interplanetary missions could make you time-warp for tens or even hundreds of years), the errors start to show up as they propagate. Therefore, I'd say it is impossible to make maintenance free orbits currently in KSP. Having said that, I'd go for keostationary orbits for low latitude coverage and Molniya orbits for polar coverage (and that's what I have done). For low(er) latitudes: In reality, geostationary orbits have a big practical advantage for communication uses over other type of orbits because they appear to be stationary to a ground observer, which means that as long as there is a satellite visible high enough above the horizon, an antenna can be pointed at it from a roof of any building anywhere in the world. On the other hand, in KSP, unless you are setting up ground stations around Kerbin, the KSC is the only place you want to keep 100% connection to, and the antennas at the tracking center are omni-directional with a range of 75 Mm, so it doesn't really matter whether a satellite remain stationary to KSC as long as there is another one to take over when it goes below the horizon; you may as well decide the altitude of your network to be, say, 1000 km, as a round number. My choice of the stationary altitude (2868.75 km) is because it is easier to launch very first few satellites if you're doing it unmanned -- if the first one is "always" in front of KSC there is less panic to set up those behind. Another reason is that the orbit is quite far out so the LKO region remains quite clear for me to see. So I could say it is entirely up to you. For polar coverage: I use polar Molniya orbits because I want the satellite to spend most of its time above the poles (besides the coverage advantage, you can also bring less battery because the satellite spends less time in an eclipse). But then again unless you're flying unmanned in a very low orbit or you want to communicate with something on the ground near the poles, these are less important. Also, if you're apoapsis is too high up the Communotron 32 stops working and you have to use dishes. You either need pointing from the keostationary ones (if you have bring extra ones on board), or from the ground by setting up a station at intermediate latitudes (so the signal goes Molniya probe <-> ground station <-> keostationary probe(s) <-> KSC). If you are doing the latter unmanned (an interesting task!), you can try the Reflectron KR-7 to ensure connection descend as it is the earliest one in the tech tree that does not break in the atmosphere while having the range to reach out far enough. (For Molniya orbits you need to set up at least two to ensure coverage, which brings us back to the impossibility of matching their orbits exactly...) If you're playing in the Carrer Mode (IMO RemoteTech is challenging (and thus fun!) only in this mode), eventually you will find yourself launching more and more probes (upgraded with Communotron 32 / upgraded with Duna coverage / upgraded with Jool coverage) to complement the old ones, so coverage "holes" will become less of a worry. Satellites crashing into each other is quite rare, and if crowded orbits really concern you, try separating them in group by changing the inclination slightly (e.g., a 0.5 deg is already a lot at the synchronous altitude).

Thanks a lot! Yes, the equation you derived is very useful for insertion into orbit at the right position and at the right time. It merits a post for discussion (got so many ideas on what to do next! ) Looking forward to your video

Hi Scottiths, LPE is the longitude of periapsis, it defines the position of the periapsis as an angle relative to a reference direction. I don't know how it is internally handled in KSP, but for a perfectly circular orbit (ECC = 0), it doesn't make sense to talk about any periapsis (or apoapsis). I recommend you leave LPE = 0. As Fett2oo5 has pointed out, where the epoch (time elapsed since a time reference, the time t = 0) is defined by EPH. MNA is not "how fast your satellite is going". To set up satellites 180 degrees apart, you can set one of the MNA = 0 and another to MNA = 3.1416 (MNA is expressed in radians, and 180 degrees is pi radians), and make sure that the two orbits have the same EPH. EDITED: got beaten! DAT Pi though

The context of this guide is based on the real-world use of communication satellites put in geosynchronous / geostationary orbits. In short, a geosynchronous orbit is an orbit with a period the same as the rotational period of the Earth; a geostationary orbit is a special case of a prograde synchronous orbit in which the orbit is directly above the Earth's equator. If our focus is solely on equatorial orbits in the same direction as Earth's rotation, the two terms basically refer to the same thing. Having satellites in a geostationary orbit is a great advantage for transmitting signals to and from the ground because the pointing of an antenna does not require further adjustments once it is set at the time of the installation. (Say the large dishes placed on the roof of skyscrapers; and if you haven't noticed, the pointing angle has something to do with the latitude at your location!) In the current vanilla version of KSP, communication coverage is not a concern because you can control a probe, whether manned or not, from any location. The mod RemoteTech 2 (RT2) offers a more realistic situation where it is possible to control an unmanned probe only when there is a proper link to the KSC. Scott Manley has done on how to deploy a network of three satellites in the configuration of an equilateral triangle in the Keostationary orbit; the trick is to put the probe carrier into a 4-hour eccentric orbit with its apoapsis at the Keostationary altitude and deploy a probe at each apoapsis pass. A crucial part of the maneuver is knowing the orbital period of your satellite. With the help of info panels provided by mods like Engineer Redux and MechJeb, this is rather straightforward. On the other hand, vanilla KSP does not currently provide a simple value readout.The purpose of this guide is to introduce the Kepler's Third Law of Planetary Motion, which will be applied as a method to set up the 4-hour transfer orbit. We will then move on to talk about setting up a network in a regular polygon configuration in general. Although the Keostationary orbit is used as an example, the idea extends to the scope beyond circular and equatorial orbits. The same maneuver can be employed whenever you are trying to deploy a number of satellites sharing the same orbit with an equal time lag between them. This guide will be divided into 4 parts. The first part will be an introduction to the law and some background information. Next, we will get to the practical example of getting communication satellites set up. In particular, we are using the 4-hour transfer orbit in Scott's demonstration. We will then move on to go through some more calculations and explore different cases of the application. It might get a bit mathematical at this point, but the goal is to try to understand it and not follow formulas blindly without knowing how they actually work (so this is not a step-by-step guide). Finally there will be some points to note when you are doing this in-game. 1) Background The Kepler's laws of planetary motion are three empirical laws established in the early 17th century that describe the motion of planets around the Sun. These laws are empirical because they were published using data from astronomical observations, not being derived from first principles. Our focus here is the 3rd law, and let's go straight to the definition: All closed orbits are ellipses (a circle is just a special case of an ellipse!); the law says that if we measure the orbital periods P of all the planets, square the numbers, and at the same time, we measure the semi-major axes a of their orbits, cube the numbers, then the ratio of these squares and cubes between two planets will be the same! Mathematically, we'd write where k is a constant (some fixed number), or, if we forget about the k, Now, if we do a logarithmic trick (astronomers use it all the time, but I don't want to dive in the Math here) to the first equation we can get which is the equation of a straight line with a slope of 3/2, or 1.5. (What line? If you have no idea what is going on here, don't worry, keep moving on.) Let's make this into a picture for the Solar System: The data points are not trimmed by hand -- they are the actual values (from Wikipedia) for the planets, and it happens that all planets (and minor-planets too) (Pluto is not a planet, deal with it) lie so close to the red line that the discrepancy is virtually invisible! This shows that the Kepler's Third Law is a very good description of the reality. If you know the math about straight lines, you may have already noticed that the line passes through the origin (0, 0) while there is a y-intercept term (1/2 log k) in the equation. This is from the careful choice of units so that P is represented in years (~orbital period of the Earth) and a is represented in AU (~average Earth-Sun distance); in general, the line does not pass through the origin -- but its slope is always 3/2. In fact, if we consider the Kerbol System and use SI units, this is what we get: I guess there is no need to explain how beautifully things fit together again. The statement of the law concerns the orbits of the planets in the Solar System, but it is not only limited to that. We can apply it to the satellites orbiting Kerbin. In fact, it can be applied everywhere, as long as the central body is the gravitationally dominant one (e.g., the Kerbol System, the Jool System, an artificial satellite system around Kerbin). (See Section 4 for more on this.) This means that we can apply the same period-semi-major-axis relation to the satellites we launch, as in the application below. 2) Application Before you perform the transfer, there are four important points to know: the Keostationary orbit has a semi-major axis (radius) of 3468.75 km; the orbital period is the same as the rotation period of Kerbin, i.e., 6 h; the radius of Kerbin is (as in a perfect sphere, ignoring hills and mountains) 600 km; apsides are represented in-game as altitudes from the planet's surface (IMO there should be a way to switch between the two representations...), so the apsides will read 3468.75 km - 600 km = 2868.75 km. For three satellites forming an equilateral triangle, this is what we are looking for: Recall that our goal is to set up a 4-hour orbit with its apoapsis at an altitude of 2868.75 km. If you already have some experiences on Hohmann transfers, it is fairly easy to burn prograde at a low-Kerbin orbit to achieve such an altitude -- the challenge here is to get the period to be 4 hours at the same time. To do this, we have to figure out what the periapsis is: The sum of the periapsis and the apoapsis is equal to two times the semi-major axis a; in other words, To find a, we use the ratio in the second equation: and we have a = 2647.1517 km. The periapsis is then at rp = 2 * 2647.1517 km - 3468.75 km = 1825.553 km. So there you go, the altitude at periapsis is h = 1825.553 km - 600 km = 1225.553 km. 3) Further Calculations The 4-hour transfer orbit works only for a 3-satellite configuration. What about a network in a regular polygon in general? In an equilateral triangle, the satellites are 120 degrees (1/3 of a full circle) apart, so we aim for a transfer orbit of a 4-hour period -- wait, shouldn't we have used a 2-hour orbit (1/3 of 6 hour)? Let's find out what altitude we need for that: which gives a = 1667.6011 km, and rp = 2 * 1667.6011 km - 3468.75 km = -133.548 km. Now you see why: a 2-hour orbit requires a negative periapsis and it is impossible! Do not get confused, it is fairly easy to get into a 2-hour orbit around Kerbin; for example, a circular orbit with radius 1667.6011 km (well beyond the atmosphere) will have a period of 2 hours. The 2-hour elliptical transfer orbit here is impossible because we require its apoapsis being at 3468.75 km. In other words, if you need a period of 2 hours, you just cannot have the apoapsis that high up. Or, in yet another words, if you need an apoapsis that high up, you cannot have a period as short as 2 hours. In fact, there is a lower limit on how short the period can be if you fix the apoapsis at a certain altitude, if we do a little bit of math. Suppose we are transferring to a circular orbit of radius ra, then the apoapsis of the transfer orbit must also be at ra, and we have To harvest some meaning out of this, consider two extreme cases: rp = ra, which is the trivial case where your "transfer" orbit is just what you want, so what do you expect? f = 1; rp = 0, which is in principle a straight line (or an ellipse with a very, very small, tiny minor-axis) as the "orbit", and when the parent object is a point-mass, here f = 1/(2 * square root(2)), or about 0.35. Therefore, no matter how hard you try, it is impossible, even in principle, to set up a transfer orbit with its period less than ~35% of that of the circular synchronous orbit. This shows how close the 2-hour orbit solution is -- 2/6 ~ 33%! Now back to the transfer problem. As we cannot use a 2-hour orbit, we resort to the closest possible one -- a 4-hour orbit. Strictly speaking, this puts the satellites with an angle of not 120, but 240 degrees apart. The second satellite being deployed is 240 deg "behind" the first one, and the third one is 240 deg behind the second one, so the third is 480 deg behind the first one; but then 480 deg is one full circle (360 deg) plus 120 deg, so in another perspective, the third is only 120 deg behind the first one (but it doesn't really matter -- we have an equilateral triangle anyway). Let's consider another configuration, where you are trying to set up 6 satellites in a regular hexagon. let alone 1 hour. The next choice is 5 hours. It should become kind of automatic for you to plug the numbers in at this point: and get a = 3071.7474 km, or rp = 2674.745 km. Since the orbital period of the transfer orbit is 5 hours, the carrier probe will return to the apoapsis and the previous satellite deployed will have travelled a bit short of a full circle (300 deg) so the next satellite will be 300 deg behind, or more conveniently this time, 60 deg ahead. Of course there are choices (actually, infinitely many choices in principle) greater than 6 hours; you just have to wait for the carrier probe to come back at the same position to deploy another satellite. Our choice here is to try to minimize the overall mission time, as well as the fuel usage by avoiding going into a higher orbit. To extend this into a general context: it doesn't matter which planet/moon/object you're orbiting, it doesn't matter what the synchronous period of the object is; As long as you are comparing two orbits in the same SoI (i.e., same source of gravity), what you need are only the required semi-major axis async and the fraction f depending on how you want the satellites to be separated, you can derive the altitude of the periapsis for your transfer orbit: What's more, it doesn't matter how eccentric the orbit is (provided you don't go inside the atmosphere or even crash onto the surface ...) -- perhaps you want to set up a Molniya orbit with three satellites. The same holds: Just bear in mind that apsides are shown in KSP as the altitude from the surface: or if you want a single formula to work with: 4) Points to Note Knowing how to deal with the maneuvers, there are some important points to note when doing it practically: Instead of setting up the transfer orbit from a low-Kerbin orbit, you can burn straight into the required apoapsis from launch to deploy the first satellite, circularize it and switch back to the carrier probe and bring up its periapsis, so that you can save some time, but you need to be quick. In RT2, Communotron 32 has a range of 5 Mm (5000 km), which is the highest among the omni-directional antennas. Yet in a equilateral triangle configuration, the separation between two satellites is 6008 km, which means that the satellites can talk to each other only by dish antennas, so be sure that you bring enough onboard. On the other hand, you can save some by pointing those on two of the satellites towards Kerbin, but you have to shorten one of the sides of the triangle so that the two lie within the cones. Your satellite will depend solely on its battery (well, the radioisotope generator is quite late in the tech tree if you're doing Carrer Mode, and who needs it when you can just bring enough battery) in an eclipse when Kerbin is blocking the Sun, so make sure you have enough to survive the eclipse. Also, bring slightly more for the occasions where you happen to find Mun in the way when you just come out of Kerbin's shadow, feeling relieved.

Hi there, This is indeed a very interesting question, and the Kepler's Third Law is your answer. I don't know about your science background, but to put it in simpler wording for the context here: the orbital period of an orbiting object depends solely on the semi-major axis of the orbit (which is the average of the periapsis and the apoapsis; notice that the altitude is displayed in-game instead). So, as long as the semi-major axis of the orbit of your satellite is equal to "35,786 km + the radius of the planet", the orbital period will be the same as the rotation period of the planet, thus the term geosynchronous. Although the rotation periods are the same, the position of the satellite as seen from the ground will change over time in a day (a complete rotation of the planet), depending on the eccentricity and the inclination of the orbit. If you want the satellite to stay in an exact direction in the sky, thus the term geostationary, you have to put it in a circular orbit directly over the equator. There is one and only one (provided that it stays in the SOI...) such orbit -- the geostationary orbit. I would say that a Molniya orbit is more practical for communications than a synchronous orbit, because having a highly eccentric orbit allows the satellite to spend most of the time above the polar regions. If you already have a geostationary communication network, the time that the polar satellite spends near the equator seems "wasted". Plus for a Molniya orbit you can bring less battery onboard because the duration of a solar eclipse is shorter as the satellite moves faster near the periapsis. For surface scanning (like Kethane or MapSat) though, notice that the altitude matters, so you might want to consider deploying two separate groups of satellites, one in eccentric Molniya orbits for communication, one in low-Kerbin orbit for survey missions. Hope it does more help than confusion

Hi Max, I didn't look up and check the quoted numbers for the apsis but if they are correct, the approach looks fine to me. One important thing to note though: 2868.75 km is the altitude for Keostationary orbits; what you actually need is the semi-major axis of 3468.75 km, which means that in a equilateral triangle configuration, the satellites will be more than 5 Mm apart. So you will need to install extra dishes (probably Comms DTS-M1) or make a polygon with more sides. (IMHO the ability to switch between altitude and the actual distance should be a feature in future KSP. It is quite inconvenient right now...) Also, I noticed that the angle you calculated is only half of that of the viewing angle -- did you forget the factor of two? If I plug in 3 468 750 m and 7 284 074 276, I get a viewing angle of ~0.055 degrees. According to the Reddit tutorial, the antenna with the shortest range outside of Kerbin's SOI is Communotron 88-88, which has a cone size of 0.06 deg, so it is just enough to cover the orbit you want to set up. (If you are playing Career Mode you probably would have unlocked Reflectron KR-14 in the tree first, but this dish has a cone size of only 0.04 deg, so you will again need extra antenna (and electricity) to actually point directly at each other.) BTW, if you didn't know, for very small angles (I would say < 1 deg is small) you can use the approximation tan(alpha) ~ alpha, given that alpha is expressed in radians. Hope it helps! Eric