Hi Michael I'm glad to hear more folks are thinking through the whole system, and whole environment, not just piece-parts. A component approach to requirement allocation makes sense when you procure a component. When you procure or integrate the entire system then the standard approach needs new thinking. Sometimes that's simply asking "why?". The why question brings out history and evolution. I find these to be invaluable in determining next- steps. Very glad to open these questions and have input from folks like Ken who helped drive years of evolution.
Our company also worries about end-to-end performance. We delivery receivers and antennas, sometimes integrated, sometimes as piece parts. We carry the whole burden of RF front end performance. Questions like the ones you ask matter to us. They are carefully considered and discussed in our team meetings. We find our "customer" appreciates that we are thinking more about helping the war fighter accomplish their mission and return home than about pushing requirements out to someone else. Glad to know we are not the only ones! Keep up the good work! I've enjoyed this thread and look forward to more. -Patrick. On Fri, May 29, 2020, 9:08 PM Ken Javor <ken.ja...@emccompliance.com> wrote: > Well, you may be in the uncommon position of procuring a brand new IFF > transponder for your aircraft, and if that is the case, then as an > integrator you can levy any spec you choose, but in general, the military > buys certain models built by outfits such as Rockwell Collins (or whatever > they are called today) and the avionics manufacturer is building to a > single spec – MIL-STD-461 – regardless of what the end item platform might > someday be. Few receivers are built for one particular platform, if only > because the point of a radio is to establish a communication link, so that > it ends up on multiple platforms. > > > > In your example of IFF, with transmit and receiver frequencies close > together and no inherent filtering from the antenna itself, a certain > amount of isolation has to be built into the radio itself. Much like a > radar has to be able to reject any close-in reflection or crosstalk of the > transmit signal into the receive path, in order to be able to receive the > desired reflection from far away. > > > > But in term of setting a limit, the required CS103/104/105 reject ratio in > the radio’s tunable range but outside the receiver bandwidth is 80 dB above > MDS. That is pretty good performance. And out-of-band to the radio, with > a limit at 0 dBm, you are looking at on-the-order-of 100 dB of rejection > (MDS ~ -100 dBm). It seems to me that it is reasonable to place any > required isolation beyond that on the integrator, either through the > out-of-band rejection of the antenna (if the threat is far enough away from > the antenna’s design frequency range), and/or if a broadcast pattern comm > type antenna, placement so as to achieve antenna-to-antenna shading, or the > use of antennas at higher frequencies with some sort of waveguide, even if > it is just waveguide-to-coax conversion, providing for rejection of lower > frequencies through waveguide-beyond-cutoff performance, or through > operational controls or blanking. The integrator has various tools at his > disposal, and the placing of 80 – 100 dB of isolation on the receiver > itself seems quite sufficient a burden. > > > > Also if the EME is from a carrier deck, consider that at the same time the > EME is that intense, the signal to be received from the ship is much higher > than MDS, so that just plain old-fashioned frequency-independent > attenuation can and will be employed by an AGC circuit to keep the intended > signal in the linear range of the IF strip, and maybe even out front of the > mixer depending upon how sophisticated the design. > > > > If someone is trying to impose an untailored CS103/104/105 on a radio in > terms of the desired signal being MDS, while tailoring the reject band > limit based on a stringent -464 EME, I’d say they need to sharpen their > pencils some. > > > > -- > > Ken Javor > > (256) 650-5261 > > > > *From: *Michael Viau <michael.t.v...@gmail.com> > *Date: *Friday, May 29, 2020 at 6:22 PM > *To: *Ken Javor <ken.ja...@emccompliance.com> > *Cc: *"EMC-PSTC@listserv.ieee.org" <EMC-PSTC@listserv.ieee.org> > *Subject: *Re: [PSES] Unreasonable Design Penalties on Receivers > > > > Hey Ken, thanks for jumping in. > > I realize that I’m talking to someone who knows more about this subject > than I ever will, so please read this as if someone with the humility of > Piglet wrote it. > > > > For some clarity, I am an integrator and we usually have a good idea of > the end product we are integrating into when we are procuring the receiver. > As well as at least a rough idea of the antenna characteristics and cables > at play. So it’s not too difficult to come up with the expected rough > estimate for the EME that the receiver would need to perform in well before > the receiver is on contract. > > > > What I’m really trying to ask is why the MIL-STD considers it unreasonable > to put the burden on the receivers front end, and if that’s still a true > statement today? > > > > For example, if I have a 1030/1090 MHz IFF system on my aircraft and I’m > expected to operate at 90% efficiency in a Table 6 environment, then as an > integrator I have to choose which percentage of that burden I want to take > for myself and which I want to give to the supplier. > > If I define the CS104 test limit at 10 dBm, then I know I have to make up > around 40 dB with an external filter to meet my other requirement. This is > because my L-Band antenna and lines are all rated to specifically perform > well in this fiery hot range (understanding that the IFF system in question > is also a contributing factor to the heat in that range). > > Well, if I tell them they need to run the test at 20 dBm, knowing that I’m > still going to need to find a narrowband filter to make up some difference, > am I now being unreasonable to the equipment supplier? > > While it would be nice to slap a filter on the butt end of every antenna, > it has its own trade-offs. > > > > It’s difficult to know whether I’m meeting my 464 requirement without > knowing where the equipment fails to perform. CS104 seems like the perfect > opportunity to show where that threshold is, and there is clearly a ton of > room for tailoring since there is no direct guidance, but for some reason > the limits of the test are “capped”. > > > > Overall, the wording threw me and I’m curious what the logic behind it was > and if it’s still applicable today. > > > > Thanks again, > > A terribly humble Michael > > > > Sent from my iPhone > > > > On May 29, 2020, at 3:11 PM, Ken Javor <ken.ja...@emccompliance.com> > wrote: > > > > I may be missing something here that is obvious to the others, and if so, > please advise. CS103/104/105 are conducted susceptibility tests meaning > two things: > > 1. It‘s conducted (why are we talking about 200 V/m or MIL-STD-464 > EMEs?), and > 2. It’s a susceptibility requirement, so proper operation is the > metric, not whether you blow the thing up or not. > > The point I really don’t understand is the leap from the CS103/104/105 > type conducted limit vs. discussion of the RS environment, whether that be > a -461 RS103 type limit, or a -464 EME table type EME. In order to make > that leap, you need to assume an antenna. When a receiver is tested, it is > a standalone product from some manufacturer and no one knows to what type > of antenna it will be connected. Being redundant here to make sure I am > not misunderstood, or perhaps to illuminate my lack of understanding of > previous posts, the requirement can *only* be a CS type when procuring a > radio receiver. > > > > If you are trying to determine whether or not the actual EME is going to > damage the receiver, you have to include antenna characteristics, and that > is an integration issue, not a radio procurement issue. > > -- > > Ken Javor > > (256) 650-5261 > > > > *From: *Michael Viau <michael.t.v...@gmail.com> > *Reply-To: *Michael Viau <michael.t.v...@gmail.com> > *Date: *Friday, May 29, 2020 at 1:32 PM > *To: *<EMC-PSTC@LISTSERV.IEEE.ORG> > *Subject: *Re: [PSES] Unreasonable Design Penalties on Receivers > > > > Thanks Patrick, I appreciate the input. > > Then I guess my next thought would be that it seems a little redundant to > test it twice. > > Since thresholding and describing failures during the heck blasting method > tells you how you would perform in the lower power test, why run it twice? > > Both requirements exist for the given system. Both should be met. > > It seems like the reasonable thing would be to test CS104 to the expected > environment levels after installation, and then to ameliorate any issues > with the appropriate filters or a better antenna or better front end > defense on the receiver itself. > > It almost seems like 461 is saying, “Don’t put the burden on the equipment > manufacturer to meet EME levels. Thats the responsibility of the > integrator.” > > But that leaves this massive gap between the levels they test to vs. the > levels they may be capable of performing up to, and the EME tables in 464. > > > > It just seems strange to me that the wording in the 461 Appendix wouldn’t > be more along the lines of encouraging testing at higher levels but setting > clear expectations for the manufacturer as to the degree of performance > they should be able to provide at those levels. > > > > Thanks again. Maybe I’m nitpicking, but it seems like it’s almost > encouraging undertesting with its current wording. > > > > - Michael > > > > > On May 29, 2020, at 9:01 AM, Patrick <conwa...@gmail.com> wrote: > > > > Hi Michael > > I've also wondered about this series of tests and relationship to -464. > > > > I think this breaks down to two considerations- a) the environment is > friendly or not, and b) the receiver is expected to operate or just survive. > > > > My conclusion is that the CS10x tests are examining the receivers ability > to operate as expected in a non-contested environment. That environment > contains other friendly tx/rx comm channels and the receiver under test > needs to be able to reject those other friendly comms and operate without > error. > > > > Whereas the -464 environments represent a different environment that is > either contested or non-friendly, or maybe just the top deck of an Aircraft > carrier. In that case the receiver under test "might" not be expected to > operate, but is expected to survive and recover. > > > > So for the first case we test with standard levels expected to be seen in > a friendly environment. And for the second case we blast the heck out of > it to see if it survives!! > > > > I'm not an expert, just trying to figure this out myself... > > > > -Patrick > > > > On Thu, May 28, 2020, 9:31 PM Michael Viau <michael.t.v...@gmail.com> > wrote: > > Can someone help me circle this square? > > MIL-STD-461 (E-G) mentions in the Appendix for CS103/4 that we shouldn’t > attempt to apply external levels like 200 V/m to this test. Even when > accounting for antenna characteristics they mention that it would place > unreasonable design penalties on the receiver. > But it doesn’t seem unreasonable in light of the 464 EME requirements, > which even go so far as to recommend lab testing for verification. > I understand why we may want to leave CS103 as its own hunt for intermods, > but for antenna connected receivers there seems like no better test than > CS104 for verifying the subsystem would be operational in a 464 Table X > environment. > I’m also aware that 464 recommends in-line filters to meet the needs for > these methods but it’s easier to find a good and airworthy 20 dB filter > than it is a 60 dB one. So it seems totally reasonable to at least test > CS104 to the expected EME levels to find your vulnerabilities/thresholds > and get the filter based on those. > > What am I missing here? Why is the wording so benevolent to the equipment > manufactures in this case? > > Thanks! And long time reader, first time poster. > Michael > > - > ---------------------------------------------------------------- > 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 < > emc-p...@ieee.org> > > 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 <sdoug...@ieee.org> > Mike Cantwell <mcantw...@ieee.org> > > For policy questions, send mail to: > Jim Bacher: <j.bac...@ieee.org> > David Heald: <dhe...@gmail.com> > > - > ---------------------------------------------------------------- > > 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 < > emc-p...@ieee.org> > > 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) <http://www.ieee-pses.org/list.html> > List rules: http://www.ieee-pses.org/listrules.html > > For help, send mail to the list administrators: > Scott Douglas <sdoug...@ieee.org> > Mike Cantwell <mcantw...@ieee.org> > > For policy questions, send mail to: > Jim Bacher <j.bac...@ieee.org> > David Heald <dhe...@gmail.com> > > - > ---------------------------------------------------------------- > > 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 < > emc-p...@ieee.org> > > 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) <http://www.ieee-pses.org/list.html> > List rules: http://www.ieee-pses.org/listrules.html > > For help, send mail to the list administrators: > Scott Douglas <sdoug...@ieee.org> > Mike Cantwell <mcantw...@ieee.org> > > For policy questions, send mail to: > Jim Bacher <j.bac...@ieee.org> > David Heald <dhe...@gmail.com> > > - > ---------------------------------------------------------------- > > 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 < > emc-p...@ieee.org> > > 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) <http://www.ieee-pses.org/list.html> > List rules: http://www.ieee-pses.org/listrules.html > > For help, send mail to the list administrators: > Scott Douglas <sdoug...@ieee.org> > Mike Cantwell <mcantw...@ieee.org> > > For policy questions, send mail to: > Jim Bacher <j.bac...@ieee.org> > David Heald <dhe...@gmail.com> > - ---------------------------------------------------------------- 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 <emc-p...@ieee.org> 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 <sdoug...@ieee.org> Mike Cantwell <mcantw...@ieee.org> For policy questions, send mail to: Jim Bacher: <j.bac...@ieee.org> David Heald: <dhe...@gmail.com>
