Do you have a question? Post it now! No Registration Necessary
- Subject
- Posted on
Re: Fixed-point algorithm for exponential function fitting for anembedded application
Please do not use html or mime. Usenet is a text mechanism.
Deleted as a security measure.
--
Chuck F ( snipped-for-privacy@yahoo.com) ( snipped-for-privacy@worldnet.att.net)
Available for consulting/temporary embedded and systems.
Chuck F ( snipped-for-privacy@yahoo.com) ( snipped-for-privacy@worldnet.att.net)
Available for consulting/temporary embedded and systems.
We've slightly trimmed the long signature. Click to see the full one.
Re: Fixed-point algorithm for exponential function fitting for an embedded application
--------------070207040202090703010609
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Please, see my answers inserted.
Jonathan Kirwan a écrit:
OK with that except that actually k is the damping factor which
proportional to viscosity. But this is a detail.
You are right. There is no magic: C is not 0 and we have to include it
in the computation.
No, your argumentation is totally correct.
No. I did not think about that. What do you mean by measurement
uncertainty?
Yes; dsPIC is the processor I am using. It is indeed equipped with a
barrel shifter.
--------------070207040202090703010609
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Please, see my answers inserted. <br>
<br>
Jonathan Kirwan a écrit:<br>
<blockquote type="cite"
cite=" snipped-for-privacy@4ax.com">
<pre wrap=""> { I'm keeping the cross-posted newsgroups intact,
but I only read comp.arch.embedded. }
On Wed, 20 Jul 2005 12:08:03 +0200, Eric Meurville
<a class="moz-txt-link-rfc2396E"
</pre>
<blockquote type="cite">
<pre wrap="">(1)
The data to be fitted come from
</pre>
</blockquote>
<pre wrap=""><!---->
So, it is to be fitted.
</pre>
<blockquote type="cite">
<pre wrap="">a Hall effect sensor from iC-Haus
(<a class="moz-txt-link-freetext"
href="http://www.ichaus.de/upload/pdf/Ma_a1es.pdf ">http://www.ichaus.de/upload/pdf/Ma_a1es.pdf </a>)
which delivers angular
positions of a rotating magnet. The output A of this sensor is connected
to the Input Capture Module of a dsPIC30F from Microchip able to
measure time between edges (every edge, every falling or rising edge,
every 4th edge or every 16th edge). Presently, the modules delivers 64
durations (time between 2 consecutive edges) per rotor turn and values
are unsigned integers between 192 and 57600 (16-bit timer for rotation
speed between 1 and 300 Hz, Fosc = 7.3728 MHz x 16, Prescaler timer = 8
and Hall sensor resolution = 64).
The magnet rotation is an exponential decay as after exciting it with an
external rotating magnetic field till 300 Hz, we cut the excitation and
the magnet being immersed in a viscous solution sees its rotation speed
slow down exponentially till .
</pre>
</blockquote>
<pre wrap=""><!---->
Is it then the case that:
1/x(t) = A * e^[-k*t] + C
where you are measuring the interval, x(t)? If so, I take it that the
viscosity is 'k'. So:</pre>
</blockquote>
<b><font color="#000099">OK with that except that actually k is the
damping factor which proportional to viscosity. But this is a detail.
</font></b><br>
<blockquote type="cite"
cite=" snipped-for-privacy@4ax.com">
<pre wrap="">
1/x(t) = A * e^[-k*t] + C
-- magically assume that C=0, for reasons I don't understand --</pre>
</blockquote>
<font color="#000099"><b>You are right. There is no magic: C is not 0
and we have to include it in the computation. </b></font><br>
<blockquote type="cite"
cite=" snipped-for-privacy@4ax.com">
<pre wrap="">
1/x(t) = A * e^[-k*t]
ln(1/x(t)) = -k*t + ln(A)
-ln(x(t)) = -k*t + ln(A)
ln(x(t)) = k*t - ln(A)
And where you will use a linear least squares fit, assuming that there
is no error in your 't' ordinate and all the error is along the x(t)
direction (the usual, very simple least squares technique, with
obvious and simple partials to solve to yield the algorithm.)
Or am I just way off?</pre>
</blockquote>
<font color="#000099"><b>No, your argumentation is totally correct.
</b></font><br>
<blockquote type="cite"
cite=" snipped-for-privacy@4ax.com">
<pre wrap="">But what is C and how do you remove it, before taking ln()? If
you do
plan to use least squares in the log domain, how do you plan to remove
this offset? Have you also considered how the measurement uncertainty
itself changes as a function of time after casting the data into the
log domain?</pre>
</blockquote>
<font color="#000099"><b>No. I did not think about that. What do you
mean by measurement uncertainty? </b></font><br>
<blockquote type="cite"
cite=" snipped-for-privacy@4ax.com">
<blockquote type="cite">
<pre wrap="">(2)
5.11 format seems to be suitable as the range of ln calculation is
between 192 and 57600.
</pre>
</blockquote>
<pre wrap=""><!---->
Okay.
I haven't looked at the dsPIC (assuming that this is the processor to
which you plan to add your code.) But does it have a barrel shifter
available?</pre>
</blockquote>
<font color="#000099"><b>Yes; dsPIC is the processor I am using. It is
indeed equipped with a barrel shifter.</b></font> <br>
<blockquote type="cite"
cite=" snipped-for-privacy@4ax.com">
<pre wrap="">
Jon
</pre>
</blockquote>
</body>
</html>
--------------070207040202090703010609--
Re: Fixed-point algorithm for exponential function fitting for an embedded application
{ I'm keeping the cross-posted newsgroups intact,
but I only read comp.arch.embedded. }
On Wed, 20 Jul 2005 22:04:36 +0200, "eric.meurville"
Which, how to remove C or the fact that your exponential tail data
will incorrectly dominate your result, unless you use a correcting
weighting factor?
If you imagine that you are taking sampled measurements of some real
underlying physical process, there is some error associated there. If
you take the same measurement 10 times you will not get the exact same
data set every time. The measured points contain added noise, which
is unpredictable. In electronic systems, this noise is usually the
aggregate of many individual Poisson events, which yields a Gaussian
distribution.
For example, let's ignore this "count" stuff you are working with and
consider a more traditional measurement of decaying volts. Say the
noise has a standard deviation of 0.1 volt. In electronics systems,
it is usually the case that this 0.1V deviation is the same whether
you are measuring it at a 10V signal level or at a 1V signal level.
So when you sample a portion of the decay, as it falls from say 10V to
1V, your expected 1-sigma noise across all the samples is still
+/-0.1V, whether the measurement was 10V, 5V, or 1V.
Now, when you take the ln() of your data set, the impact of this noise
upon the resulting log-values will no longer be equal in terms of %.
a 0.1V figure against 10V will not show the same deviation in the log
domain as will a 0.1V figure against 1V. This fact can greatly impact
the way a naive least square fit routine calculates the slope. It
will incorrectly over-emphasize the data points at the tail of the
curve and they will dominate the calculated slope. I already posted
to this thread, elsewhere, that a simple weighting factor, based on
the square of the raw data, can be applied to the least square fitting
routine in order to treat the variations in the log domain correctly.
Essentially, it amounts to this: uncertainty in the measurement
domain acquires a new signal-dependence in its uncertainty, when
placed into the log-domain. If the uncertainty is constant in the
measurement domain and is also small compared to the signal itself,
then you can use 1st order Taylor's to approximate
ln( V_t +- Sn_t ) = ln( V_t ) +- ( Sn_t / V_t )
And here you can see that the relative noise in the log domain is
scaled by (1/V_t) -- in other words, you need to adjust how you weight
the error in each point, based on the measurement itself.
Actually, closer thinking on a variety of issues can help. This is
only a hand-waving pointer in one general direction. There are many
other subtle issues to consider, such as selecting the right
measurement window (you should easily realize that too little data
will be bad and that too much data, mostly in the nearly useless tail,
will similarly not help, and that this implies an optimal middle
ground to seek), etc. But that's what I was referring to.
Jon
Re: Fixed-point algorithm for exponential function fitting for an embedded application
{ I'm keeping the cross-posted newsgroups intact,
but I only read comp.arch.embedded. }
On Wed, 20 Jul 2005 22:04:36 +0200, "eric.meurville"
You aren't logging your data for later analysis, as one might normally
do if this were a research project at an educational institution. (I
had already looked up the epfl site.) This is something being done in
real time, which suggests that you are making an instrument for sale
or internal, practical use. Yes?
Jon
Re: Fixed-point algorithm for exponential function fitting for an embedded application
We are an educational institute very industry oriented. We are presently
preparing a demonstrator which is actually a small embedded system and
the processing must be performed in real time. This research project is
presently financed by the Government and hopefully will become a product
in few years.
--
Eric Meurville
Eric Meurville
Re: Fixed-point algorithm for exponential function fitting for an embedded application
On Thu, 21 Jul 2005 13:53:25 +0200, Eric Meurville
Understood. Optimizing the sensitivity and repeatable precision of
measurement of exponential decay rates is something I've specialized
in for over 15 years -- from mathematical development and refinement,
through stochastics arguments and monte carlo simulation in helping to
make optimal choices for measurement periods, sampling rates, etc.,
through to the software routines to minimize undesirable artifacts
from their calculations in small microcontrollers and integer DSPs, at
measurement rates (not sampling rates, but full measurement of the
slope) spanning from 10k/sec to 1/sec. This means highly optimized
and highly precise routines for very fast execution on processors
without access to specialized hardware.
I guess that explains why I was drawn to your original question.
Jon
Understood. Optimizing the sensitivity and repeatable precision of
measurement of exponential decay rates is something I've specialized
in for over 15 years -- from mathematical development and refinement,
through stochastics arguments and monte carlo simulation in helping to
make optimal choices for measurement periods, sampling rates, etc.,
through to the software routines to minimize undesirable artifacts
from their calculations in small microcontrollers and integer DSPs, at
measurement rates (not sampling rates, but full measurement of the
slope) spanning from 10k/sec to 1/sec. This means highly optimized
and highly precise routines for very fast execution on processors
without access to specialized hardware.
I guess that explains why I was drawn to your original question.
Jon
Re: Fixed-point algorithm for exponential function fitting for an embedded application
My favorite reference for fixed point exp() and log() is
Knuth's "Metafont: The Program". That is in Pascal, but there
are C versions of Metafont, some done through machine source
translation. In any case, the algorithm should be described
well enough that you can write C code from it.
-- glen
Site Timeline
- » Reverse current into a lithium battery
- — Next thread in » Embedded Programming
- » Atlanta- Embedded software engineer needed
- — Previous thread in » Embedded Programming
- » A new benchmark suitable for small systems: stdcbench
- — Newest thread in » Embedded Programming
- » cherche petit Ã©metteur spÃ©cifique
- — The site's Newest Thread. Posted in » Electronics (French)