Without that absurd amount of data, I might have some reservations about taking 
such shortcuts.  With the data, I have an idea of the curve between the points 
I choose.  I also use the trends in a graph to extend the curve past the end 
points of the antennas to makeup points that help the interpolation function.  
ps. I haven't found any cheaper cal service for gettin fewer points.  But I 
have found more expensive ones for asking for a custom table of points - I 
wanted to see the data on some suspect areas of the antennas, and they are not 
normally given, from using bigger jumps in frequency than I want.

- Bill
Indecision may or may not be the problem.

--- On Sun, 6/7/09, Brent G DeWitt <[email protected]> wrote:



        From: Brent G DeWitt <[email protected]>
        Subject: RE: [PSES] Measurement Accuracy and antenna factors
        To: "'Ken Javor'" <[email protected]>, 
[email protected]
        Date: Sunday, June 7, 2009, 10:35 PM
        
        

        Well said Ken.  I have also dealt with the absurd number of points 
taken by automated systems.  Many years ago I wrote an QuickBasic program 
(yeah, that many years ago), that decimated the data based on exactly the same 
thought.  It did a simple piecewise first derivative as well as looking for 
total changes around .5 to 1 dB, depending entirely on how skeptical I was.  It 
resulted in a huge reduction in frivolous data.

         

        Brent DeWitt

        Westborough, MA

         

        From: Ken Javor [mailto:[email protected]] 
        Sent: Sunday, June 07, 2009 1:43 PM
        To: [email protected]
        Subject: Re: [PSES] Measurement Accuracy and antenna factors

         

        I’m not a fan of all this tenth of a dB concern with uncertainty.  I 
also disagree that antenna factors are selected randomly to be entered into a 
data file.
        
        It seems obvious to me that intelligent data entry would use an analog 
simulation of what the questioner is after: Lots of data points (high density) 
where the factors change rapidly with frequency, fewer points where the factor 
is relatively constant.
        
        I once had a commercial facility calibrate an antenna, and they did so 
at hundreds of frequencies, with the values bouncing around hundredths or 
tenths of a dB from data point to data point.  I’m sorry, but that seems a 
moronic waste of time and money.  All they were plotting was the error bounds 
of their measurement system, not the actual performance of my antenna.
        
        It’s time a for a little common sense to be displayed on this topic.
        
        Apologies in advance if I have hurt anyone’s feelings!
         
        Ken Javor
        
        Phone: (256) 650-5261
        
        
        
________________________________


        From: "ce-test, qualified testing bv - Gert Gremmen" 
<[email protected]>
        Date: Sun, 7 Jun 2009 18:47:36 +0200
        To: <[email protected]>
        Conversation: Measurement Accuracy and antenna factors
        Subject: Measurement Accuracy and antenna factors
        
        A lot of effort has been put into specification of
        measurement accuracies in radiated emissions.
        CISPR 16-4-2  has a number of  uncertainty budgets listed.
         
        One factor that I have not seen in any budget is the
        error introduced by interpolation between
        antenna factor calibration points by the measuring receiver.
         
         
        In general the characteristics of a calibrated antenna
        are entered into the measuring receiver as a number of 
        F/AF pairs, more or less randomly selected from
        the calibration graph. Then the AF values for frequencies
        in between those pairs a quadratic spline function is used
        to interpolate. The function requires 4 calibration pairs to operate 
correctly
        of which 2 must be lower and 2 must be higher then the 
        interpolated frequency. Especially near 30 MHz, where modern
        antennas  have steep AF graphs, a calibration point
        below 30 MHz is not always available and I assume
        the software duplicates the 30  MHz pair to
        say 25 MHz to complete the function’s requirements.
        This must introduce interpolation errors near 30 MHz.
         
        I do now know the error that might be introduced  by this
        Type of function. I know that Taylor series have alternating sign
        In their expansion, and that the values diminish each term,
        so the error of approximation remain smaller as the last term
        used to interpolate. But Taylor does not suit itself
        for approximation of non computable data (such as AF).
         
        My questions for the group are:
         
        What requirements are to be met for the F/AF pairs to
        minimize errors?
         
        What are the errors introduced by interpolation?
         
        How do YOU handle this additional uncertainty…?
         
        Gert Gremmen
        Ce-test qualified testing bv
         
         
         
        
        Van: [email protected] [mailto:[email protected]] 
<http://us.mc01g.mail.yahoo.com/mc/[email protected]]>  Namens Bill 
Owsley
        Verzonden: zondag 7 juni 2009 4:36
        Aan: [email protected]; [email protected]; GheryPettit
        Onderwerp: RE: CISPR 22-2005: testing on interconnecting DC cables?
        
         
          I routinely measure the same, but I have not been able to establish 
