re: the Iridium format

Richard Clark (rclark@LPL.Arizona.EDU)
Tue, 23 Sep 97 06:54:12 MST

Recently written by: a183231@nlevdpsb.snads.philips.nl (Bram Dorreman)
 
>I can live with the Iridium flare observation report format as
>it has now been defined by Ron Lee. Yet I have some remarks on
>it.
...
>3. I always try to determine the Right ascension and declination
>   of the middle of the flare as I am accustomed to refer to the
>   starry sky (using 7x50 binoculars). From these coordinates I
>   have to convert into Azimuth and declination. I use Redshift 2
>   for that. Elaborate.
>   If a flare occurs I do not use my binoculars, I would destroy
>   my eyes.
>4. Azimuth and elevation can be calculated from observer's
>   location and recent TLE. So in fact it needs not be reported.
>   Fortunately my prediction program (written by Patrick Wils, also
>   from Belgium) outputs the Right Ascension and declination and
>   Azimuth and elevation of the culmination point.
>5. The same is true for Sun's location: it can be calculated.
>   I use Redshift 2 for it. But it takes some time.

Regarding the coordinate system used for making the report, I take it you
are just pointing out an alternative and not suggesting change? I suspect
that most people will have an easier time reporting in az-el, especially
for recording visual (usually naked eye) observations in the field. But
yes, in the process of reducing the observations a single coordinate system
will be needed. Possibly RA-Dec, possibly a cone and clock angle system.

As far as the possibility of omitting fields that can be determined after
the fact from known observer coordinates and TLEs... many prediction
programs make it very awkward to have multiple TLEs (different epochs) for
the same satellite. Inadvertant use of an old (or too new) TLE could give
a significant along track error for the instant of the flare. By all means
the location of the flare should be retained in the report. If, for
whatever reason, something must be removed it should likely be the max
az-el of the pass.

>6. My prediction program uses the angle Sun-Satellite-observer.
>   My reports (until now) give the interpolation from observed
>   flare location w.r.t. predicted locations at the sky.
>   The Skymap convention looks more logical to me.

Yes, standards. We need more standards! That's the trouble with simple
problems, they often have simple solutions so people just solve it on the
fly and don't bother to look up the 'proper' way to do it. Sign
conventions for longitude or hour angle anybody??? I know I've been guilty
of this many times!

But what I was going to say...  As useful as the phase angle is, it may be
safer to use the sun and flare az-el and calculate the illumination angle
from that. In any case, the phase angle doesn't fully define the 3
dimensional geometry of a flare.

Incidently for anyone who is curious, the Sun-Observer-Sat version of the
phase angle is:

cos(ph) = cos(z1) * cos(z2) + sin(z1) * sin(z2) * cos(del_az)

where z1 and z2 are Zenith distances (90 - elevation) of sun and satellite
and del_az is the differnece in azimuth (or 360 - del_az). The Sun-Sat-Obs
phase angle is 180 - this. (since the Sat-Sun-Obs angle is essentially 0)

And now for an oldie but a goodie...

We've had the COSPAR vs NORAD discussion here several times. Like it or
not, here in the USA the NORAD # is as entrenched as miles and inches and
gallons. And NORAD *does* have a certain amount of klout in the satellite
tracking would. I think that for many of us the main problem with the
COSPAR id is that it isn't a fixed format. Part of it has a variable
length field that should be either left or right padded with either '0' or
'-' or ' ', or maybe some other character.

>9. I am very pleased that you have accepted the COSPAR-id of the
>   satellites. It has always been used by all sources of predictions
>   (USA, Europe, former Soviet Union) and was officially agreed upon

Nope! In the amateur world, and much non international government use it's
NORAD# over here. There are exceptions of course but mostly we use NORAD.

