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 firstname.lastname@example.org -81.8637, 41.3735, 256m elevation --- Our Earth is a precious ark of life plowing a dark and empty sea.