Power Ratios?

On Wednesday, August 7, 2019 at 11:22:45 AM UTC-4, Phil Martel wrote:
> 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 think I understand both dBV and dB power just fine.  Both are based on relative power.  dBV uses the voltage in each the reference and the measured signal without taking into account the difference in impedance.  This results in an offset in dB which can be calculated from the ratio of the two impedances.  But the calculation is still a power comparison which is seen from the multiplier used, 20. 

None of this matters since dBV is exactly the same as dB (using the correct reference) when comparing signal strength on the same circuit which is what I am doing. 

The voltage observed is lower by 0.707 which results in a calculated dB of -1.5 when it should be  -3 db.  I don't have to measure power to calculate this.  

Something is wrong in the calculations.  I will need to verify what is happening in the FPGA.  I've looked at the software and like I thought, the calcs are all in one spot and very simple.  Not much to get wrong.  It is calculating 10 * log( X2 / X1 ) where Xn is a sum of the squared voltage levels. 

Maybe my assumption that the samples are being squared is wrong.  Perhaps an absolute value is being used instead.  In that case an average voltage magnitude is being calculated which, if squared after the fact will result in a value with a fixed correction factor since the signal is a sine wave.  This value is the "form factor" and is 1.11 (RMS/avg).  I don't care about this offset since it fall out when calculating dB. 

-- 

  Rick C.

  +- Get 1,000 miles of free Supercharging
  +- Tesla referral code - https://ts.la/richard11209

On Wednesday, August 7, 2019 at 12:25:40 PM UTC-4, Randy Yates wrote:
> 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. 

Do you really not know what I was trying to say?  The signal is a fixed amplitude and frequency sine wave.  Is that better? 


> > Sorry for being long winded, but I was thinking out loud... well, on
> > paper... well, at the keyboard.  lol 
> 
> Explaining 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.

Here is the code running in the PC... 

: dB_DivideAndDisplay ( F: F1 F2 -- F3 )
	F/ FLOG 1E1 F* FDUP F. ." dB " ;

: dB_Error ( flag1 -- flag2 )
	IF ." 	>>>Error<<<" DROP TRUE THEN ;

\ Each pair is a ratio
: TestAudDisp_dB ( -- flag ) ( F: F1 F2 F3 F4 F5 F6 - ) 
  FALSE
  CR ."   Separation @ 1000 Hz is " 
      dB_DivideAndDisplay -90E0 FSWAP F< dB_Error
  CR ."   Response @ 20 Hz is " 
      dB_DivideAndDisplay -0.75E0 0.75E0 F~ 0= dB_Error
  CR ."   Response @ 20 kHz is " 
      dB_DivideAndDisplay -0.75E0 0.75E0 F~ 0= dB_Error
  ;

Even if you don't know Forth, the code is not too complex.  In Forth everything is a word (subroutine) separated by white space.  Operands are on stacks, separate integer and floating point (F: denotes the floating point stack).  Notation at the beginning of each word definition shows the stacks before and after like this, ( before -- after )  A printed string is indicated by the word ." which reads all text until the next "  

The floating point data input are three pairs, a measurement to be turned into db and the common reference for each pair.  That is, the same reference is used for all thee pairs (value at 1 kHz).  The first pair is a cross channel/noise measurement.  

F~ is a floating point word that compares a value to a window defined by the center and a magnitude offset.  So -0.75E0 0.75E0 F~ will check if the value is within 0 and -1.5 dB exclusive. 

TestAudDisp_dB is the entry point for this section of code. 

Let me know if you have any questions.  I'm going to dig into the VHDL now. 

-- 

  Rick C.

  ++ Get 1,000 miles of free Supercharging
  ++ Tesla referral code - https://ts.la/richard11209

On Wednesday, August 7, 2019 at 1:05:52 PM UTC-4, Rob Gaddi wrote:
> 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?

Yes, I'm sure about the FLOG word. 

10E0 FLOG F. 1.00000  ok
1E3 FLOG F.  3.00000  ok
1E-3 FLOG F. -3.00000  ok

I already display the input values both decimal and hex and the ratios are as expected.  So the problem must be in the FPGA code.  Thanks for the idea. 

-- 

  Rick C.

  --- Get 1,000 miles of free Supercharging
  --- Tesla referral code - https://ts.la/richard11209

If you're trying to compute 

  10*log10[SUM(a^2)/SUM(b^2)] 

and your results are half what you expect, then the most likely hypothesis is that you are somehow accidentally computing

  10*log10[SQRT(SUM(a^2))/SQRT(SUM(b^2))] = 10*(1/2)*log10[SUM(a^2)/SUM(b^2)]

Rick C <gnuarm.deletethisbit@gmail.com> writes:

> On Wednesday, August 7, 2019 at 12:25:40 PM UTC-4, Randy Yates wrote:
>> 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. 
>
> Do you really not know what I was trying to say? The signal is a fixed
> amplitude and frequency sine wave. Is that better?

I would counter with, "Do you really not know what a constant DC voltage
is?"

>> > Sorry for being long winded, but I was thinking out loud... well, on
>> > paper... well, at the keyboard.  lol 
>> 
>> Explaining 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.
>
> Here is the code running in the PC... 
>
> : dB_DivideAndDisplay ( F: F1 F2 -- F3 )
> 	F/ FLOG 1E1 F* FDUP F. ." dB " ;
>
> : dB_Error ( flag1 -- flag2 )
> 	IF ." 	>>>Error<<<" DROP TRUE THEN ;
>
> \ Each pair is a ratio
> : TestAudDisp_dB ( -- flag ) ( F: F1 F2 F3 F4 F5 F6 - ) 
>   FALSE
>   CR ."   Separation @ 1000 Hz is " 
>       dB_DivideAndDisplay -90E0 FSWAP F< dB_Error
>   CR ."   Response @ 20 Hz is " 
>       dB_DivideAndDisplay -0.75E0 0.75E0 F~ 0= dB_Error
>   CR ."   Response @ 20 kHz is " 
>       dB_DivideAndDisplay -0.75E0 0.75E0 F~ 0= dB_Error
>   ;
>
> Even if you don't know Forth, the code is not too complex.  In Forth everything is a word (subroutine) separated by white space.  Operands are on stacks, separate integer and floating point (F: denotes the floating point stack).  Notation at the beginning of each word definition shows the stacks before and after like this, ( before -- after )  A printed string is indicated by the word ." which reads all text until the next "  
>
> The floating point data input are three pairs, a measurement to be turned into db and the common reference for each pair.  That is, the same reference is used for all thee pairs (value at 1 kHz).  The first pair is a cross channel/noise measurement.  
>
> F~ is a floating point word that compares a value to a window defined by the center and a magnitude offset.  So -0.75E0 0.75E0 F~ will check if the value is within 0 and -1.5 dB exclusive. 
>
> TestAudDisp_dB is the entry point for this section of code. 
>
> Let me know if you have any questions.  I'm going to dig into the VHDL
> now. 

OK sorry I've been away for a few days. Let me take a look.
-- 
Randy Yates, DSP/Embedded Firmware Developer
Digital Signal Labs
http://www.digitalsignallabs.com