All:
My broadband connectivity to the main computer has been restored, thanks
in large part to randy, N3ZK, who helped me thru Microsoft's obtuse,
convoluted internet connection sharing. While suboptimal for many
reasons, it works, and I have restored broadband connectivity to the
main computer. This means my low profile of the last 2 weeks is over.
Thanks Randy.
73 to all,
Jim
wb4gcs(a)amsat.org
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
wb4gcs(a)amsat.org
Juan:
And you would be absolutely right. Since John developed the original
requirements document in concert with engineering management to meet the
requirements we wanted (PAVE PAWS immunization, support SDX, etc.)
aren't we glad that we have followed this procedure? We will again.
Let me know if you receive two copies of this email. If you did, you
are a member of the group. A CAVEAT: YOU MUST POST FROM THE ACCOUNT ON
WHICH YOU RECEIVE THIS EMAIL. It has to have some identifier to go by.
Bob
Juan Rivera wrote:
> John,
>
> Its no reflection on you but I still feel that it is fundamentallky
wrong for the designers and builders to create the requirements
document. It's an issue of customer vs. supplier. The requirements
should be supplied by the customer (AMSAT management). Then the folks
that are tasked with designing and building the device should generate a
plan to meet the requirements.
>
> I'd post this on the AMSAT/Eagle newsgroup if I was on that list but
I'm not.
>
> 73, Juan
>
>
> On 5/26/07, *John B. Stephensen* <kd6ozh(a)comcast.net
<mailto:[email protected]>> wrote:
>
> I think that the next step in the development of the 70 cm receiver
> needs to
> be updating the requirements document and getting it approved by
> those who
> will interface to the receiver. It was written over a year ago and
> things
> have changed. In my mind, there are several issues that need to be
> resolved:
>
> 1) Storing the frequency setting.
>
> 2) Phase noise.
>
> 3) Frequency reference failure detection and switchover.
>
> 4) Thermal environment.
>
> 5) Waiving the hardware telecommand decoding requirement.
>
> I'm in the process of updating the document and should done done in
> the next
> few days.
>
> 73,
>
> John
> KD6OZH
>
>
--
AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL,
TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair
"If you're going to be crazy, you have to get paid for it or
else you're going to be locked up." Hunter S. Thompson
And you would be absolutely right. Since John developed the
requirements document in concert with engineering management to meet the
requirements we wanted (PAVE PAWS immunization, support SDX, etc.)
aren't we glad that we have followed this procedure? We will again.
Let me know if you receive two copies of this email. If you did, you
are a member of the group. A CAVEAT: YOU MUST POST FROM THE ACCOUNT ON
WHICH YOU RECEIVE THIS EMAIL. It has to have some identifier to go by.
Bob
Juan Rivera wrote:
> John,
>
> Its no reflection on you but I still feel that it is fundamentallky
> wrong for the designers and builders to create the requirements
> document. It's an issue of customer vs. supplier. The requirements
> should be supplied by the customer (AMSAT management). Then the folks
> that are tasked with designing and building the device should generate a
> plan to meet the requirements.
>
> I'd post this on the AMSAT/Eagle newsgroup if I was on that list but I'm
> not.
>
> 73, Juan
>
>
> On 5/26/07, *John B. Stephensen* <kd6ozh(a)comcast.net
> <mailto:[email protected]>> wrote:
>
> I think that the next step in the development of the 70 cm receiver
> needs to
> be updating the requirements document and getting it approved by
> those who
> will interface to the receiver. It was written over a year ago and
> things
> have changed. In my mind, there are several issues that need to be
> resolved:
>
> 1) Storing the frequency setting.
>
> 2) Phase noise.
>
> 3) Frequency reference failure detection and switchover.
>
> 4) Thermal environment.
>
> 5) Waiving the hardware telecommand decoding requirement.
>
> I'm in the process of updating the document and should done done in
> the next
> few days.
>
> 73,
>
> John
> KD6OZH
>
>
--
AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL,
TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair
"If you're going to be crazy, you have to get paid for it or
else you're going to be locked up." Hunter S. Thompson
Sounds like we'll be soon embarking on a "frank" discussion regarding
the concerns Juan brought up during his teams build of the prototype U
Rx. Good!!
Have any pictures been posted of what the completed "Dayton" unit looked
like? Juan presented some in process pixs but I don't recall seeing the
completed unit.
Regards...Bill - N6GHz
I agree with Tom's sentiment and I gave the old "Bob can be a jerk"
stomping to private conversation's on Eagle technical matters off list.
It ends NOW. We discuss project technical matters here, from the
beginning to the end. Personnel issues are to be dealt with privately
with/by the project manager and NEVER on this list.
There are many who are on this list who have lots of experience in
building these packages for spacecraft. We need the benefit of all of
their experience.
Bob
--
AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL,
TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair
"If you're going to be crazy, you have to get paid for it or
else you're going to be locked up." Hunter S. Thompson
Robert McGwier wrote:
> There are several who have said their posts to the Eagle list are
> bouncing. For those who are having trouble with posting to the Eagle
> list (such as Juan), please tell Jim Sanford so he can correct the
> problem. He is the eagle list (eagle(a)amsat.org) administrator.
>
The problem is that this off-line list now has has ~18 addressees.
Adding eagle(a)amsat.org (now making ~19 addressees) causes a "rules"
violation that requires manual intervention by a moderator (I presume =
Paul, KB5MU). The obvious fix is to quit mailing to the long list!
Tom
Hi Bob,
Good to hear you weighing in.
Just on the subject of posting to Eagle, we need to understand why it
keeps "bouncing" posts made to Eagle. Both Tom and I have tried and
received bounces saying there are to many recipients. So there is NO,
again NO overt attempt to restrict posts, just an apparent posting
glitch, which I'm trying to work around with this post by eliminating
all recipients except you (and then including the Eagle address). We'll
see how that works.
So NO need for scolding from on high. No one has lost the desire to be
open. We just ran into what I guess is a "posting format" issue.
Looking forward to your revelation(s)......................
Regards...Bill - N6GHz
Robert McGwier wrote:
> Jim and I are reviewing the remarks but my first pass at this is to
> review history before I review the current situation in detail. We
> have had MANY spacecraft go in and out of eclipse. We have done
> thermal design work for all of them, and that work has been first
> class, and we have never EVER flown electronics where we allowed the
> temperature to move outside of its usable range. The very suggestion
> that we would is almost insulting. What I suggest is that we take a
> deep breath and analyze the situation without resorting to the sky is
> falling syndrome.
>
>
> The receiver will operate within specifications and thermal stresses
> will be mitigated. The points about mounting the circuit board and
> the bending torques thermal stresses will reviewed. Any modifications
> to the hardware will be okayed post haste.
>
> I want everyone to hold together here because I am going to hint at a
> secret that I hope is about to be revealed. DO NOT SNATCH DEFEAT FROM
> THE JAWS OF VICTORY. I believe we have extremely exciting
> developments about to come upon us for a ride to orbit <as in a launch
> contract>. Do not lose heart now. All programs for space undergo
> changes as gotchas come up. This is no reason to be discouraged but
> in my mind has always been a thrill because we have worked hard and
> overcome them. The only place in my mind where our management
> situation failed completely was on AO-40. It has never been
> completely comfortable but it is simply the nature of activities like
> this where almost everyone, if not everyone, is a volunteer.
>
> Last: WHY is this conversation not happening in the Eagle mailing
> list? I object most strenuously because it is not consistent with our
> promise to design in the public eye. We cannot start this by hiding
> our work from other eagle team members who might be wondering if any
> work is going on at all. I will listen to any good reasons before I
> issue an irreversible order. We will have a small insurrection on our
> hands when a few of the members who have not been privy to the
> conversations (and who are potentially very large donors) find out
> such as Phil Karn and Franklin Antonio. I have Franklin's assurance
> we can build the ACP in Qualcomm labs with their having equipped it. I
> will not have him angered by secrecy. This should not have been
> allowed to continue.
>
>
> 73's
> Bob
> N4HY
>
>
>
> Bill Ress wrote:
>> Juan, (et al.,)
>>
>> It will be interesting to see the responses you get to your VERY
>> appropriate post. Obviously you are wrestling with several very
>> important issues.
>>
>> I hope your subject title "We need to step back and reorganize," is
>> meant to apply not just to your 70CM Rx but to the whole Eagle program.
>>
>> I was going to add more of my few cents but I'll wait to see if and
>> how upper management replys to your points.
>>
>> We should all ask ourselves: why have there been so many amateur
>> satellite failures since AO-40? In the current batch of recently
>> launched CubeSats, many are non or semi operational. I don't know why
>> they failed once in orbit after working fine on the ground. Could it
>> be that some of the issues Juan brings up caught those design teams
>> in the butt?
>>
>> Hang in there Juan - we really need your great efforts, knowledge and
>> frank and honest criticisms. I know you're just trying to help build
>> a "reliable" satellite worthy of the many thousands of donor dollars
>> that will go into Eagle.
>>
>> Regards...Bill - N6GHz
>>
>>
>> Juan Rivera wrote:
>>> Jim,
>>>
>>> I'm writing to you at 4:00 AM because I've been laying awake for the
>>> past
>>> three hours worrying about this receiver project. Let me go over a
>>> few of
>>> the surprises that we've encountered after the requirements were peer
>>> reviewed and approved, my team was brought on board, the receiver was
>>> designed, parts ordered, and construction started:
>>>
>>> 1) Power can be interrupted every three seconds and the receiver has to
>>> store enough charge to survive those outages.
>>>
>>> 2) The receiver is not the telecommand uplink receiver. That
>>> receiver isn't
>>> even on UHF. It's on L-Band.
>>>
>>> 3) The lower temperature extreme it must survive is not -20C. It's
>>> -70C.
>>>
>>> 4) The chassis it will be mounted in flexes.
>>>
>>> 5) It may or may not have to operate while subjected to PAVE PAWS
>>> interference which is either impulse radar or chirping across the
>>> entire
>>> satellite UHF segment.
>>>
>>> 6) The receiver cannot depend on a boot from the HCU. It must be
>>> autonomous.
>>>
>>> 7) The Can-do module power switch will be bypassed to provide
>>> continuous
>>> power to the receiver. No, wait! The receiver will be shut down during
>>> eclipse and cold soaked to -70. Well, it's one of those two anyway.
>>>
>>> I'm sure I'm forgetting a few items, but you get the idea.
>>> Obviously the
>>> original requirements document was incomplete. In my opinion this
>>> was a
>>> result of the unstructured and informal approach that was used, and
>>> the fact
>>> that the RF designer, John, wrote it instead of a system engineer
>>> looking at
>>> the satellite as a whole.
>>>
>>> The receiver ATP peer review is another example. I know there are
>>> problems
>>> with that document. After all, I wrote it. Unfortunately I have not
>>> received one single comment suggesting an improvement, even though
>>> it has
>>> been posted on Eaglepedia since last year.
>>>
>>> Now is the perfect time to create a structure that will avoid these
>>> problems
>>> from now on. It should start with a completely new receiver
>>> requirements
>>> document, an ICD (Interface Control Document), and an actual review
>>> of the
>>> ATP.
>>>
>>> The requirements document needs to have input from everyone that has
>>> anything to do with the project - thermal, power, mechanical,
>>> control, EMI,
>>> etc. There should be a formal checklist to insure that no
>>> functional group
>>> is omitted from the process.
>>>
>>> There needs to be another checklist that spells out exactly what
>>> needs to be
>>> included in the specification. If the two lists are complete, and
>>> adhered
>>> to, then all future requirements should be complete as well.
>>>
>>> The requirements need to start by defining the RF environment that the
>>> receiver is expected to operate in. I've seen email suggesting that
>>> PAVE
>>> PAWS is impulse radar. The addendum that is attached to the ATP
>>> suggests
>>> otherwise, but it could be wrong. The nature of the RF environment the
>>> receiver will operate in needs to be defined clearly. The ATP
>>> references
>>> that addendum and has a test or two designed to characterize receiver
>>> operation under the conditions that addendum and John's requirements
>>> document outline. Are those assumptions incorrect? Does it really
>>> matter
>>> since this receiver is no longer the command uplink receiver? The
>>> entire
>>> design rests on assumptions that may or may not be accurate. All of
>>> these
>>> issues need to be addressed before John is turned on to begin the
>>> revision
>>> process.
>>>
>>> I also question the mechanical layout of the receiver. Having the
>>> Can-do
>>> module at right angles to the receiver makes no sense in terms of space
>>> utilization. Perhaps it should be a daughter board that sits
>>> parallel to
>>> the main PCB. The DB15 also doesn't make any sense to me. I'm
>>> sorry but
>>> why use such a large connector? At the very least a 15-pin
>>> connector could
>>> be used that occupies a DB9 shell. That connector dictates having the
>>> Can-do module vertical, which in turn forces the chassis to be much
>>> higher
>>> than it needs to be. The front panel space is also severely
>>> restricted by
>>> the Can-do PCB, leaving very little room for connectors associated
>>> with the
>>> main PCB.
>>>
>>> The case itself is flexible and that flex will be transferred to the
>>> PCB and
>>> from there to the SMD devices, many of which are very susceptible to
>>> mechanical damage from board flex. Lastly, the entire rear third of
>>> the
>>> chassis is empty - another waste of space. I know I'm stepping on
>>> toes but
>>> I'd much prefer milled aluminum boxes to sheet metal. They wouldn't
>>> necessarily be much heavier and would be much more rigid, providing
>>> badly
>>> needed stability to the PCBs. I fully expect to be shot down on
>>> this but it
>>> should be open to discussion while a new requirements document is
>>> created.
>>> Working with surface mount devices is completely different than the
>>> through-hole PCBs of the past. These devices have special needs
>>> that can
>>> only be ignored at your peril.
>>>
>>> I don't mean this email to be a complaint because we've learned a
>>> tremendous
>>> amount in the process so far. I'm actually very excited about the
>>> chance we
>>> now have to really tighten up the requirements definition process
>>> and take a
>>> fresh look at this receiver. The lessons learned on this project
>>> will make
>>> life much easier for the next group. I'm convinced.
>>>
>>> 73,
>>>
>>> Juan
>>> WA6HTP
>>>
>>>
>>>
>>>
>>
>>
>
>
Bob,
I hear what you say about machined housings and the concerns that Juan
has about sheet metal. Personally I prefer a machined housing to help
(not cure) many of the issues that Juan raises regarding CTEs.
Consider this.....
I have been using eMachineshop ( www.emachineshop.com) with great
success and with very nice pricing for rather simple machined housings
for my microwave widgets. I have a small prototype mill and lathe to
build the first one and when I'm happy, the drawing is converted to
their software, the quote is done online, you place your order and the
parts come in the mail. So we don't need a team member with CNC
capability. Since our housings are somewhat "universal", a "basic"
housing can be machined (in quantity) with modifications tailored to the
specific circuit variations required. Seems like we have to do that with
the sheet metal housing anyway.
Just a thought!!
Regards...Bill...N6GHz
Robert Davis wrote:
> Juan,
> You bring up things that should be discussed. I hope you're not as
> frustrated as your email sounds. If you are, then I fear that our
> communication shortcomings are worse than the technical problems you
> refer to.
> I can comment on a couple of your points.
>
> Here's the history of the module development as I heard it. From AO-40
> there was the desire for greater access to components on the PCBs, by
> removing the side walls. As a reaction, Dick created a lightweight
> module where the PCB mounts to the baseplate, then a cover is added.
> This was his solution for the "requirement" he was given or at least
> interpreted.
> I absolutely recognize the problem of having a baseplate that can be
> flexed or even bent, to which a geometrically sensitive circuit board
> is screwed, and then this is contorted to fit a potentially imperfect
> cover. It seems to me that machining a module (base & walls) would
> contradict the requirement Dick had to begin with. It's also possible
> that the requirement for greater access is just plain at odds with
> SMDs. Maybe this can be improved with a thicker baseplate. This is
> absolutely an open issue right now.
>
> The CAN-DO is another topic. You're right. You can trade internal area
> for the connector face. I do regret that this was not a specific
> conversation earlier, as you have the PCB area to do almost anything.
>
> As for the unused area inside the module, I personally have no
> interest in pursuing module dimensions that react to the PCB
> dimensions in both planform directions. We already have 3 module
> variants where we vary one planform direction. I think this is enough.
> The spacecraft module mounting real estate is not valuable enough to
> make modules based on each PCB delivered. We've essentially bloated
> the exterior of Eagle to generate more power, and the innards haven't
> changed much.
>
> You also bring up machined chassis. On AO-40, AMSAT paid for *a lot*
> of machining, because AMSAT has no specific CNC capabilities.
> Volunteers offer what they have, and whatever volunteers we have this
> year has entered into our decisions on what to make. And certainly
> this is the case for machined modules versus bent sheetmetal. Using
> jigs, it was seen as a good thing that modules could be replicated by
> someone with perhaps fewer fabrication capabilities. The bent
> sheetmetal chassis have alignment issues that in the 3 or 4 prototypes
> we made, we were unable to demonstrate reliable tolerances. This
> didn't bother me so much, as the alignment jigs for bending were built
> during this process. You certainly imply here that sheetmetal modules
> are not compatible with SMD PCBs. I hope that's not true, as then
> that's a driving requirement for us mechanically.
>
> Anyway, there's my comments for the day. I suspect the issues you
> bring up are major enough that we'll be addressing them for a while,
> not simply a weekend of emailing.
>
> Best regards,
> bob
> Robert Davis
> KF4KSS
>
