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

Groups > comp.arch.embedded > #25054 > unrolled thread

Optimize pow() function

Back to article view | Back to comp.arch.embedded

Contents

  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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#25058

On Thu, 22 Sep 2016 15:36:11 +0200, 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.

Only if you're talking about voltage applied to a resistive load.  
There's a lot of loads that aren't purely resistive.

> 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.

As already suggested, the first thing to do is determine what's wrong 
with your measurement and fix it.

Assuming you can't do that, the first thing that I'd suggest is to use 
interpolation or a curve fit to a number of measured points.  
Interpolation is easy -- just store a number of calibration points and 
then use linear, quadratic, or cubic interpolation between them.  Even 
cubic interpolation should be quicker than using pow.  Alternately, fit a 
function y = A + B * x + C * x^2 + D * x^3 to your calibration points, 
and store A, B, C & D in memory.

-- 
Tim Wescott
Control systems, embedded software and circuit design
I'm looking for work!  See my website if you're interested
http://www.wescottdesign.com

[toc] | [prev] | [next] | [standalone]

#25059

Il giorno giovedì 22 settembre 2016 17:01:51 UTC+2, Tim Wescott ha scritto:

> function y = A + B * x + C * x^2 + D * x^3 to your calibration points, 
> and store A, B, C & D in memory.

and the use the alternate form:

y = A + x *(B + x *(C + x*D))

to calculate the thing, so you need less operations.

Bye Jack

[toc] | [prev] | [next] | [standalone]

#25061

On Thu, 22 Sep 2016 08:08:38 -0700, Jack wrote:

> Il giorno giovedì 22 settembre 2016 17:01:51 UTC+2, Tim Wescott ha
> scritto:
> 
>> function y = A + B * x + C * x^2 + D * x^3 to your calibration points,
>> and store A, B, C & D in memory.
> 
> and the use the alternate form:
> 
> y = A + x *(B + x *(C + x*D))
> 
> to calculate the thing, so you need less operations.
> 
> Bye Jack

Definitely.  Unless you're doing the computations with an ADSP 21xx chip, 
in which case you can code up my original function into a hardware loop, 
with one set of registers doing a MAC and another register doing z = z * 
x at each iteration.  Very handy, if you happen to need to do it.

(The ADSP 21xx core is a frustrating chip to write optimized code for.  
It has a buttload of registers, each of which does two or three things, 
and no two of which do the _same_ set of things.  So you'll be coding 
along, and have to go back a dozen instructions just to (ferinstance) use 
x2 instead of x1, so that when you get to where you are you don't need to 
juggle data around.)

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

I'm looking for work -- see my website!

[toc] | [prev] | [next] | [standalone]

#25062

Tim Wescott <seemywebsite@myfooter.really> wrote:

> On Thu, 22 Sep 2016 08:08:38 -0700, Jack wrote:
> 
> > Il giorno giovedì 22 settembre 2016 17:01:51 UTC+2, Tim Wescott ha
> > scritto:
> > 
> >> function y = A + B * x + C * x^2 + D * x^3 to your calibration points,
> >> and store A, B, C & D in memory.
> > 
> > and the use the alternate form:
> > 
> > y = A + x *(B + x *(C + x*D))
> > 
> > to calculate the thing, so you need less operations.
> > 
> > Bye Jack
> 
> Definitely.  Unless you're doing the computations with an ADSP 21xx chip,
> in which case you can code up my original function into a hardware loop,
> with one set of registers doing a MAC and another register doing z = z *
> x at each iteration.  Very handy, if you happen to need to do it.
> 
> (The ADSP 21xx core is a frustrating chip to write optimized code for.
> It has a buttload of registers, each of which does two or three things,
> and no two of which do the _same_ set of things.  So you'll be coding
> along, and have to go back a dozen instructions just to (ferinstance) use
> x2 instead of x1, so that when you get to where you are you don't need to
> juggle data around.)

or you can let the C compiler do the job for you ;)

Bye Jack

-- 
Yoda of Borg am I! Assimilated shall you be! Futile resistance is, hmm?

[toc] | [prev] | [next] | [standalone]

#25064

