I'm confused by some code I wrote to measure signal amplitude from a CODEC. The FPGA sampled for some period of time squaring the samples and summing them up. I did not take the square root of the result, at least not in the FPGA. I would expect this result to be proportional to the power in the signal. When I compare this number at multiple frequencies to get the variations, I found that a ratio of 1.5 dB of this number (10 log(X1/X2)) seems to correspond to a ratio of 0.71 of the voltage amplitude (3 dB) of the signal at the CODEC input. Perhaps I should return to the test bench to measure some data again since I am recalling this from some time ago. I ended up coding 1.5 dB limits in the software, but I am having trouble understanding what was happening. I guess I could do some numbers in a spread sheet to duplicate these results, but I thought I would ask here to see if the issue was obvious and I am having a brain cramp. -- Rick C. - Get 1,000 miles of free Supercharging - Tesla referral code - https://ts.la/richard11209
Power Ratios?
Started by ●August 6, 2019
Reply by ●August 6, 20192019-08-06
Rick, I didn't quite understand your ratio statements, but if you break it down to first principles the theory is straightforward. Just look up the definition of RMS voltage and know that P = VRMS^2 / R. So if you didn't square root the sums, that's good, because the square of the VRMS negates the square root corresponding to the "R" in "RMS". What you haven't accounted for (or at least I don't see it accounted for in your description) is the time over which you are computing the mean. Perhaps this is your discrepancy? Then again, if you are computing P2/P1, and the mean of each measurement is computed over the same interval, the time cancels out. Another possible reason for your discrepancy could be that P1 and P2 are over different impedances, so the impedance, which should normally cancel out in the ratio P2/P2, doesn't ----Randy gnuarm.deletethisbit@gmail.com writes:> I'm confused by some code I wrote to measure signal amplitude from a > CODEC. The FPGA sampled for some period of time squaring the samples > and summing them up. I did not take the square root of the result, at > least not in the FPGA. I would expect this result to be proportional > to the power in the signal. > > When I compare this number at multiple frequencies to get the > variations, I found that a ratio of 1.5 dB of this number (10 > log(X1/X2)) seems to correspond to a ratio of 0.71 of the voltage > amplitude (3 dB) of the signal at the CODEC input. > > Perhaps I should return to the test bench to measure some data again > since I am recalling this from some time ago. I ended up coding 1.5 dB > limits in the software, but I am having trouble understanding what was > happening. I guess I could do some numbers in a spread sheet to > duplicate these results, but I thought I would ask here to see if the > issue was obvious and I am having a brain cramp.-- Randy Yates, DSP/Embedded Firmware Developer Digital Signal Labs http://www.digitalsignallabs.com
Reply by ●August 7, 20192019-08-07
PS: Another potential (and simpler) clue from the 3 vs 1.5 is that you are missing a factor of two, and power from a voltage ratio is 20*log(V2/V1) and not 10*log(V2/V1), but this is usually used where V1 and V2 are constant DC voltages, whereas it seems you were working with a voltage which varied in time. --Randy Randy Yates <yates@digitalsignallabs.com> writes:> Rick, > > I didn't quite understand your ratio statements, but if you break it > down to first principles the theory is straightforward. Just look up the > definition of RMS voltage and know that P = VRMS^2 / R. > > So if you didn't square root the sums, that's good, because > the square of the VRMS negates the square root corresponding > to the "R" in "RMS". > > What you haven't accounted for (or at least I don't see it accounted for > in your description) is the time over which you are computing the mean. > Perhaps this is your discrepancy? > > Then again, if you are computing P2/P1, and the mean of each measurement > is computed over the same interval, the time cancels out. > > Another possible reason for your discrepancy could be that P1 and P2 are > over different impedances, so the impedance, which should normally > cancel out in the ratio P2/P2, doesn't > > ----Randy > > gnuarm.deletethisbit@gmail.com writes: > >> I'm confused by some code I wrote to measure signal amplitude from a >> CODEC. The FPGA sampled for some period of time squaring the samples >> and summing them up. I did not take the square root of the result, at >> least not in the FPGA. I would expect this result to be proportional >> to the power in the signal. >> >> When I compare this number at multiple frequencies to get the >> variations, I found that a ratio of 1.5 dB of this number (10 >> log(X1/X2)) seems to correspond to a ratio of 0.71 of the voltage >> amplitude (3 dB) of the signal at the CODEC input. >> >> Perhaps I should return to the test bench to measure some data again >> since I am recalling this from some time ago. I ended up coding 1.5 dB >> limits in the software, but I am having trouble understanding what was >> happening. I guess I could do some numbers in a spread sheet to >> duplicate these results, but I thought I would ask here to see if the >> issue was obvious and I am having a brain cramp.-- Randy Yates, DSP/Embedded Firmware Developer Digital Signal Labs http://www.digitalsignallabs.com
Reply by ●August 7, 20192019-08-07
On Tuesday, August 6, 2019 at 10:59:35 PM UTC-4, Randy Yates wrote:> Rick, > > I didn't quite understand your ratio statements, but if you break it > down to first principles the theory is straightforward. Just look up the > definition of RMS voltage and know that P = VRMS^2 / R. > > So if you didn't square root the sums, that's good, because > the square of the VRMS negates the square root corresponding > to the "R" in "RMS". > > What you haven't accounted for (or at least I don't see it accounted for > in your description) is the time over which you are computing the mean. > Perhaps this is your discrepancy? > > Then again, if you are computing P2/P1, and the mean of each measurement > is computed over the same interval, the time cancels out. > > Another possible reason for your discrepancy could be that P1 and P2 are > over different impedances, so the impedance, which should normally > cancel out in the ratio P2/P2, doesn'tMaybe I didn't explain the problem clearly. If I didn't mention this, this whole thing is a production test fixture for a daughter card to measure frequency response. The circuit is a CODEC driven by an FPGA. The analog signal is looped back and the measurements are made by the FPGA. A fixed amplitude sine wave is driven into the CODEC and the resulting signal is captured. Since the analog circuit doesn't change, there is no difference there. The impedance is not a factor. The time period of collection is constant for all readings, so that is not a factor. As you say, the RMS calculations would produce a value proportional to the RMS voltage. Since I don't take the square root the resulting number is proportional to the power/energy in the signal. I include energy for the pedants. As I said, I confirm the results of my testing by measuring the reading and comparing to direct measurements at the input to the CODEC. When the analog input is reduced by 3 dB (0.707 amplitude by voltage) the calculation shows -1.5 dB reduction, not 3 dB. I don't have the means of easily looking directly at the digital samples since they aren't provided by the FPGA. I could be done, but not so easily. All the software is doing is taking the sum of squares value and performing 10 * log(x) on the ratio of the two readings. Hard to mess that up. -- Rick C. + Get 1,000 miles of free Supercharging + Tesla referral code - https://ts.la/richard11209
Reply by ●August 7, 20192019-08-07
On Tuesday, August 6, 2019 at 11:06:29 PM UTC-4, Randy Yates wrote:> PS: Another potential (and simpler) clue from the 3 vs 1.5 is that > you are missing a factor of two, and power from a voltage ratio is > 20*log(V2/V1) and not 10*log(V2/V1), but this is usually used > where V1 and V2 are constant DC voltages, whereas it seems you > were working with a voltage which varied in time.The voltage does not vary in time during a reading other than the sine wave. I am using 10 log(x) because the values fed into the ratio are the squares of the RMS values and so proportional to the power, not the voltage. I guess you would call them MS readings. Clearly there is the factor of two as you say, but where. I thought something I was doing wrong or wrong thinking might leap out to someone else. This code was written a long time ago. Perhaps I should review the code to verify I'm not compensating for the power vs. voltage thing twice. Maybe the software is taking the square root as well as only using the 10 multiplier. I'm pretty sure this is not the case as the values to be squared are 16 bits producing 32 bits (I think technically 31 since the numbers are signed). The number of samples summed has to be set carefully to fit in the range available. I think there are only 15 actual bits of significance since the sine bit is lost in the square and the result won't have any more accuracy than the 15 bits in the original value. I think the values are treated as 16 bit values before summing leaving room for 64 k samples or a little over 1 second. Sooooo... The software reports the raw values which are close to the max value in the 32 bit number. If the square root is being taken, it would have to be in the actual dB calculation which is not likely to be doing both the square root and multiplying the log by 10 rather than 20. Sorry for being long winded, but I was thinking out loud... well, on paper... well, at the keyboard. lol -- Rick C. -- Get 1,000 miles of free Supercharging -- Tesla referral code - https://ts.la/richard11209
Reply by ●August 7, 20192019-08-07
Rick C <gnuarm.deletethisbit@gmail.com> wrote:>All the software is doing is taking the sum of squares value and >performing 10 * log(x) on the ratio of the two readings. Hard to mess >that up.Maybe you are partially overflowing? Steve
Reply by ●August 7, 20192019-08-07
On Wednesday, August 7, 2019 at 12:39:17 AM UTC-4, Steve Pope wrote:> Rick C <gnuarm.deletethisbit@gmail.com> wrote: > > >All the software is doing is taking the sum of squares value and > >performing 10 * log(x) on the ratio of the two readings. Hard to mess > >that up. > > Maybe you are partially overflowing?If that were the case, it would not produce reliable results. The data is pretty tight. At one point I had the limits set to -0.5 dB to -1.5 dB since there are filter components so the level *should* be rolling off a bit at 20 Hz and 20 kHz. We found a very small number of units that just failed the -0.5 limit so I bumped it back up to 0 dB. -- Rick C. -+ Get 1,000 miles of free Supercharging -+ Tesla referral code - https://ts.la/richard11209
Reply by ●August 7, 20192019-08-07
On 8/6/2019 23:38, Rick C wrote:> On Tuesday, August 6, 2019 at 10:59:35 PM UTC-4, Randy Yates wrote: >> Rick, >> >> I didn't quite understand your ratio statements, but if you break it >> down to first principles the theory is straightforward. Just look up the >> definition of RMS voltage and know that P = VRMS^2 / R. >> >> So if you didn't square root the sums, that's good, because >> the square of the VRMS negates the square root corresponding >> to the "R" in "RMS". >> >> What you haven't accounted for (or at least I don't see it accounted for >> in your description) is the time over which you are computing the mean. >> Perhaps this is your discrepancy? >> >> Then again, if you are computing P2/P1, and the mean of each measurement >> is computed over the same interval, the time cancels out. >> >> Another possible reason for your discrepancy could be that P1 and P2 are >> over different impedances, so the impedance, which should normally >> cancel out in the ratio P2/P2, doesn't > > Maybe I didn't explain the problem clearly. > > If I didn't mention this, this whole thing is a production test fixture for a daughter card to measure frequency response. The circuit is a CODEC driven by an FPGA. The analog signal is looped back and the measurements are made by the FPGA. A fixed amplitude sine wave is driven into the CODEC and the resulting signal is captured. > > Since the analog circuit doesn't change, there is no difference there. The impedance is not a factor. > > The time period of collection is constant for all readings, so that is not a factor. > > As you say, the RMS calculations would produce a value proportional to the RMS voltage. Since I don't take the square root the resulting number is proportional to the power/energy in the signal. I include energy for the pedants. > > As I said, I confirm the results of my testing by measuring the reading and comparing to direct measurements at the input to the CODEC. When the analog input is reduced by 3 dB (0.707 amplitude by voltage) the calculation shows -1.5 dB reduction, not 3 dB.3 dB is a factor of 2 in power terms. In voltage terms 6 dB is a factor of 2. You are confounding dbV and dBPower.> > I don't have the means of easily looking directly at the digital samples since they aren't provided by the FPGA. I could be done, but not so easily. > > All the software is doing is taking the sum of squares value and performing 10 * log(x) on the ratio of the two readings. Hard to mess that up. >-- Best wishes, --Phil pomartel At Comcast(ignore_this) dot net
Reply by ●August 7, 20192019-08-07
Rick C <gnuarm.deletethisbit@gmail.com> writes:> On Tuesday, August 6, 2019 at 11:06:29 PM UTC-4, Randy Yates wrote: >> PS: Another potential (and simpler) clue from the 3 vs 1.5 is that >> you are missing a factor of two, and power from a voltage ratio is >> 20*log(V2/V1) and not 10*log(V2/V1), but this is usually used >> where V1 and V2 are constant DC voltages, whereas it seems you >> were working with a voltage which varied in time. > > The voltage does not vary in time during a reading other than the sine > wave.A sine wave is a time-varying signal.> [...]> Sorry for being long winded, but I was thinking out loud... well, on > paper... well, at the keyboard. lolExplaining everything in words is problematic. It would be much better to write the precise mathematic expressions being evaluated. And/or post the code. Between these two actions, your error will probably be discovered in minutes. -- Randy Yates, DSP/Embedded Firmware Developer Digital Signal Labs http://www.digitalsignallabs.com
Reply by ●August 7, 20192019-08-07
On 8/6/19 8:38 PM, Rick C wrote:> On Tuesday, August 6, 2019 at 10:59:35 PM UTC-4, Randy Yates wrote: >> Rick, >> >> I didn't quite understand your ratio statements, but if you break it >> down to first principles the theory is straightforward. Just look up the >> definition of RMS voltage and know that P = VRMS^2 / R. >> >> So if you didn't square root the sums, that's good, because >> the square of the VRMS negates the square root corresponding >> to the "R" in "RMS". >> >> What you haven't accounted for (or at least I don't see it accounted for >> in your description) is the time over which you are computing the mean. >> Perhaps this is your discrepancy? >> >> Then again, if you are computing P2/P1, and the mean of each measurement >> is computed over the same interval, the time cancels out. >> >> Another possible reason for your discrepancy could be that P1 and P2 are >> over different impedances, so the impedance, which should normally >> cancel out in the ratio P2/P2, doesn't > > Maybe I didn't explain the problem clearly. > > If I didn't mention this, this whole thing is a production test fixture for a daughter card to measure frequency response. The circuit is a CODEC driven by an FPGA. The analog signal is looped back and the measurements are made by the FPGA. A fixed amplitude sine wave is driven into the CODEC and the resulting signal is captured. > > Since the analog circuit doesn't change, there is no difference there. The impedance is not a factor. > > The time period of collection is constant for all readings, so that is not a factor. > > As you say, the RMS calculations would produce a value proportional to the RMS voltage. Since I don't take the square root the resulting number is proportional to the power/energy in the signal. I include energy for the pedants. > > As I said, I confirm the results of my testing by measuring the reading and comparing to direct measurements at the input to the CODEC. When the analog input is reduced by 3 dB (0.707 amplitude by voltage) the calculation shows -1.5 dB reduction, not 3 dB. > > I don't have the means of easily looking directly at the digital samples since they aren't provided by the FPGA. I could be done, but not so easily. > > All the software is doing is taking the sum of squares value and performing 10 * log(x) on the ratio of the two readings. Hard to mess that up. >Are you sure as sure can be that your log() is a) correct and b) a base-10 log? Can you change the software so that you get the sum-square values, or sum-square ratios, directly rather than after decibalization and check for yourself? -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.
