Jump to content
  • 1

Placing satellites in a geostationary orbit


KenwoodFox
 Share

Question

Hello! This may sound silly but with all my years playing ksp, having bought it several years ago, when the game was just about the extent of the demo now, ive never acquired a true geostationary orbit, is there any way to place a ship or satellite in such an orbit without the use of mods, does KSP have a feature or something else to help a craft into such unique orbits, thanks!

Link to comment
Share on other sites

19 answers to this question

Recommended Posts

  • 2

As far as i know if you're in the orbital map and focus Kerbin, the orbital period is shown to be 5 hours 50-something minutes. Increase you Peri- an Apoapsis so the opposite point is half the time away and you are in synchronous orbit.

That is how i would do it without mods.

Edited by ThomasOnLinux
Link to comment
Share on other sites

  • 1

The errors in plotting your orbital data are too inaccurate to be in a completely stable geostationary orbit. Even KER's readouts aren't accurate enough for extremely long-term stability. Having said that, if you're willing to use hyperedit or edit your savefile, then set this as your craft's SMA:

3463334.05948876

As long as you don't reload your vessel, that SMA will keep your craft in a stationary orbit far, far longer than you care to be playing the game. Think hundreds of thousands of years... If you'd like to position your satellite over a specific area of Kerbin, then change the LPE to something other than zero. If you want to be directly overhead of KSC, then set this as your LPE:

15.4244444444444

EDIT: You'll also want to set all other values to zero: ECC, INC, LAN, MNA, EPH.

Edited by Rayder
Clarification
Link to comment
Share on other sites

  • 0

@diomedea Interesting thing is that the savefile can actually go one more decimal place, using 16 digits. Problem is MS excel only works with 15. I decided that the ability to use the number in formulas far outweighed the slight inaccuracy of 8 decimal places instead of 9 :P

But you're more than welcome to prove my number wrong haha! I did it to improve the accuracy of my formulas more than anything. Having a perfectly stationary orbit for 300,000 years was just a bonus...

EDIT: My testing indicates that SMA = 3463334.05915771 has a few seconds drift after about ten years. Do you find this is the case as well?

Edited by Rayder
Clarification
Link to comment
Share on other sites

  • 0
3 hours ago, Rayder said:

EDIT: My testing indicates that SMA = 3463334.05915771 has a few seconds drift after about ten years. Do you find this is the case as well?

Actually not, at least in theory. That difference would bring to 1 second difference every 757.7992420966 Kerbin years. But I use math to compute that, don't rely on KSP to give accurate results. Internal precision used by Unity is generally less than we have with our sheets.

EDIT: found to have limited precision in one of the equations in my own sheet (computing sidereal rotation period). Updated, my SMA now is 3463334.05947685. That's probably as much as my sheet can give; difference against yours now rates for 1sec every 21061.79967... years.

Link to comment
Share on other sites

  • 0

 

12 hours ago, Rayder said:

@diomedea Interesting thing is that the savefile can actually go one more decimal place, using 16 digits. Problem is MS excel only works with 15. I decided that the ability to use the number in formulas far outweighed the slight inaccuracy of 8 decimal places instead of 9 :P

The accuracy of a IEEE 754 double precision floating point number in the range 221 to 222 is about 4.66*10-10 - in other words, the "spacing" between representable numbers is about 0.000 000 000 466 (spaces added for ease of reading). The more you know!

(The accuracy in general for an IEEE 754 double in the range 2n to 2n+1 is 2n-52, which gives the usual rule of thumb of 15-17 digits of precision.)

Edited by renhanxue
Link to comment
Share on other sites

  • 0

Note: if you allow MJ or KER, the preferred method of making the satellite keosynchronous (without messing in save files or cheat menus) is to make your orbit roughly circular at altitude close to 1508045km then set thrust limiter to 0.5% and burn pro/retrograde to make your orbital period to 5h 59m 9.425s sharp. You'll have a small libration due to resulting eccentricity, but there won't be any drift. If you make a constellation of satellites, always set their orbital periods to identical value and they won't drift relative to each other.

Alternatively, there's a way using KIS... switch speed display to 'surface', make it less than 0.4m/s and then... Keostationarity guaranteed!

Link to comment
Share on other sites

  • 0

