Welcome, courtesy, OIG

Walter Nissen (dk058@cleveland.freenet.edu)
Thu, 18 Jun 1998 18:11:27 -0400 (EDT) 

Welcome to all the new subscribers to SeeSat-L.  Thanks for posting your 
introductory messages. 
 
The value and quality of postings to SeeSat-L are a constant source of 
satisfaction and delight. 
 
 
Please note that SeeSat-L is a mailing list and not a newsgroup.  Behavior 
that is ordinary and caring in a newsgroup, such as quoting an entire 
message, is perceived as burdensome and careless in SeeSat-L.  People who 
haven't received earlier messages can readily retrieve them from the 
hypermail archive.  Usually an effective quote is only about 2 lines, 
though longer quotes of older or convoluted material may sometimes be 
necessary. 
 
Most questions that new subscribers to SeeSat-L may have are answered on 
the VSOHP, http://www2.satellite.eu.org/satintro.html, the 2 in 
that address being optional, or below the VSOHP, especially in the FAQ or 
the SeeSat-L archive. 
 
 
3432P@VM1.CC.NPS.NAVY.MIL (Craig Cholar) writes: 
 
> I update it several times a week using an automated script mechanism 
> I wrote that takes the output from Iridflar and creates the HTML. 
 
Let me point out that long ago I suggested that this type of service, 
remote computing, becomes more and more economical as processor and 
storage costs drop relative to communication costs.  Communicating vast 
numbers of elsets for local computation will eventually cost the 
distributors more than doing the computation for the prospective user and 
communicating the, usually brief, results.  Not to mention the cost for 
the recipients (I have a vast number of old elsets for objects I've never 
seen, but I have to plow thru them anyway as I search for a goodie).  How 
much is the drop in processor and storage cost relative to communications 
cost?  Substantial.  As an extreme, but universal, example; at the 1984 
divestiture, a local phone line cost about $10/month.  It still does. 
Meanwhile processor and storage cost is down to maybe 1 or 2% of the 1984 
cost. 
 
Put this in personal terms.  Would it be more economical for you to pipe a 
slew of elsets via a wireless communications service, like Iridium, from 
your homebase machine to your laptop for computation there, or to do the 
selection of appropriate objects at the base machine and communicate the 
few selected elsets to the laptop for the display computation? 
 
Let me also point out again that the information content of elsets in the 
TLE format is sparse.  The vast majority of a TLE is blank space, zeroes, 
ASCII padding, insignificant digits, and other "useless" fluff.  It is a 
rare elset which contains as many as 30 bytes of actual data. 
 
The useful content of new elsets is even smaller, as usually only a few 
bits change from day to day, or even month to month.  As a not-so-extreme 
example, the catalog number can range from 1 (Sputnik 1 r/b; they did 
rockets first in those days, which has its own logic, if you think about 
it) to 65535 (it's taken 40 years to arrive at 25000) in a 2-byte, 16-bit, 
integer.  In a TLE, the catalog number occupies 12 bytes for itself, plus 
9 bytes for the COSPAR ID and who knows how many bytes for the vulgar name 
(16??), neither of which adds even 1 more bit of information, not to 
mention the potential for trouble.  That's a density of about 5% data, 95% 
fluff. 
 
I haven't actually implemented an intelligent transmission system for 
elset updating, but I would guess that a weekly update to the 230K Molczan 
elset file would fit in 4K bytes, maybe 8K. 
 
A pretty well thought out proposal appeared in SeeSat-L a while back, 
suggesting that the TLE format should be expanded to include a variety of 
additional information.  At an even lower density.  My own thoughts have 
run toward compressing it for transmission, if not necessarily for 
display. 
 
As another nuance, you may wish to consider that few updates provide any 
useful information whatever.  Because people don't know if a significant 
update is needed, they routinely obtain 10 or 20 times, I would guess, as 
many elsets as they really need.  Many elsets could be updated every month 
or two, or more, with no loss of useful information. 
 
Altogether, the distribution of elsets is an exercise in tremendous 
overkill. 
 
But when you need, say, 2 or 4 bits of new data, you really need them. 
Without them, you spend lots of time looking into blank sky and miss 
lots of OBS. 
 
 
Cheers. 
 
Walter Nissen                   dk058@cleveland.freenet.edu 
-81.8637, 41.3735, 256m elevation

---

Our Earth is a precious ark of life plowing a dark and empty sea.