[eagle] EMI in Eagle (Was: CAN-Do-Too! ??????????)

[n1al@cds1.net]

Re electromagnetic interference in Eagle:

I suspect the big issue will be neigher component cost nor weight, but
rather the size of the engineering task, both for the specification writer
and the hardware designers.

An over-complicated spec just makes extra work for everybody.  A
too-simple spec risks a last-minute re-design.  Paraphrasing Einstein, the
specification should be as simple as possible, but no simpler.

Alan


> 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.
>
> 73,
>
> John
> KD6OZH
>
> ----- 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
>
>