Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #25076

Re: Optimize pow() function

Show all headers | View raw

Il 22/09/2016 23:31, rickman ha scritto:
> On 9/22/2016 5:10 PM, pozz wrote:
>> Il 22/09/2016 16:17, Don Y ha scritto:
>>> On 9/22/2016 6:36 AM, pozz wrote:
>>>> I have to convert voltage measure (Volt) into power (Watt).  As you
>>>> know, the
>>>> physics says I need to square the voltage measure.
>>>>
>>>> I have to calibrate the mathematical law and I have two points:
>>>> 0W -> 0V
>>>> <nominal power> -> <voltage at nominal power>
>>>>
>>>> That could be enough, but we noticed a different relation between volt
>>>> and watt
>>>> at intermediate points. I, as the software engineer, have to try to
>>>> compensate
>>>> differences from the theory, without increasing complexity during
>>>> calibration.
>>>>
>>>> My idea is to calibrate the exponent: it is normally 2.00, but I can
>>>> calibrate
>>>> from 1.00 to 3.00.
>>>> In this way, the two old calibration points are the same as before.
>>>> So the
>>>> exponent (the third calibration measure) can be changed at last.
>>>>
>>>> The problem is pow() function with double arguments takes a lot of
>>>> time to
>>>> finish.  Do you suggest a mathematical method to reduce its complexity?
>>>>
>>>>
>>>> uint16_t power_nominal = 1500;   // In Watt
>>>> uint16_t volt_nominal;   // Volt measured at nominal power
>>>> signed uint8_t exp_corr = -100 to +100;
>>>> double exp = 2.00 + exp_corr;
>>>>
>>>> uint16_t volt = adc_convert(...);  // Actual volt measure
>>>> double alpha = (double)power_nominal / pow((double)volt_nominal, exp);
>>>> uint32_t watt = alpha * pow((double)volt, exp);
>>>>
>>>>
>>>> alpha can be pre-calculated, because power_nominal, volt_nominal and
>>>> exp are
>>>> constant (after calibration). The last instruction is the problem.
>>>
>>> No, the "problem" lies in your transducer/measurement error.
>>> The definition of a "watt" (power) doesn't change just because your
>>> observations of that APPARENT relationship (V ~ W) "has issues".
>>>
>>> Perhaps your load's characteristics are changing as a function
>>> of operating point.  Or, nonlinearities in your measurement system.
>>> Or, ...
>>>
>>> Ask yourself WHY the exponent needs to be changed.  I suggest you
>>> don't have an accurate model of your load and its excitation.
>>> Until you do, how will you know that this is the CORRECT means of
>>> compensating your model to agree with your observations?
>>
>>
>> I know the problem is in the poor quality of the transducer, but I'm
>> only in charge of the software and the hardware engineer can't fix it
>> (often the software solves hardware issues).
>>
>> So I need a more complex law. The quadratic law (one parameter) can be
>> calibrated with a single measure (nominal value). The generic power law
>> (exponent not exactly equals to 2, two parameters) needs two calibration
>> measures and has a nice feature: it's very simple to calibrate in two
>> steps.
>>
>> The input section has an hardware calibration, a simple digital trimmer.
>> So the first step is to calculate the power from the measured voltage
>> with the following formula:
>>   P = Pn / (Vn ^ 2) * (V ^ 2)
>> where Pn is the nominal power and Vn is the voltage needed at nominal
>> power.  The user increase/decrease the trimmer pot until the correct
>> power is displayed.
>>
>> Second step. Change the power to another value (half of nominal power,
>> for example). If the transducer works as in theory, the measured power
>> is correct. Otherwise the user increase/decrease the exponent until the
>> power displayed is correct. The power is calculated as:
>>   P = Pn / (Vn ^ exp) * (V ^ exp)
>>
>> After the second step, we are sure the first calibration point is yet
>> valid, because that formula is correct when V=Vn, even if exp isn't 2.
>>
>>
>> If I use the linear law P=AV^2+BV, I think the two calibration steps
>> aren't indipendent: the operator should execute two measures, the system
>> should save the two couples (P,V) and only after that calculate A and B
>> coefficients.
>>
>>
>> It seems to me the exponentiation law is simpler during calibration.
>
> I don't know that complicating your power calculation is the right way
> to go.  Even if you do, why do you thing adjusting the exponent is the
> right compensation?  There are any number of other ways the values you
> are measuring could be out.

I know exponentiation could be not the optimum compensation, but I don't 
need it.  The transducer is similar to the theoric model (square law), 
but it differs from it a little.  I need only a mathematical trick to 
change slightly the shape of the square curve... and keeping simple the 
calibration of this new shape.

I found changing exponent is good in my application, because I'm sure it 
is exact at three points (0, Pn/2, Pn) and good at other points.
I don't need high accuracy in the reading.


> Can you measure the *actual* voltage the transducer is measuring?

Yes.


> How
> are you getting the power measurement to compare to your calculations?

Power meter.


> What is the device which is the load for this calculation?

The load is an RF amplifier.


