Math problem.

Projects General Guidance
1

Can someone help with this code.
In the setup I need to calibrate a sensor(mv1) so what ever value it returns( lets say 300 at the start) will give the variable ppo1 a value of 100.
So the calibration value would be 300/100=3 or multi1=mv1/100

Later if the sensor gives a value of 600 then ppo1 should then =200 so mv1/multi=200

All seems pretty straight forward but the math does not work and I guess it has to do with decimal places or something.

Can someone please explain how this code should be written.

setup()

mv1=analogRead(PPO1pin);
mult1=(mv1/100); // puts sensor value into PPO#pin then works out the calibration multiplier.

Loop()

mv1=analogRead(PPO1pin);
ppo1=mv1/mult1;

2

OK. I have tried it a different way and it seems to work much better.

But is it best?

What is the highest number you can work with ( 32767?) and what is the lowest (0?)?
From what I understand you cant use decimals? so 0.1 cant be used and 9/4= 2 not 2.25??

setup()

mv1=analogRead(PPO1pin);
mult1=(mv1/4);

Loop()

mv1=analogRead(PPO1pin);
ppo1=(mv1*25)/mult1;

3

Do you want the value when it starts to = 100 no matter what the initial value is?

4

I want PPO to = 100 at start up based on what the value of mv1 is.
So if mv1=500 at start up PPO will be 100.( mult1= 500/100)
Later when mv1 changes to 250 PPO will = 50
If mv1 changes to 1000 PPO will then =200

Like wise upon start up if mv1 = 200 PPO will be 100 ( mult1= 200/100)
when mv1 rises to 1000 PPO will be 500

5

What is the highest number you can work with ( 32767?) and what is the lowest (0?)?

An "int" has the range -32768 to +32767, an "unsigned int" has the range 0 to 65535,
a "long" goes -2 147 483 647 to +2 147 483 648 and an "unsigned long" 0 to 4 294 967 295.

6

Packhorse:
What is the highest number you can work with ( 32767?) and what is the lowest (0?)?
From what I understand you cant use decimals? so 0.1 cant be used and 9/4= 2 not 2.25??

AWOL has given you the highest and lowest values of the integral types. If you want to use decimals, use type 'float' instead. So, whereas 9/4 is indeed 2, 9.0/4.0 is 2.25, as is ((float)9)/((float)4).

7

If you want Analog In * Scale = 100 then Scale=100/Analog In

mv1=analogRead(PPO1pin); //=Analog In
mult1=(100/mv1); //=Scale
ppo1=mv1*multi1 //=100
Or
If you want Analog In /Scale= 100 then Scale=Analog In/100

mv1=analogRead(PPO1pin);
mult1=(mv1/100);
ppo1=mv1/multi1

float variable will let you use decimals but... see reference/float
You may want to glance at variable decleration while your there

8

You can use the map function to map the input of an analogRead() to the values 0..100.

void setup()
{
  Serial.begin(115200);
  Serial.println("Start");
}

void loop()
{
  int val = analogRead(A0);
  int x = map(val, 0,1023, 0,100);
  Serial.println(x);
  delay(1000);
}
9

I think he/she need to calibrate first.
Maybe to an ambient reading or some kind of calibration medium for a sensor.
Perhaps this: ( 'unsigned int', close enough? )

setup()
mv1=analogRead(PPO1pin);
mult1=((mv1*10)/2);

Loop()

mv1=analogRead(PPO1pin);
ppo1=((mv150)/mult110);

10

Thanks Robcam ( and everyone else).

He/me needs to calibrate first.

I see your solution is similar to mine which seems to work well.
So basically increasing the values so that any decimals have very little effect on the math while keeping the values low enough to not exceed 32767.

11

so 0.1 cant be used and 9/4= 2 not 2.25??

float result = 9 /4;
// result will contain 2

float result = 9.0 / 4.0;
// result will contain 2.25

12

I see your solution is similar to mine which seems to work well.
So basically increasing the values so that any decimals have very little effect on the math while keeping the values low enough to not exceed 32767.

I just changed your solution so mult1 would always equal a whole number so it has half a chance of being exact. The values would be less than 65,535 'unsigned int'. If mv1 = 1023 then multiplying it by 50 will =51150.
Multiply by <32 in you want to use int.

Your first solution (and mine) will work with float. I can see why float is slower than int calculations but I'm not sure why

Floating point numbers are not exact, and may yield strange results when compared.