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...
No comments:
Post a Comment