> Rather than fudging the calculation, maybe it is simpler to figure out
> how the measurement is out and correct that before you perform the power
> calculation.

The measure on the field is similar to the theory (square law). 
Unfortunately it isn't exactly a square law (don't ask why, I don't 
know), so I'm finding a mathematical trick to change *a little* the 
shape of the square law.

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Optimize pow() function pozz <pozzugno@gmail.com> - 2016-09-22 15:36 +0200
  Re: Optimize pow() function Don Y <blockedofcourse@foo.invalid> - 2016-09-22 07:17 -0700
    Re: Optimize pow() function pozz <pozzugno@gmail.com> - 2016-09-22 23:10 +0200
      Re: Optimize pow() function rickman <gnuarm@gmail.com> - 2016-09-22 17:31 -0400
        Re: Optimize pow() function lasselangwadtchristensen@gmail.com - 2016-09-22 14:44 -0700
        Re: Optimize pow() function pozz <pozzugno@gmail.com> - 2016-09-23 09:03 +0200
          Re: Optimize pow() function Paul Rubin <no.email@nospam.invalid> - 2016-09-23 00:17 -0700
          Re: Optimize pow() function Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2016-09-23 22:45 +0300
      Re: Optimize pow() function rickman <gnuarm@gmail.com> - 2016-09-22 17:44 -0400
        Re: Optimize pow() function pozz <pozzugno@gmail.com> - 2016-09-23 09:08 +0200
          Re: Optimize pow() function rickman <gnuarm@gmail.com> - 2016-09-24 01:54 -0400
      Re: Optimize pow() function Don Y <blockedofcourse@foo.invalid> - 2016-09-22 14:50 -0700
        Re: Optimize pow() function pozz <pozzugno@gmail.com> - 2016-09-23 09:23 +0200
          Re: Optimize pow() function Don Y <blockedofcourse@foo.invalid> - 2016-09-23 00:32 -0700
          Re: Optimize pow() function Evgeny Filatov <e.v.filatov@ieee.org> - 2016-09-23 12:56 +0300
            Re: Optimize pow() function Don Y <blockedofcourse@foo.invalid> - 2016-09-23 10:41 -0700
          Re: Optimize pow() function Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2016-09-23 21:07 +0200
          Re: Optimize pow() function Don Y <blockedofcourse@foo.invalid> - 2016-09-23 12:12 -0700
    Re: Optimize pow() function pozz <pozzugno@gmail.com> - 2016-09-22 23:12 +0200
      Re: Optimize pow() function Don Y <blockedofcourse@foo.invalid> - 2016-09-22 14:58 -0700
  Re: Optimize pow() function Tim Wescott <tim@seemywebsite.com> - 2016-09-22 10:01 -0500
    Re: Optimize pow() function Jack <jack4747@gmail.com> - 2016-09-22 08:08 -0700
      Re: Optimize pow() function Tim Wescott <seemywebsite@myfooter.really> - 2016-09-22 11:53 -0500
        Re: Optimize pow() function pippo2@disney.com (Jack) - 2016-09-22 21:12 +0200
          Re: Optimize pow() function lasselangwadtchristensen@gmail.com - 2016-09-22 13:12 -0700
          Re: Optimize pow() function Tim Wescott <seemywebsite@myfooter.really> - 2016-09-22 15:51 -0500
    Re: Optimize pow() function pozz <pozzugno@gmail.com> - 2016-09-22 23:15 +0200
      Re: Optimize pow() function Tim Wescott <seemywebsite@myfooter.really> - 2016-09-22 17:52 -0500
      Re: Optimize pow() function David Brown <david.brown@hesbynett.no> - 2016-09-23 09:32 +0200
    Re: Optimize pow() function David Brown <david.brown@hesbynett.no> - 2016-09-23 09:28 +0200
      Re: Optimize pow() function Paul Rubin <no.email@nospam.invalid> - 2016-09-23 00:47 -0700
        Re: Optimize pow() function David Brown <david.brown@hesbynett.no> - 2016-09-23 11:05 +0200
        Re: Optimize pow() function Tim Wescott <tim@seemywebsite.com> - 2016-09-23 11:44 -0500
  Re: Optimize pow() function Jack <jack4747@gmail.com> - 2016-09-22 23:15 -0700
    Re: Optimize pow() function Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2016-09-23 20:49 +0200
  Re: Optimize pow() function Richard Damon <Richard@Damon-Family.org> - 2016-09-25 06:50 -0400
    Re: Optimize pow() function Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2016-09-25 16:36 +0300
      Re: Optimize pow() function Chris <xxx.syseng.yyy@gfsys.co.uk> - 2016-09-26 17:30 +0000
        Re: Optimize pow() function Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2016-09-26 21:49 +0300
      Re: Optimize pow() function pozz <pozzugno@gmail.com> - 2016-09-26 23:30 +0200
        Re: Optimize pow() function Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2016-09-27 18:58 +0300
  Re: Optimize pow() function Robert Wessel <robertwessel2@yahoo.com> - 2016-09-26 22:44 -0500

csiph-web