[eagle] Re: CAN-Do-Too! ??????????

John B. Stephensen kd6ozh at comcast.net
Tue Jul 10 08:34:30 PDT 2007

Designing for the worst case probably makes sense for Eagle. The number of 
units being built is tiny so component cost for the electronics is not a big 
issue. The big issue is weight.



----- Original Message ----- 
From: "Alan Bloom" <n1al at cds1.net>
To: <eagle at amsat.org>
Cc: <eaglesensor at vom.com>
Sent: Tuesday, July 10, 2007 06:37 UTC
Subject: [eagle] Re: CAN-Do-Too! ??????????

> Jim wrote:
>> 4.  EMI Spec:  You put a gun to my head, and I'm going to pull out the
>> MIL-STD, which is probably overkill, but MAYBE NOT.  I'd really prefer
>> that one of you guiys current in the INDUSTRIAL world take on this
>> task and come up with something good enough and reasonable.
> I specified several power supplies when I worked for HP/Agilent.  I
> found it really hard to come up with system-level noise specifications
> in instruments for the same reasons as in the Eagle project.  The
> problem is that it's a complicated multi-dimensional problem.
> Dimension 1:  Emissions (power supply) vs susceptibility (modules)
> Dimension 2:  Radiated vs conducted emissions
> Dimension 3:  Interference path:
>  Radiated:
>  - Magnetic (inductive) vs electric (capacitive) coupling
>  Conducted:
>  - Power supply bus vs signal lines vs ground loops
>  - Voltage (open circuit) vs current (short circuit) specification
> Dimension 4:  Emissions level versus frequency (audio to microwave)
> Dimension 5:  Broadband vs narrowband interference
> (Some circuits are more susceptible to sine-wave interference, some to
> pulse-type interference, some to broadband noise.)
> If you specified every box in the N-dimensional matrix you would have
> hundreds of specifications.
> Add to that the fact that the power supply must be specified before the
> subassemblies are designed/built/tested and vice versa, and it becomes
> an almost intractable problem.
> The military's solution is to specify all power supplies and
> subassemblies for the worst-possible situation you can imagine.  While
> that does improve the probability of success, it still is not perfect
> and is very expensive.
> On the projects I worked on, we basically just specified the power
> supply as good as reasonably practicable using standard shielding and
> filtering techniques and then did whatever was needed in the various
> subassemblies to make the instrument meet specifications.
> One point to pay attention to is ground loops.  Ideally there would be a
> single-point ground in the spacecraft (probably in the main power
> supply).  The idea is that each assembly's ground return connects only
> with a separate wire to the single-point ground.
> It's not practical to do that 100% (think of the Can-Do power bus for
> example) but any module that can draw large current transients from the
> power supply should probably have separate power and ground wires that
> connect directly to the power supply.  Also, any sensitive modules
> should not have any additional ground returns on the module side of
> their power supply filters.  (That is, the ground return should go
> through the on-board filter.)
> Al N1AL
> On Mon, 2007-07-09 at 18:30, Jim Sanford wrote:
>> All:
>> I'm excited to read all of the emails on this topic.  Several
>> thoughts, which I'd really like to discuss in more detail with all of
>> you tomorrow night on TeamSpeak.
>> 1.  As an experiment, and data collection exercise, I'd like to see
>> the inductor Juan identified as the source of radiated EMI replaced
>> with a shielded inductor or toroid.  As I mentioned to some of you, I
>> saw a similar noise problem (source & victim were reversed) in my day
>> job solved with exactly that one change.  I think this would tell us
>> much about how big a problem we have (radiated and conducted), and be
>> a useful piece of data for posterity.  As Bdale said almost two years
>> ago, "Our legacy may very well be our documentation."
>> 2.  Second, I'd like to see if we can, with a few ccomponent changes
>> on the existing widget board change the switching power supply
>> frequency as Juan suggested.  Another useful data point, with minimal
>> effort.
>> Request for action:  Can one of Chuck, Lyle, Stephen, or Bdale take on
>> obtaining a shielded/toroidal inductor of the same value and provide
>> to Juan for testing, and then take on researching a change to the
>> switching PS frequency?  IF so, Juan, would you and your team please
>> make the changes and repeat testing?
>> 3.  Regarding Chuck's comment:  If we wind up with Can-Do Too, I'd ask
>> Juan if his accomplished project oscar team could take on component
>> selection/purchase and construction of a couple of prototypes?  This
>> could happen in parallel with John's redesign of the U-band receiver.
>> I know you guys have done a lot, but, YOU"RE GOOD!
>> 4.  EMI Spec:  You put a gun to my head, and I'm going to pull out the
>> MIL-STD, which is probably overkill, but MAYBE NOT.  I'd really prefer
>> that one of you guiys current in the INDUSTRIAL world take on this
>> task and come up with something good enough and reasonable.  In
>> general, I'd like to eliminate as much mass and extra "touch" labor in
>> the assembly process (multiple shields) as possible.  Bob Davis:
>> Please weigh in here, if the possible milled modules simplify this
>> issue, please enlighten us.
>> 5.  Chuck:  I appreciate your comments on lessons learned.  You
>> obviously have some things in mind, please scribble them down, get
>> them to me, and I'll get placed on the EaglePedia lessons learned
>> page.
>> 6.  CAN-Do! team:  Several folks have opined to me that it appears
>> that the widget design is final, complete, and we'd better live with
>> it.  I'd intended to discuss some of the above with you when Bdale got
>> back.  I am EXTREMELY PLEASED AND GRATEFUL to see you stepping up to
>> the plate and acknowledging the need and willingness to do something
>> based on what Juan has learned.  Your intellectual honesty, integrity,
>> and willingness to take on more for the team are recognized and
>> appreciated.
>> 7.  Requirements:  Bob McGwier is correct, we really did start with a
>> very top-level requirements document.  It is not perfect (Bob has
>> hated it from the word go), but can be found on EaglePedia under
>> Functional Requirements.  It is also in need of updating, after the
>> October BoD decision.  On my list to do.  Like you, I have finite
>> energy and time, but it is on my list.  I think John did an EXCELLENT
>> job of documenting the UHF Receiver requirements based on what he
>> knew.  The need for an EMI spec was not obvious, but is now, thanks to
>> Juan's testing efforts and exceptional documentation.  Lou:
>> Functional requirements for power supplies?  Bob Davis:  Functional
>> requirements for structure and thermal performance?  etc. etc.....we
>> have much to do, but I think worthwhile effort.  By the way, I'm
>> reading (in a few spare minutes here and there) an EXCELLENT book on
>> requirements management.  When I finish, look for a review of it on my
>> project management page.  I will also be providing suggestions on
>> writing "good" requirements, based on that book and my recent
>> experiences in the day job.
>> 8.  Somebody brought up the issue of CAN bus vs. discrete wiring
>> harness.  In my mind, the discrete harness is a non-starter.  WAY too
>> much room for error and difficulty in testing.  Yeah, I know the AO-40
>> harness was perfect the first time, but the guys who made that happen
>> have made it clear to me that they don't ever want to do it again --
>> and I agree.  So, I think we should remain committed to the CAN bus
>> for many reasons.  In my view, the recent "issues" with the CAN-Do!
>> widget are just issues to deal with, not show stoppers.  The CAN-Do!
>> team is willing to deal with the issues, and so should the rest of
>> us.  Case closed in my mind.  As always, open to well-justified better
>> idea, but I think the writing remains on the wall.
>> I'm sure there's more action following this recent discussion, but
>> specifics currently elude me.  Feel free to send me suggestions,
>> update the agenda for tomorrow night's TeamSpeak, and please be there.
>> Thank you all.
>> Very 73,
>> Jim
>> wb4gcs at amsat.org
>> Robert McGwier wrote:
>> > Bill Ress wrote:
>> >
>> > > All - -
>> > >
>> > > To add support to Juan's conviction that we need to start developing
>> > > "top down" specifications versus the bottom up activities we've been
>> > > involved with, I would add that  in order to develop a  "realistic" 
>> > > EMI
>> > > spec for the satellites power distribution system, we really need to
>> > > know what those circuits will do.
>> > >
>> > > With that in mind, I feel we need to breadboard the key circuits
>> > > associated with that system and get hard data versus shooting from 
>> > > the
>> > > hip with assumptions. At some point this power system is needed 
>> > > anyway,
>> > > so why not focus design attention on that "top level" system now and 
>> > > get
>> > > that issue settled - or at least better understood?
>> > >
>> > > On the issue of housing panel area, and the possible consideration of 
>> > > a
>> > > Mark 2 version, I think if I remember correctly, there were comments 
>> > > on
>> > > wondering why a DB-9 (or even a physically smaller connector series)
>> > > couldn't be used or are all the 15 pins needed?
>> > >
>> > > Regards...Bill - N6GHz
>> > >
>> > >
>> > >
>> > I also support the breadboarding of primary circuits.  And we did
>> > develop our specifications for the latest incarnation of Eagle top 
>> > down.
>> >   We started with what services we wanted to deliver and moved down 
>> > from
>> > there.
>> >
>> > When I rejoined the project, and started the software defined
>> > transponder movement, and long before I was leadership, the Can-Do was
>> > "in the can".  I had almost no input to it. That said, I really do
>> > support the goal of the CanDo.  Anyone who has heard of the horror
>> > stories of Marie Marr and the wiring harness or seen Lou's spreadsheet
>> > for interconnections  for AO-40 knows that these few words do not do it
>> > justice.  We have found a gremlin.  That is normal in any project of
>> > this complexity and is not easily remedied by specifications in a
>> > project like this where the work and the tools necessary to make the
>> > relevant measurements are spread over the globe.
>> >
>> > I look forward to our doing better as a team.
>> >
>> > Bob
>> >
>> >
>> >
>> ______________________________________________________________________
>> _______________________________________________
>> Via the Eagle mailing list courtesy of AMSAT-NA
>> Eagle at amsat.org
>> http://amsat.org/mailman/listinfo/eagle
> _______________________________________________
> Via the Eagle mailing list courtesy of AMSAT-NA
> Eagle at amsat.org
> http://amsat.org/mailman/listinfo/eagle 

More information about the Eagle mailing list