# What are the problems that need to be taken in consideration when trying to find planetary position by using jpl ephemerides?

I'm currently trying to determine the position of the sun and the moon from jpl ephemeris DE200 which is referred to the dynamical equator and equinox of 2000 and uses tdb time. I am using the j2000 system ECI.The things that trouble me are the following:

1.Is the moon position given with respect to Earth or with respect to the barycenter? Also when we find the sun position by using the earth-moon barycenter position and lunar coordinate , will the sun position be with respect to Earth?

2.If I'm using UTC time , how exactly to obtain the TDB or TAi, since it's oscillating?( After that I want to obtain the JD for TDB)

3.If I'm using J2000 ECI coordinate system , do I need to take in acount the effect of nutation and precession? And how to do that?

– uhoh
Jun 13 '18 at 2:12
• The soft that I'm trying to build is in matlab. The ideea is that I want to plot the orbit of 2 satellites and to assure that they don't collide over a period of time. For that I'm integrating their position with respect to the following perturbations: j2 , drag, srp, third body(moon,sun). The reason why I use DE200 is that I can understand it a little better than DE4** beacuse , for DE4** I know that its being used icrf which I don't understand how to convert in ECI and I can't find too much info or explanation of how to do it. Jun 13 '18 at 10:19
• Great, that's a really helpful clarification!
– uhoh
Jun 13 '18 at 11:15
• Duplicate of: astronomy.stackexchange.com/questions/26617/…
– user7073
Jun 13 '18 at 16:11

# Moon position

The Moon position is given with respect to the Earth Moon barycenter, whose NAIF ID is 3. Note that the barycenter of the Earth-Moon system is very close to the center of the Earth (otherwise it wouldn't have taken humans that long to figure out where tides came from). You should be able to list all the bodies of a given BSP file by looking at the beginning of the file. If you're running Linux or MacOS, open a terminal and inspect that file with od -vc de438.bsp | less. It'll take a few seconds for your eyes to figure out what's going on, but then it's somewhat human readable.

# Time management

The times in these kernels is given in "ephemeris time." In all honesty, I forget what the ephemeris time is pegged against. This SPK tutorial mentions that the "Leapsecond file" .LSK allows a conversion between ET and UTC, so I suspect that ephemeris time could be UTC without the leap seconds. If you just need a list of leap seconds (which is what you get in the naif000xx.lsk files), I would recommend using the IETF life from here, as they are the ones who announce leap seconds a few months in advance. If by luck you're using a programming language called Rust, you might want to check the library called hifitime which already includes Modified Julian date and UTC date management with leap seconds (full disclosure, I authored it). (Since it's Rust, it should be reasonably easy to use this library from C or C++, and a bit less easy to use it in Python).

# ECI frame

ECI stands for Earth Centered Inertial frame. As an inertial frame (i.e. it has no acceleration), nutation and precession do not apply. The ECEF frame (Earth Centered Earth Fixed) however, does need to handle Greenwich apparent solar time, nutation, precession and polar motion. As per the IAU2000 framework, the "ECI" frame has been renamed CRS for "Celestial reference system" and the ECEF frame is now the TRS for "terrestrial reference system." The ECEF/TRS frame is only needed if you need spherical harmonics or some specific geodetic parameters (the geodetic latitude, longitude and height are with respect to the reference ellipsoid and therefore only require knowledge of the flattening coefficient of the body). For example, if you wish to compute the visibility of a vehicle in the ECI frame from the point of view of an observer in the ECEF frame, then you would need to include all the parameters of said frame. Finally note that the IAU2000 framework allows for decently easy computation of the Greenwich apparent sideral time, precession and nutation, but the polar motion is not predictable and as such is published regularly by BIPM (Bureau International des Poids et Mesures). That said, the polar motion is incredibly small (I think the axis changes by 0.002 degrees per century), so you likely do not need to take that into consideration for most short- to medium-term computations. On the topic of the IAU2000 reference frame transformation, I recommend reading the open-access IERS Technical Note No. 29 by McCarthy and Capitaine (whose full title is : Practical Consequences of Resolution B1.6 "IAU2000 Precession-Nutation Model," Resolution B1.7 "Definition of Celestial Intermediate Pole," and Resolution B1.8 "Definition and Use of Celestial and Terrestrial Ephemeris Origin").

# DE200 kernel

As mentioned by uhoh in the comment above, DE200 is quite a few years older, and I would encourage you to use a more recent planetary ephemeris kernel. For example, DE438 was released last Monday (04 June 2018), cf. ftp://ssd.jpl.nasa.gov/pub/eph/planets/ascii/de438/README.txt . Moreover, if you only need dates from January 1900 to December 2100, you should probably use the de438s.bsp (cf. ftp://ssd.jpl.nasa.gov/pub/eph/planets/bsp/ ).

• – uhoh
Jun 13 '18 at 4:24
• @ChrisR I'm trying to integrate the position of 2 satelllites and to assure that they won't collide. The positions and velocities for integration are given in ECI . So,from what you've said , if I 'm only interested on the positions of this 2 satellites with respect to ECI , I don't need to take account of precession , nutation, polar motion, since ECI is an inertial frame.Is that a correct interpretation? Jun 13 '18 at 18:16
• Yes, that's correct Jun 13 '18 at 23:08