Cant make accurate Geostationary orbit.

[Razorforce7]

Hello fellow Kerbalnauts.

I have a issue.

I can't launch fully stationary geosynchronous orbits around Kerbin. I mean fully stationary?

I know I need to send the intended vehicle to a altitude of 2,868,750meters above the Kerbin surface at a speed of 1009m/s - 1009,1m/s.

That is correct right? ^^

Anyway if it is correct then I have done this!

However I tend to play within the same save file creating my own space programs universe over the course of Years, I said [Years]

After the launch of my geostationary sattelites I spend 6 years into the simulation of my save file.

I have 4 geostationary sattelites in what I thought would be geostationary orbits since these 6 years Click

But these sattelites have taken distance towards each other. The sattelites whom I thought where stationary are moving closer to each other. Meaning that either 1,2,3 of them are moving towards each other since they all repositioned.

Or all 4 of them did (probably that <<)

Or away from each other making themselves closing in. They do not remain stationary from each other.

By my wishes they should each fullfill a quarter section of the orbiting space they rotate (if you know what I mean)

Like a sliced pie in 4 quarters. Without one of the four sattelites overtaking one of the other geostationary sattelites.

Here is another picture with explanation in it Click

This 4 sattelites GEO stationary system is to simulate earths geostationary sattelites to simulate a sattelite system that enables global communication. Other then that it really doesnt serve anything in case you were wondering.

In simple terms I dont know what causes the instability. But I do suspect it has something to do with the fact that even although the sattelites are at the correct speed and at the correct height they are in fact

not following Kerbins equator evenly. Or in other words they have a slight 0.0.1.1.1.1.1 [fill in] difference in the orbiting plane that's causing them to reposition themselves disorderly closer to each other over the course of years.

Is that the case? might that be the case?

If it is the case how do I ensure optimal equatorial alignment? Can you guys give me the exact math involved up to the last decimal that KSP can process or give other parameters that ensures that my geostationary sattelites remain stationary for over 100 perhaps thousands

