Project TLE to Orbiter

[reverend]

Hi All...

I used to have a PHP script which would download TLEs from celestrak and generate an Orbiter Scenario from that data. I lost the work ages ago, but I'm once again interested in re-writing this.

A long time ago I released the Orbiter to TLE utility which would extrapolate the current scenario elements into some makeshift TLEs. This project would attempt to accomplish the reverse so I'd probably call it TLE to Orbiter.

This time, I'm not sure a PHP script would be the right mechanism because I'm considering a few other bits of functionality that would probably just warrant an Orbiter Addon.

Anyone interested in contributing to the project is encouraged to provide feedback.

Here's some of my initial ideas:

• Program should allow user to choose which TLEs to download from celesktrak
• Should support choosing from a list, such as "Stations", or "Visible"
• Should allow entering one or more names of specific objects
• Should save previously chosen station list, allowing to add or remove
• Should allow the user to create a mapping of TLE named objects to particular vessel type, using some default vessel for all unknowns (perhaps the Carina vessel)
• Should be able to write out an Orbiter SCN file including the selected objects
• Should be able to update a running simulation, creating new vessels if necessary if the object does not already exist in the simulation. Update existing vessels

Development will probably start over the next 1 to 2 weeks.

 

[SolarLiner]

It should especially be able to have state propagation algorithms that would end up in a closer-to-reality estimation.

I've made a similar tool and was working on a SGP4/SDP4 implementation when I kinda lost time and motivation. Maybe I'll finally finish working on it.

 

[reverend]

It should especially be able to have state propagation algorithms that would end up in a closer-to-reality estimation

I'm not sure if this is necessary or not? I realize TLEs are not extremely accurate over time, but I would assume that so long as the simulation MJD is within a week or so of the downloaded data, then shouldn't it be pretty accurate?

 

[SolarLiner]

From my implementation on the tool, I can get errors as high as 120 km when testing on the ISS - so no it's not too bad for general use, but it is kinda far off for any specific use.

 

[Messierhunter]

It should especially be able to have state propagation algorithms that would end up in a closer-to-reality estimation.

I've made a similar tool and was working on a SGP4/SDP4 implementation when I kinda lost time and motivation. Maybe I'll finally finish working on it.

I've found this to be true as well. I'm writing an unrelated program for optically tracking satellites IRL with a telescope. Even within just 24 hours from the epoch I get propagation errors that are unacceptably high for accurate tracking when using a 2 body approximation. Out of curiosity, do you know of any SGP4/SDP4 open source code for visual basic, or were you having to implement those algorithms manually?

 

[SolarLiner]

I found implementations in C#, but I'll rather make my own version as I'm using a custom Orbiter framework for scenarios.

 

[GLS]

I have a question for you folks that know about TLEs and Orbiter. A while back I used ScenarioEditorTLE with some 80s TLEs from celestrak, to come up with some launch scenarios for rendezvous (the TLE epoch was as close as possible to the sim date to keep propagation errors down), and it seemed that the orbital plane was not where IMO it should be. So the question is: could there be a need to correct the data due to leap seconds and/or leap years or something else?

 

[Urwumpe]

So the question is: could there be a need to correct the data due to leap seconds and/or leap years or something else?

Yes. Remember, that Orbiter uses MJD as epoch, while the TLE use essentially year and day of year. For converting from Gregorian calendar to MJD (which is solar days since Epoch), you need to include the leap seconds and leap days.

 

[SolarLiner]

Yes. Remember, that Orbiter uses MJD as epoch, while the TLE use essentially year and day of year. For converting from Gregorian calendar to MJD (which is solar days since Epoch), you need to include the leap seconds and leap days.

That is indeed interesting. To get a DateTime object (using a Gregorian calendar) from an MJD, I'm just adding 'MJD days' from Nov. 17th, 1858. But to get an MJD from a DateTime, I'm doing a bunch of maths around:

public static double GetMJD(DateTime dt)
{
    int Y = dt.Year;
    int M = dt.Month;
    int D = dt.Day;

    if (M <= 2) { Y -= 1; M += 12; }

    int A = Y / 100;
    int B = A / 4;
    int C = 2 - A + B;
    int E = (int)Math.Floor(365.25 * (Y + 4716));
    int F = (int)Math.Floor(30.6001 * (M + 1));
    double jd = C + D + E + F - 1524.5;

    double day_remainder = dt.TimeOfDay.TotalDays;

    jd += day_remainder;

    return jd - 2400000.5;
}

(link to source)

This is code I've written copy-pasted some time ago while developing AOSP as an independent project, and never really got to look into it. But I see numbers like 365.25 and 30.6001 being used, which accounts for leap second/days?

 

[GLS]

Yes. Remember, that Orbiter uses MJD as epoch, while the TLE use essentially year and day of year. For converting from Gregorian calendar to MJD (which is solar days since Epoch), you need to include the leap seconds and leap days.

Then I guess the ScenarioEditorTLE doesn't do that conversion correctly.

