2

I am using PyEphem to predict satellite passage over a point in a constellation design project.

I would answer my question by it is orbit epoch but I would like to be sure. Here is an example that rose the question at first:

What works

Here is the result I get with PyEphem (With only one date per access), compared with STK (see below to see how I obtained it):

2014/4/27 03:37:59
2014/4/28 03:15:59
2014/4/29 02:53:59
2014/4/30 02:31:59
2014/5/1 02:09:59
2014/5/2 01:47:59
2014/5/5 00:42:09
2014/5/6 00:20:09
2014/5/6 23:58:09
2014/5/7 23:36:19
2014/5/8 23:14:19
2014/5/9 22:52:19
2014/5/10 22:30:19

27 Apr 2014 03:43:08.427
28 Apr 2014 03:20:44.792
29 Apr 2014 02:58:21.163
30 Apr 2014 02:35:57.546
1 May 2014 02:13:33.952
2 May 2014 01:51:10.384
3 May 2014 01:28:46.848
4 May 2014 01:06:23.358
5 May 2014 00:43:59.92
6 May 2014 00:21:36.571
6 May 2014 23:59:13.310
7 May 2014 23:36:50.173
8 May 2014 23:14:27.216
9 May 2014 22:52:04.550
10 May 2014 22:29:42.571

Set up in for PyEphem

import numpy as np
import ephem, math


sat = ephem.EarthSatellite()
sat._e = 1.4538821258014423e-09
sat._M = 136.92
sat._ap = 0.0
sat._raan = 199.662
sma = 6878.13631
sat._n = 86400  * np.sqrt(398600.4418/sma**3) / (2*np.pi)
sat._epoch = '2014/02/14 13:00:00'
sat._inc = 46.8
satellite = sat
target = ephem.Observer()
target.lon, target.lat = '6.9', '46.8'
tr = ephem.Date('2014/04/26 16:00:00')
tend = ephem.Date('2014/05/13 16:00:00')
satellite.compute(target)
ephemeris = []

while tr < tend:
    target.date = tr
    satellite.compute(target)
    alt = satellite.alt
    h = satellite.range / 1000
    tr = ephem.Date(tr +  10.0*ephem.second)
    if alt <=0: 
        tr = ephem.Date(tr + 60.0 * 10 * ephem.second)
        continue
    Ona = np.arctan(6378 * np.cos(alt)/(h + 6378 * np.sin(alt))) # Target ONA

    alt = np.degrees(alt)
    if np.fabs(math.degrees(Ona)) > 5 :continue
        ephemeris.append(tr)
print ephemeris

Here is the STK setup (the dates for the experiment are the same):STK satellite setup

So that is almost perfect, even if I don't understand why there is this one hour difference between STK and PyEphem epoch, I suspect something with the UTCG thing.

What does not

Now, If I increase the inclination to 49, I get these results (PyEphem first, Stk then):

2014/5/12 00:01:19
2014/5/12 23:39:29

5 May 2014 02:45:25.831
6 May 2014 02:23:14.987
7 May 2014 02:01:06.514
8 May 2014 01:38:58.566
9 May 2014 01:16:50.962
10 May 2014 00:54:43.643
11 May 2014 00:32:36.592
12 May 2014 00:10:29.850
12 May 2014 23:48:23.509

By setting the epoch to 2014/02/14 11:35:00, I get the expected results:

2014/5/5 02:43:59
2014/5/6 02:22:09
2014/5/7 02:00:19
2014/5/8 01:38:29
2014/5/9 01:16:39
2014/5/9 01:16:49
2014/5/10 00:54:49
2014/5/10 00:54:59
2014/5/11 00:33:09
2014/5/12 00:11:19
2014/5/12 23:49:29

Since The first example is giving satisfactory results, I would not say that my model caused the difference but it could. So my question is, what do I do wrong with this epoch time?

4

1 回答 1

1

通过将 STK 和我的模型中的纪元时间设置为实验的开始，在这里2014/04/26 16:00:00，我不再有结果的变化。

我确实理解卫星位置的误差与平均异常时期和分析时间之间的差异成比例增长，但我不明白为什么这个误差会导致结果发生变化而不是完全不同的结果.

请注意，这里的仰角和偏离天底角之间的转换非常好，前提是h + R卫星与地球中心之间的距离 ( range + Earth_radius) 的值由地球上的高度校正，即h + R + target_altitude。

我将我的问题标记为已解决，因为我获得了预期的结果，但欢迎对移位效果进行解释！

我借此机会感谢 Brandon Rhodes 在 PyEphem 上所做的出色工作。

于 2014-05-01T12:47:24.513 回答