that there is any requirement for a direct measurement.  In general, if the EMI 
from the DC cables causes a problem it will show  in the usual required tests.  
A test on the DC cables just focuses on the problem area and helps with debug 
efforts, but I have not been able to claim that it is required by CISPR 22 (or 
related standards)  ps. Some of the DC cables are much longer than any standard 
one normally used and so come fall under some of the immunity tests, so by 
quantum leaps in logic, we apply the emissions test to them.  But when it comes 
time to ship, no problem...
         
         - Bill
         Indecision may or may not be the problem.
         
         --- On Fri, 6/5/09, Pettit, Ghery <[email protected]> wrote: 
         From: Pettit, Ghery <[email protected]>
         Subject: RE: CISPR 22-2005: testing on interconnecting DC cables?
         To: "[email protected]" <[email protected]>, 
"[email protected]" <[email protected]>
         Date: Friday, June 5, 2009, 2:25 PM  Pat,
         
         Annex C deals exclusively with telecommunication ports.  This is clear 
in the first sentence of the annex.  If a port isn't used for 
telecommunications (see article 3.6 in CISPR 22:2008 for the definition) then 
Annex C doesn't apply.  And while the term "mains" isn't defined in the 
standard, it commonly is taken to mean the low voltage distribution network in 
a building that is supplied from the public power supply.  Thus, the mains port 
is the port that plugs into the wall socket.  I don't see how the DC output 
port on your power supply is either a telecommunications port or a mains port, 
so this test by your customer doesn't make sense to me, at least not as a 
'requirement' in CISPR 22.  
         
         I hope this helps.
         
         Ghery S. Pettit
         
         
         -----Original Message-----
         From: [email protected] </mc/[email protected]>  
[mailto:[email protected] 
<http://us.mc01g.mail.yahoo.com/mc/[email protected]>  
</mc/[email protected]> ] On Behalf Of [email protected] 
</mc/[email protected]> 
         Sent: Friday, June 05, 2009 10:48 AM
         To: [email protected] </mc/[email protected]> 
         Subject: CISPR 22-2005: testing on interconnecting DC cables?
         
         Good Friday morning all,
         
         We have a customer who is measuring conducted emissions on the DC 
output 
         of our external switching power supply (laptop-style power supply), 
         claiming it is required by CISPR 22.  As I read through CISPR 22-2005 
for 
         rebuttal material, the phrase telecom port was defined and the 
measurement 
         details looked clear.  Until I got to Annex C.
         
         Clause C.1.5 is titled 'Flowchart for selecting test method', and says 
the 
         flowchart in Figure C.6 is applied to different ports.  The flowchart 
has 
         a decision block at the top based on whether the port is a telecom 
port. 
         If not, no testing is necessary. 
         If the port is a telecom port, you choose between 4 methods:
         - Unscreened pairs
         - Screened or coaxial
         - Mains
         - Other
         
         Certainly, Mains ports need testing regardless of whether the EUT has 
         telecom ports, so the flowchart has logic errors. 
         But does the port choice 'Other' mean you must test any port not 
already 
         covered?  Can a single statement in a flowchart define testing 
         requirements not detailed elsewhere?  BTW, the flowchart says 'Other' 
         ports must meet the telecom test limits.
         
         Pat Lawler
         EMC Engineer
         SL Power Electronics Corp.
         
         -
         ----------------------------------------------------------------
         This message is from the IEEE Product Safety Engineering Society 
emc-pstc discussion list. To post a message to the list, send your e-mail to 
<[email protected] </mc/[email protected]> >
         
         All emc-pstc postings are archived and searchable on the web at:
         http://www.ieeecommunities.org/emc-pstc
         Graphics (in well-used formats), large files, etc. can be posted to 
that URL.
         
         Website:  http://www.ieee-pses.org/
         Instructions:  http://listserv.ieee.org/request/user-guide.html
         List rules: http://www.ieee-pses.org/listrules.html
         
         For help, send mail to the list administrators:
         Scott Douglas <[email protected] 
</mc/[email protected]> >
         Mike Cantwell <[email protected] </mc/[email protected]> >
         
         For policy questions, send mail to:
         Jim Bacher:  <[email protected] </mc/[email protected]> >
         David Heald: <[email protected] </mc/[email protected]> >
         
         -
         ----------------------------------------------------------------
         This message is from the IEEE Product Safety Engineering Society 
emc-pstc discussion list. To post a message to the list, send your e-mail to 
<[email protected] </mc/[email protected]> >
         
         All emc-pstc postings are archived and searchable on the web at:
         http://www.ieeecommunities.org/emc-pstc
         Graphics (in well-used formats), large files, etc. can be posted to 