That is indeed interesting. To get a DateTime object (using a Gregorian calendar) from an MJD, I'm just adding 'MJD days' from Nov. 17th, 1858. But to get an MJD from a DateTime, I'm doing a bunch of maths around:

public static double GetMJD(DateTime dt)
{
    int Y = dt.Year;
    int M = dt.Month;
    int D = dt.Day;

    if (M <= 2) { Y -= 1; M += 12; }

    int A = Y / 100;
    int B = A / 4;
    int C = 2 - A + B;
    int E = (int)Math.Floor(365.25 * (Y + 4716));
    int F = (int)Math.Floor(30.6001 * (M + 1));
    double jd = C + D + E + F - 1524.5;

    double day_remainder = dt.TimeOfDay.TotalDays;

    jd += day_remainder;

    return jd - 2400000.5;
}

(link to source)

This is code I've written copy-pasted some time ago while developing AOSP as an independent project, and never really got to look into it. But I see numbers like 365.25 and 30.6001 being used, which accounts for leap second/days?

The 365.25 is the average days in a year: ((365 * 3) + 366) / 4
I would say the 30.6001 is something about days in a month... of some sort.... :shrug:

 

[boogabooga]

I have a question for you folks that know about TLEs and Orbiter. A while back I used ScenarioEditorTLE with some 80s TLEs from celestrak, to come up with some launch scenarios for rendezvous (the TLE epoch was as close as possible to the sim date to keep propagation errors down), and it seemed that the orbital plane was not where IMO it should be. So the question is: could there be a need to correct the data due to leap seconds and/or leap years or something else?

How bad was it?

ScenarioEditorTLE can be tricky to use. You must PAUSE the simulation, load the TLE, hit Apply, then unpause the simulation. My mistakes early on were due to not following this procedure.

 

[GLS]

How bad was it?

ScenarioEditorTLE can be tricky to use. You must PAUSE the simulation, load the TLE, hit Apply, then unpause the simulation. My mistakes early on were due to not following this procedure.

I can't remember exactly how bad it was, but it seemed to be bad enough that I did something else instead...
I think I tried every thing when loading the TLEs: I always hit pause before I edit my state vectors :lol:, I tried to load closest TLE, both the closest before the sim time and the closest after, and the results were the same, so it was not a bad TLE or something.
I'm way to busy now to try anything (deadline coming up), but I want try using the info Urwumpe provided, as it makes sense.

 

[SolarLiner]

So after thinking about it, I figured that I could convert between MJD and DateTime (in C#) with a simple subtraction. The method I posted above is useful in simple scripts that doesn't have date and time handling features that C# has.

So, theoretically, an MJD is the number of days (integer and fractional) since the 17th of November, 1858. That means that you can simply subtract that from the DateTime you want to convert, and take the total number of days. And the reverse is true; you add your MJD to 11/17/1858 to get your DateTime.

Surprisingly I did the latter but not the former. That is a bit strange, but I believe I was only getting started with C# when I wrote that part of code... Maybe 2, 3 years ago (already!)


So the question now is: Is C#'s DateTime class leap second/day/year aware?
Leap years: Adding a year to 02/28/2016 would make it 02/28/2017, but what about adding a year to 02/29/2016 ?
For C#, the result is 02/28/2017:

static void Main()
{
    DateTime dt = new DateTime(2016,02,29);
    Console.WriteLine(dt.AddYears(1));
}

// Output: 02/28/2017 00:00:00

To me, it seemed surprising: I'd have thought a year after 02/29 would be 03/01. But here it operates by keeping the month intact, and instead taking the last available day of that month.
It behaves similarly when adding months: thus, March 31st + 1 month = April 30th, and not May 1st.

Even internally I'm debating over whether this is the correct - and expected - behavior, or not. But asking relatives and friends, they mostly agree with my views that 03/31 + a month = 05/01.

Leap seconds: Generally, leap seconds go unnoticed by most people. It's only us the nerds that have to deal with them
Seriously though, .NET doesn't implement leap seconds. This means that July 1st, 2012 - June 30th, 2012 = 24 hours, and not 24 hours and 1 second. Which can cause problems here.

But that would only be problematic if a leap second were to be in the time between the TLE epoch and the scenario run date, other times the time span would go unaffected.



I wonder how Orbiter handles state propagation internally. If you change the date using the Scenario Editor, you have the choice to maintain current geographic positions, maintain elements, or "propagate along orbit". Does that last one means Orbiter uses a SGP/SDP technique or is it 'simple' "on-rails" propagation a la KSP?

 

[reverend]

Weird... In my original scripts, I never experienced any major discrepancies as described. Perhaps it was just proper handling of the data. I remember making comparisons between Orbiter and Orbitron and positions were pretty close to matching.

I have used SGP4/SDP4 in the past, and I did find a .NET library for it at one time, but since we aren't trying to draw anything on a surface map, I didn't think that it would have much value for the purpose of this plugin.

I'll try to get a bitbucket repository setup this weekend to get started. I don't even have a GUI mockup yet.