General Question Orbiter and TLE data

[Marijn]

I am working on an application to create scenario files. One of the features I like to implemend is to have the orbital elements of the ISS updated on the fly with the most recent data and include this data in the scenatio files.

So I am learning about TLE data sets now. This material is new to me and I am quite confused by all these numbers. I am trying to figure out how to select the correct data on the web and how to process this data so it can be used in Orbiter.

If I am not mistaken, Orbiter offers two formats to define an orbit. A list of orbital elements and state vectors. The manual states that the ELEMENTS parameter in the ship entries is an alternative to RPOS and RVEL.

My first question is: Why two formats? In what situation will you choose either one? I thought state vectors are to be used for atmospheric conditions, but now I am not sure. It seems state vectors are preferred because I've actually never seen an ELEMENTS list in an Orbiter scenario. But why?

Are TLE data sets ready to be put into Orbiter's ELEMENTS list? Inclination and eccentricity obviously are, but it's not clear to me if that is true for the other params. The description of TLE on Wikipedia and the parameter names in the Orbiter manual are quite different. If these are indeed compaitble, why would anyone bother to convert them to state vectors? If not, why does Orbiter use a different format and how can these values be converted from TLE to Orbiter then?

I am breaking my head over this. Any help is greatly appreciated.

 

[martins]

There is a tool called TLE Scenario Generator by solarliner on Orbithangar. Maybe this already does what you need? Otherwise, it comes with sources, so you should be able to extract relevant information.

 

[Marijn]

Thanks for your suggestion. I'll have a look. The plan is to create a webservice which outputs the ship parameters with the most recent data so I (and others if they're interested) can merge it into a scenario file. Initially for the current time only, but I might persist the data so it can be used for scenario's in the past.

What do you recommend for such an application? State vectors or elements?

 

[martins]

What do you recommend for such an application? State vectors or elements?

They should be equivalent, so whatever's easier to generate.

 

[Marijn]

This is the idea. Inclination and eccentricity are simple. But now the other params. I was not aware of the complexity. But I'll try to finish this.

https://script.googleusercontent.co...TCqnGIg&lib=MhLpUAJCQYvpwq3kig-KFV9VEECnZo2W5

 

[Marijn]

Ok, slowly getting there. My scripts fetches a tle from https://spaceflight.nasa.gov/realdata/sightings/SSapplications/Post/JavaSSOP/orbit/ISS/SVPOST.html and formats it as an Orbiter ship list entry:

ISS:ProjectAlpha_ISS
  STATUS Orbiting Earth
  ELEMENTS 6783741.003478244, 0.0003697, 51.6391, 118.1943, 303.1658, 175.1083, 58410.70838163  
  AROT 00.00 00.00 00.00
  PRPLEVEL 0:1.000
  IDS 0:588 100 1:586 100 2:584 100 3:582 100 4:580 100
  NAVFREQ 0 0
  XPDR 466
END

DEBUG MODE
ISS
1 25544U 98067A   18292.70838163  .00016717  00000-0  10270-3 0  9038
2 25544  51.6391 118.1943 0003697 303.1658  56.9140 15.53825292 17875

Epoch: 2018-10-19T17:00:04.173Z

ORBITAL ELEMENTS
semi-major axis: 6783741.003478244 m
eccentricity: 0.0003697
inclination:  51.6391
longitude of ascending node: 118.1943
argument of periapsis: 303.1658
mean anomoly:  56.9140
true anomoly: 56.94950414036255
true longitude: 118.30960414037874
periapsis: 6781233.054429654 m
apoapsis: 6786248.952526836 m
period: 5560.4706941531695 s

STATE VECTORS
x-component of the position vector: -3211879.9371549455 m
y-component of the position vector: 5973632.934191057 m
z-component of the position vector: 10702.483783653006 m
x-component of the velocity vector: -4187.499350571676 m/s
y-component of the velocity vector: -2259.592454519227 m/s
z-component of the velocity vector: 6011.813604460368 m/s

But it's not working properly yet. When I open this in Orbiter the location is way off.

For the Mean longitude at epoch (eps) I am taking the sum of LAN and the Mean anomaly (118.1943 + 56.9140 = 175.1083). The ScenarioEditor manual says something like that on page 5. But I don't think that is right by looking at the screenshot on the same page. It would not add up.

If that's indeed the problem, how can the eps be calculated?

 

[GLS]

ELEMENTS 6783741.003478244, 0.0003697, 51.6391, 118.1943, 303.1658, 175.1083, 58410.70838163

I could be wrong, but I don't remember commas being used/needed between the numbers...

 

[Marijn]

I could be wrong, but I don't remember commas being used/needed between the numbers...

In the File Format manual on p30, the values are separated with commas. I'll give it a try, thanks.

edit
Nope.. tried it with this one. It's a different orbit but still completely off..
ELEMENTS 6783762.448532366 0.0004031 51.6363 114.0299 311.5402 162.5703 58411.54446346

 

[Donamy]

Did you put a semicolon in front of the date ?

 

[martins]

But it's not working properly yet. When I open this in Orbiter the location is way off.

When you say it's not working, do you mean that the values in the Orbit MFD differ from what you set in the scenario file? They work for me (using space-separated values without commas.) Please note that the elements in the scenario refer to the ecliptic frame. If your TLE elements refer to the equatorial frame, you will need to map the elements accordingly.

 

