Derek:
About the only place I would like to fall is on the side of truth and integrity. I’ll drop some bright blue comments into your response below This is long; too bad I don’t get paid by the word! Ed Price WB6WSN Chula Vista, CA USA From: DEREK WALTON [mailto:[email protected]] Sent: Wednesday, April 17, 2019 8:47 PM To: Edward Price Cc: EMC-PSTC Subject: Re: [PSES] Question re: Measuring a signal in a noisy environment Whoah Ed, you just landed along side Ken and Ghery! Derek, I’m not aiming my comments at you, you are simply in the sequence of the thread. But however I have landed, I feel I’m in good company. I don’t know why you would “strongly oppose some of my views” because I always thought that I was on the side of reason and sweetness. I have to strongly oppose some of your views on what the test lab should or shouldn’t Know/do. Wow, have you any idea of the variety of equipment that roles in the lab door, and the complexity of it? NO, it is NOT the labs job to understand the EUT, other than how to interpret the standard so it can be tested. It is totally unreasonable to expect a test person to muse the subtleties of sub micron silicon one day then the ramifications of 10,000 psi hydraulic pumps the next. I doubt few could listening in. I spent 44 years doing multiple phases of EMC, about 8 years in an independent test lab, about 18 years in an in-house lab doing mostly military testing for multiple divisions of a big conglomerate plus some outside commercial testing, about 2 years of consulting and about 16 years running a 2-man in-house test lab doing military and outside commercial testing. So yes, I have some ideas about testing variety, as I have tested everything from stereo tuners to mainframe computers, power tools to encrypted data links, aircraft APU’s to Abrams thermal sights, Atlas to Stinger to Tomahawk, Sony & Medtronic, Ohio class launch consoles & Apollo ALSEP to a whole lot of stuff what goes zoom and boom. I did FCC 15 & 18, man-worn electronics and GPS. Having had the luxury of “visiting" well over 350 labs around the globe over the last 23 years I’ve gathered quite a bit of insight on lab operations and their clients. I happen to have worked in one for 40 years and owned one or two for 30+ years. So much of the email thread is huff and puff. IN the sales world it would be called FAD: fear and disillusionment. On every EMC job I undertook, I owned the job, from planning to test report. I felt it was my responsibility to understand the support needs of the EUT, to review the operational modes of the EUT, to anticipate setup and operational problems and to anticipate issues associated with support equipment and possible chamber interface degradation. It was not my area of expertise to know the inner workings of the EUT or the support equipment, but it was my responsibility to think of them as big black boxes with a controlled perimeter, and to know how the EUT box related to support boxes and the whole outside World. I didn’t expect my customer to be an expert in either the standard or the test process. My customer came to me because I had the testing facilities and I knew how to expertly operate those facilities to deliver a competent test and understandable & accurate test data. Ultimately, I sold reliable answers, not specification interpretations. Lets set some records straight: The majority of labs do a superb job with all the constraints they are under. And yet this particular lab did NOT do a superb job. They advertised expertise and competence, but delivered polluted data. Can we find out why? You know what they say about rocket explosions? The majority of the parts worked fine. An ISO 17025 assessment cannot prevent mistakes, but it does make provisions for just about all foreseeable, and quite a few unforeseeable problems. Mistakes happen, but systems are established to catch those mistakes. If a very basic mistake happens, and is not noticed, then the “mistake catching system” seems to be a tad less than superb. Not having your chamber ambient under control, and not knowing it, is a massive failure of lab performance. I fault the tech for not seeing the noise during data acquisition, the managing EMC Engineer for allowing an environment in which this can happen, and the assessment system for blessing an operational environment where this fundamental type of problem can exist. I think fixing this is best started top-down. The technical reason for the noise intrusion may not be easy to fix, but for the data pollution to go unnoticed is very unprofessional. Everyone can have a bad day: that includes test engineers/technicians. I have had bad test days, but I always operated under the assumption that things will break and the process will scream out of control, so I include periodic confidence checks. An attenuator might get cooked, a current probe gets dropped, an antenna gets bent, a coax might go lossy or the software might decide it was time for a negative miracle. You build “check measurements” into your operational testing so that you can be flagged that something has gone wrong before you have wasted a lot of time creating incorrect data. (The type and frequency of these confidence tests is always debatable; it depends on your tolerance for risk.) Technology evolves, and what’s true at one point may not be true sometime later. Unless everything is checked to the nth degree, EVERY time, things will escape notice. For all those calling out check after check, I bet under the same breath they are complaining about the cost of testing! Absolutely true, but what is the true cost of bad data? Catch the problem after 4 hours and it’s embarrassing. Not catching it at all can cascade into many wasted man hours, schedule slippage, wasted redesign effort and wasted retesting effort. And maybe at the worst, your customer goes home and you begin a new day with a new customer, ready to repeat your faulty process. How many customers will you fail before somebody notices a pattern? And for the record, those critical of overseas test labs should go and pay a visit: most times they are careful to incredible levels running tests. Who said anything about where the lab was located? But now that you mention that, there are some cultures where certain types of errors happen with greater frequency. The aviation industry has worked hard to eliminate flight crew historic cultural attitudes which have contributed to accidents. There is no reason that similar attitudes are not present in some test labs. If a manufacture brings a device in for testing, no-one, that’s NO-ONE knows it better than he does. He has a responsibility to understand the testing his device will be subjected to and its behavior, heck, he’s supposed to have designed the device to pass the test! That includes support equipment too! Until your customer has “gone around the track a few times,” he probably knows very little about the details that can cause his product to not comply. Oh sure, every so often you get a customer who has his own in-house pre-compliance group that really knows their stuff, and they walk in with excellent support equipment and an EUT that they know is 15 dB on the safe side of the standards. All they need is a proper test lab to run through the tests and give them a formal blessing. From my experience, that might happen once a year. You have to be prepared for the customer who brings in a rat’s nest collection of Radio Shack components nailed to a sheet of plywood, with all I/O lines and powerlines Ty-wrapped into a single, thick bundle. I will readily admit that my experience grows more obsolete with each passing year, but, in the battle between human nature and procedural controls, the smart money is on human nature. A lab should help someone who’s a novice in the EMI field to avoid pitfalls, that’s professional curtesy. It’s also in the labs interest as they don’t want someone packing up and leaving a few hours into the day and leaving the rest of the day not generating revenue. This topic is huge, and I hear so called experts spout contentious opinions that are ill founded. It’s particularly distasteful especially in a professional form such as this as it forms false opinions in peoples minds, especially as some of these experts have a high platform from which to pontificate. There isn’t a rampant problem in the testing community, and many hardworking technicians, engineers, managers, QA people, Assessors, assessing bodies and even test witnesses would be very aggrieved to hear some of these statements. Well, in this forum we already don’t name names, so I think that’s about as much cover as I’m willing to give some place that has royally screwed up. My “professional colleagues” will just have to learn to live with “distasteful” situations. I value honesty and integrity more than taste. Notice that I’m not suggesting execution for mistakes, but if mistakes are not talked about and critically examined, there is little pressure to correct what has caused the mistake. I’m not sure what you mean by someone having a “high platform” (as I’m retired, I don’t think I even have a platform), and I never thought of myself as a “pontificator” (although I do regularly argue with my Spell Checker). I also think that there is no “rampant problem” in the testing community, but that’s not to say that every lab I have seen has an equal commitment to quality (I have been an independent lab, been an in-house lab, done testing for other labs and sent overflow work to other labs; I think I have seen every angle of the business except being an assessor). I can recall a few nameless labs where I knew trouble was in their future, either because they were terminally frugal, their tech management had no curiosity or their business management was pressing them to cut corners. Testing is a team mentality, And YOU are the coach, ultimately responsible for whoever trips, drops the ball or who doesn’t read the playbook. not a glass wall mentality. Don’t know about a glass wall, but testing people certainly have a glass ceiling. In a large company, compliance testing is a near guarantee of never making Vice-President. And valid data is the responsibility of BOTH parties. Valid data is more the lab’s responsibility than the customer’s. If pressed, I would put the ratio at about 80/20. It requires capable people who have a systematic work approach. And the hallmark of a good system is the inclusion of sufficient internal controls to limit the damage of mistakes. So unless ALL the full details are known spreading scuttlebutt or opinions of what could have/should have, is NOT helpful. ALL the full details are NEVER known until the autopsy. Most people in this forum are very hesitant to properly describe a problem they have; they will sanitize it and give hints and do everything possible to make the issue as generic as they can. As such, it is difficult to make any helpful suggestions without a bit of speculation. After a few rounds of speculation, a few facts get sprinkled into the thread and just maybe there is some resolution. But Derek, when somebody tells me that their product was declared non-compliant because the test lab measured noise external to the shielded enclosure, that information runs a bit higher than “scuttlebutt.” My 10 cents as I have to go back and tend to a test I’ve been running since 6am. Hmm, automated testing? Nothing like a computer to ease you into a disaster. Been there, done that! ☺ Shalom. Derek. - ---------------------------------------------------------------- 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.ieee-pses.org/emc-pstc.html Attachments are not permitted but the IEEE PSES Online Communities site at http://product-compliance.oc.ieee.org/ can be used for graphics (in well-used formats), large files, etc. Website: http://www.ieee-pses.org/ Instructions: http://www.ieee-pses.org/list.html (including how to unsubscribe) 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]>
