Code:
// Now current is in the range [0,213] (if it's in 0 to 500amp for the LEM 300)
// Now current is in the range [0,366] (if it's in 0 to 1000amp for the Melexis HB with 3/8" x 3/4" bus bar. 0.125" above bus bar.)
current_fb = (loc_current_fb * 11) >> 3; // (11/8 * 366 = 503)
// current_fb = (loc_current_fb * 27) >> 4; //(27/8 is almost 506/298. Use this for the 700amp version)
// current_fb = (loc_current_fb * ??) >> ??; // ?? / ?? is almost 1000 / MELEXIS RANGE
// now current is in [0, 510] or so, close to same as current reference range
I'm glad it's working! That one line up there that's not commented out is where the change was. The feedback from the current sensor is [512, 512+366], which gets translated to the interval [0, 366], which gets scaled to around [0,510]. Then, you can compare the throttle feedback, which is also in the range [0,510] to the current sensor feedback. That's because you are always trying to make the current sensor feedback match with the throttle position. To do the scaling from [0,366] to [0,510], I multiply by 11/8. It's not perfect, but dividing by 8 can be done with bit shifting. If I would have just multiplied by 510/366, I would have had to use actual division, and also LONG variables, which would have eaten up like 30 clock cycles or something like that. So, all the confusion comes from trying to make the code fast. It's many times faster to multiply by 11 (using 'short' multiplication), and then bit shift by 3 (which divides by 8).
I'm not sure what happened with the other 2 now. I know one of them had a bunch of funny issues, which I kept fixing, but could have been related to operator error and how it was hooked up. haha. It feels so long ago, I can't remember anymore.