Celestia Forums

I know that a number of people (me included) have been wanting a way to get improved satellite orbits into Celestia for a long time, using TLEs and the SGP4 model to do it. Here's an outline of how to do it, /without/ having to implement the SGP4 model in Celestia. This should work fine with any recent version of Celestia, with or without Spice. What you do need is the NAIF spice toolkit.

Note that I have not done this, I've just seen from the docs how it would work. I'm not giving a cookbook here, so you'll need to read the docs and have a clue.

1) Build a Spice kernel from TLE

Using the toolkit program MKSPK, build a type 10 SPK from your desired TLE. This program will implement the SGP4 model. You will need the 'geophysical.ker' file from the NAIF website, as well as the most recent leapseconds kernel (currently naif0008.tls). I have not tested if Celestia can directly use a type 10 kernel, but I would assume it should have no problems. Doesn't really matter though, because of...

2) Generate xyz data from Spice kernel

Using the toolkit program SPKDIFF, generate a 'difference dump report' between the satellite and body 399, which is the center of the earth. You will need to specify the same kernel twice (e.g. SPKDIFF -b1 399 -b2 <sat_id> -t <output.xyz> kernel.bsp kernel.bsp). This will give you an output file in the format '<jul secs past J2000> <delx> <dely> <delz> <delvx> <delvy> <delvz>', with distances in kilometers. You can change the time format, but how to specify it is documented only in the source code .

To put this in a format Celestia will like you need to convert the time to a Julian date, and drop the last three fields. Should be simple to do with a spreadsheet.

Enjoy!

A quick reading of the MKSPK documentation did not find any mention of taking gravitational effects into account. As a result, I don't understand how this would produce a better result than Grant Hutchison's TLE to SSC conversion spreadsheet if you only have a single TLE.

http://www.lepp.cornell.edu/~seb/celest ... ets.html#3

Wouldn't you need to provide a long sequence of TLEs for any changes in the orbit to be shown? How good would the interpolation be between them?

You're right, the MKSPK documentation doesn't mention SPG at all. Unfortunately, NAIF seems to suck at documenting things in obvious places...

From the intro to 'geophysical.ker':

The mkspk application needs the data in this kernel to produce
type 10 SPK segments based upon the two-line element sets available
from NORAD/SPACETRACK. The data applies ONLY to the Two Line Element
sets and only to the Spacetrack 3 SGP/SDP implementations included
in the SPICE library [1]. Mkspk copies this data to the constants
partition of the type 10 segment, so the user has no need for the kernel
after creation of the corresponding SPK.

Reference 1 there is referring to Spacetrack Report #3, which is where NORAD documented the details of the SGP4 model.

As far as accuracy is concerned, it's kinda anyone's guess. STR3 (the report they refer to) is the only place details of the model were publically released, and it's from 1980. NORAD specifically says you have to use the exact model they use to get accurate results, but they have changed the model since, and not released the details. Pretty much everyone who 'claims' to implement SGP4 has reverse-engineered later TLEs to try to discover how the model has changed, and everyone has done it differently. Here's a link to a recent article discussing the subject, including graphs showing the difference between different inplementations.http://celestrak.com/publications/AIAA/2006-6753/

I have no idea about interpolation between different TLEs. Again, I haven't played with this, I just noticed that it should be possible. I'll probably start playing with this after I finish my current project (creating a SPK from DE414 for the solar system).

I think the most reliable method for generating a xyz for a propelled spacecraft (ISS, for example) would be to use a TLE from immediately after each propulsive maneuver to generate a SPK for the span till the next maneuver, merge the kernels, and then create an xyz for the entire thing. Spice allows you to have multiple segments for the same object in one kernel as long as there is no overlap, but spkmerge will let you prioritize multiple kernels and will remove overlaps.