1) glad to know there is a plane-of-the-ecliptic solution. Whew.
a. Yay!
2) I think, from looking at the nice animated images, that STK has a bug in the precession rate needed to have the semimajor axis precess once per year. In fact it seems to be the confusion between a solar day and a sidereal day, and is a perpetual source of consternation! The point is that if the Earth goes around the sun once, even if it has zero spin angular momentum and isn’t “spinning”, you still get sunup and sundown but it takes a year for that to go through a cycle. In other words, it looks like the STK model drops out of synch by one Earth rotation over a year.
a. I hope this is the case, but if it is, it would seem to be a huge oversight on STK's part; I'll take your word for it. For it to be off that much in the gif seems wrong. To note, there is a distinction made here in STK (Satellites - Propagators - Two-Body, J2 Perturbation & J4 Perturbation (agi.com)):
- J2Perturbation includes the point mass effect as well as the dominant effect of the asymmetry in the gravitational field (i.e. the J2 term in the gravity field, representing North/South hemisphere oblateness); J4 additionally considers the next most important oblateness effects (i.e., the J2^2 and J4 terms in addition to J2). None of these propagators model atmospheric drag, solar radiation pressure or third body gravity; they only account for a few terms of a full gravity field model.
- These propagators are often used in early studies (where vehicle data is usually unavailable for producing more accurate ephemeris) to perform trending analysis: J2 Perturbation is often used for short analyses (weeks) and J4Perturbation often for long analyses (months, years).
Even when i implemented this, it doesn't look like it makes much of a difference when I simulate it with J4.
3) For the access times I think you need to add the constraint that the satellite be in the Earth's shadow? Is that simple to do?
a. Yup! I did it below.
I was able to find a feature in STK that allows me to filter such that Access is only achieved and computed when the satellite is in the Umbra or Penumbra (it is called lighting in STK: Constraints - Sun (agi.com)). Following this discovery and implementation, I recomputed access for the following three orbits, all of which met the sun-synched criteria from last week.
Auxiliary things:
- There is also a cool constraint feature in STK that lets you ensure you only compute access for orbits that are above a certain angular rate. As for whether you can see the angular rate, I have not been able to find that property on STK yet.
- There is also a cool constraint allowing you to limit it to times above a certain elevation angle:
- From STK(Introduction to STK (agi.com)): "You know that when you are on the ground trying to see something in space the lower you look along the horizon the more atmosphere you have to look through and the better the chance that something will be in the way. To help avoid the elevation angle problem, STK allows you to put an elevation angle constraint on a ground-based location. A good typical minimum elevation is 6-8 degrees, but it can be more depending on the area, the surrounding terrain, and even buildings."
- There are also a list of other constraints you can impose on Access times (a full list is here:Constraints - Basic (agi.com))
- Notable ones include elevation angle, elevation rate, altitude, and line of sight.
ORBIT 1
a = 15100 km, e = 0.55, inc = 169 deg
I still filtered for evenings from 17:30 to 6:30, so that still cut off some times.
As you can see, the times for access are now much more realistic (on the order of 10 minutes). We still could not see Antarctica, and we can barely see Greenland. With this new constraint, there is a gap in times in Cambridge in April and October, and a gap in times in July in Chile. Access numbers are noted below for this.
ORBIT 2
Next, I did a = 12000 km, e = 0.3, inc = 169 deg
There is no access for Greenland or for Antarctica. However, there is quite good access for Cambridge and Chile.
ORBIT 3
Next, I did a = 12000 km, e = 0.3, inc = 23 deg
No Antarctica access, per usual. This is the solution we want, but it performs very poorly for some months of the year, sadly. That isn't to say we can't launch two satellites to cover dead zones of the other, though? Plus, since we've seen that times for access haven't gone down for the other satellites when we implement the penumbra/umbra constraint, I'd say it doesn't even matter that we don't put it in the plane of the ecliptic (would you agree)?
So I'm glad that issue was resolved.
One final thing I decided to do was optimize for the smallest angular rate given some fixed inclination = 157.5 deg (23.5 deg giving the same solution), by varying the value of a first then varying the value of eccentricity. This is because the orbit solution for a = 12000 km, e = 0.3, inc = 23 deg was an unoptimized solution; when I wrote my own code for it, I was now able to optimize for the a and ecc to give the smallest angular rate. The plots for these results are shown below. (These solutions are implemented with the constraint that the perigee value should be at least 400 km above Earth).
The two solutions to take from this are:
eccentricity solution: (the ang_rate is off by a factor of 1000 because of the way units work in PoliAstro, the actual value is 87.22 arcsec/sec)
semi-major solution:
I must say that the two solutions look very similar to each other, with very similar eccentricities and semi major axes; this is expected, as I just parameterize one of the values. So, it will just be said that the solution is:
a = 14600, ecc = 0.532, inc = 157.5 or inc = 23.5
In the gif, you can see the two orbits from this optimized solutions, the only difference being the inclination.
The orange orbit is the a = 14600, ecc = 0.532, inc = 157.5 solution
The blue orbit is the a = 14600, ecc = 0.532, inc = 23.5 solution
The purple orbit is the a = 15100, ecc = 0.55 inc = 169 solution from earlier for reference