of Kerbin years (if that's possible)

If it's not the case that equatorial alignment is the cause of the problem which I do suspect then what is the fix of this happening?

[astropapi1]

That also happens to real world satellites. Little differences in speeds can drastically affect the constellation after a while.

[Sirrobert]

Seeing as it's damn near impossible to get it EXACTLY right, that's what will happen over the corse of several years yes

[Taki117]

Because of their different orbital velocities (And slightly different orbits) they will drift over a very long period of time, in order to establish a perfect KSO you will need to do some save file editing.

Find the following bits of code and modify accordingly.

This example is from my satellite network around Laythe. (It's semi-synchronous because LSO lies outside LSOI)

alt = 2767180 (Altitude you want your orbit at)

ORBIT
			{
				SMA = 3267180 (this determines hoe big your orbit is, set this equal to the value listed in the wiki)
				ECC = 0 (Eccentricity, 0 is a perfect circle)
				INC = 0 (Inclination 0 is equatorial)
				LPE = 180 (Position of the periapsis)
				LAN = 0 (Position of the AN, set to 0 for ease)
				MNA = 4.64064663263034 (This value must be the same for all craft)
				EPH = 23200961.363508 (This must match UT)
				REF = 9 (Don't worry about this)
				OBJ = 1 (Or this)
			}

a note on LPE, if you have a network of satellites and you want them to be x degrees away from one another (In your case 90) then the LPE must be a multiple of x (In your case sat 1 would be 0, sat 2 90 and so on)

[Stone Blue]

If all you need is a system to use with RemoteTech, the satellites do not need to be perfectly positioned. As long as they have LOS to at least one other sat, and at least one sat has LOS over KSC, the comm system will work.

I had a constellation of just four sats; three that were placed roughly 120° apart, with one about 30° west of KSC, and a 4th, spare sat, placed about 45° east of KSC....All 4 sats had constant LOS with the other 3, and TWO always had LOS to KSC....I never had a problem with lost comms while in Kerbin SOI.

[arq]

What is most important for satellite constellations is orbital period, not so much indicated altitude or speed. Get a mod like Engineer, Mechjeb, or any other that will give you orbital period info. Using this, it is easy to set up satellites with orbits of 6hrs within around 0.1s/orbit. At this rate, your satellites should remain in a pretty good constellation, drifting by maybe 3mins/yr relative to each other. This should be suitable for 20+yrs without modification.

[Razorforce7]

I was aware that reallife geosynchronous sats are to closing in by small orbit changes. I do not know but I suspect they do alot better then mine. Meaning irl sats reposition themselves like mine did but over a much longer period.

I was hoping I could indeed tweak the orbits so that they would remain stationary for the most part during 100+ years. I never thought I would have to dig as deep into changing save file parameters and then still not be able to achieve that. I thought a ion engine on a relatively large sattelite weight could do the same if you fine tune it.

While working on my speed and altitude I will also pay attention to all the sats orbital periods.

I will use the assistance of Engineer and Mechjeb. Later today because I'm going to work now

Thanks for the assistance so far.

[Kasuha]

Put it at approximately the right orbit. It doesn't have to be perfect. Then go to map view, click on periapsis marker, click on apoapsis marker, so their descriptions stay displayed. Then use RCS to thrust prograde or retrograde till the difference between the two times displayed below these two markers is exactly 3 hours. Not only that they show the same number, but the seconds value should also change at exactly the same time.

Edited December 17, 2013 by Kasuha

[superm18]

I've found that the trick is not to get the perfect Ap/Pe, but the perfect orbital period.

[Zander]

real satellites have RCS and use it to make periodic adjustments to maintain their orbit. Why not add RCS to your satelites and use remotetech's KOS integration to create a program you can run every so often to make them readjust their orbits .

[MisterFister]

Everything described here is true and useful, but I think the OP is also asking "why" this happens.

First, it's true that realworld GSO satellites drift and have to consume fuel for stationkeeping purposes over their operational lifetimes. I highly recommend the wikipedia pages for this topic, and I specifically refer you to mentions of "graveyard orbits." Generally, realworld orbit perturbations result of myriad underlying causes, including faintly off-kilter calculations to begin with, along with fuel impurities (resulting in slightly-less-than-optimal thurst vectors, resulting in burn times being minisculely off-mark) and outside gravitational influences. Over extended periods for extremely accuracy-sensitive satellites, influences such as the moon's orbit, solar activity, and minute irregularities in Earth's own gravity well (resulting from variations in the distribution of mass in the Earth's liquid or semisolid mantle). Also, there is something called insterstellar and interplanetary drag, such as the cumulative slowdown you get from floating through faint dust clouds and debris stemming from Keppler Syndrome, as well as naturally occuring events such as the leonids.

Obviously, since KSP is a game, the Unity engine is not designed to (nor could it ever) faithfully model every single one of those conditions. Indeed, in KSO all SOIs are perfectly spherical, because each planet's mass is perfectly uniformly distributed, resulting in a featureless gravity well. For example, there is no such thing as lagrange points in this game. All fuel is uniformly pure, as another example. There is one obvious issue with maintaining accurate KSO paths and two subtle issues.

The obvious issue is human input, just as with realworld. If you design your maneuver nodes well (which even then is not entirely sufficient for the accuracy we would like due to the two subtle reasons below) it's still necessary to aim and burn them well, too. Good form amd fuel efficiency on maneuver nodes begins with good calculations in the VAB / SPH, and continue to include dividing the total burn time evenly across the node point (for example, a sixty second burn should hypothetically begin exactly 30.00 seconds BEFORE the designated time, and end exactly 30.00 AFTER, though with the fraction of a second it takes to actually go from zero to full throttle, this is never exactly possible) and accurately following the node indicator on your navball -- when you are down to the last few m/s of burn, it's generally a good idea to lower your throttle, puff those final m/s out, and actually follow the drifting node marker on your navball whenever possible, since the location of the marker DOES calculate your new trajectory live by applying any burn imperfections into the original node calculations. Generally, everything I've said so far makes an immediate sort of sense, when it's laid out.

The two other reasons why KSO orbits drift the way they do are much less obvious, however. First, we can agree that the actual math (advanced conic calculus) that goes into figuring and plotting (and subsequently simulating and rendering) any non-linear path, either through realworld space or through KSP space, is highly complex, with numbers that have unending decimal places. Simply put, in order to "work," the game engine at some point is forced to say "that's close enough" and stop calculating past the umpteenth decimal place and just fly with that. Those rounding errors, particularly when projected forward over simulated time lapses, become significant -- ESPECIALLY in a situation like yours where you have multiple satellites involved, and one realizes that you can run the same calculation a hundred times, and round it the "same way" each of those hundred times, and little eensy teensy discrepancies become more and more noticeable.

As if all of that wasn't enough, there's also the fact that when comign into and out of time compression, and when OTHER craft in your savefile change SOIs, all of those calculations are reset and recomputed... and re-rounded. As you play your game, whether you simply blast forward at 100,000x time compression for 5 realworld days, or you simply place a satcomm network for RemoteTech2 and then go about your merry ways, this repetitive rounding will compound and worsen all of the above factors that I've described, each time the engine calculates it, which can often be hundreds of times every realworld second. (FYI, the fact that it crunches such heavy numbers is the specific reason why this game can become a slideshow when it has to keep track of large and complex craft in close proximity to each other.)

So, ultimately, there is nothing that any player of this game could ever do, including savefile editing, that will absolutely eliminate this problem. Savefile editing will, of course, come the closest to totally eliminating it, since doing so will eliminate all of the human-introduced and even a significant portion of the game-introduced factors and floating point errors that I described above. Ultimately, just as in realworld satellite maintenance, you just have to in some way incorporate this inevitability into the design of your craft and your mission profiles (for example, by periodically re-editing your savefile, or by launching more satellites for your network, so that when one drifts out of position, it won't IMMEDIATELY result in a blind spot in your coverage, and by launching those satellites with extra RCS for better finetuning over a longer operational life.)

[Keldor]

Ion engines are your friends here, since their low thrust is perfect for fine-tuning your orbit.