HEY,
So I have been using map() in my project. I need to convert my analog readings to extermely low float numbers.
variable = map(analogread, 0, 1023, 0.009, 0.1);
The above map function doesn't seem to work.
Is there a limitation for map() function?
Take a look at the documentation - it's using long, not float.
Is there a library or a function which can be used to map float variables
Any help is appriciated. 
You could just write your own. It is just a linear interpolation.
Here is the actual map() function. You could start with that.
long map(long x, long in_min, long in_max, long out_min, long out_max) {
return (x - in_min) * (out_max - out_min) / (in_max - in_min) + out_min;
}
you could use
double fmap(double x, double in_min, double in_max, double out_min, double out_max)
{
return (x - in_min) * (out_max - out_min) / (in_max - in_min) + out_min;
}
EDIT: sorry @ToddL1962, typing at the same time
J-M-L:
you could usedouble fmap(double x, double in_min, double in_max, double out_min, double out_max)
{
return (x - in_min) * (out_max - out_min) / (in_max - in_min) + out_min;
}
EDIT: sorry @ToddL1962, typing at the same time
Lol. No worries.
Thanks All for the quick reply
(analogin - 0) * (0.1 - 0.009) / (1023 - 0) + 0.009
This also worked for me
The correct scale factor for analog to digital or digital to analog conversion is an exact power of two, in this case 1024. Not 1023.
Huh? I dont know much about math but the above solution seemed to work for me.
And also I am scaling from 0 - 1023 not from 0 -1024.
SathvikHegde:
Huh? I dont know much about math but the above solution seemed to work for me.
And also I am scaling from 0 - 1023 not from 0 -1024.
It works because the error is so small.
Your last sentence is wrong. You scale by, not "scale from". In fact, 0-1023 is 1024 values, that has a lot to do with why you should scale by 1024.
that has a lot to do with why you should scale by 1024
everything to do with
aarg:
It works because the error is so small.Your last sentence is wrong. You scale by, not "scale from". In fact, 0-1023 is 1024 values, that has a lot to do with why you should scale by 1024.
Oh, I see
Next I will try to scale values which are exact power of 2
Thanks For the quick replies though
aarg:
The correct scale factor for analog to digital or digital to analog conversion is an exact power of two, in this case 1024. Not 1023.
are we having this debate again?
Once you have sampled your analog value, there is no going back to the original. You have to pick a guess that would have been interpreted as that value. So 1023 and 1024 are both leading to possible values
some possible reverse functions:
Your link is broken. I can't find my boilerplate explanation, someone else may want to tackle it.
The (usual) goal of division by the ADC precision, is to normalize the value to the range 0.0-1.0, essentially to make the value "virtual" and not depend on the precision. This value is then often multiplied by another scaling value that represents some physical range (like 0-5V).
The exact literal value produced by the ADC is always at the low end of a range of actual input values. For example, a 2 bit ADC will produce a "0" for any input between 0 and 1/4 of the full scale input. It will produce a "3" for any value between 0.75 and 1.0. However in treating the ADC result, it is important to remember what it actually represents - a range. Thus if we read "3" we shouldn't complain that it doesn't represent 1.0 just because we "know" that the input is 1.0. That happens when people try to scale for voltage and cry when it seems unable to represent the full scale value (e.g. 5.000V). There are four ranges in the input of a 2 bit ADC. Dividing the reading by the same number, 4, produces a valid index to the lower bound of the range that it registered. If we understand that a reading of 3/4 actually refers to the range 3/4 to 1, everything is good. However if we fall into the temptation of "correcting the error" of the upper range so it will produce the full range value, we have broken the system, as if we divide by 3, 3/3 does produce a 1, but inputs between 0.75 and 1 now scale outside (above) the input range. That is not an honest representation of the actual range that the input signal was contained in.
The four ranges of a 2 bit ADC correspond to four normalized ranges within the range 0-1 if, and only if, the result is divided by the exact number of ranges, which is 2^(bits of ADC precision). The same principle applies to an ADC of any precision.
It is true that the truncation error from quantization tempts a guess at the original value. But the "best guess" is one that uses the same scale factor for normalization, as it does for measurement.
thanks - corrected the link (Dividing by 1023 or 1024? The final verdict on analogRead) - there was a healthy debate there. Not sure anyone changed opinion
Mine is that it does not matter. Both are OK, and zillions more options. As long as you fit within the interval leading to that sampled value, your guess is as good as any other. (you could look at minimizing the distribution error but then it's best to shoot for the center of the interval - and given the precision of the ADC and power supplies usually used... there is no point)
It reminds me of the "Can an airplane on a conveyor belt running in the opposite direction from the runway in front of the plane, take off?" controversy. Two camps, reams of confusing arguments from both sides. People sticking to their view no matter what. People saying, "it's obvious". Occasional conversions.
Never heard about the plane but seems like a relative velocity question to me
There might be some aerodynamics laws at play that I’m not aware of though
The ADC feels simpler. Once you have sampled, you lost information. There is no going back as a range of different analog values can lead to that sample. So it’s ok to have a range of formulas leading to a likely original value - ideally categorized with an error range.
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.