I don't know why nobody mentioned it, but there's another way of doing it, in career mode, without mods - completing a contract that asks for a geo-(keo-)stationary orbit satellite (where there's visually a target orbit that you can match). It's not terribly accurate, but you could still roughly feel it.

Link to comment
Share on other sites

  • 0
8 hours ago, diomedea said:

But I use math to compute that, don't rely on KSP to give accurate results. Internal precision used by Unity is generally less than we have with our sheets.

It's interesting that you mention this. I also used standard formulas and used the information from the wiki to do these calculations, but I found the numbers were inaccurate when applying them ingame; this was using on rails physics, by the way. After that I set out to determine the SMA manually and that's how I came up with 3463334.05948876. This led me to believe that some information on the wiki possibly isn't as accurate as it could be.

Another interesting fact:

The other day I discovered that Ike isn't perfectly synchronous or tidally locked. The minute differences in the sidereal rotation periods and Ike's SMA mean that over long periods of time Ike will drift around its orbit. I discovered this when I was testing the geosynchronous orbit around Duna and Ike sneakily came up behind my satellite and ejected it.

Edited by Rayder
Extra Information
Link to comment
Share on other sites

  • 0

For real... all of this discussion is moot for folks who don't have KER or care to set their altitude using the cheat menu. Carrying the accuracy to jillions of decimal points is good for a theoretical exercise, but in reality they only know G to 6 digits, so any computations past that accuracy are statistically noisy. And in reality, we are only able to see our altitude to the nearest meter,

 Personally, I don't mind if the sat drifts a few degrees per year. It's a pretty simple matter to do a correction burn every now and then.

Best,
-Slashy

Edited by GoSlash27
Link to comment
Share on other sites

  • 0

@Rayder: indeed, something similar here. I use gravitational parameter, SMA of the orbit and solar day duration (for Kerbin) as reported on the wiki, I believe those are exactly the values as coded in KSP (same for radius of the body and a few atmospheric data, though those aren't required to compute geostationary orbits). All other values are derived from the first three and the equations provide exact values to the precision of the sheet. The wiki is accurate for most practical purposes, but doesn't really compare with that level of accuracy. E.g., sidereal orbital period comes from Sun gravitational parameter and SMA of the orbit, the sheet gives (for Kerbin) 9203544.59721733 (wiki rounds to the closest integer); sidereal orbital period and solar day duration give sidereal rotation period (21549.4251829786, while  wiki has 21549.425); to note, that is valid for Kerbin, but other bodies have exact values (coded) for sidereal rotation, so I compute solar day instead. Of course gravitational parameter and sidereal rotation period are all to compute SMA of the stationary orbit. You may have observed already from the above, my sheet accuracy is to 15 digits. I'm actually less confident about the accuracy used by KSP, even when it uses double precision (like it should with orbital parameters). The way Kerbin was switched to show 21600 seconds duration from sidereal to solar day is probably a bit less accurate, but only looking within KSP code may provide evidence of the accuracy and method used. Still if the result you have from manual testing in KSP is so close to what I get with a purely math approach, the accuracy is clearly good enough for all gaming purposes.

Link to comment
Share on other sites

  • 0
35 minutes ago, Rayder said:

This led me to believe that some information on the wiki possibly isn't as accurate as it could be.

I think the wiki still doesn't reflect some changes made in 1.2.x:

1.2.0:

* Now always use g0 = 9.80665 and G (big G) = 6.67408e-11 for gravitational constants.

1.2.1:

On 11/2/2016 at 0:40 AM, UomoCapra said:

* Fix CBs being in different places in 1.2 by adjusting GeeASL.

Link to comment
Share on other sites

  • 0
15 minutes ago, diomedea said:

Still if the result you have from manual testing in KSP is so close to what I get with a purely math approach, the accuracy is clearly good enough for all gaming purposes.

Agree with you here. As I stated in my first post in this thread, getting an SMA approximately right (such as you and I have) will keep your satellite stationary for far, far longer than anybody is willing to invest into a single savegame.

15 minutes ago, diomedea said:

orbital period and solar day duration give sidereal rotation period (21549.4251829786, while  wiki has 21549.425

Haha another wrench in the works. I checked Kerbin's sidereal rotation period in Hyperedit and the value it threw at me was 21549.4251830898. Not entirely sure how Hyperedit works in some circumstances but I assume that it's pulling the values directly from the game?

Edited by Rayder
Link to comment
Share on other sites

  • 0
32 minutes ago, swjr-swis said:

I think the wiki still doesn't reflect some changes made in 1.2.x:

1.2.0:

* Now always use g0 = 9.80665 and G (big G) = 6.67408e-11 for gravitational constants.

Actually the wiki, still reporting 9.81 m/s2 for Kerbin's gravity, is accurate. Computing gravity with exact values of mass and universal gravitational constant (or, gravitational parameter) and radius for Kerbin, gives exactly 9.81 at sea level.

But the value of gravity changes in reality with latitude. That's why the conventional standard for gravity on Earth (9.80665) is an average of gravity measured at different locations. Earth's gravity of course depends also from the radius of the planet, that is larger at the equator and less at the poles; but even with a perfectly spherical body as Kerbin, true gravity depends on centrifugal acceleration due to its rotation, this depends on latitude (still from my sheet, centrifugal acceleration at the equator for Kerbin = 0.051008154 m/s2, use it with cos(latitude) to have the correct value at any latitude). Summing gravity from gravitational law (9.81) with the centrifugal acceleration gives makes 9.80665 a good average value. KSP uses the average value where appropriate, but that doesn't apply to vessels orbiting Kerbin.

Link to comment
Share on other sites

  • 0

To place a sat into KSO directly overhead KSC in a stock game:

Launch the sat into LKO of 100,217m.
Using a seeker on KSC grounds, track the passage of the sat overhead and mark the time.
Fire for KSO injection exactly 26 minutes 23 seconds after passage.
Circularize at 2,863,334m.

Best,
-Slashy

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...