[boogabooga]

Perhaps I can help.

It seems state vectors are preferred because I've actually never seen an ELEMENTS list in an Orbiter scenario. But why?

Because Orbiter itself saves scenarios using state vectors, and ELEMENTS are only used for hand-made scenarios (and not many know how to do this)?

Are TLE data sets ready to be put into Orbiter's ELEMENTS list?

Actually, no, not really. I recommend that you visit Celestrak for information. See this:
https://celestrak.com/columns/v04n05/#FAQ05

Actually, this is one of the most common questions I get asked. Usually, the user has data in some other format that they want to use in a program that uses two-line element sets or they have two-line element set data that they want to use in their favorite satellite-tracking program. The simple answer is: Just don't do it! Here's why.

The common misconception is that the two-line element sets are simply a format for standard data. After all, if both the two-line element set format and Format X have an eccentricity term, it should be a simple matter of substituting the value. Other terms could simply be interchanged by using a straightforward mathematical transformation (such as the relationship between mean motion and semi-major axis). Isn't there a program to automatically handle this conversion? Unfortunately, it's not quite that simple.

The elements in the two-line element sets are mean elements calculated to fit a set of observations using a specific model—the SGP4/SDP4 orbital model. Just as you shouldn't expect the arithmetic and geometric means of a set of data to have the same value, you shouldn't expect mean elements from different element sets—calculated using different orbital models—to have the same value. The short answer is that you cannot simply reformat the data unless you are willing to accept predictions with unpredictable errors.

To martins's recommendation, the solarliner's TLE tool is not the only one in town. Take a look at Ajaja's: [ame="https://www.orbithangar.com/searchid.php?ID=2617"]Scenario Editor TLE[/ame]

It uses proper SGP4/SDP4 orbital models and calculates state vectors, as I believe is the output of those models. I've used it (in Orbiter 2010) to model real ISS passes over my area, and I would say that the results were very accurate. But, you need to check if it works in Orbiter2016.

 

[Marijn]

do you mean that the values in the Orbit MFD differ from what you set in the scenario file? .. Please note that the elements in the scenario refer to the ecliptic frame. If your TLE elements refer to the equatorial frame, you will need to map the elements accordingly.

I launch the scenario paused and then go straight to the scn editor to inspect the values.

Indeed, the values should be adjusted for the ecliptic frame. Thanks. I'll look in to the 5th value as well. And use whitespace.

---------- Post added at 11:24 AM ---------- Previous post was at 10:46 AM ----------

Because Orbiter itself saves scenarios using state vectors, and ELEMENTS are only used for hand-made scenarios (and not many know how to do this)?

Actually, I am doing this because I want to get rid off manual editing and automatically generate scenario files with serverside javascript, so it runs on the web and I can access resources on the web like a fresh tle for the ISS. So I can't do anything with Windows applications.

The simple answer is: Just don't do it! Here's why.

It's probably my lack of understanding, but at this time I don't see why translating a tle into an Orbiter Element List would be a bad idea. The simulation time and tle epoch will be quite close, not much more than a day. I expect accurate results in that condition.

---------- Post added at 11:27 AM ---------- Previous post was at 11:24 AM ----------

Did you put a semicolon in front of the date ?

To commend out that line? That's just a debug line which is not part of the ship entry.

 

[Marijn]

Ok. I am happy with the calculations which populate the ELEMENTS list now. I did inspect the work of SolarLiner on GitHub and compared the results to Ajaja's eq_to_ecl console app which I found on avsim.net. Here's the result:
https://script.google.com/macros/s/AKfycbxJweWn9kqD1hQ3i0hKa681l4jMbeENIIaEm20B5ty6JHrTvP_g/exec

I am using this tle source now: https://api.wheretheiss.at/v1/satellites/25544/tles?format=text

Tle's have a number. I found tle's on the web which, apart from the checksum, have the same number but different values. Is this to be expected? Or could this be mistakes by the publishers of those sites? I would expect them to auto-increment. But they don't seem to do so.

The official NASA site, https://spaceflight.nasa.gov/realdata/sightings/SSapplications/Post/JavaSSOP/orbit/ISS/SVPOST.html, offers a lot more tle's and other information. I like to know how the 'best' tle should be selected and what other information on this site could be useful.

Next is AROT and VROT. I want to calculate the values to represent it's actual orientation and angular velocity. Is there an easy way to do this? Thing is, my insights in the math are rather limited. I just eyeball things and test it as long as it takes to arrive at an expected value. So I might overlook something obvious.. Any help is much appreciated.

 

[GLS]

Next is AROT and VROT. I want to calculate the values to represent it's actual orientation and angular velocity. Is there an easy way to do this? Thing is, my insights in the math are rather limited. I just eyeball things and test it as long as it takes to arrive at an expected value. So I might overlook something obvious.. Any help is much appreciated.

If you have the state vectors, calculating an orientation that puts the ISS in its usual attitude should be possible. The vertical direction is the easy one, it comes from length( pos.x, pos.y, pos.z ). The side parts gets more math intensive... sadly I don't have the time to calculate that ATM.

BTW: the calculation would have to be done with an Earth-relative state vector, and then the orientation would need to be converted to the "global orientation", which I think is what AROT and VROT use.