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

Juan Rivera juan-rivera at sbcglobal.net
Tue Jul 10 20:26:06 PDT 2007


An EMI spec doesn't have to become an intractable problem.  Let's approach
this from a purely practical standpoint.

>From a Global Perspective:

1) Build up the proposed switching battery charger circuitry and quantify
the conducted noise output.  Do the same for anything else that is part of
the common power distribution for Eagle.

2) Create a piece of hardware that mimics that conducted noise - just copy
some of the switching supplies that will actually be used and stick them in
a box...

Write a spec that says that while receiving primary DC power from this noisy
power source the stuff has to still work, and then define 'work'.

CAN-Do/Enclosure combination:

Once these two are sorted out then you can do the same thing again here.
Equipment receiving switched power from CAN-DO has to be able to work while
getting the noisy primary power fed through the CAN-Do module, and sitting
inside the enclosure.

Obviously this is a simplification, but if we create several noisy power
sources that mimic what we expect to see in orbit, then the spec doesn't
have to deal with radiated field intensity and other parameters that we
can't measure anyway.  Just stick your board in an enclosure, close the lid,
run it off the noisy power, and see how it works...

That's my two cents worth.



-----Original Message-----
From: eagle-bounces at amsat.org [mailto:eagle-bounces at amsat.org] On Behalf Of
John B. Stephensen
Sent: Tuesday, July 10, 2007 8:35 AM
To: n1al at cds1.net; eagle at amsat.org
Cc: eaglesensor at vom.com
Subject: [eagle] Re: CAN-Do-Too! ??????????

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 

Via the Eagle mailing list courtesy of AMSAT-NA
Eagle at amsat.org

More information about the Eagle mailing list