Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

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. IF these results look good to you, one final thing I want to do is change the eccentricity for the plane of the ecliptic solution (I arbitrarily set it to 0.3=ecc) to see if there is a lower angular rate solution. 






  • No labels