# Mapping a non-linear sensor value

Hi guys new member on the forum I want to thank you all for having me.

I have a problem mapping a non-linear value - as the title states. I’m reading from analog input, and the values are weird, first it starts at zero ground (which in my case is around 430) then dips down, then goes up again and gradually grows.

My question is, if I wanted to map these values, for ex. 430 to be 1, 412 to be 2, and then as you can see from the picture below, it goes up, so say right after the 10 on the X-axis which would be around 11-12 the sensor value would be the same as the 0 on the X-axis (around 430). How would the program know that the first one is 0 and then the second same value is 12(approximately), and more importantly, how will the mapping go?

I read about the map function and multiMap, but I don’t think that would be the best approach to my problem. How would the program understand the mapped values if they have the same sensor readings?

Thanks and have a nice day.

How would the program understand the mapped values if they have the same sensor readings?

How could a human understand them? The sensor obviously isn't useful at the low range.

Thanks for the reply.

But those low range values are important for me, that’s how the mapping needs to go - I realise that there are duplicated values, I was asking is there any solution for this? I hope you understood what I was trying to explain.

The sensor does not give unique values for different inputs, so the output is impossible to interpret. You need a different sensor.

Create an array and map the sensor values and the output you want. If there are two input values that are the same, you can determine by array position how to handle it.

If there are two input values that are the same

The problem is that two output values are the same, for different input values.

Two output values being the same is easy. Shoot in the easiest case the output is a constant value for all values of input. 8^)

In this case, the OP has to determine which part of the curve he should use. If the sensor input can randomly spit out any value it will be impossible. Other wise he might have to keep track of old values to determine which part of the curve he is on.

In this case, the OP has to determine which part of the curve he should use.

Yep. Another sensor! Cheers!

Not necessarily, he might be able to tell from the slope or other information which part of the curve he is on. For example, if you use RPM to calculate vehicle speed you just need to keep track of what gear you are in. You might not even need a separate sensor for that. As long as you always go from one gear to another in order, you just need to keep track of the discontinuities in the rpm values.

Hi and thanks for the replies and suggestions.

I added another sensor, and now for every input I write 2 output sensors to EEPROM and later read them to determine which number I'm on, so I can distinguish the duplicate numbers.

But now, for the mapping part, if I tell it to map from 0 to 40, it will go from 430 to 580 (suppose those are the sensor values), but in my case 10 will be the dipping area - 410(ish) so it won't register those values, and again it will be a mess.

Do I go manually and tell it if it's at 0, map it from 0 to 5 (430-420), if the value is 5 - map it from 5 to 10?

What kind of sensor is this?
Is the initial dip just an artifact of starting up somehow?
Is the behavior you're talking about over time, and you're wrongly mapping it to a linear scale?
It sounds like this sensor would never be able to change directions and make sense, with the way you're describing it, which makes me ask again, what kind of sensor is this? Some kind of cumulative counter, capacity, or something?

I think you're confusing yourself with that nonsensical graph with what you put on the axes. Think of mapping more like a function table. Every input can only have one unique output, else it is not a function.

1 Like

If the graph truly represents that output of that sensor, it is completely useless.

For a single, isolated reading on the lower part of the horizontal axis, it is impossible to distinguish between two possible inputs. Throw it away and choose another sensor from a different manufacturer.

To be completely useless it would have to produce no information about what its sensing - this sensor
produces quite a lot of information.

Sensor is fine, the malfunction is the user.

Said user might as well be mapping Y-axis temperature and X-axis date, and saying no two days can have the same temperature.

gimza:
I added another sensor, and now for every input I write 2 output sensors to EEPROM and later read them to determine which number I'm on, so I can distinguish the duplicate numbers.

When people said "add another sensor", they meant "that is different from the one you have".

With respect to that dip, you need some way to decide which side of the dip your sensor is on. For instance, maybe you know that at a certain time of day, the 'real' value will be increasing. By looking at how the sensed value is moving, you can tell which side of the dip you are on: if the real value should be increasing, and the sensor is reporting that the sensed value is decreasing, then it's a safe bet that you are on the left hand side of that curve. Maybe you know that of your motor is "reverse" and has been reversed for for than 50ms, then the value should be dropping. Again, this is enough to tell you where on the curve the value currently is.

In other words: maybe there's some other source of information that you can use to disambiguate the state. Another sensor that (for instance) is very probably false at less than 5 and very probably true at greater than 5 would allow you to probably get the reading right.

As for the mapping: use floating point. A floating point number is almost always only an approximation of some real value, but sensors aren't accurate unless they are counting things - using floating point isn't going to introduce more inaccuracy than you already have.

BTW: you might get better advice if you tell people what this sensor actually is rather than trying to be all abstract.