>   in the early days of the space era. It has been defined to avoid
>   confusion about a satellite's name. I was "educated" with COSPAR-
>   id's. All positional observations were always sent in with the
>   COSPAR-id as the indication of which satellite the observation
>   concerned. If you frequently use them, you don't know better.
>   I can tell you the COSPAR-id's of most bright satellites by heart.
>   I don't know any NORAD number of them except Mir: 16609. Just as
>   with KJ (Kurt Jonckheere).
>   The advantage of Iridium's is that the COSPAR-id of them looks
>   the same for the same launch:
>       97- 20 A..E, 97-30 A..G, 97-34 A..E, 97-43 A..E, 97-51 A..G
>   A side effect is that you know which have been launched by Delta
>   and which by Proton. You even can guess the COSPAR-id's of these
>   rockets, if they were catalogued.

The same can be said about NORAD# if that's what your used to. And if you
have TLEs for the whole set it's trivial to tell the Delta groups from the
Protons.

>   I must admit that 5-digit-numbers can be processed easier than
>   those complicated COSPAR-id's.

Especially if you want to be able to deal with all known flavors of
COSPAR. Of course, truth be told, I *do* recognize the advantages of
COSPAR and agree with most of them and would welcome a switch to it if the
format ever got nailed down. (And maybe the USA could switch to the SI
while we're at it:-) But the NORAD# seems quite solidly established here,
and all the software I use works with either NORAD# or common name, and
so...

Speaking of 80 characters/line... Sorry to get a little off topic by
bringing up an 'internet 101' sort of issue but the problem that inspires
(irritates:-) me to point it out just occurred in the very message that
defines a reporting format that can be affected by it. Don't mean to be
picking on Ron, but his message includes an example of the problem and
observations of Iridium flares can definitely be affected by it in a way
that can require fairly tedeous manual 'repairs'.

>> From Ron's latest Iridium format post >>>>
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.2 (16)
Date: Mon, 22 Sep 1997 20:29:47
To: SeeSat-L@cds.plasma.mpe-garching.mpg.de
From: Ron Lee <ronlee@pcisys.net>
Subject: Iridium Format...Final Version
Mime-Version: 1.0

NORAD   date       time   Dir  aI eI  aM  eM  aS   eS Phs  Dur Mag Obs  COSPAR
xxxxx  yy-mm-dd  hh:mm:ss  x  xxx xx  xxx xx  xxx -xx xxx  tt  Sn  III
yy-nnn p

xxxxx  97-08-21  20:27:00  S  028 30  xxx xx  324 -13 Unk  20  -1   BG
97-043 A

        10        20        30        40        50        60        70
  80
123456789 123456789 123456789 123456789 123456789 123456789 123456789
123456789 
<<<< end quote

Notice something wrong with some of these lines? I use a vanilla unix mail
program and a pure ASCII editor, neither of which does any hand holdiing
or checking at all so this is a literal quote of parts of the message as I
received it.

Some mail programs, or perhaps their embedded editors, have a tendency to
butcher lines. Mozilla (packaged with Netscape) is by far the worst. (or
at least one of the most commonly used, but I think it is also one of the
worst because it does other things that irritate me but I won't list them
here) *All Windows versions* of it by default break lines around column
70. Any line breaks entered by the user or already present in material
pasted into the composition window remain in the outgoing message in
addition to the line breaks that it adds to any 'long' lines. There is *no
indication* that these line breaks are being added. From the appearance of
the message in the composition window the user would think he is sending
out an attractive well formatted message. In the case of Mozilla this can
be overridden (so far as I am aware) only on a single message basis. The
default setting, and the limiting value for line lengths can't be
altered. Mozilla is the only one I have personal experience with although
I have noticed this feature is also present on a few other mailers and is
one of those things that is becomming ever more common with the 'user
friendly' applications that have become so common of late. (Hi B1ff!-) We
all need to make sure we understand the (mis)behavior of our mailers and
what our carefully crafted work looks like once it leaves the environment
in which it was created.

Having said that I should add that I have noticed very few mozillisms
(like the broken lines or atteched HTML duplicates of messages) right here
on SesSat-L compared to some other forums I read.

Richard Clark
rclark@lpl.arizona.edu