aha! Math.log!
double temperature_in_C = (Math.Log(raw_analogueValue) * -35.0) + 28.37;
And this was the little experiment to confirm it's all working
which is now outputting this:
How is this done within FuseGL? I've got a coolant sensor in my engine that I've wired in to the FB using a basic voltage divider, and the formula for its curve is: y
y = -35.0ln(x) + 28.37
Using Sensors.cs, I can make a custom sensor so I know that y will be temperature_in_C and x with be raw_analogueValue. But I'm a bit confused as to how to write that in C#
aha! Math.log!
double temperature_in_C = (Math.Log(raw_analogueValue) * -35.0) + 28.37;
And this was the little experiment to confirm it's all working
which is now outputting this:
Last edited by Grrrmachine; 03-11-2013 at 04:49 PM.
Thanks for the particularly useful comment, but for complete non-coders such as myself it can be a daunting experience. Just trying to help.
sorry, i thoght you have experience by coding in c#, and need some help with math .
FYI - I deleted this original reply and re-replied with the additional PS below. (I hope that makes sense!)
Hmmm - I'm tempted to take on the math - maybe by using the linear approximation technique else suggesting a lookup table and iteration, and harryberlin - you should have typed the search line in to the google LMTTFY link - it's far more effective (and drives the point home to some of the slower people, else the provides the suitable links). :wink:
But I just wanted to comment on the test bed. Definitely as professional as I've ever used (geared up employers excepted) though I can't understand the inverted mug. Mine's always been near full - usually with cold coffee. (That's multiplexing, else limited budget and resources.)
And surely there's some detergent called Ace or Hero or similar - just in case people misconstrue the pic's target audience?
Maybe 2k1Toaster has some suggestion to suit the FB?
For know I'll just sit back and marvel at you guys. :thumbs-up!:
PS (3 hours later) - I had a quick look at linear approximations (in case C++ or the FB can't handle exponentials)...
Grrrmachine the y = -35.0ln(x) + 28.37 - is x centered around some value?
If it is - eg, 1 or 1.5 or 2 etc - then a linear approximation can work quite well. You merely supply the value for ln(x) for its "central" value and add/subtract a simple manipulation of the difference to the actual x as read.
You can find worst case inaccuracy by calculating the extremes and comparing to real ln(x) values.
(Man, I used to use so much of that stuff!)
Apologies if I am stating the obvious.
Last edited by OldSpark; 03-11-2013 at 09:03 PM.
In this application, for a linear approximation to be used I would have to discard a lot of the data. Automotive temp sensors (like most thermistors) have a standard operating range in which they're accurate enough to drive a mechanical dial, which means it's only supposed to show temps between 80 and 95 degrees C. For me, that's not good enough, especially when the sensor itself is responsive from -17 all the way up to 122 degrees.
My maths is as poor as my coding, so my solution was simply to plot all the data into excel, make a chart of it, and then let excel figure out the trendline and provide the formula. As long as the R-squared value of the trendline is close enough, then the formula is there and ready to be converted to C#. In this case, the log formula has an R-squared value of .999
Cool - that's why I asked. And I wasn't sure if x was voltage, though it's not likely to be anything else (since current gets converted to voltage etc).
There are multiplication expansions like the Taylor and Euler series which I think suit any (positive) x value.
And I'm wondering about other circuit components that can offset the ln - ie, make its output voltage linear. (That rings a bell, but...)
Of course then there are logarithmic OpAmp circuits...
But the above is IMO what software is for, except when the low values are too crushed or low for accurate uPC sensing.
Then I'd probably get a more linear temp sensor....
That .999 R^2 formula seems strange. Why not 1? (No, not because 1^2 and 1^infinity are easy to calculate.) Just beware calculation errors. I recall how simple operations done and undone on 1 (or was it 0.1) would come to a .99999 result etc due to binary-decimal errors. Actually it was 0.1, but that was merely a "guaranteed" simple example of binary errors for non-integer numbers..
But I don't know of that "R" stuff, though it reminds me of the sum of least squares and convergence stuff.
At least most "R"s and ln's etc are the same as when I studies it, but we used .IXIXIX instead of σημείο999 etc. (ha ha?)
Bookmarks