Loading AI tools
A Sun-synchronous orbit (SSO), also called a heliosynchronous orbit,[1] is a nearly polar orbit around a planet, in which the satellite passes over any given point of the planet's surface at the same local mean solar time.[2][3] More technically, it is an orbit arranged so that it precesses through one complete revolution each year, so it always maintains the same relationship with the Sun. A Sun-synchronous orbit is useful for imaging, reconnaissance satellite, and weather satellites,[4] because every time that the satellite is overhead, the surface illumination angle on the planet underneath it will be the same.
A Sun-synchronous orbit is useful for imaging, reconnaissance satellite, and weather satellites,[4] because every time that the satellite is overhead, the surface illumination angle on the planet underneath it will be nearly the same. This consistent lighting is a useful characteristic for satellites that image the Earth's surface in visible or infrared wavelengths, such as weather and spy satellites; and for other remote-sensing satellites, such as those carrying ocean and atmospheric remote-sensing instruments that require sunlight. For example, a satellite in Sun-synchronous orbit might ascend across the equator twelve times a day each time at approximately 15:00 mean local time.
Special cases of the Sun-synchronous orbit are the noon/midnight orbit, where the local mean solar time of passage for equatorial latitudes is around noon or midnight, and the dawn/dusk orbit, where the local mean solar time of passage for equatorial latitudes is around sunrise or sunset, so that the satellite rides the terminator between day and night. Riding the terminator is useful for active radar satellites, as the satellites' solar panels can always see the Sun, without being shadowed by the Earth. It is also useful for some satellites with passive instruments that need to limit the Sun's influence on the measurements, as it is possible to always point the instruments towards the night side of the Earth. The dawn/dusk orbit has been used for solar-observing scientific satellites such as Yohkoh, TRACE, Hinode and PROBA-2, affording them a nearly continuous view of the Sun.
A Sun-synchronous orbit is achieved by having the osculating orbital plane precess (rotate) approximately one degree eastward each day with respect to the celestial sphere to keep pace with the Earth's movement around the Sun.[5] This precession is achieved by tuning the inclination to the altitude of the orbit (see Technical details) such that Earth's equatorial bulge, which perturbs inclined orbits, causes the orbital plane of the spacecraft to precess with the desired rate. The plane of the orbit is not fixed in space relative to the distant stars, but rotates slowly about the Earth's axis.
Typical Sun-synchronous orbits around Earth are about 600–800 km in altitude, with periods in the 96–100-minute range, and inclinations of around 98°. This is slightly retrograde compared to the direction of Earth's rotation: 0° represents an equatorial orbit, and 90° represents a polar orbit.[5]
Sun-synchronous orbits are possible around other oblate planets, such as Mars. A satellite orbiting a planet such as Venus that is almost spherical will need an outside push to maintain a Sun-synchronous orbit.
In many simulations of orbital entities, orbital state vectors are used, as the inclusion of many bodies for N-body simulation is significantly more straight forward when applied through direct vectors between masses. As an example, earth orbiting artificial satellites in low earth orbit are significantly impacted by earth's oblate nature (often intentionally), but there exists other significant gravitational forces upon them, such as the moon and sun. J2 perturbations can be included into state-vector propagators using their linearized form[6]:
Summed with the acceleration vector of the object in question:
where
and all vectors are in an ECI (Earth-centered inertial) coordinate frame.
The magnitude of gravitational acceleration values at first glance make the magnitude of perturbation acceleration seem negligible. However, precession is still significant over a long enough time:
While state vectors find themselves often arising in large N N-body numerical propagators, basic perturbation estimation for earth-centric two body problems through Keplerian orbital elements requires less setup and provides quick and reasonably accurate results. The angular precession of the righ ascenscion of the ascending node, , per orbit for an Earth orbiting satellite is able to be given by:
where
An orbit will be Sun-synchronous when the precession rate ρ equals the mean motion of the Earth about the Sun, which is 360° per sidereal year (1.99096871×10−7 rad/s), so we must set ΔΩ/T = ρ, where T is the orbital period.
As the orbital period of a spacecraft is
where a is the semi-major axis of the orbit and μ is the standard gravitational parameter of the planet (398600.440 km3/s2 for Earth); as p ≈ a for a circular or almost circular orbit, it follows that
or when ρ is 360° per year,
As an example, for a = 7200 km (the spacecraft about 800 km over the Earth surface) one gets with this formula a Sun-synchronous inclination of 98.696°.
Note that according to this approximation cos i equals −1 when the semi-major axis equals 12352 km, which means that only smaller orbits can be Sun-synchronous. The period can be in the range from 88 minutes for a very low orbit (a = 6554 km, i = 96°) to 3.8 hours (a = 12352 km, but this orbit would be equatorial with i = 180°). A period longer than 3.8 hours may be possible by using an eccentric orbit with p < 12352 km but a > 12352 km.
If one wants a satellite to fly over some given spot on Earth every day at the same hour, it can do between 7 and 16 orbits per day, as shown in the following table. (The table has been calculated assuming the periods given. The orbital period that should be used is actually slightly longer. For instance, a retrograde equatorial orbit that passes over the same spot after 24 hours has a true period about 365/364 ≈ 1.0027 times longer than the time between overpasses. For non-equatorial orbits the factor is closer to 1.)
Orbits per day |
Period (h) | Altitude (km) |
Maximal latitude |
Inclin- ation | |
---|---|---|---|---|---|
16 | 1+1/2 | = 1:30 | 000274 | 83.4° | 096.6° |
15 | 1+3/5 | = 1:36 | 000567 | 82.3° | 097.7° |
14 | 1+5/7 | ≈ 1:43 | 000894 | 81.0° | 099.0° |
13 | 1+11/13 | ≈ 1:51 | 001262 | 79.3° | 100.7° |
12 | 2 | 001681 | 77.0° | 103.0° | |
11 | 2+2/11 | ≈ 2:11 | 002162 | 74.0° | 106.0° |
10 | 2+2/5 | = 2:24 | 002722 | 69.9° | 110.1° |
09 | 2+2/3 | = 2:40 | 003385 | 64.0° | 116.0° |
08 | 3 | 004182 | 54.7° | 125.3° | |
07 | 3+3/7 | ≈ 3:26 | 005165 | 37.9° | 142.1° |
When one says that a Sun-synchronous orbit goes over a spot on the Earth at the same local time each time, this refers to mean solar time, not to apparent solar time. The Sun will not be in exactly the same position in the sky during the course of the year (see Equation of time and Analemma).
Sun-synchronous orbits are mostly selected for Earth observation satellites, with an altitude typically between 600 and 1000 km over the Earth surface. Even if an orbit remains Sun-synchronous, however, other orbital parameters such as argument of periapsis and the orbital eccentricity will evolve, due to higher order perturbations in the Earth's gravitational field, the pressure of sunlight, and other causes. Earth observation satellites, in particular, prefer orbits with constant altitude when passing over the same spot. Careful selection of eccentricity and location of perigee reveals specific combinations where the perturbations largely cancel and hence the orbit is relatively stable – a frozen orbit. The ERS-1, ERS-2 and Envisat of European Space Agency, as well as the MetOp spacecraft of EUMETSAT and RADARSAT-2 of the Canadian Space Agency, are all operated in such Sun-synchronous frozen orbits.[7]
Category:Earth orbits Category:Satellites in low Earth orbit
The simplest implementation of N-body simulations where is a naive propagation of orbiting bodies; naive implying that the only forces acting on the orbiting bodies is the gravitational force which they exert on each other. In object-oriented programming languages, such as C++, some boilerplate code is useful for establishing the fundamental mathematical structures as well as data containers required for propagation; namely state vectors, and thus vectors, and some fundamental object containing this data, as well as the mass of an orbiting body. This method is applicable to other types of N-body simulations as well; a simulation of point masses with charges would use a similar method, however the force would be due to attraction or repulsion by interaction of electric fields. Regardless, acceleration of particle is a result of summed force vectors, divided by the mass of the particle:
An example of a programmatically stable and scalable method for containing kinematic data for a particle is the use of fixed length arrays, which in optimised code allows for easy memory allocation and prediction of consumed resources. In C++, this is trivial:
struct Vector3
{
double e[3] = { 0 };
Vector3() {}
~Vector3() {}
inline Vector3(double e0, double e1, double e2)
{
this->e[0] = e0;
this->e[1] = e1;
this->e[2] = e2;
}
};
struct OrbitalEntity
{
double e[7] = { 0 };
OrbitalEntity() {}
~OrbitalEntity() {}
inline OrbitalEntity(double e0, double e1, double e2, double e3, double e4, double e5, double e6)
{
this->e[0] = e0;
this->e[1] = e1;
this->e[2] = e2;
this->e[3] = e3;
this->e[4] = e4;
this->e[5] = e5;
this->e[6] = e6;
}
};
Note that OrbitalEntity
contains enough room for a state vector, where:
, the projection of the objects position vector in Cartesian space along
, the projection of the objects position vector in Cartesian space along
, the projection of the objects position vector in Cartesian space along
, the projection of the objects velocity vector in Cartesian space along
, the projection of the objects velocity vector in Cartesian space along
, the projection of the objects velocity vector in Cartesian space along
Additionally, OrbitalEntity
contains enough room for a mass value.
Commonly, N-body simulations will be systems based of some type of equations of motion; of these, most will be dependent on some initial configuration to "seed" the simulation. In systems such as those dependent on some gravitational or electric potential, the force on a simulation entity is independent on its velocity. Hence, to seed the forces of the simulation, merely initial positions are needed, but this will not allow propagation- initial velocities are required. Consider a planet orbiting a star- it has no motion, but is subject to gravitational attraction to its host star. As a time progresses, and time steps are added, it will gather velocity according to its acceleration. For a given instant in time, , the resultant acceleration of a body due to its neighbouring masses is independent of its velocity, however, for the time step
, the resulting change in position is significantly different due the propagation's inherent dependency on velocity. In basic propagation mechanisms, such as the symplectic euler method to be used below, the position of an object at
is only dependent on its velocity at
, as the shift in position is calculated via
Without acceleration, is static, however, from the perspective of an observer seeing only position, it will take two time steps to see a change in velocity.
A solar-system-like simulation can be accomplished by taking average distances of planet equivalent point masses from a central star. To keep code simple, a non-rigorous approach based off semi-major axes and mean velocities will be used. Memory space for these bodies must be reserved before the bodies are configured; to allow for scalability, a malloc command may be used:
OrbitalEntity* orbital_entities;
orbital_entities = (OrbitalEntity*)malloc(sizeof(OrbitalEntity) * (9 + N_ASTEROIDS));
orbital_entities[0] = { 0.0,0.0,0.0, 0.0,0.0,0.0, 1.989e30 }; // a star similar to the sun
orbital_entities[1] = { 57.909e9,0.0,0.0, 0.0,47.36e3,0.0, 0.33011e24 }; // a planet similar to mercury
orbital_entities[2] = { 108.209e9,0.0,0.0, 0.0,35.02e3,0.0, 4.8675e24 }; // a planet similar to venus
orbital_entities[3] = { 149.596e9,0.0,0.0, 0.0,29.78e3,0.0, 5.9724e24 }; // a planet similar to earth
orbital_entities[4] = { 227.923e9,0.0,0.0, 0.0,24.07e3,0.0, 0.64171e24 }; // a planet similar to mars
orbital_entities[5] = { 778.570e9,0.0,0.0, 0.0,13e3,0.0, 1898.19e24 }; // a planet similar to jupiter
orbital_entities[6] = { 1433.529e9,0.0,0.0, 0.0,9.68e3,0.0, 568.34e24 }; // a planet similar to saturn
orbital_entities[7] = { 2872.463e9,0.0,0.0, 0.0,6.80e3,0.0, 86.813e24 }; // a planet similar to uranus
orbital_entities[8] = { 4495.060e9,0.0,0.0, 0.0,5.43e3,0.0, 102.413e24 }; // a planet similar to neptune
where N_ASTEROIDS
is a variable which will remain at 0 temporarily, but allows for future inclusion of significant numbers of asteroids, at the users discretion. A critical step for the configuration of simulations is to establish the time ranges of the simulation, to
, as well as the incremental time step
which will progress the simulation forward:
double t_0 = 0;
double t = t_0;
double dt = 86400;
double t_end = 86400 * 365 * 10; // approximately a decade in seconds
The positions and velocities established above are interpreted to be correct for .
The extent of a simulation would logically be for the period where .
An entire simulation can consist of hundreds, thousands, millions, billions, or sometimes trillions of time steps. At the elementary level, each time step (for simulations with particles moving due to forces exerted on the them) involves
The above can implemented quite simply with a while loop which continues while exists in the aforementioned range:
while (t < t_end)
{
for (size_t m1_idx = 0; m1_idx < 9 + N_ASTEROIDS; m1_idx++)
{
Vector3 a_g = { 0,0,0 };
for (size_t m2_idx = 0; m2_idx < 9 + N_ASTEROIDS; m2_idx++)
{
if (m2_idx != m1_idx)
{
Vector3 r_vector;
r_vector.e[0] = orbital_entities[m1_idx].e[0] - orbital_entities[m2_idx].e[0];
r_vector.e[1] = orbital_entities[m1_idx].e[1] - orbital_entities[m2_idx].e[1];
r_vector.e[2] = orbital_entities[m1_idx].e[2] - orbital_entities[m2_idx].e[2];
double r_mag = sqrt(r_vector.e[0] * r_vector.e[0] + r_vector.e[1] * r_vector.e[1] + r_vector.e[2] * r_vector.e[2]);
double acceleration = -1.0 * BIG_G * (orbital_entities[m2_idx].e[6]) / pow(r_mag, 2.0);
Vector3 r_unit_vector = { r_vector.e[0] / r_mag,r_vector.e[1] / r_mag,r_vector.e[2] / r_mag };
a_g.e[0] += acceleration * r_unit_vector.e[0];
a_g.e[1] += acceleration * r_unit_vector.e[1];
a_g.e[2] += acceleration * r_unit_vector.e[2];
}
}
orbital_entities[m1_idx].e[3] += a_g.e[0] * dt;
orbital_entities[m1_idx].e[4] += a_g.e[1] * dt;
orbital_entities[m1_idx].e[5] += a_g.e[2] * dt;
}
for (size_t entity_idx = 0; entity_idx < 9 + N_ASTEROIDS; entity_idx++)
{
orbital_entities[entity_idx].e[0] += orbital_entities[entity_idx].e[3] * dt;
orbital_entities[entity_idx].e[1] += orbital_entities[entity_idx].e[4] * dt;
orbital_entities[entity_idx].e[2] += orbital_entities[entity_idx].e[5] * dt;
}
}
Focusing on the inner four rocky planets in the simulation, the trajectories resulting from the above propagation is shown below:
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.