that URL.
         
         Website:  http://www.ieee-pses.org/
         Instructions:  http://listserv.ieee.org/request/user-guide.html
         List rules: http://www.ieee-pses.org/listrules.html
         
         For help, send mail to the list administrators:
         Scott Douglas <[email protected] 
</mc/[email protected]> >
         Mike Cantwell <[email protected] </mc/[email protected]> >
         
         For policy questions, send mail to:
         Jim Bacher:  <[email protected] </mc/[email protected]> >
         David Heald: <[email protected] </mc/[email protected]> > 
          
        
        -
        ----------------------------------------------------------------
        This message is from the IEEE Product Safety Engineering Society 
emc-pstc discussion list. To post a message to the list, send your e-mail to 
<[email protected]>
        
        All emc-pstc postings are archived and searchable on the web at 
http://www.ieeecommunities.org/emc-pstc
        Graphics (in well-used formats), large files, etc. can be posted to 
that URL. 
        Website: http://www.ieee-pses.org/
        Instructions: http://listserv.ieee.org/request/user-guide.html
        List rules: http://www.ieee-pses.org/listrules.html 
        
        For help, send mail to the list administrators:
        Scott Douglas <[email protected]>
        Mike Cantwell <[email protected]> 
        
        For policy questions, send mail to:
        Jim Bacher <[email protected]>
        David Heald <[email protected]> 
        -
        ----------------------------------------------------------------
        This message is from the IEEE Product Safety Engineering Society 
emc-pstc discussion list. To post a message to the list, send your e-mail to 
<[email protected]>
        
        All emc-pstc postings are archived and searchable on the web at 
http://www.ieeecommunities.org/emc-pstc
        Graphics (in well-used formats), large files, etc. can be posted to 
that URL. 
        
        Website:      http://www.ieee-pses.org/
        Instructions:  http://listserv.ieee.org/request/user-guide.html
        List rules:     http://www.ieee-pses.org/listrules.html 
        
        For help, send mail to the list administrators:
        Scott Douglas <[email protected]>
        Mike Cantwell <[email protected]> 
        
        For policy questions, send mail to:
        Jim Bacher  <[email protected]>
        David Heald <[email protected]> 

        -
        ----------------------------------------------------------------
        This message is from the IEEE Product Safety Engineering Society 
emc-pstc discussion list. To post a message to the list, send your e-mail to 
<[email protected] 
<http://us.mc01g.mail.yahoo.com/mc/[email protected]> >
        
        All emc-pstc postings are archived and searchable on the web at 
http://www.ieeecommunities.org/emc-pstc
        Graphics (in well-used formats), large files, etc. can be posted to 
that URL. 
        Website: http://www.ieee-pses.org/
        Instructions: http://listserv.ieee.org/request/user-guide.html
        List rules: http://www.ieee-pses.org/listrules.html 
        For help, send mail to the list administrators:
        Scott Douglas <[email protected] 
<http://us.mc01g.mail.yahoo.com/mc/[email protected]> >
        Mike Cantwell <[email protected] 
<http://us.mc01g.mail.yahoo.com/mc/[email protected]> > 
        For policy questions, send mail to:
        Jim Bacher <[email protected] 
<http://us.mc01g.mail.yahoo.com/mc/[email protected]> >
        David Heald <[email protected] 
<http://us.mc01g.mail.yahoo.com/mc/[email protected]> > 
        -
        ----------------------------------------------------------------
        This message is from the IEEE Product Safety Engineering Society 
emc-pstc discussion list. To post a message to the list, send your e-mail to 
<[email protected]>
        
        All emc-pstc postings are archived and searchable on the web at 
http://www.ieeecommunities.org/emc-pstc
        Graphics (in well-used formats), large files, etc. can be posted to 
that URL. 
        Website: http://www.ieee-pses.org/
        Instructions: http://listserv.ieee.org/request/user-guide.html
        List rules: http://www.ieee-pses.org/listrules.html 
        For help, send mail to the list administrators:
        Scott Douglas <[email protected]>
        Mike Cantwell <[email protected]> 
        For policy questions, send mail to:
        Jim Bacher <[email protected]>
        David Heald <[email protected]> 


-

This message is from the IEEE Product Safety Engineering Society emc-pstc 
discussion list. To post a message to the list, send your e-mail to 
<[email protected]>

All emc-pstc postings are archived and searchable on the web at 
http://www.ieeecommunities.org/emc-pstc
Graphics (in well-used formats), large files, etc. can be posted to that URL. 

Website: http://www.ieee-pses.org/
Instructions: http://listserv.ieee.org/request/user-guide.html
List rules: http://www.ieee-pses.org/listrules.html 

For help, send mail to the list administrators:
Scott Douglas <[email protected]>
Mike Cantwell <[email protected]> 

For policy questions, send mail to:
Jim Bacher <[email protected]>
David Heald <[email protected]> 


Reply via email to