Date: Sun, 15 Jan 1989 12:27-EST From: space-tech-request@cs.cmu.edu To: "~/st/lists/stdigest" Subject: Space-tech Digest #21 Contents: Dale Amon Re: Space Plane Dale Amon Re: LPO historical note Paul Dietz Searching for asteroids (was Modular Satellites) Joe Beckenbach Modular Satellites Craig Keithley Modular satellites -- The Core Module ------------------------------------------------------------ Date: Fri, 13 Jan 1989 15:51-EST From: Dale.Amon@H.GP.CS.CMU.EDU To: space-tech@cs.cmu.edu Subject: Re: Space Plane I would recommend that a great deal of effort go into sensors and telemetry. It might be a good idea to mount several cheap Sony CCD videocameras at strategic points. Possibly one looking over the engine, a few mounted so that wings and control surfaces can be watched. Sense everything you can think of for Temp, flow rates, pressures, etc etc. It is probably cheaper than running through 10 models trying to find out why the thing vanishes without a trace 15 minutes after ignition. You will obviously not have the resources to track and recover wreckage, and I don't think your first 5, 10 or maybe even 20 models will be successful. It is faster and cheaper to lose $75K models than it is to design to aerospace industry zero defect on first flight standards. The Cray computer alone costs more than your 20 models. The COMPUTER time ALONE might cost more than the trial and error test articles. And the trial and error method does not leave you vulnerable to the limitations of knowledge that the computation models carefully hide in their perfect internal world. Let's face it, it's a rather nonlinear world out there at Mach 20... If you intend to learn by the Thomas Edison method ("But I now know 1000 things that don't work!") you need to squeeze every last bit of data out of every failure. I suggest the video cameras because of the old adage that a picture is worth a thousand words. If a wing flutters and shears (or burns through), what better way to figure out what happened? Of course some strain gauges to record the frequencies are good also. But it might take one failure to figure out where to put them. Then you fly a second test article, knowing it will fail again and return the precise diagnostic data you need. The question that comes to mind though is how severe the internal environment will be, and what kind of electronics (or packaging) will be required for them to continue to function from drop to splash. ------------------------------ Date: Fri, 13 Jan 1989 16:40-EST From: Dale.Amon@H.GP.CS.CMU.EDU To: space-tech@cs.cmu.edu Subject: Re: LPO historical note The first time I heard about the LPO idea was in a discussion between Gordon Woodcock (of L5) and John Champa (of AMSAT) at the 1985 Midwest Space Development Conference. John and some others had given a presentation on the truly amazing cost cutting methods used by AMSAT, such as bridal veil for it's thermal properties, batteries from some hospital equipment (a defibrillator I think) that were identical to space rated batteries at $90 a case instead of thousands per unit, and so forth. Gordon at that time suggested that a proposed AMSAT geosynchronous satellite project could be turned into an LPO since the delta-v used to insert in GSO is also sufficient to insert into a lunar orbit. (I'm not sure if it is enough for LPO, my memory of conversations from 3 years ago isn't THAT good...) Also present at the discussion were myself and BDale Garbee. I know that Gordon did the math and proved it some time later. I'm pretty certain that Gordon Woodcock is the originator of the private LPO idea. The $2000 for the lunar polar orbiter was raised by Rick Tumlinson at the 6th Space Development Conference her in Pittsburgh in March 1987. (I was the conference chair) The express purpose of the money, in Rick's own word's was "We're going to bend metal folks..." I was also present at a meeting in Houston during the 2nd Lunar Base Symposium between Gordon Woodcock (former NSS exec), Greg Maryniak (SSI Exec) a few people from WSF and JPL, I think someone from AMSAT, and a few other odds and ends like myself, Gary Oleson, (I think Bill Higgins was there too) The JPL types were talking about $$$M for launch and satellite. They just didn't quite understand the idea of a shoe string effort. I also know that S David Eisenberg in New York was trying to coordinate some effort on this about a year ago. I found him an arpa account via someone out on the West coast, Will Marchant. I have listed some contact info on most of the individuals named above. I also have home phone numbers (and the missing home addresses), but I will not post those globally. If some one needs a specific one and has a good reason, I would be willing to supply it. Maryniak, Greg REF: SSI (Vice President) WorkPhone: 609-921-0377 WorkMail: PO Box 82 Princeton, NJ 08540 Eisenberg, David HomePhone: 212-580-2952 HomeMail: PO Box 1117 Ansonia Station New York, NY Email: david@dasys1.UUCP Email: cmcl2!phri!dasys1!david Email: sun!hoptoad!dasys1!david Tumlinson, Rick HomeMail: 92 Perry. Apt 12 New York, NY 10014 HomePhone: 212-255-2317 Phone: 212-245-2533 (Intrepid) Higgins, Bill REF: Fermi Lab Email: HIGGINS%FNALCDF.BITNET@WISCVM.WISC.EDU Woodcock, Gordon REF: Boeing Aerospace (Laboratory Module Outfitting Manager) WorkPhone: 205-461-2396 WorkMail: PO Box 1470 Huntsville, AL 35807 Marchant, Will WorkMail: Space Sciences Lab University of California Berkeley, CA 94702 WorkPhone: 415-642-8515 Email: marchant@sag3.ssl.berkeley.edu Email: ...!ucbvax!ucbssl!sag3!marchant Champa, John REF: AMSAT (Executive Vice President (85-?)) HomeMail: 7800 Hartwell St Dearborn, MI 48126 WorkMail: PO Box 27, Washington, DC 20044 (AMSAT) Garbee, BDale HomeMail: 4390 Darr Circle Colorado Springs, CO 80908 HomeEmail: bdale@net1.ucsd.edu HomeEmail: {bellcore, crash, hp-lsd, hpcsma, pitt, symmetric, vixie}!winfree!bdale (uucp) HomeEmail: bdale%winfree@flash.bellcore.com HomeEmail: pitt!winfree!bdale@cadre.dsl.pittsburgh.edu HomeEmail: n3eua @ wb0blv, Colorado Springs (packet) HomeEmail: encore!vaxine!spark!128!18!sysop@talcott.harvard.edu ------------------------------ Date: Fri, 13 Jan 89 17:02:10 EST From: dietz@cs.rochester.edu To: C43RGP%ENG4.gm@hac2arpa.hac.com Cc: space-tech@cs.cmu.edu Subject: Searching for asteroids (was Modular Satellites) > RGP has a strong personal interest in a satellite-borne > telescope to search for asteroids with a combination of mass, > composition and orbit which would be suitable for diversion to > Earth's orbit. I just read "First Light", and the section about Gene Shoemaker made me think about amateur asteriod searches. (By the way: read the book, if you haven't already; it's enjoyable.) The chapter follows Gene and his wife Carolyn as they use the smallest Schmidt camera at Mt. Palomar to search for new Trojan asteroids. They used photographic film. I think CCD detectors, which can be 100x more sensitive, might make searching for faint asteroids possible with scopes of more modest size. CCD's have a number of advantages over film, besides the much higher quantum efficiency. CCD's dump data directly into a computer, so the search can be automated. Also, CCD's can be read off in near real-time, so one could take multiple exposures of a field in quick succession rather than a couple of long exposures. It would then be easier to extract faint objects moving in straight lines from the background noise. Some things have to hold for this idea to make sense: (1) asteroids have to be bright enough to see against the noise due to sky brightness and CCD noise, (2) CCDs have to be cheap enough (maybe surplus/marginal ones could be used), (3) we need enough computing power to store and to process the images. Just for sake of argument, I'll plug in some numbers. Suppose an asteroid with an albedo of .05 is 10^7 km beyond the earth. If it were spherical with a radius of R (in meters) its reflected light at earth would be about 3.5e-19 R^2 W m^-2 (making some assumptions about how it reflects light). So, a telescope with a 30 cm aperture would collect 2.5e-20 R^2 watts. For R = 50 m, this is 6e-17 watts, or roughly 100 photons per second. If the field is 2 degrees x 2 degrees and the CCD is 500x500 pixels, each pixel is 14 arc seconds across. I don't have good figures for sky brightness available, but I think it will give a signal of several hundred photons per second per pixel, which should dominate electronic noise. If sky brightness is 800 photons/(pixel s), a 1 second exposure would have an SNR of 3. Going to larger CCD's helps, since one can scan larger solid angles and/or have each pixel cover less sky to reduce noise. Tektronix is supposed to be making a 2kx2k CCD; I think Kodak just announced a 4kx4k CCD. If the observatory can detect candidates in real time, it makes sense to then use a narrow-field scope (with CCD) to refine the observation. Time is of the essence for close asteroids; an asteroid moving at 5 km/s relative to earth at 10^7 km moves up to .1 degree per hour. Even if finding asteroids is hard, a CCD-telescope combination would make a really nice amateur observatory -- especially if you could steer it and watch the display from indoors. Paul F. Dietz dietz@cs.rochester.edu ------------------------------ Date: Fri, 13 Jan 89 12:04:54 -0800 From: Joe Beckenbach (joe@cit-vax.caltech.edu) To: C43RGP%ENG4.gm@hac2arpa.hac.com Cc: space-tech@cs.cmu.edu Subject: Re: Modular Satellites(a great idea!) > From: C43RGP%ENG4.gm@hac2arpa.hac.com > We have been following the discussions of amateur > satellites with considerable interest. Being "modular" kinds > of software engineering guys we have a suggestion for a > philosophical approach to these ambitious undertakings. You're not the only one! It seems that 'real engineers' have this thing for modularity too: standard screw and bolt sizes, modular homes, integrated circuit chips, wrenches and other tools, etcetera. > Essentially, all of these proposals for satellites have > a core of common requirements. A basic frame and series of > subsystems could be designed for use in a number of disparate > satellite projects. Then, additional subsystems can be > constructed for specific projects such as the Lunar/Polar missions, > a mini deep space telescope, or a materials science research > platform. I've fiddled around with this idea some too. The big wins are: 1) easy to mass-produce and thus get volume discounting once started 2) MULTIPLE VENDORS!!! [less dependent on a single supplier of ANYTHING] 3) customers KNOW what can fit and what cannot; design time is lessened 4) once standard sizes are set, a few simple frames allow it to be launched on a multiple of vehicles with minimal effort-- switching from Shuttle to Long March could be vastly simpler, for instance. Some projects will need custom work-- but then the smallest standard stuff can still be used for that. Think of a compiled program as the satellite, the modules of code as the modules, and the custom projects for specific needs as the assembly-coded routines. See? Engineering isn't that far from reality. ;-) :-) > Our approach has a number of advantages least not of > which is that it satisfies the age old adage that it is > necessary to crawl before an attempt to walk. Ah, the engineer's approach-- do it right, then do it well. > Core Module > Main Mission Computer subsystem > R/F transmitter/receiver [data and command distribution system] > Minimal power supply for free-flying core module > Power Module > batteries > solar panels > Attitude Module > Gyros > thrusters > star/sun finder navigational support [computing, whatever] > There would be Auxiliary modules which are of > standard design but whose use would be mission-dependent. > For instance, if you needed more power for your mission > there would be standard auxiliary power modules that can be > added to the basic frame. > Mission specific modules would be designed specifically > for a particular mission. We call these Experiment modules. > Their subsystems would be designed by the people who wanted to > do a specific mission(e.g. Lunar/Polar probe). Mars Observer main platform provides standard powers, navigational information, and command/data linking to Terra, along with the basic transportation and structural support. The experiments [including my previous employing team, Mars Observer Camera] have a well-defined data and command delivery interface, with testing equipment provided by JPL so that the experiment packages can concentrate on the experiment objective and 'ware. > We need a more developed concept of how to divide up the > Modules and subsytems. Interfaces must be defined and a basic > frame and dimensions for the components must be specified. > What do you all think? Yea! Yea! Yea! :-) Uh, folks, the same thing goes for telemetry, and 'infrastructure' of all sorts. And launchers.... But who is RGP? Enough for now. Joe Beckenbach Caltech CS Dept. joe@cit-vax.caltech.edu ------------------------------ Date: Fri, 13 Jan 89 18:24:06 PST From: C43CJK%ENG4.gm@hac2arpa.hac.com To: TECHDIS@hac2arpa.hac.com, C43RGP@hac2arpa.hac.com Subject: Modular satellites -- The Core Module Recently Randall Parker and I suggested the concept of modular satellites. I would like to lead off the discussion of the Core module. The Core module would be divided into the following areas: 1. Mission Computer subsystem 2. R/F transmitter/receiver subsystem 3. Room for a battery/solar panel subsystem 4. Room for a 20000 (approx) cubic cm. experiment subsystem 5. A 'spinal-tap' for attaching the module to the satellite spine. And now for the particulars: 1.0 Mission Computer subsystem o A card cage for up to 4 (maybe 8) cards. Anyone out there familiar with the Gespac G64/G96 buss? The G96 buss has 32 bit address and data support. A G64/G96 card is about 4" by 6" inches. o Processor card. Gespac has a variety of 68000 cards. One card has an 8 MHz 68000, up to 512k ROM, 256k SRAM (battery backed), a real time clock, watchdog timer, dual high speed (1 meg baud) serial ports, and parallel I/O. About $800 without SRAMs, $1000 with SRAMs. o Expanded memory card. 1 or 2 meg of battery backed RAM. o Special mission specific/experiment cards. Some applications would require a faster data rate than would be available via the Mission Bus. A DMA interface to CCD camera for example. o Small experiment subsystem control card. It would not make much sense for the small experiment subsystem to contain its own processor and mission bus interface. o R/F transmitter/receiver interface card. Frequency selection etc. Backplane/BUS selection: I am not particular to a given bus or card form-factor. How about STD BUS, VME Bus (I think it's too large though), IBM PC Bus, etc. I'll post the G64/G96 specs if anyone is interested. Mission bus (inter-module and inter-subsystem communication): I'm familiar with MIL-STD-1553 and ARINC-429 serial interfaces. I believe that most of the interface between subsystems could be accomplished with a high speed serial interface across a simple twisted pair network. I have some more specific thoughts for those who are interested. Power consumption: How much power could be allocated? Between 10 and 20 watts seems like a minimum. Any ideas? Software development environment: IBM PC probably. Macs, VAXes, Suns, Apollos...What else? We would need a C compiler, assembler, linker, etc. Does anyone want Forth? (not me!) 2.0 R/F transmitter/receiver subsystem o Selectable frequencies? o Filtering? o Antenna design? o Digital or Analog transmissions? o TDRS capability? o How much power consumption (in watts)? +++++ Anyone know anything about these things? I sure don't. 3.0 Battery/solar panel subsystem This subsystem would provide enough power for the MC, R/F and small experiment subsystems. +++++ We need an expert on Solar panels, the power conditioner, battery chargers, etc. Sizes, weight, efficiency factors to be considered. 4.0 Small experiment subsystem Size: This subsystem would be for those amateur satellites that only required about 20000 cubic cm (3/4 cubic foot) for their experiments. Power: The power allocated depends entirely on the configuration of the satellite, how much power the Battery/Solar panel subsystem/modules provide, etc. How much would be a reasonable maximum? Some general thoughts: The experiment module would be able to contain between 6 and 8 small experiment subsystems. In that case, each small experiment subsystem would contain its own single chip microcomputer/mission bus interface. +++++ What experiments could fly in a 20000 cubic cm area. Is this too large, too small, etc? Comments anyone? 5.0 Spinal connection The spinal connection would provide a method of bolting the Core module to the standard satellite spine. The satellite spine would contain primary and reserve power conduits, mission bus, mission specific signals, perhaps some plumbing to run nitrogen to different thrusters at the fore and aft, etc. +++++ Space/air frame engineer wanted. Must be able determine stress factors, materials, thermal dynamics, etc. Should the spine go up the center of all the modules or along the side? That's about it. Let's discuss size, CPU and bus choices, power consumption, etc. Is the modular concept worthwhile? Could a core module be designed to be generic enough for a variety of missions? ------------------------------------------------------------------------------- Craig Keithley /----------------------+---------------------------------+---------------------\ | Craig Keithley | C43CJK@ENG1.GM.HAC.COM | (805) 968-5981 | | GM DSO-SBO | C43CJK%ENG1.GM@HAC2ARPA.HAC.COM | | \----------------------+---------------------------------+---------------------/ These ideas which have been hatched out of my fertile and vivid imagination SHOULD NOT IN ANY WAY be construed to represent the opinions or policies or plans of General Motors or Delco Electronics or other subsidiaries of General Motors. ------------------------------ End of Space-tech Digest #21 *******************