I'm working on a patch that will have a single global MAP sensor scaling for everything that uses MAP or boost for control. Its half done. Will turn my attention back to it after I do live map compatibility for 8859.

That much is incorrect we can't actually measure PSI we can only monitor voltages and apply a scaling that looks like PSI. So essentially you do need to adjust scaling for different sensors.

Not that this method bothers me I just want to make this as clean for the end user as possible.

So would this be like input the bar of the sensor, min volts, and max volts?

I kind of like that idea could be pretty useful and trivial for getting to a psi kpa output

You actually can create "MAP" and not just a voltage to use in axis pretty easily. You simply make a variable and convert from MAP voltage to MAP and then you have "MAP". That MAP voltage to MAP table is where you would scale for different MAP sensors.

I already have a code scheme written to do just this method. My car is apart though so I can't test it and I'd rather not put it out there until I test it on my own car. Based on JCSBanks thread and a simple excel spreadsheet to check my numbers, I'm pretty sure it will work just fine though.

In the end, it's all the same in function, but I'm just trying to suggest a away that would reduce rescaling things and make it easy to use all kinds of different setups. It takes a little more code, but the code fits in the branch where JCSBanks hooked into with room to spare. Actually, I shouldn't say that as I think I may have ran out of the "off" locations to call up the variables as I used the same structure as the OEM coding and had to call up and make several variables and a couple more math functions.

We could make it just like an excel spread sheet and use a couple settings

ADC 10 bit for volts
Bar rating for sensor
min volts
max volts

kPa = (Sensor Bar Rating) * ((sensor_volts - min_volts)/(max_volts-min_volts)) * 100;

We already have the 10 bit scaling for volts so thats no issue.

since the max number for the ADC is already 1023 probably will need to use that wierd floating point thing that this cpu does for this kind of thing.

well i've being using it a little more today but have the following problems, car cuts out just after cranking (about 2 seconds) and i have to keep taping the accelerator for about 3mins until started to warm up, i'm getting jitter now where i didn*mt before and also the fuel trims don't seem to be working

any ideas ?

Not really sure the patch shouldn't affect any of those areas the car simply wouldn't run if it did.

Did you have to do anything special to your previous rom to stop the jitter and starup issues?

Roadspike, I was debating between doing that and just a look up table. The benefit of the lookup table is you just call up the the basic 2D lookup table sub routine, code wise it makes it pretty easy. I'm sure doing a simple "gain" and "Offset" system would work well too and just calculating on the fly. Probably reduce the total amount of code the ECU has to step through too, but that's pretty insignifigant? Also would reduce the amount of ROM memory used by the code.



Maybe get a general concensus on it though. Which one would more people be comfortable with, a two value MAP sensor calibration or tabulated values?

no nothing, and i copied everything over too :( will have a mess I guess and re-check everything

cant wait to try this out when i put my new block in.

*subscribed*

Pull the negative battery cable to clear the trims and any garbage in RAM and give it another shot.

Is O2 feedback working? My tims worked, but without reseting the ECU they quickly maxed out and it struggled to idle.

I did notice additional jitter but I did't port over any of the fixes. The rest I just attributed to the VE not being properly tuned yet.

does that mean the jitter is happening because the car is running lean?

you should be able to tune out any lean spots with the table

Think I've settled on a pretty easy to implement method :)

ADC gives us a 10 bit number or 1023 in integer format. thats the equivalent to 0x3FF.

We take this number minus the minimum voltage and use the D7A linear interpolation routine to adjust the voltage from 5volts to something that is less than 5 volts.

Now sticking with the whole 1 byte thing we can multiply this 0x3ff value by a max of 0x40. I'm suggesting a max value of 16 simply becuase it works out into a nice 0.25 bar per value.

The end multiplication would give us a max value of 0xFFC0 or 65472 with a max kPa at 0xFFC0 at 16 bar or 1600 kPa of boost.

Thoughts? We could also set the max to 8 bar which will give even more sensor limit resolution down to 0.125 bar

Notes:
Need a little more research on the d7a routine.

Edit:

Figured out a little easier logic

Scaled Volts Routine;
adj_volts = (ADC_volts - min_volts);
max_diff = (1023 - max_volts);
adj_adder = (adj_volts * max_diff) / max_volts;
scaled_up_volts = adj_volts + adj_adder;

I would say the 8-Bar max is all that would ever be needed, plus the added resolution couldn't hurt. If anyone is running over 80psi I doubt they're still on stock ECU :D

I would say far less then 8 bar is even needed. Couldn't you simply use the following?

MAP = (X - Adder)*Gain where X is the raw ADC bit count, Adder = voltage offset in raw bit count and Gain is simply the slope of the line?

One of the add functions can deal with signed variables so you could effectively subtract with it. Follow it up with a mulu.w call and you have your MAP output.

Or

Just use the code I posted in that other thread and have the conversion be a table. I actually just used the current SD MAP VE table and changed the VE scaling to suit my needs and wrote it to a new variable. Pretty simple really.