As to why the FCC specifies field intensities in linear terms I can't say with certainty but the following is factually true. Getting a reading in dBuV implies use of a logarithmic amplifier. Use of the logarithmic amp precludes both averaging and quasi-peak detection, which are both averaging functions. Averaging can only be performed in linear, not log space. Therefore FCC limits which are verified with either quasi-peak or average detection are defined as numerics, not decibels.
---------- >From: umbdenst...@sensormatic.com >To: emc-p...@majordomo.ieee.org, chris.maxw...@nettest.com >Subject: RE: The Trouble with Convention >Date: Tue, Oct 23, 2001, 8:18 AM > > > Chris, > > I don't believe we are addressing math proofs in this situation. Just as > the free space impedance of 377 ohms (51.5 dB) does not apply to the > reactive near field but is specified by ETSI for conversion from dBuV to > dBuA for repeatability. > > So the FCC wants a report of average voltage and we want to combine the > other factors. I guess with today's spreadsheets we can easily enter the > formulas and just crank, or we can fall back to the easy to follow log > conversions and add the factors. > > A voltage is represented in log terms as 10*log (V)^2 or 20*log (V). > Average voltage is still V, it just happens to be V = a*V1. Therefore the > expression is 10*log(a*V1)^2 or 20*log(a*V1), which yields 20*log(a) + > 20*log(V1). Considering average voltage is what is being sought, and > 20*log(a*V1) yields it, it becomes a useful tool for repeatability. > Mathematically correct -- I won't say that. Another useful mis-applied > convention, perhaps. > > By the way, did you ever wonder why the FCC specifies their results in uV, > not dBuV? probably to avoid this wrangling :-) > > Best regards, > > Don Umbdenstock > Sensormatic > > PS: another FCC anomaly -- specifying limits in uV for systems operating > below 30 MHz, e.g., 50 kHz. Many of these systems are inductive loop > systems; the FCC even specifies measuring systems operating below 30 MHz > with a loop antenna, but give the limits in uV instead of uA. > >> ---------- >> From: Chris Maxwell[SMTP:chris.maxw...@nettest.com] >> Sent: Tuesday, October 23, 2001 8:37 AM >> To: umbdenst...@sensormatic.com; emc-p...@majordomo.ieee.org; >> dmck...@corp.auspex.com; ken.ja...@emccompliance.com >> Subject: RE: The Trouble with Convention >> >> Don, >> >> The mathematical proofs to verify that 20log(D) is a valid method to >> calculate the change in dBuV for a voltage signal with duty cycle D are >> mathematically incorrect. There is no sanity check. >> >> Multiplying D times V will yield the "average voltage". That's as far >> as it goes. >> >> After that, using a factor of 20log(D) to convert to dBuV or dBmW cannot >> be proven. It will yield erroneous results. >> >> If you assume any voltage, convert it to dBuV then put it across a load >> and convert to dBmW then assume a duty cycle "D". You will find that >> using 20log(D) will not provide the proper factor to ensure that changes >> in dBuV correspond to an equal change in dBmW. >> >> Does the FCC specifically state "20log(x)" where "x" is the duty cycle? >> If they do, then we can use it to fill out a data sheet (follow the >> convention), but it is mathematically incorrect. >> >> Chris Maxwell | Design Engineer - Optical Division >> email chris.maxw...@nettest.com | dir +1 315 266 5128 | fax +1 315 797 >> 8024 >> >> NetTest | 6 Rhoads Drive, Utica, NY 13502 | USA >> web www.nettest.com | tel +1 315 797 4449 | >> >> >> >> >> >> > -----Original Message----- >> > From: umbdenst...@sensormatic.com >> [SMTP:umbdenst...@sensormatic.com] >> > Sent: Monday, October 22, 2001 5:47 PM >> > To: emc-p...@majordomo.ieee.org; dmck...@corp.auspex.com; >> > ken.ja...@emccompliance.com >> > Subject: The Trouble with Convention >> > >> > >> > Pursue the right question and one might receive a meaningful answer. >> > >> > How do you convert from dBuA to dBuV when measuring a 50 kHz signal at >> > 10 >> > meters? How do you convert from linear terms to log terms when >> > addressing >> > the output of an averaging detector where the limit is field strength >> > in >> > units of uV? One needs to be aware of who is asking and what the >> > applicable >> > conventions are, i.e., is it a question of science or a question of >> > convention? >> > >> > The issue is generally how does one create a standard that assures >> > repeatability? >> > >> > In ETSI EN 300330, there is a statement that says "For measuring >> > equipment >> > calibrated in dBuV, the reading should be reduced by 51.5 dB to be >> > converted >> > to dBuA/m." 51.5 dB is based on 377 ohms, Z of free space. The >> > impedance >> > of free space applies in the far field, not the reactive near field >> > where >> > the impedance of a magnetic field may be as low as a couple of ohms. >> > The >> > approach may not be mathematically correct, but it provides a simple >> > means >> > of achieving repeatable results. >> > >> > Similarly, it appears the same issue of convention is the basis of >> > certain >> > FCC clauses, for example, the reporting of the output of an averaging >> > detector as called for by 15.209 and other clauses for some frequency >> > bands. >> > The FCC is looking for field strength, a voltage representing the >> > output of >> > the averaging detector. The FCC is aware that there are different >> > implementations of "averaging" detectors and linearity issues so they >> > provided instructions to arrive at the reporting level by mathematical >> > means >> > for consistency. The instruction was to multiply the peak detector >> > reading >> > by the duty cycle and report this value in terms of the limit units, >> > uV, as >> > the equivalent of the output of the averaging detector. >> > >> > So, what is this unit they asked for? It appears to be the function >> > of >> > averaging a voltage signal, i.e., if the signal is X and is on for y, >> > 0<y<1, >> > then the value of the signal to be reported is y*X (uVolts). >> > >> > When it is desired to address multiple factors (distance correction, >> > antenna, cable, preamp, etc.), the process is simplified by converting >> > to >> > log terms. By the relationship between P and V, we have developed the >> > expression for V in log terms to be 10*log V^2 or 20*log V. >> > Addressing the >> > entire expression above, we have 10*log (y*X)^2, or 20*log(y*X). This >> > can >> > also be expressed as 20*log (y) + 20*log(X). From this expression we >> > see >> > that duty cycle is expressed as 20*log (y) for this situation. >> > >> > It appears in this case the FCC is looking for average voltage, not >> > average >> > power. >> > >> > Speaking of power, don't forget the power of the sanity check :-) >> > >> > Best regards, >> > >> > Don Umbdenstock >> > Sensormatic >> > >> > >> > > ---------- >> > > From: Ken Javor[SMTP:ken.ja...@emccompliance.com] >> > > Sent: Friday, October 19, 2001 5:07 PM >> > > To: umbdenst...@sensormatic.com; >> > emc-p...@majordomo.ieee.org; >> > > dmck...@corp.auspex.com >> > > Subject: Re: duty cycle closure >> > > >> > > No. You aren't applying the rule correctly. As I stated earlier: >> > > >> > > log a*b = log a + log b >> > > log b^n = n log b >> > > Combining, it is clear that >> > > log (a*b^n) = log a + n log b. >> > > >> > > ---------- >> > > >From: umbdenst...@sensormatic.com >> > > >To: emc-p...@majordomo.ieee.org, dmck...@corp.auspex.com >> > > >Subject: duty cycle closure >> > > >Date: Fri, Oct 19, 2001, 2:33 PM >> > > > >> > > >> > > > >> > > > Going back to fundamentals -- >> > > > >> > > > Given a = duty cycle = average power >> > > > and define "^2" = "squared" >> > > > >> > > > Then P[ave] = a P[ref] >> > > > >> > > > P = V^2/R >> > > > >> > > > V[ave]^2/R = aV[ref]^2/R, the Rs cancel leaving >> > > > >> > > > V[ave]^2 = aV[ref]^2 >> > > > >> > > > 10 log(V[ave]^2) = 10 log (aV[ref]^2), which is equivalent to >> > > > >> > > > 20 log (V[ave]) = 20 log (aV[ref]) >> > > > >> > > > = 20 log (a) + 20 log (V[ref]) >> > > > >> > > > In the last equation one sees the duty cycle isolated as "20 log >> > (a)" >> > > when >> > > > referring to power in terms of voltage. >> > > > >> > > > Best regards, >> > > > >> > > > Don Umbdenstock >> > > > Sensormatic >> > > > >> > > > >> > > >> ---------- >> > > >> From: Doug McKean[SMTP:dmck...@corp.auspex.com] >> > > >> Reply To: Doug McKean >> > > >> Sent: Friday, October 19, 2001 2:41 PM >> > > >> To: emc-p...@majordomo.ieee.org >> > > >> Subject: Re: Is This Right? >> > > >> >> > > >> >> > > >> > >> > > >> > More to the proof discussion launched by the duty cycle >> > question, >> > > >> given >> > > >> > >> > > >> > > dB = 10 log (P1/P2) >> > > >> > > >> > > >> > > Let "a" be the duty cycle ratio, with 0<a<1, so that P1 = >> > aP2. >> > > >> > > >> > > >> > > Then dB = 10 log (aP2/P2) = 10 log (a). Eq. >> > > >> > > (1) >> > > >> > > >> > > >> > If 10 log (P1/P2) = 10 log (V1^2/V2^2) = 10 log (V1/V2)^2 = 20 >> > log >> > > >> (V1/V2), >> > > >> > >> > > >> > Then does it follow that, >> > > >> > >> > > >> > dB = 10 log (aV2^2/V2^2) = 10 log (aV2/V2)^2 = 20 log (a) ? Eq. >> > (2) >> > > >> > >> > > >> > >> > > >> > If this is true, then >> > > >> > >> > > >> > duty cycle "a" = 10 log (a) from Eq. (1) and >> > > >> > >> > > >> > = 20 log (a) from Eq. (2) >> > > >> > >> > > >> > What am I missing? >> > > >> >> > > >> The original intention of the calculations. >> > > >> >> > > >> The first relation, dB = 10 log (aP2/P2) = 10 log (a) >> > > >> is a "power" relation. >> > > >> >> > > >> The second relation, dB = 10 log (aV2^2/V2^2) = 20 log (a) >> > > >> is a "voltage relation. " >> > > >> >> > > >> Equating the two is invalid since you're trying to equate >> > > >> two different concepts. Doesn't mean anything. >> > > >> >> > > >> - Doug McKean >> > > >> >> > > >> >> > > >> >> > > >> ------------------------------------------- >> > > >> This message is from the IEEE EMC Society Product Safety >> > > >> Technical Committee emc-pstc discussion list. >> > > >> >> > > >> Visit our web site at: http://www.ewh.ieee.org/soc/emcs/pstc/ >> > > >> >> > > >> To cancel your subscription, send mail to: >> > > >> majord...@ieee.org >> > > >> with the single line: >> > > >> unsubscribe emc-pstc >> > > >> >> > > >> For help, send mail to the list administrators: >> > > >> Michael Garretson: pstc_ad...@garretson.org >> > > >> Dave Heald davehe...@mediaone.net >> > > >> >> > > >> For policy questions, send mail to: >> > > >> Richard Nute: ri...@ieee.org >> > > >> Jim Bacher: j.bac...@ieee.org >> > > >> >> > > >> All emc-pstc postings are archived and searchable on the web at: >> > > >> No longer online until our new server is brought online and >> > the old >> > > >> messages are imported into the new server. >> > > >> >> > > > >> > > > ------------------------------------------- >> > > > This message is from the IEEE EMC Society Product Safety >> > > > Technical Committee emc-pstc discussion list. >> > > > >> > > > Visit our web site at: http://www.ewh.ieee.org/soc/emcs/pstc/ >> > > > >> > > > To cancel your subscription, send mail to: >> > > > majord...@ieee.org >> > > > with the single line: >> > > > unsubscribe emc-pstc >> > > > >> > > > For help, send mail to the list administrators: >> > > > Michael Garretson: pstc_ad...@garretson.org >> > > > Dave Heald davehe...@mediaone.net >> > > > >> > > > For policy questions, send mail to: >> > > > Richard Nute: ri...@ieee.org >> > > > Jim Bacher: j.bac...@ieee.org >> > > > >> > > > All emc-pstc postings are archived and searchable on the web at: >> > > > No longer online until our new server is brought online and >> > the old >> > > > messages are imported into the new server. >> > > > >> > > >> > >> > ------------------------------------------- >> > This message is from the IEEE EMC Society Product Safety >> > Technical Committee emc-pstc discussion list. >> > >> > Visit our web site at: http://www.ewh.ieee.org/soc/emcs/pstc/ >> > >> > To cancel your subscription, send mail to: >> > majord...@ieee.org >> > with the single line: >> > unsubscribe emc-pstc >> > >> > For help, send mail to the list administrators: >> > Michael Garretson: pstc_ad...@garretson.org >> > Dave Heald davehe...@mediaone.net >> > >> > For policy questions, send mail to: >> > Richard Nute: ri...@ieee.org >> > Jim Bacher: j.bac...@ieee.org >> > >> > All emc-pstc postings are archived and searchable on the web at: >> > No longer online until our new server is brought online and the >> > old messages are imported into the new server. >> > > ------------------------------------------- > This message is from the IEEE EMC Society Product Safety > Technical Committee emc-pstc discussion list. > > Visit our web site at: http://www.ewh.ieee.org/soc/emcs/pstc/ > > To cancel your subscription, send mail to: > majord...@ieee.org > with the single line: > unsubscribe emc-pstc > > For help, send mail to the list administrators: > Michael Garretson: pstc_ad...@garretson.org > Dave Heald davehe...@mediaone.net > > For policy questions, send mail to: > Richard Nute: ri...@ieee.org > Jim Bacher: j.bac...@ieee.org > > All emc-pstc postings are archived and searchable on the web at: > No longer online until our new server is brought online and the old > messages are imported into the new server. > ------------------------------------------- This message is from the IEEE EMC Society Product Safety Technical Committee emc-pstc discussion list. Visit our web site at: http://www.ewh.ieee.org/soc/emcs/pstc/ To cancel your subscription, send mail to: majord...@ieee.org with the single line: unsubscribe emc-pstc For help, send mail to the list administrators: Michael Garretson: pstc_ad...@garretson.org Dave Heald davehe...@mediaone.net For policy questions, send mail to: Richard Nute: ri...@ieee.org Jim Bacher: j.bac...@ieee.org All emc-pstc postings are archived and searchable on the web at: No longer online until our new server is brought online and the old messages are imported into the new server.