Den torsdag den 22. september 2016 kl. 21.12.25 UTC+2 skrev Jack:
> Tim Wescott <seemywebsite@myfooter.really> wrote:
> 
> > On Thu, 22 Sep 2016 08:08:38 -0700, Jack wrote:
> > 
> > > Il giorno giovedě 22 settembre 2016 17:01:51 UTC+2, Tim Wescott ha
> > > scritto:
> > > 
> > >> function y = A + B * x + C * x^2 + D * x^3 to your calibration points,
> > >> and store A, B, C & D in memory.
> > > 
> > > and the use the alternate form:
> > > 
> > > y = A + x *(B + x *(C + x*D))
> > > 
> > > to calculate the thing, so you need less operations.
> > > 
> > > Bye Jack
> > 
> > Definitely.  Unless you're doing the computations with an ADSP 21xx chip,
> > in which case you can code up my original function into a hardware loop,
> > with one set of registers doing a MAC and another register doing z = z *
> > x at each iteration.  Very handy, if you happen to need to do it.
> > 
> > (The ADSP 21xx core is a frustrating chip to write optimized code for.
> > It has a buttload of registers, each of which does two or three things,
> > and no two of which do the _same_ set of things.  So you'll be coding
> > along, and have to go back a dozen instructions just to (ferinstance) use
> > x2 instead of x1, so that when you get to where you are you don't need to
> > juggle data around.)
> 
> or you can let the C compiler do the job for you ;)
> 

the adsp21xx c compiler was horrible, but assembler was very human readable

[toc] | [prev] | [next] | [standalone]

#25065

On Thu, 22 Sep 2016 21:12:21 +0200, Jack wrote:

> Tim Wescott <seemywebsite@myfooter.really> wrote:
> 
>> On Thu, 22 Sep 2016 08:08:38 -0700, Jack wrote:
>> 
>> > Il giorno giovedì 22 settembre 2016 17:01:51 UTC+2, Tim Wescott ha
>> > scritto:
>> > 
>> >> function y = A + B * x + C * x^2 + D * x^3 to your calibration
>> >> points,
>> >> and store A, B, C & D in memory.
>> > 
>> > and the use the alternate form:
>> > 
>> > y = A + x *(B + x *(C + x*D))
>> > 
>> > to calculate the thing, so you need less operations.
>> > 
>> > Bye Jack
>> 
>> Definitely.  Unless you're doing the computations with an ADSP 21xx
>> chip,
>> in which case you can code up my original function into a hardware
>> loop, with one set of registers doing a MAC and another register doing
>> z = z * x at each iteration.  Very handy, if you happen to need to do
>> it.
>> 
>> (The ADSP 21xx core is a frustrating chip to write optimized code for.
>> It has a buttload of registers, each of which does two or three things,
>> and no two of which do the _same_ set of things.  So you'll be coding
>> along, and have to go back a dozen instructions just to (ferinstance)
>> use x2 instead of x1, so that when you get to where you are you don't
>> need to juggle data around.)
> 
> or you can let the C compiler do the job for you ;)

I pity the poor bastard who's called upon to do a good job making an 
optimizing compiler for that chip.  It's the answer to the question "How 
can an instruction set _not_ be orthogonal?"

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

I'm looking for work -- see my website!

[toc] | [prev] | [next] | [standalone]

#25068

Il 22/09/2016 17:01, Tim Wescott ha scritto:
 > [...]
> Assuming you can't do that, the first thing that I'd suggest is to use
> interpolation or a curve fit to a number of measured points.
> Interpolation is easy -- just store a number of calibration points and
> then use linear, quadratic, or cubic interpolation between them.  Even
> cubic interpolation should be quicker than using pow.  Alternately, fit a
> function y = A + B * x + C * x^2 + D * x^3 to your calibration points,
> and store A, B, C & D in memory.

Yes, this is a lighter calculation for the MCU, but the calibration 
would be much more difficult to the operator.

Please, take a look at my answer to Don Y for additional details on my 
system: I have a digital trimmer.

[toc] | [prev] | [next] | [standalone]

#25074

On Thu, 22 Sep 2016 23:15:51 +0200, pozz wrote:

> Il 22/09/2016 17:01, Tim Wescott ha scritto:
>  > [...]
>> Assuming you can't do that, the first thing that I'd suggest is to use
>> interpolation or a curve fit to a number of measured points.
>> Interpolation is easy -- just store a number of calibration points and
>> then use linear, quadratic, or cubic interpolation between them.  Even
>> cubic interpolation should be quicker than using pow.  Alternately, fit
>> a function y = A + B * x + C * x^2 + D * x^3 to your calibration
>> points, and store A, B, C & D in memory.
> 
> Yes, this is a lighter calculation for the MCU, but the calibration
> would be much more difficult to the operator.
> 
> Please, take a look at my answer to Don Y for additional details on my
> system: I have a digital trimmer.

Assuming that you could go offline for a moment right after calibration, 
you could choose to have the operator do whatever calibration action you 
want externally, then compute the values of your coefficients from those 
results.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

I'm looking for work -- see my website!

[toc] | [prev] | [next] | [standalone]

#25083

On 22/09/16 23:15, pozz wrote:
> Il 22/09/2016 17:01, Tim Wescott ha scritto:
>> [...]
>> Assuming you can't do that, the first thing that I'd suggest is to use
>> interpolation or a curve fit to a number of measured points.
>> Interpolation is easy -- just store a number of calibration points and
>> then use linear, quadratic, or cubic interpolation between them.  Even
>> cubic interpolation should be quicker than using pow.  Alternately, fit a
>> function y = A + B * x + C * x^2 + D * x^3 to your calibration points,
>> and store A, B, C & D in memory.
> 
> Yes, this is a lighter calculation for the MCU, but the calibration
> would be much more difficult to the operator.

Nah, it's just a few matrix inversions.  When it is part of a
calibration operation, it doesn't matter if it takes a second for the
calculations (and that would be for the dumbest of 8051 chips - with an
ARM or similar you'd be well under a millisecond).

But the maths is more difficult for the /programmer/ - that might be a
challenge :-)

> 
> Please, take a look at my answer to Don Y for additional details on my
> system: I have a digital trimmer.
> 
> 

[toc] | [prev] | [next] | [standalone]

#25081

On 22/09/16 17:01, Tim Wescott wrote:

> As already suggested, the first thing to do is determine what's wrong 
> with your measurement and fix it.

Yes.  Measure lots of points, getting data on real power versus measured
signal - then you can see what the curve looks like.

Then do the same with different boards, different loads, different
temperatures, different source voltages, different cooling of the loads
- whatever can vary in the system.

Then you can see if you are actually able to get an accurate value for
the real power based only on the measured signal - or if you need more
data (such as a temperature sensor) in your calibration.  And you can
find out what levels of accuracy you can expect from the system.  If
different load types mean a 10% variation in the signal for the same
real power, then there is no point trying to make a complex curve to
squeeze an extra 1% of fit.

> 
> Assuming you can't do that, the first thing that I'd suggest is to use 
> interpolation or a curve fit to a number of measured points.  
> Interpolation is easy -- just store a number of calibration points and 
> then use linear, quadratic, or cubic interpolation between them.  Even 
> cubic interpolation should be quicker than using pow.  Alternately, fit a 
> function y = A + B * x + C * x^2 + D * x^3 to your calibration points, 
> and store A, B, C & D in memory.
> 

Yes, cubics are good for this sort of thing.

Even if the underlying curve really is a power-law curve, a cubic
approximation or cubic spline is likely to be the fastest way to get a
reasonable fit.

[toc] | [prev] | [next] | [standalone]

#25084

David Brown <david.brown@hesbynett.no> writes:
> Even if the underlying curve really is a power-law curve, a cubic
> approximation or cubic spline is likely to be the fastest way to get a
> reasonable fit.

Still seems worth spending some effort identifying sources of error in
the measurement, then seeing how they combine into a joint error term
and trying to estimate that, rather than just guess at the final shape.

[toc] | [prev] | [next] | [standalone]

#25085

On 23/09/16 09:47, Paul Rubin wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> Even if the underlying curve really is a power-law curve, a cubic
>> approximation or cubic spline is likely to be the fastest way to get a
>> reasonable fit.
> 
> Still seems worth spending some effort identifying sources of error in
> the measurement, then seeing how they combine into a joint error term
> and trying to estimate that, rather than just guess at the final shape.
> 

