[Server-sky] NORAD TLE's (4)

[Keith Lofstrom]

On Mon, Apr 06, 2009 at 04:41:48PM -0700, Tony Rick wrote:
> Keith,
> 
> I'm using a c++ package available
> here<http://www.zeptomoby.com/satellites/>to extract the orbit
> description data
> from the TLEs (originally for MSVC++, modified by me for linux/g++).  All
> the values you mentioned are made available as instance methods in one
> of the defined classes.   I know you have a penchant for Perl.  I just went
> this way when I thought we were gonna be looking at billions of data points.
>
> I put some code on the server-sky wiki at
> ServerSky->OrbitsV01->EarthOrbits->OrbitSoftware->SxP4TestPatch.
> I have an app that reads 3-line TLEs, feeds them to the orbit
> extractor, and uses the result to predict the ascending node altitude.
> I need to beef it up to  include the descending node.  I have been
> retrieving the all-data sets from Space-Track for about two weeks.
> 
> What concerns me is that any orbit defined by a single observation
> is a prediction subject to error.  It is too much to hope for that
> all objects for which data is available will have observations close
> to either node, but it is reasonable to expect that some will, and
> the probability should go up with the number of observations.
> 
> - tony

Cool.  I've spent the last couple of hours playing with libgd, which
has both Perl and c++ instantiations.  I've been using it with c++ .
It can produce animated gifs.  I have been using the MathGL library,
also via Perl, but I can use that directly in c++ as well.  The main
thing that C++ is weak on compared to Perl is string matching and text
processing, but if you already have that problem conquered, then we
are golden.

So let's focus on C++.  If we do any web apps, we can feed the data
through an "armored" Perl wrapper, but we probably want to do big
computations in C++ anyway.  C++ will probably port better to CUDA
when we need it. 

Again, we are not worried about absolute accuracy.  The data will
surely change by deployment time, but the shape of the problem will
stay the same.  The lower perigee orbits will drop in apogee, the
high inclination orbits will precess, but they will certainly do
this slowly enough that we can move server-sats around to stay out
of the way.  For now, I am concerned with getting an overall idea
of how this works, then making slides and animations, and presenting 
the alpha version on April 15.

A customer taught me that there is a time to innovate, and a time
to polish.  We are in innovation mode now;  we will make plenty of
errors, and we will (in time) identify them, and find mitigations
for them.  Now is pre-marketing.  We don't have to achieve high
precision right now (though we must develop an error budget in the
future).  So let's not worry too much about noisy 3-TLE data.

BTW, once we are down to a few dozen names for satellites, we can
just Google for them to learn about their status.  That worked for
the 5 or 6 test cases I tried.

Keith


-- 
Keith Lofstrom          keithl at keithl.com         Voice (503)-520-1993
KLIC --- Keith Lofstrom Integrated Circuits --- "Your Ideas in Silicon"
Design Contracting in Bipolar and CMOS - Analog, Digital, and Scan ICs