Hi
Bob,
No,
I’m
not as frustrated as I sound. Let me try to imbed my comments in your
email…
From: Robert Davis
[mailto:[email protected]]
Sent: Saturday, May
26, 2007 4:28
PM
To:
[email protected]
Cc: Jim Sanford; Rick Hambly; Bob McGwier;
Gould Smith; William A
Schmitt; Lou McFadin; Lee McLamb; Stan Wood; Tom Clark; Bill Ress;
[email protected]; Dick Jansson-rr; John B. Stephensen
Subject: Re: We need
to step back
and reorganize
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.
I
think access
to the PCB once it’s in a chassis needs to be carefully considered.
The ceramic chip capacitors are sort of the canary in the coal mine.
They
are extremely brittle and easily cracked during assembly, rework, PCB
flexing, and
so forth. They can also be damaged by CTE induced stress. Cracks
can easily go unnoticed and cause a failure at a later date. They tend
to
fail in nasty ways such as a short. I’ve attached a short paper
from the manufacturer AVX that discusses several issues that we are
touching on
here. They seriously frown on touching a cap with a test probe, your
fingers, or a soldering iron tip for example. Given all these cautions
I
question why access to the PCB is required once it’s in the
chassis. It is however, extremely important to prevent any stresses
from
damaging those sensitive parts. Unlike through-hole leaded parts, they
can’t absorb stress by flexing their leads. Assuming for the moment
that the PCB was mounted to a chunk of granite, there would still be
many
sources of stress to be considered during design, assembly, and
handling.
It’s impossible to completely avoid thermal coefficient of expansion
(CTE) mismatches. Each component mounted to the PCB has a different
CTE,
and they are all going to differ from the PCB itself. The greater the
temperature extremes that the receiver must survive, the more CTE
mismatch
becomes an issue. This is one major reason that -70C is such a huge
issue
to me. That’s almost down to the temperature of liquid CO2.
Now,
if we
mount the PCB on a chassis that is not completely plumb, or stable,
then any
flexing of the chassis will be transferred to the board, and from the
board to
the components. Since they can’t flex the solder joints are
stressed, along with the part. You want everything to be in a neutral
state half way between the two temperature extremes. That’s one of
the reasons that hand soldering as we normally practice it is very
bad.
The component expands as it is heated, but the PCB doesn’t. That
puts the part under static stress when it tries to contract as it
cools.
This is why the PCB must be preheated before any soldering operations
take
place.
Given
all of
the above, I think its imperative that whatever chassis is used is very
stable
and is not warped. The same goes for the surface that the chassis is
to
be mounted on. If there is a misalignment I think it should be deal
with
by shimming and not by flexing the chassis to pull the high side down.
If
all this can be done with sheet metal then that’s fine, but it’s
been my experience that it’s these little nit picking details that make
the difference between success and some unknown early failure –
probably after
a few hundred thermal cycles in orbit.
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.
In
the case of
this particular receiver perhaps we could think about mounting the
Can-do
module flat to free up badly needed front panel space. Right now there
is
a mechanical problem with the two SMA IF output connectors being too
close
together and also blocking a chassis mounting hole. It’s worth a
thought since we have plenty of real estate.
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.
I
agree.
I just don’t like to see wasted space going into orbit.
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.
Well,
I don’t
want to start dictating what kind of chassis should be used. I’m
not a metal worker or machinist. Once the thermal environment is
nailed
down we can do an analysis based on the component specifications that
should
lead to a spec for chassis flexing and mounting flatness. Then you can
determine how best to meet it. I think that makes sense.
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.
I
am of the
opinion that the early problems and high level of confusion so far are
indications of a flaw in the process, or lack there of. I’d hate to
think that the entire satellite will be constructed in this manner. I
also understand that this is a volunteer effort and not a DoD
multimillion
dollar project. I think a few fairly simple steps can be taken to
insure
that requirements are accurate and complete before work begins. Of all
the process and procedural paperwork I have been exposed to at work, I
think
there are about three documents and as many procedural steps that
should
be used on this project:
SCD
–
Specification Control Drawing
ICD
–
Interface Control Drawing
ATP
–
Acceptance Test Procedure
The
SCD spells
out exactly what it is that is to be built, how it is to work, what it
is to
do, etc.
The
ICD spells
out all of the interface requirements and how your device will
interface to
others – power, control, RF, and so forth
The
ATP spells
out the testing that is to be passed before the unit is considered to
be
delivered
Then
there are
usually several meeting during the life cycle of the project:
PDR
–
Preliminary Design Review
CDR
–
Critical Design Review
You
get the
idea. Some top-level document spells out exactly what each of these
documents is to contain and how they are to be written, and when and
what is to
be covered at these meetings, and which groups are to attend and have
input.
One
more
important point – these requirements should not be written by the
people making
the part. These are high-level tasks for someone with the broad
overview
picture of the entire satellite.
73,
Juan
WA6HTP
On
5/25/07, Juan
Rivera <[email protected]>
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