Problem going from orbital elements to long/lat

[Messierhunter]

I'm working on a spreadsheet to calculate the approximate longitude, latitude, and altitude of a given satellite (in this case, the Hubble Space Telescope) based on the two line elements. I've checked my work with Orbiter and while I'm close I'm still a bit off somewhere between "true longitude" and "geocentric longitude." Latitude matches up perfectly with orbiter, no problems there. So does the true anomaly and true longitude according to the scenario editor's orbital elements editing function, it's a perfect match with my calculations. Geocentric or "geographic" longitude is the tricky bit, it's consistently just a few degrees off the way I'm doing it and I can't seem to figure out why. There must be some factor I'm overlooking, and it appears larger than I would expect precession, nutation or other minor effects to be. I couldn't find a formula for it so I tried to figure it out on my own which is no doubt where I'm making a mistake and overlooking some factor. I expressed it simply as the true longitude minus greenwich mean sidereal time - switching to greenwich sideral time (not mean sidereal time) doesn't seem to make a dent in the difference which is about 2-3 degrees different from what orbiter is telling me despite the simulation being paused at startup and the same time being entered on the spreadsheet. Any thoughts on what I'm doing wrong?

 

[kamaz]

Have you looked at this:

https://github.com/shashwatak/satellite-js

 

[BrianJ]

Hi,
just a couple of thoughts (before I'm properly awake this morning!)
1. I'm pretty sure Orbiter still uses CT (Coordinated Time) rather than UTC, there's about 1 minute difference. Don't know what time-stamp your TLE's use, but that might be a factor. See this thread for CT/UTC discussion.

2. Have you verified that Orbiter's Earth rotation model is accurate for the time in question? I remember having an issue with it a long time ago in previous Orbiter versions, but it has been much improved since then.

Good luck with your TLE->Lat/Long calculations!
Brian

 

[Messierhunter]

Hi,
just a couple of thoughts (before I'm properly awake this morning!)
1. I'm pretty sure Orbiter still uses CT (Coordinated Time) rather than UTC, there's about 1 minute difference. Don't know what time-stamp your TLE's use, but that might be a factor. See this thread for CT/UTC discussion.

2. Have you verified that Orbiter's Earth rotation model is accurate for the time in question? I remember having an issue with it a long time ago in previous Orbiter versions, but it has been much improved since then.

Good luck with your TLE->Lat/Long calculations!
Brian

Thanks, I tried every iteration of adding or subtracting leap seconds or delta T, no dice, that doesn't seem to be my problem. The problem is equivalent to an offset of about 14 seconds at the epoch of the orbital elements, but does not appear to be consistent - in some cases it gets me very close to the right answer if I add the seconds, in other cases it gets me very close to the right answer if I subtract the seconds. It didn't stray too much from orbiter's result though over the time frame I checked (a few days of interest around the epoch of the elements). I'm checking with orbiter 2006, but I don't think that's the problem; separate software I have to track satellites agrees with Orbiter to within a few hundredths of a degree. I feel like the fact that it's consistently about a 14 second difference is key, it feels like there's something wrong in my calculations to do with the longitude due to the oblateness of the earth perhaps? I've calculated geodetic latitude but I've read that geodetic longitude is the same as geocentric so oblateness shouldn't be an issue for the latter then right?

*new hint to the problem; the longitude calculated by my spreadsheet seems to agree very closely with Orbiter as I cross the equator. I'm thinking it has to be something to do with oblateness I just don't know how to correct for it in longitude.


---------- Post added at 11:38 AM ---------- Previous post was at 11:37 AM ----------

Have you looked at this:

https://github.com/shashwatak/satellite-js

Very helpful I think, but I'm having trouble parsing the variables he has there. They seem to be referring to the latitude or local sidereal time of the "observer" in some cases for calculating the ECI for the satellite. There is no observer in this case, other than the satellite itself. Not sure how to reconcile that.

---------- Post added at 12:34 PM ---------- Previous post was at 11:38 AM ----------

Actually I think I now see the problem, I just have to work out the math to fix it; true longitude is of course a quantity that assumes no inclination, so you can't get terrestrial longitude just by factoring in GMST. I have to take Hubble's inclination into account in factoring the longitude.

---------- Post added at 05:22 PM ---------- Previous post was at 12:34 PM ----------

Alright, solved it! It was indeed the inclination problem. I had to realize that the component of the longitude of the ascending node is in the plane of the celestial equator and does not need to be adjusted for the inclination of Hubble's orbit, but the argument of periapsis and true anomaly are "out of plane" and do need to be adjusted. All three elements comprise true latitude but you need to separate them back out to fix the problem by only rotating the latter two elements. The spreadsheet now agrees with Orbiter in predicting Hubble's position to within a few hundredths of a degree in longitude.

 

[Messierhunter]

Here's the resulting spreadsheet and the application I used it for. Thanks for your help guys.
https://www.youtube.com/watch?v=UXzRai-Z_CA