Certainly, if you can get a better model of the system (including its
errors) then that's a good idea.

[toc] | [prev] | [next] | [standalone]

#25095

On Fri, 23 Sep 2016 00:47:02 -0700, Paul Rubin wrote:

> David Brown <david.brown@hesbynett.no> writes:
>> Even if the underlying curve really is a power-law curve, a cubic
>> approximation or cubic spline is likely to be the fastest way to get a
>> reasonable fit.
> 
> Still seems worth spending some effort identifying sources of error in
> the measurement, then seeing how they combine into a joint error term
> and trying to estimate that, rather than just guess at the final shape.

Well, yes, but sometimes that's just not in the cards, either because of 
the abilities of the people involved, or because management's breathing 
down one's neck.

Finding root problems and fixing them are almost always best in the long 
run.  Unless they delay product introduction to such an extent that your 
project gets canceled, or misses its market window -- then they're bad in 
the long run.

-- 
Tim Wescott
Control systems, embedded software and circuit design
I'm looking for work!  See my website if you're interested
http://www.wescottdesign.com

[toc] | [prev] | [next] | [standalone]

#25075

Il giorno giovedì 22 settembre 2016 15:36:12 UTC+2, pozz ha scritto:

> 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);

start using integer math instead of float.

Bye Jack

[toc] | [prev] | [next] | [standalone]

#25098

Am 23.09.2016 um 08:15 schrieb Jack:

> start using integer math instead of float.

Good advice in general, but hardly practical while he's still dead-set 
on computing, of all things, a fractional power of his input value.

[toc] | [prev] | [next] | [standalone]

#25111

On 9/22/16 9: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.
>
Whoever told you that didn't give you the full message, as it applies in 
only very limited cases.

Electrical Power is Voltage * Current, not Voltage squared.

IF you have a resistive load, then we have that

Voltage = Current * Resistance.

 From this we can get to Power = Voltage * Voltage / Resistance.

This means that for a system with constant resistance we can say that 
Power goes as Voltage squared, with a scale factor of 1/Resistance.

If the resistance of the system isn't constant, this relationship 
absolutely doesn't hold. I have built systems where (within an operating 
band) the Power consumed goes up with dropping voltage.

If all you can measure in the field is the Voltage, and the system if 
fairly stable, then what you can do is in the lab go to a NUMBER of 
points and measure voltage and power to determine how your system 
responds and come up with some sort of curve to fit the results.

You need MORE points than unknowns to be able to sanity check your fit. 
You also should perform it under varying conditions (like ambient 
temperature) to make sure the results are stable.

[toc] | [prev] | [next] | [standalone]

#25112

On 25.9.16 13:50, Richard Damon wrote:
> On 9/22/16 9: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.
>>
> Whoever told you that didn't give you the full message, as it applies in
> only very limited cases.
>
> Electrical Power is Voltage * Current, not Voltage squared.
>
> IF you have a resistive load, then we have that
>
> Voltage = Current * Resistance.
>
> From this we can get to Power = Voltage * Voltage / Resistance.
>
> This means that for a system with constant resistance we can say that
> Power goes as Voltage squared, with a scale factor of 1/Resistance.
>
> If the resistance of the system isn't constant, this relationship
> absolutely doesn't hold. I have built systems where (within an operating
> band) the Power consumed goes up with dropping voltage.
>
> If all you can measure in the field is the Voltage, and the system if
> fairly stable, then what you can do is in the lab go to a NUMBER of
> points and measure voltage and power to determine how your system
> responds and come up with some sort of curve to fit the results.
>
> You need MORE points than unknowns to be able to sanity check your fit.
> You also should perform it under varying conditions (like ambient
> temperature) to make sure the results are stable.


The situation of the OP is more complex: He's attempting to measure
the output power of a RF amplifier by measuring the DC feed voltage
and relating the output power to it.

There are simply too many moving parts in the equation, it will not
work with some mathematical trickery.

-- 

-TV

[toc] | [prev] | [next] | [standalone]

#25113

On 09/25/16 13:36, Tauno Voipio wrote:

>
> The situation of the OP is more complex: He's attempting to measure
> the output power of a RF amplifier by measuring the DC feed voltage
> and relating the output power to it.
>
> There are simply too many moving parts in the equation, it will not
> work with some mathematical trickery.
>

