PyEphem: What is the epoch attribute for EarthSatellite

Question

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?

Answer 1

By setting the epoch time in both STK and my model to the beginning of the experiment, here 2014/04/26 16:00:00, I don't have the shift in the results anymore.

I do understand that the error on the satellite position grows proportionally with the difference between the epoch of the mean anomaly and the time of analysis, but I don't understand why this error leads to a shift in the results and not in completely different results.

Note that the conversion between elevation and off nadir angle here is quite good, provided that the value h + R, distance between the satellite and the Earth center (range + Earth_radius), is corrected by the altitude on Earth, that is h + R + target_altitude.

I mark my question as solved, since I obtained the desired results, but an explanation on the shift effect is welcomed!

I take this opportunity to thank Brandon Rhodes for the great work on PyEphem.