pcmhacking.net

Howdy, first time posting, been on here a bunch off and on. I'm new to programming and tuning, and am trying to learn. I just ordered a Jim stim so I can build a test bench, and an oscilloscope so I can see what's on with some of the outputs.

I'm working with the GM OBD2 V6 PCM used from ~1996- ~2003, this particular PCM was used with the GM 60 degree V6, the 3800, and the 3.5 DOHC "shortstar" V6, with transverse and longitudinal automatics, and longitudinal 5 speeds. The PCM was also used in forced induction applications VIA the L67 3800. here's a link to the info I have compiled on the PCM(along with a couple of other pinouts):

http://www.gearhead-efi.com/Fuel-Inject ... CM-pinouts

I'm currently building a GM high Value V6, which have been setup to run this PCM. the build is capable of 7000+RPM, and boost, unfortunately, the PCM's fuel and spark tables only go to 6400 RPM, so I would like to expand the tables to go up a little higher, maybe 8000 RPM. I've been playing around with IDA, tunerpro, and the Tiny tuner "thingy". because the PCM is already supported to a degree, it's easy enough for me to find the tables, I just go to the TTthingy, select the table I want, and it shows me the address of the table. when I look it up in IDA though, I don't see any rhyme or reason to it, I don't really understand what I'm looking at. so I punch it in in tunerpro's 3d hex viewer, and it's there nice and clear.

I guess my question really comes down to, how do I interpret the hex to see the table, I see sets of numbers, but they don't match up to rows or columns that I can see.

I figured it would be pretty easy to just go in and change the resolution a bit to get a little more RPM. I guess I quickly proved myself wrong... LOL.

I appreciate any help guys!

I havnt hacked pcms to this level, but I do know something about the code and can give you some general pointers. The table needs to be contiguous, so you need enough extra space after the table to fit the data you are going to add. If that space isnt there then you need to move the table, and update all references to its location in the code to point to the new spot.

There is an x size and y size of the table, they are generally just before it but im not sure. This is how you'd extend it.

The values in the table are scaled. If you have an xdf for the bin you can check the equation to see how the data in the tune is converted to the table you see on the screen.

In most factory GM tunes of that era that im aware of when the rpm extends past the top of the table it uses an scalar named something like 'extension slope' to adjust the top row by a certain amount per degrees vs rpm. If your tune has that you might you can probably adjust the slope to get acceptable results without hacking the code.

We also got the L67 in aussie based cars, so one of the1s extended bins might not be too hard to swap in (with aussie ecu and a re-pin), though I dont know either car well enough to give a proper appraisal of that. have a look at the VT/VX enhanced bins here: http://pcmhacking.net/forums/viewtopic.php?f=27&t=2518

I don't think the1's bins would help me ATM, might give me something to get ideas from though. I'm kinda wanting to stick with US stuff for the time being, so that if something breaks, I'm not SOL until it can be shipped from down under. also, it looks as though the aussie PCM's are all built to be inside the car, my PCM is mounted outside, in a case identical to the '0411 LS1 PCM case.

At the moment, all I was going to do was change the resolution of the table, I wasn't planning on adding to the table yet. Both tables would use the same number of cells, but because one steps up at a different rate, it would allow for a higher value. I understand this is a trade off, and I lose low speed resolution, but I wouldn't necessarily change it that drasically, and the table (stock from GM) has two different resolutions, at low RPM, 200 RPM per cell, high RPM, 400 RPM. if I change that to 250 and 500, I would accomplish close to what I need. 300 and 600 would go well beyond...

200:400
400-600-800-1000-1200-1400-1600-1800-2000-2200-2400-2800-3200-3600-4000-4400-4800-5200-5600-6000-6400
250:500
400-650-900-1150-1400-1650-1900-2150-2400-2650-2900-3400-3900-4400-4900-5400-5900-6400-6900-7400-7900.
300:600
400-700-1000-1300-1600-1900-2100-2400-2700-3000-3300-3900-4500-5100-5700-6300-6900-7500-8100-8700-9300
400:800
400-800-1200-1600-2000-2400-2800-3200-3600-4000-4400-5200-6000-6800-7600-8400-9200-10000-10800-11600-12400
this wouldn't work?

Yeah I reckon that would work. Look for the values of the break points just before the tables in the bin. Im not saying thats where they'll be but its worth a shot. Make sure you test any changes on the bench with the jim stim, this is just an educated guess.

antus wrote:Yeah I reckon that would work. Look for the values of the break points just before the tables in the bin. Im not saying thats where they'll be but its worth a shot. Make sure you test any changes on the bench with the jim stim, this is just an educated guess.

testing is definitely in order, I'm glad to hear there's a chance that it might work, because that seems much simpler then moving the table where there's more space and then changing all of the addresses! esp because I would be doing multiple tables too.

I appreciate the help!

the next step is going to be trying to adapt coil per cylinder ignition to this PCM, the LX5 "shortstar" V6 used coil per cylinder, so I'm going to try and see if I can make it work without going in and doing a trigger wheel swap. the shortstar used a dual pattern 24x wheel whereas the 3100/3400 used a 7x+24x setup. it'll be interesting to see it can be made to happen.

you can setup dual trigger wheel on jimstim with dual outputs.

The Reason why GM limits the RPM to this in most software is reliability isn't 100%.

The RPM byte that outputs the RPM may be limited, ours luckly has a 1/1 RPM variable so when i code ours i can use this, but still depends on the limit of the PCM CPU to what you can run with it. This is something to test on the bench with FF tables.

If it's an automatic, you could remove the limiter by FF tables, then set your shift points to control at what RPM it shifts at.

If your building a L67 or something unless you have alot of money to work it i doubt it's worth reving more than stock limiter.

The1 wrote:you can setup dual trigger wheel on jimstim with dual outputs.

The Reason why GM limits the RPM to this in most software is reliability isn't 100%.

do you mean the software isn't reliable, or the engine isn't reliable?

The1 wrote: The RPM byte that outputs the RPM may be limited, ours luckly has a 1/1 RPM variable so when i code ours i can use this, but still depends on the limit of the PCM CPU to what you can run with it. This is something to test on the bench with FF tables.

If it's an automatic, you could remove the limiter by FF tables, then set your shift points to control at what RPM it shifts at.

If your building a L67 or something unless you have alot of money to work it i doubt it's worth reving more than stock limiter.

My car is a Turbo LX9 3500 V6 with ported heads, ported upper intake, custom upper intake, big meaty cam, ect. there's more to be had up top for my build.

sorry if this is a dumb question, but what are the FF tables?

FF Hex or 255 Dec

ejs262 wrote:it's easy enough for me to find the tables, I just go to the TTthingy, select the table I want, and it shows me the address of the table. when I look it up in IDA though, I don't see any rhyme or reason to it

Have you had a look at winols? It's very handy for this sort of thing.

I just downloaded the demo today, haven't haven't had a chance to really look at it yet though. most of my time during the week gets soaked up by school, so progress really only happens on the weekend.