Eagle (INACTIVE) October 2006

26 participants
28 discussions

Re: [Bod] FCC Omnibus R&O
by Dr. H. Paul Shuch 02 Nov '06

02 Nov '06

Hi, Tom, I too am still in CA (funny, I didn't see you on the street last night!) With restricted access. Unfortunately, your 301 kByte PDF confounded Mr. Blackberry. It got stuck in his windpipe and blocked 68 othetr messages (not to worry, they were all spam). My point is, we should be careful with large email attachments. Rather than posting them to multiple lists, anything other than brief ASCII text should probably be posted to a website somewhere, and only the URL forwarded around. That way, we can download the files at will, when back home connected to the Real World. Mr. Blackberry thanks you for your consideration. 73, Paul -- H. Paul Shuch, Ph.D., Chief Engineer Microcomm Consulting +1 (570) 494-2299 121 Florence Drive, Cogan Station PA 17728 paul(a)microcomm.net http://microcomm.net ---------- This document may contain proprietary information, intellectual property, trade names, and logos which may be confidential to Microcomm Consulting. Dissemination for any purpose of any part of the data contained herein without specific prior written authorization from Microcomm Consulting is hereby prohibited.

3 2

Power system thoughts and comments
by Phil Karn 02 Nov '06

02 Nov '06

I was fascinated by Lou's talk at the Symposium. His idea of a "parallel" power system is an excellent one if a few potential problems can be addressed. The first and most obvious one is efficiency. Switching converters tend to be much less efficient at low voltages and high currents, though power MOSFETs have gotten very good of late. Every Pentium 4 motherboard has had a DC-DC converter that takes 12V and produces ~1V at up to 100A to power the CPU. The fact that there isn't a massive heat sink and fan for the supply as well as the CPU says that these converters can't be too terribly inefficient. I'll be interested in some actual figures for the "virtual battery" converters. The second issue is robustness. Just as serial architectures are vulnerable to single-point open faults, parallel architectures are potentially vulnerable to single-point shorting faults, e.g., of the power transistors and diodes in the converter. I'm hoping a judicious application of fuses can take care of this. Super caps look very promising thanks to their claimed long cycle lives, but I wonder about their radiation robustness. Imagine what a highly energetic, totally ionized particle might do as it rips through the Aerogel holding large numbers of electrons a few microns apart from large numbers of holes. Have any radiation tests been performed on these things? Also, I would not take their cycle life claims as gospel without some tests to back them up. Electrolytic caps have become some of the most unreliable components in electronics today. They fail on a regular basis in computer power supplies and motherboards, often spectacularly. While super caps aren't built quite the same way, both kinds of caps achieve their high capacities with lots of extremely thin dielectric material. Cycling the cap must place some pretty serious electrostatic compression stresses across this material. What happens, e.g., after many cycles at very low temperatures? At a system level, I see a potential "gotcha" with multiple paralleled virtual battery units. You can never get multiple voltage references to exactly agree, so if the control loop gains are too high, then one virtual battery might think the bus voltage is a little too low when another might think it's too high. Then you'll have large amounts of current flowing from one virtual battery into another, obviously an undesirable situation. The simplest fix I can think of is to program the control logic in each virtual battery to follow a specified current vs voltage characteristic. The slope of this curve must be gentle enough so that small differences in reference voltages across the units will not produce significantly different I/V curves. Bus regulation won't be quite as tight, but hopefully the loads won't mind. Overall I think Lou's proposed architecture is an excellent idea, and with attention to a few details it should be a lot more reliable than the conventional power systems we've had in the past. --Phil

5 10

Eaglepedia articles
by Alan Bloom 30 Oct '06

30 Oct '06

I have set up a new category on Eaglepedia called "Hardware Design Guidelines". http://www.amsat.org/amsat-new/eagle/EaglePedia/index.php/Category:Hardware… I seeded the new category with two new articles, "SMT Thermal Design" and "HEO Radiation Environment". I also added several old Eaglepedia articles that should be useful to hardware designers. I'm new to posting Wikepedia-type articles so I'm not sure I got the category thing right. Also I'm not an expert on thermal design or the space radiation environment, so I hope other members of the Eagle team will do the Wikipedia thing and add to, modify, correct what I've done. Al N1AL

1 0

AMSAT award
by Robert McGwier 28 Oct '06

28 Oct '06

It pleases me greatly to announce that Eric Ellison has been presented with an award from AMSAT. It is sometimes easy to take for granted what seems to many to be a small thing. In the case of AMSAT, Eric's work made virtual meetings not only possible but easy. AMSAT has literally run its Eagle project using VOIP facilities which Eric set up on behalf of the technical groups active today in amateur radio in satellites, technology, and in particular software defined radio. AMSAT and TAPR both recognize Eric's work, AMSAT with the award and TAPR membership with Eric's election to its board of directors. Someday Eric's TEAMSPEAK server will be universally recognized for the spectacular impact it has had and will continue to have. Eric, the award is in the mail from the AMSAT office along with a gift membership in AMSAT for a year. Jim Sanford, Eagle project manager, and I and the entire organization give you our thanks for your generosity and help. 73's Bob McGwier N4HY -- AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair "You see, wire telegraph is a kind of a very, very long cat. You pull his tail in New York and his head is meowing in Los Angeles. Do you understand this? And radio operates exactly the same way: you send signals here, they receive them there. The only difference is that there is no cat." - Einstein

2 1

CONGRATULATIONS TO N2UO
by Robert McGwier 24 Oct '06

24 Oct '06

I know all of the Eagle designers will join me in congratulating Marc Franco, N2UO on his being granted permanent residency here in the U.S. His skills represent a major asset to Eagle, Lintech, and the U.S. [in that order ;-)] and it is good when the immigration office does something sensible for a change. CONGRATULATIONS Marc! Bob N4HY -- AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair "You see, wire telegraph is a kind of a very, very long cat. You pull his tail in New York and his head is meowing in Los Angeles. Do you understand this? And radio operates exactly the same way: you send signals here, they receive them there. The only difference is that there is no cat." - Einstein

