Return-path: X-Andrew-Authenticated-as: 7997;andrew.cmu.edu;Ted Anderson Received: from beak.andrew.cmu.edu via trymail for +dist+/afs/andrew.cmu.edu/usr11/tm2b/space/space.dl@andrew.cmu.edu (->+dist+/afs/andrew.cmu.edu/usr11/tm2b/space/space.dl) (->ota+space.digests) ID ; Wed, 21 Mar 90 03:12:46 -0500 (EST) Message-ID: Reply-To: space+@Andrew.CMU.EDU From: space-request+@Andrew.CMU.EDU To: space+@Andrew.CMU.EDU Date: Wed, 21 Mar 90 03:12:09 -0500 (EST) Subject: SPACE Digest V11 #168 SPACE Digest Volume 11 : Issue 168 Today's Topics: Re: What was Challenger really up to? Death in Space (was Re: Shuttle Escapes) Re: Death in Space (was Re: Shuttle Escapes) Re: Another SR-71 comes to NASA Ames-Dryden Landsat-5 Emergency UoSAT-OSCAR-14 & UoSAT-OSCAR-15 Status Report 15-Mar-90 Re: Resolving Power of Hubble Space Telescope Re: Challenger Report question ---------------------------------------------------------------------- Date: 20 Mar 90 00:19:26 GMT From: swrinde!cs.utexas.edu!news-server.csri.toronto.edu!utgpu!utzoo!henry@ucsd.edu (Henry Spencer) Subject: Re: What was Challenger really up to? In article <5189@jarthur.Claremont.EDU> jokim@jarthur.Claremont.EDU (John H. Kim) writes: >the sonar image that turned out to be the Challenger crew cabin. It >was just a bump on the bottom--there were no details that would let >you say "yes, this is the crew cabin," it could just as easily have >turned out to be a rock... All the more so because the Cape has been a test range for decades, and the bottom offshore is littered with man-made debris of all kinds. There was at least one promising-looking false alarm that was really a crashed helicopter. -- MSDOS, abbrev: Maybe SomeDay | Henry Spencer at U of Toronto Zoology an Operating System. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu ------------------------------ Date: 20 Mar 90 03:04:15 GMT From: bfmny0!tneff@uunet.uu.net (Tom Neff) Subject: Death in Space (was Re: Shuttle Escapes) In article shafer@skipper.dfrf.nasa.gov (Mary Shafer (OFV)) writes: >It's my belief, however, that nothing is absolutely safe, particularly >flight. If informed people wish to assume the risk, that's their >right and their decision. Let them pay to train themselves for spaceflight, and this might be true. In the meantime, while the public foots the bills, I think we should try to make our human components profoundly recoverable. It's nice that they're willing to die and all that, but we don't really pay them to make such decisions. > Nobody is forced to fly in the Shuttle, >nobody is forced to fly in fighters or bombers or airliners. We're >all volunteers. As long as we really understand the risk we're taking, >what's the problem? The problem is that killing people in space is a waste of time. This is not some game. Every death in space is a horrific setback to the program. Nobody, not even the crew members themselves, have the right to 'accept' such a risk unquestioningly. Their personal stake is only a small part of the whole. It's worth remembering that, almost without exception, past flight crew deaths could have been avoided but for political expediency in one form or another. The roll of "space martyrs" is just that. The myth of "inevitable" crew losses needs re-examined. The real "inevitability" seems to be that every few years, political pressure will build to the point where things get rushed, until something fatal is overlooked. When I look at the crammed do-or-die schedule for NASA's Space Station, my blood runs cold. "My God, , when do you want me to launch? 2010?" -- Perestroika: could \O\ Tom Neff it happen here? \O\ uunet.uu.net!bfmny0!tneff ------------------------------ Date: 20 Mar 90 05:24:47 GMT From: skipper!shafer@ames.arc.nasa.gov (Mary Shafer (OFV)) Subject: Re: Death in Space (was Re: Shuttle Escapes) But, no matter what you do, it will never be perfectly, 100% risk-free to fly. Or to drive, or to walk, or to do anything. One of our pilots here died when he waited too long to eject from a spinning aircraft. He was wrong; he should have jumped out earlier. He failed in his duty, IMO. One of our engineers was walking his dog when a car driven by a kid jumped the curb and hit him. Only his leg was broken. But he walks his dog again, now. Who know better than him the danger? There's no way to make life perfectly safe; you can't get out of it alive. You can't even predict every danger. How can you guard against a hazard you can't even conceive of? I agree that the days of "kick the tires and light the fires" are gone, but insisting on perfect safety is the single most reliable way of killing an aerospace project. I've been on both sides of the FRR (Flight Readiness Review) process for a number of aeronautical projects. Experienced engineers try to think of everything that can go wrong. But airplanes can still surprise the best team. I've had to sign a form, certifying that to the best of my knowledge everything that we're going to do on a flight is safe. I've never seriously asked myself "What will I say to the AIB (Accident Investigation Board)" because once one starts on that, the form will never be signed, the flight will never be flown, and the research will never be done. But I have asked myself "Have I told everybody exactly what we're going to do and what the _known_ risks are and are we agreed that these risks are acceptable" and when I can answer that "yes" I sign the form. That also answers the question of what I'd say to the AIB. I'm not talking about abstract theories here, I'm talking about test pilots that I've known for decades. Believe me, I _know_ exactly what the consequences of a mistake on my part could mean. The reminders are all around me: Edwards AFB--killed in the XB-49, Lilly Ave--NASA pilot killed in a crash, Love Rd--I _saw_ his burning F-4 auger into the lakebed, with him in it. But once I've done my best, like everybody else on the team, it's time to go fly the airplane. Insisting on perfect safety is for people who don't have the balls to live in the real world. -- Mary Shafer shafer@skipper.dfrf.nasa.gov or ames!skipper.dfrf.nasa.gov!shafer NASA Ames Dryden Flight Research Facility, Edwards, CA Of course I don't speak for NASA ------------------------------ Date: 20 Mar 90 15:56:43 GMT From: voder!dtg.nsc.com!alan@ucbvax.Berkeley.EDU (Alan Hepburn) Subject: Re: Another SR-71 comes to NASA Ames-Dryden In article <1990Mar20.024341.10435@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >In article shafer@skipper.dfrf.nasa.gov (Mary Shafer (OFV)) writes: >>And everybody troops back into the building on this beautiful spring >>day, exhilerated by the flyby. > >Followed by the sound of several thousand people elsewhere on the net >turning green with jealousy... :-[ >-- I second the emotion! How about convincing the powers that be to do the same thing up here by NASA-Ames? Since my place of employment is just a stone's throw from the blue cube (okay, a small stone thrown by a very strong person!), I'm sure a low level pass like that would impress a lot of people! Just imagine the fun it would be to fly the SR71 around the country, turning onto final at each local airport, firing the burners, and blasting the windows out of the terminals! (Sigh...) -- ------------------------------------------------------------------------------- Alan Hepburn Omne ignotum pro magnifico mail: alan@blenheim.nsc.com My opinions are just that: opinions ------------------------------------------------------------------------------- ------------------------------ Date: 20 Mar 90 18:25:59 GMT From: cs.utexas.edu!usc!elroy.jpl.nasa.gov!jato!mars.jpl.nasa.gov!baalke@tut.cis.ohio-state.edu (Ron Baalke) Subject: Landsat-5 Emergency Landsat-5 Emergency The Landsat operations people had declared a Landsat-5 spacecraft emergency and requested support from a JPL 34 meter tracking station in Goldstone, California. The reason for the emergency was an apparent loss of attitude control system on the spacecraft. Ron Baalke | baalke@mars.jpl.nasa.gov Jet Propulsion Lab M/S 301-355 | baalke@jems.jpl.nasa.gov 4800 Oak Grove Dr. | Pasadena, CA 91109 | ------------------------------ Date: 18 Mar 90 20:13:40 GMT From: att!tsdiag!ka2qhd!kd2bd@ucbvax.Berkeley.EDU (John Magliacane) Subject: UoSAT-OSCAR-14 & UoSAT-OSCAR-15 Status Report 15-Mar-90 UOSAT-OSCAR-14 and UOSAT-OSCAR-15 REPORT #007 15-Mar-90 ** UoSAT-OSCAR-14 ** Attitude Control and Stabilization Manueuvers prior to gravity gradient stabilization have taken somewhat longer than expected. The most recent delays were caused by the need to add digital filters to the attitude determination software to remove unwanted noise from the magnetometer readings. The filters have been installed, and a new version of the FORTH diary will be uploaded soon. High Speed Downlink Tests The UoSAT Command Station has been conducting limited experiments with the 9600 bits/second Frequency Shift Keyed (FSK) downlink on UO-14. These tests have been quite successful, doubling the highest digital link speed previously used on any OSCAR satellite (4800 bps is routinely used on UO-11). Data transmitted during these tests has been either asynchronous telemetry from the Very Large Scale Integrated telemetry system or continuous streams of 1 bits (no data at all). The "stuck ones" tests are very useful because of the scramblers in the modulator and demodulator. The 1's are scrambled and transmitted as pseudorandom data over the RF link. The groundstation demodulators then lock onto this data, descramble it, and reproduce the continuous 1's. Any 0's in the demodulated output data stream are caused by bit errors on the communication link, and the link bit error rate (BER) can be calculated from the frequency of such transitions. BER tests are to be scheduled into the DIARY in aid of those trying to test their FSK receive system. The first scheduled tests were scheduled for the morning passes over the East Coast of the US on 15 March. - de G0/K8KA. ** UoSAT-OSCAR-15 ** The team at Stanford has succeeded in detecting local oscillator (LO) leakage from the UO-15 command receiver. The weak signals were first detected on March 10 and then again on March 11. Roy Long, leading the Stanford Research Institute team on the recovery attempt, said that there is no dbt that the signal comes from UoSAT-15. It is weaker than the corresponding signal on UoSAT-14, as expected from prelaunch measurements. Each UoSAT carries three receivers: a fixed-frequency command receiver and two communications receivers with switchable frequency. Efforts will now concen- trate on monitoring one of the switchable frequency receivers. If one of these receivers is heard, commands will then be sent to change the receiver frequency, which should cause a corresponding change in the LO frequency. Observation of changed LO frequency will confirm that the satellite's command system is basically healthy. The work at Stanford is very time consuming, requiring azimuth and elevation control of the huge Stanford 150 diameter dish to within tight limits. Data are collected for only a few seconds, followed by hours of post-processing. -- AMPR : KD2BD @ NN2Z (Neptune, NJ) UUCP : ucbvax!rutgers!petsd!tsdiag!ka2qhd!kd2bd "For every problem, there is one solution which is simple, neat and wrong." -- H.L. Mencken ------------------------------ Date: 19 Mar 90 14:02:21 GMT From: unmvax!nmtsun!nraoaoc@ucbvax.Berkeley.EDU (Daniel Briggs) Subject: Re: Resolving Power of Hubble Space Telescope In article <1990Mar19.082655.19642@metro.ucc.su.OZ.AU> bedding@extro (Tim Bedding) writes: >Try an article by M. Mueller and G. Weigelt in Astronomy and Astrophysics >(Vol. 175, p. 312, 1987) called "High-resolution astronomical imaging >by roll deconvolution of Space Telescope data". Thanks for the pointer, Tim. I dug out the article, and it cleared several points up. I don't really have time to do a complete summary from the ground up, but the basic idea is really pretty simple if you know Fourier theory. It also pointed out to me a few of the prejudices that I carry regarding imaging problems. A couple of the off-the-cuff assumptions I made earlier really don't translate into the optical domain so well. Here are a few not terrible coherent thoughts on the topic: 1) I asked why the HST people didn't do a "generic" CLEAN algorithm, as I am used to in radio work. The most important reason why not, is that the PSF of a non-diffraction limited telescope (i.e. one limited by imperfections in the optics, or by the instantaineous atmosphere), is *not* sharply peaked. The speckle pattern is just that, a modest number of blobby shapes that may all have roughly the same amplitude. [If anyone is wondering, the PSF is the image that you see when you look at a perfect point source. Consider that an extended astronomical object such as a galaxy is really made up of a whole lot of point sources right next to each other. Now take every one of these point sources, multiply them by the aforementioned arbitrarily blobby shape, and sum them all together. This is the mess that a deconvolution algorithm is trying to sort out.] The generic CLEANs depend on being able to tell which part of an image is real, and fix the pixels in descending order of brightness. If an intermediate brightness pixel was really just an artifact from a bright one, by the time the algorithm gets around to trying to fix it, the artifact has already been removed and is never confused with a real source. This idea is absolutely dependent on having a strongly peaked PSF, so that you know which pixel to start with. In the radio (aperture synthesis) case, we are trying to remove the sidelobes of the beam (PSF) caused by the fact that our telescope is mostly empty space. In the case of a filled aperture telescope, the side lobes of the PSF are small enough that they aren't a major worry. What is a worry is imperfections in the reflecting surface. Radio people deal with the analagous problems by a process know as self-calibration. Optical people use an image deconvolution algorithm such as this roll-deconvolution. I guess that the moral of the story is that while we use very similar tools in our image deconvolution tasks, they are actually used in slightly different places in the data paths. 2) As to what the roll deconvolution algorith actually is, I'm afraid that I may have to drop into jargon a bit. Basically, they are just using simple inverse filtering to do the deconvolution for each image and point spread function. (The PSF is in fact a measured quantity, and may even be obtainable from a foreground star on the same frame as the program object.) The two images are used to resolve the zero problem with the inverse filter. For this kind of process, note the following relationships i1(x,y) = o(x,y) * p1(x,y) and i2(x,y) = o(x,y) * p2(x,y) where i1 & i2 are the two images, o is the object in question, and p1 & p2 are the PSF of the Hubble telescope in the two different orientations. '*' is convolution, of course. Take Fourier transforms of these two, and get I1(u,v) = O1(u,v) x P1(u,v) and I2(u,v) = O2(u,v) x P2(u,v) O1 & O2 are not really different functions here, but are the same function that has been _measured_ in two different ways. All we want to do is get a good estimate of O, and we are done. The "zero problem" mentioned before is that where P1 and P2 happen to be zero, we have no information about O. This is because Oi(u,v) = Ii(u,v) / Pi(u,v). (We can't divide by zero) By rolling the telescope around, we move the zeros of P around. It turns out to be very unlikely that the zeros of the two transformed PSFs happen to coincide. (In that case, you can apply a fixup by interpolation.) The simple idea behind this is to just toss out your measurement of O when the tranformed PSF drops below some critical value. You will still have a good measured value from the other image. When both measurements are OK, just take the average of the two. (Frankly, I don't see why they don't weight each inversely with the magnitude of the transformed PSF, but that's a fairly minor quibble.) Once you have O, back transform to o, and you're done. The authors go through a few variations about different ways to measure the PSFs, but they all seem to work pretty well. The simulated images do indeed look pretty good. ----- This is a shared guest account, please send replies to dbriggs@nrao.edu (Internet) Dan Briggs / NRAO / P.O. Box O / Socorro, NM / 87801 (U.S. Snail) ------------------------------ Date: 19 Mar 90 16:29:01 GMT From: clyde.concordia.ca!news-server.csri.toronto.edu!utgpu!watserv1!watdragon!dahlia!mskucherawy@uunet.uu.net (Murray S. Kucherawy) Subject: Re: Challenger Report question hewett@SUMEX-AIM.STANFORD.EDU ("Mike Hewett") writes: >If you haven't done it yet, I highly recommend reading the report. Anyone know if it's FTP-able, and from where? Please answer by e-mail. =========================== Murray S. Kucherawy ============================ E-Mail: mskucherawy@{ watmath | dahlia | crocus | trillium }.waterloo.edu University of Waterloo, 1B Mathematics (entering Pure Math/Computer Science) Postmaster/Gamesmaster, UW Computer Science Club (mkuch@watcsc.waterloo.edu) System Manager, VAX/VMS Network, Board of Education, London, Ontario, Can. ------------------------------ End of SPACE Digest V11 #168 *******************