Satellite Tracking with Propeller (cont)

Well, I am going to set this aside for a little while and do other things as I am a bit tired of the project.  I calculated a perigee pass for AO-51 at .02 km.  Hmmm...  I am thinking that at less than 70 feet, that might be a little low, eh?  :)  Ah well...  Obviously I have work to do.  But, for now this one is shelved and I will come back to it when more refreshed.

Satellite Tracking with Propeller (cont.)

Good progress today.  I am actually down to the place where I am debugging the SGP4 implementation.  I have initially hardwired the observer's position to be the lat/lon for my home QTH.  I also do not handle deep space objects or deal with geostationary objects yet.

All the pre-calc work is done and the SGP4 calculations have completed.  The post processing code has some problems that I am working on, but now it is time for sleep.

Satellite Tracking with Propeller

Work continues to build a SGP4 object implementation on propeller.  Getting the mathematical expressions correct is at best painful.  I have been converting a C language implementation into spin little by little.  I have written some utilities to assist with that conversion and progress is more quick now and less error prone (I hope).  I use the FPU utilities provided to convert the math expressions into FPU assembly language and then run through my utility to convert that to spin.

I could really use some insights into how to validate the results.  I can of course always compare results against the version I am converting from, but who is to say that it is correct?  Ideally there would be a standard test kep set and a standard observation location that would create known results that could be validated.

The SGP4/SDP4 specification does speak to this a bit, but my understanding of it is not yet adequate to evaluate.  If anyone has insights here, I could use some advice.

Parsing Keplerian Elements with uM-FPU

Today I played around with my new floating point coprocessor.  I decided to build a bit of code that would parse a two line Keplerian Elements.

I have built an object that will parse this data out into its constituent values using the coprocessor.  The output from this test looks like this:

  AO-51
1 28375U 04025K   12068.46137681 +.00000200 +00000-0 +72724-4 0 02147
2 28375 098.1341 038.4897 0084202 346.8009 013.0981 14.40905486404267

satName:   AO-51
idesg:     04025K
epoch:     12068.46
xndt2o:    1.9999999E-6
xndd6o:    0.0
bstar:     7.2723999E-5
xincl:     98.134101
xnodeo:    8.4897
eo:        0.0084201993
omegao:    346.8009
xmo:       13.098098
xno:       14.409052
catnr:     2837
wlset:     0.0
revnum:    40426

It is interesting to note the effect of a 32 bit floating point value used to hold this data.  Since only 7.2 significant digits are available, values like epoch have been truncated to fit in 32 bits.  I parse out 12068.46 for a value that should be 12068.46137681.

At best only an approximation is going to be possible with 32 bits for SGP4 calculations, which given the beamwidth of my antennas is likely to be sufficient.  In any event is is an interesting chip to work with.

With 128 floating point registers available and the ability to store user-defined functions on-chip, I am hopeful that the calculations can be done completely on-chip.  In an ideal world, I would pass in the kep of the satellite of interest as a string and would get back azimuth, elevation, aquisition/loss of signal times, etc.  In a more ideal world, I would get back only the necessary information to move an az/el rotor system to the correct point in space.  We shall see how it goes...