This has been a long thread, but fundamentally, you can't determine
output power into the load without measuring the load vswr. Depending
on the output power, a simple directional coupler could be a short 
length of coax, measuring forward and reverse power simultaaneously,
which could be calibrated via a lookup table and interpolation to the
required accuracy. No need for complex math in the software...

Why does it have to be such hard work ?...

Regards,

Chris

[toc] | [prev] | [next] | [standalone]

#25116

On 26.9.16 20:30, Chris wrote:
> On 09/25/16 13:36, Tauno Voipio wrote:
>
>>
>> The situation of the OP is more complex: He's attempting to measure
>> the output power of a RF amplifier by measuring the DC feed voltage
>> and relating the output power to it.
>>
>> There are simply too many moving parts in the equation, it will not
>> work with some mathematical trickery.
>>
>
> This has been a long thread, but fundamentally, you can't determine
> output power into the load without measuring the load vswr. Depending
> on the output power, a simple directional coupler could be a short
> length of coax, measuring forward and reverse power simultaaneously,
> which could be calibrated via a lookup table and interpolation to the
> required accuracy. No need for complex math in the software...
>
> Why does it have to be such hard work ?...
>
> Regards,
>
> Chris


 From a directional coupler, you get the component amplitude, which
has to be squared for power. (It is kosher here, due to telegraph
equations). The math happens to go so that the net output is available
as forward power - reflected power.

-- 

-TV

[toc] | [prev] | [next] | [standalone]

#25117

Il 25/09/2016 15:36, Tauno Voipio ha scritto:
 > On 25.9.16 13:50, Richard Damon wrote:
 >> On 9/22/16 9: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.
 >>>
 >> Whoever told you that didn't give you the full message, as it applies in
 >> only very limited cases.
 >>
 >> Electrical Power is Voltage * Current, not Voltage squared.
 >>
 >> IF you have a resistive load, then we have that
 >>
 >> Voltage = Current * Resistance.
 >>
 >> From this we can get to Power = Voltage * Voltage / Resistance.
 >>
 >> This means that for a system with constant resistance we can say that
 >> Power goes as Voltage squared, with a scale factor of 1/Resistance.
 >>
 >> If the resistance of the system isn't constant, this relationship
 >> absolutely doesn't hold. I have built systems where (within an operating
 >> band) the Power consumed goes up with dropping voltage.
 >>
 >> If all you can measure in the field is the Voltage, and the system if
 >> fairly stable, then what you can do is in the lab go to a NUMBER of
 >> points and measure voltage and power to determine how your system
 >> responds and come up with some sort of curve to fit the results.
 >>
 >> You need MORE points than unknowns to be able to sanity check your fit.
 >> You also should perform it under varying conditions (like ambient
 >> temperature) to make sure the results are stable.
 >
 >
 > The situation of the OP is more complex: He's attempting to measure
 > the output power of a RF amplifier by measuring the DC feed voltage
 > and relating the output power to it.

I think many misunderstandings derive from this assumption.  I never 
wrote (or I think I never wrote) that I need to calculate the output 
power of an amplifier knowing only the DC feed voltage.

I'm trying to calibrate a measurement device that, in my case, is a 
directional coupler.  For me (the firmware engineer), it is a voltage 
signal that is related to the output power by a square mathematical law 
(at least, this said the RF engineer).

By comparing our results with a professional instrument, we noticed that 
the square law (P=kV^2) is somewhat good for our necessity. 
Unfortunately, if it is calibrated at the nominal power (k), at low 
power levels the results deviate a little from the theorical square law.

This is why I'm trying to introduce a second parameter in a mathematical 
law P=f_k,h(W) that is *the* square law when the second calibration 
parameter (h) isn't touched.
That formula is:
    P = k * (V / Vn) ^ (2 + h)
When h=0 (second calibration parameter not touched) the law *is the* 
theoric square law.

If the operator notices a big error at, i.e., Pn/2, he tries to change 
h. In this way, he is sure the measure at Pn/Vn will not change.

 >
 > There are simply too many moving parts in the equation, it will not
 > work with some mathematical trickery.
 >

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.arch.embedded

csiph-web