Team: Much has happened over the last couple of weeks that I need to address.

First some background:

I apologize for being low profile lately, and allowing things to fester which should have been resolved sooner. Unfortunately, I've been dealing with some personal issues (consider, Non Maskable Interrupt) and with my 84 year old Pearl Harbor veteran father who has been with us enroute the new home enroute the nursing home. I'm sorry to have neglected Eagle, but had to deal with the immediate issues.

There have been some important discussions, on and off list, which have simultaneously been productive and not necessarily contributory. I should have reacted sooner, but couldn't. I hereby strive to get things back in the box.

I'd like to restate some "groundrules", history, and current status as I know it, if you will:

Eagle is an open project. All we do is visible to the AMSAT membership, and all we do is open to their question. NEVER FORGET: "Its nice to see all this new technology, but what are you clowns doing to make sure the thing JUST WORKS?"

Communications within the team should be open and technical, not personal. Messages which say or imply, "you idiot, that will never work because. . .." are just not helpful.

We must have a clear and visible demarcation between open discussion and things that must be formal, such as decisions, requirements, etc. For my part, when I authorize an expenditure, or publish a decision, I will ALWAYS do so in e-writing in an unambiguous way. Things such as requirements changes, will be discussed, peer-reviewed, and formally announced.

Requirements are always open to question and modification, ESPECIALLY as designers and constructors learn new things. The recent work on the U-band receiver prototype have been MOST illuminating -- and well documented on EaglePedia. I believe the work by John, Juan, and the Project Oscar team sets an example, matched only by Bdale and Stephen with regard to the CAN-Do! widgets.

We still need to document requirements for some pieces of the satellite. To help with this, I have some friends looking for some freeware requirements management tools. (This is different than Vision and MSProject, which we're already using, I'm talking about tracing the history of requirements generation, and tracking requirements-to-test traceability.) You guys in industry -- I'm open to suggestion.

Team leads: IF we don't have good requirements for your "piece", you know who you are, we ought to be developing them, so that we can proceed with prototyping and testing -- against requirements.

There have been some questions and different understandings on how we will command Eagle. Bob McGwier and I sorted thru the various thoughts a few days ago. The primary command will be L-band, direct into the IHU, as was discussed in the Orlando meeting. The always-on U-band receiver will also be a command receiver -- thru the SDX, since the IHU can only accommodate a single I/Q pair. I particularly like this approach, because it minimizes (not eliminates) opportunities for a single failure to take out all command capability. (TBD on whether or not the S2 ACP uplink can also be used for command. It was discussed as a possibility in San Diego, but has not been decided, to my knowledge.) This is consistent with the discussions at Orlando.

Another lesson learned from the U-RX prototype effort is that receivers must recover from power interruptions autonomously, without IHU intervention. This realization has some of us ready to go to crystal LOs; Bill Ress has articulated some other options. Look for a discussion on this topic after we have results from the U-RX ATP and revise the design for flight. There will be another peer review.

There have been some questions and discussion regarding temperature range the payload modules can expect to see. There's some discussion of this in the notes from the Orlando meeting, but this is an area where we need to document some requirements. To help, Bob McGwier is doing a historical search on what AMSAT has designed to in the past. His results will be published.

Related to the above, Juan Rivera has raised some very good issues regarding temperature and effects of differential coefficients of expansion. Thermal design is becoming more challenging as LSI devices generate more heat in smaller areas, raising local heat fluxes much higher than we've ever worked with before. Ancient parts have become unobtanium, so we have to figure out how to deal with this -- the thermal folks have their work cut out for them, but industry is doing it. Aggravating the above, today's SMD components are smaller and more brittle, making it possible for temperature issues to physically break things. Juan has posted some interesting information on "things" that can break SMD stuff. (If you haven't yet checked out his construction notes on EaglePedia, you're missing a REAL treat. Bdale said in Pittsburgh, "Our legacy may very well be in our documentation," and Juan is providing the documentation in a huge way.)

Related to thermal issues, there has been some discussion regarding use of machined enclosures, rather than the sheet metal which is our current design. Bob Davis, mechanical team lead, will evaluate and provide a recommendation -- look for this discussion.

I've seen some discussions regarding all the "wasted space" as a result of the larger structure, driven by our power and antenna needs. Please, let's not go down the path of tossing in the kitchen sink to fill the volume. We have discussed one or two TSFR spaces, and this should continue, but payloads beyond what the BOD approved in SFO should be viewed skeptically.

All right, that's what I have to say by way of "catching up." Given Murphy's law, somebody is going to be pissed about something herein -- please don't be. Let's not get emotional about technical subjects. We're all working toward the same end, and I'm trying to bring some structure to our efforts. In my experience, a large team like us periodically needs to step back and review the bidding, and that's the purpose of this email.

Goals: Again, I apologize for not making Dayton, and not having the working things that Juan, Project Oscar, and Bill Ress worked so hard to deliver to me. Given the "frantic" nature of Dayton, I'm told that I make a bigger deal out of this than it was, because few would have the opportunity to really hang around and study. Symposium in Pittsburgh will be different. We MUST have some working things to show, and I want to be able to announce early -- as an inducement to the membership to come on down. I believe this is achievable -- U-RX, V-TX, SDX, IHU, possibly a power demonstration.

For info, our host in Pittsburgh, the Wireless Association of South Hills, has in the last 18 months, raised quite a bit of money and constructed a trailer-mounted tilt-over, crank up tower, for use at Field Day and in emergencies. This will be at Symposium, and will have whatever antennas on it we like. I'd REALLY love to have a working transponder hooked up to it, so that we can demonstrate, in the local area, not just at the hotel, what Eagle will be like. (We can also work satellites overhead as demos.)

Personal note: Again,I apologize for my low profile lately. I'm getting back in the saddle, as I get hammered from all sides to, "slow down". I briefly considered reducing my time/efforts on Eagle, but quickly realized that would be MORE stressful than what I'm doing. Working with this team of brilliant intellect has been enjoyable and rewarding, matched by only a very few things in my entire life. I thank you all for that. As time goes on, we're all going to get busier, so we need to step up recruiting efforts, and I'll be asking some key people to help me on discrete tasks.

Thank you all for indulging my pontifications. Let's press ahead.

Thanks & very 73, Jim [email protected]