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


Groups > comp.arch.embedded > #25091

Re: Optimize pow() function

From Evgeny Filatov <e.v.filatov@ieee.org>
Newsgroups comp.arch.embedded
Subject Re: Optimize pow() function
References <ns0mo1$7j2$1@dont-email.me> <ns0p5g$ggu$1@dont-email.me> <ns1hbm$c75$1@dont-email.me> <ns1jmm$jk0$1@dont-email.me> <ns2l98$789$1@dont-email.me>
Message-ID <W_6Fz.693$9A6.240@fx41.iad> (permalink)
Organization usenet-news.net
Date 2016-09-23 12:56 +0300

Show all headers | View raw


On 23.09.2016 10:23, pozz wrote:
> Il 22/09/2016 23:50, Don Y ha scritto:
>> On 9/22/2016 2:10 PM, pozz wrote:
>>
>>>  > 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.
>>
>> Backup.
>>
>> You're calibrating because, presumably, you need *some* degree of
>> accuracy.
>> How (formally) has that been specified?  Percent of reading?  Percent of
>> range?  etc.
>>
>> This tells you how "good" your model of the load must represent the
>> ACTUAL load, as viewed from the standpoint of your *single* measurement
>> device.  So far, you appear to only be considering fitting a curve
>> to two points:
>> - 0V (= 0 power!)
>> - Vmax (= some particular power)
>>
>> Yet, you seem to care about the values between 0 and Vmax.
>>
>> How *much* do you care about them?  If you are only operating at the
>> 0 & Vmax points on the curve, then you don't need to fit an equation;
>> just store:
>>    (0V, 0W)
>> and
>>    (Vmax, Pmax)
>>
>> [Obviously, this is not the case!]
>
> Yes, I already made those considerations and I already tested my
> mathemaical model (exponentiation) against the correct measures made by
> a professional instrument.  I found exponentiation (after calibration)
> is good for the accuracy I need in the application.
>
>
>>> 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.
>>
>> But, you aren't *controlling* any of these things (?) rather, just
>> *sensing* them (i.e., someone tells you "this is a load of X" while
>> you examine a sensed parameter -- voltage -- to correlate with that
>> declaration).
>
> The operator enters nominal power Pn (depending on the machine under
> test). The voltage needed at nominal power Vn is fixed (somewhat at 80%
> of the ADC input range, 0-4.096V = 3276 points).
> During first step calibration, the operator actually changes the trimmer
> position until the input voltage to the ADC is Vn (the ADC conversion
> value is 3276 points).
>
>
>>> The user increase/decrease the trimmer pot until the correct power is
>>> displayed.
>>
>> What is your *load*?  If purely resistive, does it have a temperature
>> coefficient?  (e.g., if you left it operating at Pmax, would you see
>> changes)
>>
>> In operation, do you expect the load to be "static"?  Or, time varying?
>> Does the load's impedance change based on how *it* is driven?  etc.
>
> I don't care the load.  I'm only working on the power transducer.  If
> the load changes (because of temperature, degradation, ...), the output
> signal of transducer will change accordingly and the power reading will
> change too.
>
>
>>> 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.
>>
>> Your concern should be that of how *accurate* the proposed calibration
>> will be, in the context of the specifications governing that accuracy.
>> Unless you know how your load behaves, how can you begin to analyze how
>> well your model (equation) will fit its observed behavior?
>>
>> Someone (customer) will apply your device and complain that the accuracy
>> AT THEIR PARTICULAR OPERATING POINT sucks.  Regardless of how accurate it
>> is at "0" and "Pmax" (and P/2).
>>
>> Understand the load, first.  This gives you an idea of what *style* of
>> model you should be using.  Then, design the calibration procedure to
>> exploit that model as appropriate.
>
> I think I'm making a measurement device.  It is independent from the
> load.  I only have to calibrate my measurement device, that is my
> transducer.
>

Nope. In general case the load will influence the measurement, unless 
it's specifically provided for by the hardware. What I mean is the 
relationship doesn't have to be linear.

What I would suggest you to do -- get your hardware schematics, then use 
it to produce a model of how does the measurement work (involving the 
load). In that model you would have perhaps two unknown variables (like 
real and imaginary parts of complex impedance of the load), so then you 
would know exactly how many measurements do you need to make, and how to 
calculate the power.

HTH,

Gene

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