Before I continue I will say that everything worked just fine before I started altering the code to eliminate a harmless but annoying bug (unrelated to map).

I reverted my troubleshooting steps (or at least this is what I believe) but the map() doesn't re-map the value properly anymore.

As soon as the re-mapped value exceeds the number 2386, it continues with -2385, -2384,...,0, 1, 2, ....2385, 2386, -2385, etc. in circles.

HW: Arduino Pro Micro (detected as Leonardo) + Load Cell + HX711 amp.

Update: below is the most recent troubleshooting. I simplified the code as much as possible and getting same weird results. Looks like map() function is able to return 4772 values only.

That's what map looks like. Run a few of your numbers through on paper and see if any of the intermediate results overflow a long.

Yes, I did that multiple times. Also it worked before. Unless I changed something that I can't see. But even if it was a wrong data type somewhere, still returning only 4772 values regardless of the new range... I don't get it...

maxturcan:
Yes, I did that multiple times. Also it worked before. Unless I changed something that I can't see. But even if it was a wrong data type somewhere, still returning only 4772 values regardless of the new range... I don't get it...

What is the value of loadCellValue when it wraps around. Run it once and print both the constrained value and the mapped value at the same time so we can see how they relate.

maxturcan:
Yes, I did that multiple times. Also it worked before. Unless I changed something that I can't see. But even if it was a wrong data type somewhere, still returning only 4772 values regardless of the new range... I don't get it...

OK, I can do math. Let's see.

Let's let loadCellValue be 9200000.

Now map looks like:

(9200000 - 8600000) * 4095 / (9500000 - 8600000)

(600000) * 4095 / 900000

2457000000 / 900000

And right there it is. 2457000000 overflows a long. That's going to end up as a negative number. And when you finish the math with that negative number, you get the negative result.

You're not up against some data type with 4772 values. You're doing more math there, so you're reducing that range.

You're going to have to rewrite your own version of map that can deal with this.

And right there it is. 2457000000 overflows a long. That's going to end up as a negative number. And when you finish the math with that negative number, you get the negative result.

You're not up against some data type with 4772 values. You're doing more math there, so you're reducing that range.

You're going to have to rewrite your own version of map that can deal with this.

Hmm.... I did that a few times but I was looking at the results only, not possible overflows at each calculation step...

Thank you sir for pointing me to the right direction!

Since you map to [-1000..3095], you couldSerial.println(map(Hx711.read()/100, 86000, 95000, -1000, 3095));instead ofSerial.println(map(Hx711.read(), 8600000, 9500000, -1000, 3095));
Jacques

FWIW I noticed that using constrain() after the map() increases the serial output speed by 2x. I don't know if Windows is getting the readings 2x faster, but still, moved the constrain AFTER map().

From 8600 to 9500 you have 901 possible values.
From -1000 to 3095 you have 4096 possible values.
That means that you are throwing away most of the possibilities for output values, and for no good reason.

You don't need map(), just common sense and arithmetic.

From 8600000 to 9500000 you have a spread of 900000.
From -1000 to 3095 you have a spread of 4095.
So you want to multiply by the fraction 4095/900000. In lowest terms, this fraction equals 91/20000.
So, just subtract 8600000, then multiply by 91, then divide by 20000, and finally subtract 1000.
Note that, in the range you seem to care about, the multiplication will not overflow a long.

long inputValue = Hx711.read();
int outputValue = (((inputValue - 8600000L) * 91L) / 20000) - 1000;
Serial.println(outputValue);