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

Groups > comp.arch.embedded > #25102

Re: Optimize pow() function

Show all headers | View raw

On 9/23/2016 3:08 AM, pozz wrote:
> Il 22/09/2016 23:44, 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.
>>
>> I think your equation is not written in a clear way.  I think what you
>> mean is this...
>>
>> P = Pn * (V ^ exp) / (Vn ^ exp)
>
> IMHO, they are identical mathematical expressions.

It is equivalent, but the way you wrote it the order of operations has 
to be implied by the standard rules.  I typically don't write a division 
that way because often the equation really intended is

A = B / (C * D) rather than A = (B / C) * D

which are *not* equivalent.  So

A = B * D / C is more clear, to me anyway.  Or supply the parentheses.


>> Now the equation makes sense to me.  But that still doesn't mean it will
>> give close to correct values anywhere other than the calibration points.
>
> Yes, I have tried and this mathematical law could be ok for my application.
>
>
>> Have you considered...
>>
>> P = Pn * (V / Vn) ^ exp
>
> Again IMHO, this is identical to the above expressions.

Yeah, I got wrapped around the axle on this thinking of logs.  A 
division before taking the log is equivalent to adding the logs of the 
two values.

Still, again, this is a more clear way to write what you are doing.  The 
value Vn is just a scale factor.  Why complicated it by taking the 
exponent and dividing after the exponent is taken of the value measured? 
  At least this is more clear to me.


>> Then there are an infinite set of other corrections you could use.  The
>> question is which ones are more accurate?
>
> I don't need to increase accuracy.  I only need a little compensation of
> the square law.  The calibration process of the mathematical model
> should be simple.

Isn't the "compensation" to get better accuracy?


>> Have you looked at a range of data to see what the correction curve
>> needs to be?
>
> Yes, and it is somewhat a square law.  In some cases, I need to change
> the shape of the square law a little.

"A little" is a poor way to describe this.  There are many ways to 
correct your data.  You have chosen one that you find hard to calculate 
quickly enough.  So why not consider others which can be evaluated more 
quickly?  Others have given you other approaches.  I suggest you 
consider them more carefully and not wed yourself to using a variable 
exponent.  You say it is easy for the user to calibrate, but really you 
are saying it is easy for *you* to write the calibration algorithm.  If 
you can do the calibration with two measurements with your variable 
exponent, you can do a calibration with an x^3 term with two 
measurements.  The user doesn't need to know what the software is doing 
with those measurements.

-- 

Rick C

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