Re: Is this addition to line0 OK?

Phil Rogers (progers@mindspring.com)
Thu, 17 Jun 1999 23:21:40 -0400

Jay Respler wrote:
>Rick von Glahn wrote:
>>I believe the values are in square meters. My requestor so indicates and I'm
>>sure he is right but, oddly enough the "Satellite Situation Report" hasn't a
>>legend indicating the measurement units for any data. But, it all seems to
>>be, what else??, metric.
>
>You're right. No reports describe RCS. However, I do have a letter from
>SpaceCom stating that RCS is in square meters. Unfortunately, there
>are also a few other descriptive indicators that do not show up in SSR.

Both of you are correct. This can be plainly seen through a quick look
at the values listed. I took such a look at a small sampling of the
values in the latest copy of the SSR last night (no time to post then...
laundry took precedence) and both the lack of negative values and the
magnitude of the existing values indicates that they are in units of
sq mt rather than dbsm. Otherwise some of the values listed, if
taken to represent manmade space objects, could could only describe
objects of a size seen only in the world of Star Trek.

>No reports describe RCS.

It is described in the pages of the Radar Handbook by Skolnik which gets
extremely deep past the second chapter where the radar equation is
introduced. There is a mini-Skolnik too that is much more readable.

Actually I was specifically looking at values for the two primary RCS
calibration satellites whose RCS characteristics are very well known.
Object 5398 is a 1 meter sphere (0 dbsm) and with a value of 0.85 listed
indicates these are units of sq mt. Object 6212 is a long thin rod
tumbling with a period of roughly 3 minutes. (In essence, 6212 is the rf
equivalent of the Iridium flashers in the visual world). As such it
serves as a dipole, the simplest form of an antenna which reradiates a
signal presenting a lobing pattern characteristic of a dipole which
reaches a peak RCS value of 26.4 dbsm as the rod becomes perpendicular
to the line between it and the site observing it. This is equivalent to
a rather large observed size of 500 sq mt from an otherwise
comparatively small target. The value listed in the SSR for 6212 is only
1.6 sq mt or so. This indicates additionally that the values listed are
average RCS values as opposed to peak values which is what I would
have expected (peak that is).

Someone mentioned that columns 40-53 in line zero are already used for
apogee and perigee values. This is fine, but is this really necessary
considering that precise values of apogee and perigee are easily
computed from the elset itself. Perhaps someone needed this in order to
manually select specific elsets from a list of elsets which met certain
orbital criteria. Even this could still be done by looking at the mean
motion and eccentricity fields of the elset. Could someone explain what
these additional values are actually used for? Perhaps somebody happened
to need these values and wanted someone else to do the computations for
them or perhaps existing programs do not output these values. I am in
the Mac world and write my own orbital software (which does indeed
output this info) so I don't really have that much reason to keep up with
what is output on the Wintel side of the fence.

In any event, there is so much space remaining on line zero that it
should pose no problem for anybody. If nobody gets too greedy for more
columns than they really need, then there is room for 5 more parameters
to be encoded into line zero. Even if this space is squandered, there is
room enough for 4 more parameters. This is of course in term of
parameters after column 40. There are two ways to approach this problem.
The RCS values could be encoded into the columns following the
apogee/perigee info. Alternatively it could be encoded in the same space
and a semi-intelligent parser could be used to distinguish between the
two types of content based on columns that would be separators (spaces)
in one format but digits in other formats. Obviously the first approach
is always best and would cause the least number of programs to break.
I would suggest that three groups 1) Rick von Glahn, 2)the originator of
the apogee/perigee format and 3) the users of that specific info get
together to discuss if it is really needed at all considering its
existence in the primary elset parameters already. Once that item is
resolved then you can decide whether to encode RCS starting at column 40
or at column 53. Someone else had a valid point that cross section could
be computed from the dimensions that already exist on line zero. On one
hand I tend to agree with this, but on the other hand there are many
cases where an object's geometry often has more to do with RCS than its
actual size so the computed values might be altogether different from
what is measured.

Rick, I have one more suggestion for you once you decide where to put
the information. I think you will probably decide on using sq mt as your
units rather than dbsm, but you should probably truncate the values in
SSR to one and no more than two decimal places. I don't know where such
precise data came from unless it is theoretical data but it certainly is
not measurable to that degree and would only waste two columns which
might be better used in the future for other purposes. I could go into
detail to you (off the list) if you are interested but will try to
minimize the radar talk here. In reality, dbsm would be better units for
use on the elsets since the log operation compresses the data and
requires fewer digits than sq mt. I could easily take the current SSR
contents and reprocess it to a list of dbsm vs obj number for you to
use, but that leaves open the question of what to do with future new
elsets unless you choose to implement that computation in your own
program. This is why I said I think that you will probably want to use
sq mt.

Somebody suggested adding an elset line 4. Please, I hope that you were
half joking. Elsets originally started out as 5 card elsets, but this
included many excessive parameters and duplicate info. This was back in
the days when transmission was via 75 baud TTY (still is this way in
many places) and storage was limited to 6 MB on a 7 foot high RAD file
(electronically addressable disk with 512 heads) for sites that were
lucky and on paper tape for the others. As a result the fat was culled
from the 5 card elsets to give the two card elsets that we know now.
Have we now come full circle back to the doorstep of the 4 and 5 card
elsets once again?

Phil Rogers
progers@mindspring.com
********