3 2

Eagle Team Leadership change announcement
by Jim Sanford 23 Oct '06

23 Oct '06

Team: I wish to announce that Bob Davis, KF4KSS, has assumed the role of Structure and Mechanical Team Leader. Bob has experience in finishing and integrating AO-40, and is employed in the aerospace industry, where he has acquired significant experience since the AO-40 campaign. Dick Jansson, WD4FAB, has led this team for several years and is not going away. Dick will support Bob as a team member, focussing on structural team coordination and thermal design and analysis. Dick told me this afternoon, "I'm really excited to see the new blood coming in and assuming leadership roles. I look forward to supporting Bob and being on his team." I thank Dick for all that he has done for AMSAT and WILL do for Eagle and AMSAT. Thanks for all you've taught us. Bob, thanks for stepping up to the plate. I look forward to working with you, and I look forward to learning from you. Thanks and very 73 to all, Jim wb4gcs(a)amsat.org Eagle Project Manager

1 0

AVP -Engineering team
by Robert McGwier 21 Oct '06

21 Oct '06

I have asked the following folks to be AVP for Engineering. Jim Sanford as Eagle project manager Lou McFadin as Manned Space chief engineer Bob Davis as lab director and spacecraft integration leader Please add them to the officers mailing list if they are not already on it please. Welcome and thank all of them for their continued great service to AMSAT. Bob N4HY -- AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair "You see, wire telegraph is a kind of a very, very long cat. You pull his tail in New York and his head is meowing in Los Angeles. Do you understand this? And radio operates exactly the same way: you send signals here, they receive them there. The only difference is that there is no cat." - Einstein

1 0

S1 downlink coordination and interference mitigation
by Howard Long 18 Oct '06

18 Oct '06

Folks, Coincidentally at the Symposium, Graham Shirville spent some time coordinating proposed frequencies to some satellites, including Eagle, and after a suggestion I had from from Drew KO4MA, I reiterated to Graham that it may be advantageous to propose S1 frequencies right down at the bottom 1MHz of the 2.4GHz satellite allocation. 802.11 specifies a 1MHz guard band at 2400 to 2401MHz for regulatory OOB emission reasons. Signals +/-11MHz from the centre must be at least 30dB down from the carrier. Channel 1 is at 2412MHz. Taking into account Doppler, the recommended S1 coordinated frequencies will be at the bootom end of 2400MHz without the possibility of OOB emissions on Earth due to Doppler. 73, Howard G6LVB

2 2

Service class names
by Jim Sanford 18 Oct '06

18 Oct '06

Team: A few days ago, I made a proposal for naming Eagle's communications services and solicited comments. I received many good comments. I really think it important that we have unambiguous service class names. Based on all the comments, I propose: U/V "linear" L/S "linear" Text messaging Low Rate ACP High Rate ACP While I'd prever something less ambiguous than "linear", our customers seem to understand that "linear" means SSB/CW/PSK31/SSTv . . . . etx. Any strong objections to this? If not, I'll get the announcement on AMSAT.org changed. It's time to get precise. Thanks & 73, Jim wb4gcs(a)amsat.org

2 1

Module Paper
by Dick Jansson-rr 15 Oct '06

15 Oct '06

I have been asked if I can provide a copy of the module paper of mine that was so skillfully presented by Bob Davis at the recent AMSAT Space Symposium. This is for those of you who were not able to be at the symposium and receive the Proceedings. This paper is now available on Eaglepedia at: <http://www.amsat.org/amsat-new/eagle/EaglePedia/index.php/Module_Design> http://www.amsat.org/amsat-new/eagle/EaglePedia/index.php/Module_Design Dick Jansson --------------------------- <mailto:[email protected]> rjansson(a)cfl.rr.com ---------------------------

1 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

Eagle (INACTIVE) October 2006