The ultimate LT1 $$EE patch thread

[kur4o]

After digging through the code for the last year and define most of the unknown tables, recently I was busy with hardware breakdown.
I mapped almost all pins on the PCM and for most of them found the software addresses.
There is alot of unused input pins, AD pins, 1 freq input pins and some output control pins, pwm output pins. It wont be hard to add three more drivers for output control(but still need to find software input for them). There is still some work to do for couple of pins.

The mystery 3rd processor with mask id D84G, works with conjuction with the main eside processors and is reponsible for 4 freq inputs and knock count inputs. Also makes internal calc for speedometer and possibly drives the spark and injectors relays. It might have its own Rom or EEProm which needs to be read someway. I will be glad if someone can help read the 3rd processor internal memory.

The patching possibilities are endless and requests are welcome, testers also needed.

Alot of info to follow

[steveo]

i'll help however i can.

i plan to get eehack program a bit more useful to you in the next release if i have time, with some places for arbitrary mode4 comm requests from both t-side and e-side.

the code patches i'm most interested in right now are simple, such as open loop idle, i think maybe open loop if tps=0% or open loop if blmcell=16 would be ideal? also dropping charcoal canister purge without disabling blm cells >15 along with it would be useful.

my personal goal right now that i got that decel crap worked out is to finish understanding the flash routine.

[jthompson122183]

anyway to patch for using the 96-97 4l60e?

[steveo]

anyway to patch for using the 96-97 4l60e?

that would be an excellent goal - i've been asked this before too, and since i don't care about automatic transmissions much, i haven't come up with an answer. there are solenoid behavior differences of some kind, right?

[kur4o]

Open loop Zero tps patch can be easily done. There is 32 bytes space(it`s used for rear 02 sensor) for that to achieve. Alot of variables can be put in place like timer, map range, or mph range. I will have to think about it. BLM cell cant be implemented because it needs to be in closed loop for cells to be updated. CCP is also doable but the way i see it there is no need for patch, just disable the ccp related errors, disconnenect valve and leave it as is(patch can be made also to save some processor load).

Pinout for 95 and 96-97 transmission is the same. I suppose it can work with 95 code, but if there is difference in solenoid resistance, that might be a problem. I need to find out what`s the exact difference between 95 and 96-97 solenoids.
I have been thinking for 98+ls1 transmission with plate and older 4l60 for tcc control.

What do you think of external switches which can change MAF to speed density or loading second spark table.

[steveo]

What do you think of external switches which can change MAF to speed density or loading second spark table.

definitely a good idea.

[lionelhutz]

I'm running a 96 transmission with a 8051. Best I could find was the downshift solenoid is a higher resistance. It doesn't seem to matter because it works fine and didn't throw any codes.

[kur4o]

Initial version for OL zero tps patch.
Different version for manual and auto.
Forced Open loop with external switch on pin B23. ground needs to be applied on this pin through light diode and resistor, for visual confirmation.
Also MAP and MPH check to enable.

Initial version so use at your own risk.
Feedback needed.

[RobertISaar]

Best I could find was the downshift solenoid is a higher resistance.

less load on the quad/output driver, so I'd say that's not a problem. if inductance of the solenoid changed as well then it may want to be driven at a different frequency, but it sounds like it works as-is.

[steveo]

Initial version for OL zero tps patch.
Different version for manual and auto.
Forced Open loop with external switch on pin B23. ground needs to be applied on this pin through light diode and resistor, for visual confirmation.
Also MAP and MPH check to enable.

Initial version so use at your own risk.
Feedback needed.

awesome, i'll test it (except the auto version, i can't test)

[steveo]

i tested your manual OL IDLE patch today; with the patch the car refused to go closed loop at all

[kur4o]

That`s good to know. Most likely something jumps not as expected. Bad news is, I don`t have access to running vehicle now and debugging will be very hard.
I`ve been thinking to take new approach. Cell 16 is zero tps, zero mph, cell 17 is zero tps, very low map, cell 18 is zero mph, tps>0.
Do you want open loop only in cell 16 and keep closed loop in other cells. I want to try to duplicate conditions for OL with the conditions of entering this cells.

[kur4o]

I`ve switched the settings for forced open loop commanded by PIN b23. (in open state I thought it was 0, but actually it`s 1)
Now is fixed I hope the other part works as expected.

[steveo]

That`s good to know. Most likely something jumps not as expected. Bad news is, I don`t have access to running vehicle now and debugging will be very hard.

i know that story... im afraid to experiment too much with my car since its my only car! but i'll try again soon


Do you want open loop only in cell 16 and keep closed loop in other cells.

that would be perfect...

[kur4o]

Added a new patch. It duplicates conditions for entering cell 16. If all conditions met it goes to open loop.
This patch depends on CCP functionality in the part of selecting blm cells.
If, BLM min ccpDC% enable byte_2626 is changed it might not work as expected.

[steveo]

didn't realize but mode3 can return multiple memory bytes in a single request just by stringing them together:



F4 5C 03 01 EE 01 ED 01 00 CF > F4 59 03 00 00 87 29


since aldl request length is limited to the single length byte (0xFF - 0x52 = dec173) minus the checksum/mode/length/device bytes.

so 169 message bytes, and since they're 16 bit addresses, that's 84 bytes of memory in a single mode4 request.

it's almost as good as a mode1 request, but the request itself is way longer which slows stuff down to about 3-4ms per byte requested.

i have tested this by grabbing the entire BLM table memory from both banks in a single request, and it works.

one gigantic request but still a magnitude faster than multiple mode3 requests...



f4a203001c001d001e001f0020002100220023002400250026 002700280029002a002b002c002d002e002f00300031003200 33003400350036003700380039003a003b003c003d003e003f 0040004180
>
f47c0380808080808080808080808080808080808080808080 808080808080808080808080808080808d

[steveo]

... mode 2 dumps 64 bytes of data doesn't it?

[kur4o]

Actually I was experimenting with mode 3 to do the same thing, but it didn`t work. I am glad you figured it out. It will be very useful if you request multiple bytes in different locations.
For consecutive memory dump mode 2 is the best.
You can try this command f4 58 02 00 1c for blm cells, it will dump all that info in the first 38 bytes.
What about mode 2 do the same thing as mode 3? I will test it.

[steveo]

doesn't seem to do anything for me..

anyway just mentioning in passing that there's a bug in that custom command feature i wrote for you. the 'b' field locks up after you use it (stupid mistake on my part). i'll fix it in the next release.

EDIT: here's a special beta release for you that works better (you can try my vin/cal id stuff out too)

http://fbodytech.com/files/eehack-3.4-beta.zip

[jthompson122183]

Kur4o Have you been able to patch for nitrous retard using the traction control spark retard?

[kur4o]

I spent lots of time to figure out how that traction work. It has two modes for spark retard request. On y-body retard request is analog and is on pin C12, on f-body it is digital and uses some pwm signal to activate. Also there is some ALDL data send from traction module to PCM.
For successful implementation pin C12 must be used for activation. From there patch will be really easy to implement and will disable some timers for using the tables.
If there is anyone that wants to experiment I will give a try.

[fbody_Brian]

Just wondering if any of the unused input pins could be used for wideband input/logging? It would be nice not to have to hack my AC sensor wire and disable my AC during logging.

[kur4o]

Alots of external inputs can be used you can add 2 wideband channels if you want.
It can be done with minor modification.
I am not quite sure which channels are suitable for wideband, they have different pull up resistors.
You can make some experiments if you like here is adx with pin description which also logs data. You can try different pins and see where you get good solid data.( You want to try pins that says 5_ in the description)
Then i will make some small patch for easy implementation.

I`ve also thinking for doing that but will take quite some time. If you can help a liitle we can speed things up.
I will be very glad if you can make a log with the adx during cranking.

[kur4o]

I found the easiest way for wideband logging.
No patch needed.

Put wideband 0-5v output on pin D27 (blue connector 27)

Output will be at memory byte_103 which is streamed at mode 01 msg 00 byte 55 from ALDL message.

If anyone wants to try I will make updated adx with this item set up.

[fbody_Brian]

I found the easiest way for wideband logging.
No patch needed.

Put wideband 0-5v output on pin D27 (blue connector 27)

Output will be at memory byte_103 which is streamed at mode 01 msg 00 byte 55 from ALDL message.

If anyone wants to try I will make updated adx with this item set up.

awesome!

I'll have to get some stuff done, but I'm definitely willing to test.

[jthompson122183]

I found the easiest way for wideband logging.
No patch needed.

Put wideband 0-5v output on pin D27 (blue connector 27)

Output will be at memory byte_103 which is streamed at mode 01 msg 00 byte 55 from ALDL message.

If anyone wants to try I will make updated adx with this item set up.
Im setup and trying to figure out how modify the adx but having no luck,what needs changed in the adx? also is there a conversion for the instant fuel economy stuff to US standard units . Thanks for all this awesome stuff that your doing for this pcm, its good to see people want more out of it other than whats already known or available.

[fbody_Brian]

I used the adx, and pin 27 is working. I'm not really familiar with logging with tunerpro, so I don't know how to set it up to show an afr, and it's funny, but the ONLY thing that was actually updating on the log screen was the pin27 gauge that I added..

need to figure out how to use it.

[kur4o]

This is my latest ADX. Fixed some stuff that prevent it from working right.
Now it should be ok.
Also wide BAND AFR stream on pin D27 (blue connector 27) If anyone wants to try.
Added MPG fuel economy also.

[fbody_Brian]

I guess I was editing my post while you replied.
I have pin 27 hooked up to the wideband and I'm getting data from it!

[kur4o]

Well that`s good.
You can use $EE-16188051-V3[1].8_MOD[V01].adx (http://www.gearhead-efi.com/Fuel-Injection/attachment.php?attachmentid=9810&d=1448147202) I uploaded. It is fixed version with pin 27 added to datastream.
I want to make sure it works right. If you have multimeter you can check voltage on the wideband 0-5v line and compare it with the datastream wideband voltage just to make sure there isn`t some offset in the voltages.

Yes I definitely missed that post.

[fbody_Brian]

I tried the new one and I'm getting data now. I need to put in the formula for my wideband, but it's looking good

[jthompson122183]

This is my latest ADX. Fixed some stuff that prevent it from working right.
Now it should be ok.
Also wide BAND AFR stream on pin D27 (blue connector 27) If anyone wants to try.
Added MPG fuel economy also.

9820
Pin 27 is working for me with my innovate lc-2.:rockon: only thing is that its like the a/c port in that the voltage jumps back and fourth between .002 and .004 without any activity, when the lc-2 is starting up it displays 7.4, with pin 27 it shows 8.4 in tunerpro/aldldroid. anyways here is my datalog(from aldldroid) from a cold startup. ive also included the bin and my adx that i use. p.s i zeroed out 12046

[steveo]

alright kur4o, im getting bored with developing eehack. it analyzes, programs, alters, graphs... what's next?

lets talk some serious patches.

the thought occured to me, my eehack program (and this ecm in general) can do quite a bit of fun stuff if we patch appropriately... but i just don't want to *require* users to have any patches to use the software.

so i've decided i'm going to make an official eehack patch for $EE but eehack will still behave with stock bins.

here's the plan, eehack will do a simple mode 3 request to a completely unused byte we'll choose which will 0x00 (unpatched) or contain a version number of the current patch. if the patch matches the one required for the current version of eehack, the extra features will be enabled.

this patch can only be applied at flash time with a check box... 'enhance bin' or whatever. this allows us to do whatever we want to a source bin without the user's bin on disk actually being altered, so the patch can also include relocating tables or code without breaking any XDF/definition/tunercat compatibility.

ideas:

- patch for mode3/mode4 on e-side (you already have them done, so... awesome! that'll be first). that way we can query entire tables from the e-side. this is a BIG deal, since during data analysis, eehack can troll around and grab copies of current tables silently from the e-side (where a lot of the good tables are) in between logging and use them for interesting things.
- a new mode1 request without extraneous crap that isn't displayed in eehack anyway to speed up datalogging, that packet is at least 12 bytes large, and real tuners don't care about error codes anyway. can grab those error bytes every 100 iterations or so in between other data if required. i think we can get the data acq rate for useful parameters way up.
- ANYTHING extra for real-time tuning we can come up with... which i'll start looking at now. you did note a good chunk of memory in the e-side, lets get a solid map of that and start playing ball. we can figure out a good way to alter a single memory byte for switching between eeprom and memory tables? maybe one of the rarely-used mode4 bytes? maybe something else?
- patch will set all unused bytes to 0xFF to assist with my next release of the flash tool, so our patched bin will write way faster. the more areas we can fill with 1s without the ecm shitting a brick the better for speed-flashing. i think IDA can help out mapping unused eeprom regions, but the more we patch the more these regions might change..so each patch may have a different unused bytes map.

only stuff with real-world tuning applications that people will use, of course..

[steveo]

first digging into the mode1 stuff, hadn't looked at it much before.

so message 3 seems a great candidate for my 'short' message. i can't really find a use for it elsewhere. message 5 is another good one that no other loggers seem to use. i dont think altering them hurts any other tools.

so what i want to do is make mode 3 my short message, and shorten its length appropriately. then i think i'll make message 5 my "extra stuff" message, maybe to include as many other useful bytes as possible from your t-side map?

the tables themselves seem simple enough; here are the starting bytes for each table it looks like,
msg0=F3A3 ; msg1=F425 ; msg2=F48B ; msg3=F4FF ; msg4=F58F ; msg5=F5F3 ; msg6=F6BF

the byte at offset 0x05 appears to define the length of each reply, at (raw data length+1). can be assumed since msg0 has 60 bytes and it's length byte is 0x3D (dec61)?

it appears after a 10 byte header, each is a table of 16 bit memory addresses. code for mode1 replies looks similar to what i read with mode2/3 requests, obviously just uses a table instead of incoming aldl data to determine memory addresses.

so a patch to message 3 should be fairly trivial,

@ 0xF4FF: 00 00 F4 F4 80 23 19 92 19 92 00 E6 00 E7 FF FF 01 C3 02 42 01 34 01 A7 02 59 01 02 01 08 01 76 01 17 18 28 01 24 01 26 01 65 01 63 01 64 01 62 01 61 FF FF 02 B3 FF FF 02 BD FF FF 02 C5 18 25 02 41 02 3A FF FF 02 38 01 03 01 9D 02 3F

this maps the following datastream elements as in msg1byte-msg0byte, including no error codes, evap codes, egr, ccp, just the important stuff for tuning, but also throwing in command afr at the end:

1-13,2-14,3-18,4-19,5-20,6-21,7-23,8-25,9-27,10-28,11-30,12-31,13-32,14-33,15-34,16-37,17-38,18-39,19-40,20-41,21-42,22-43,23-44,24-45,25-46,26-47,27-49,28-51,29-52,30-53,31-54,32-55,33-58,34-COMM_AFR

im going to convert all of this to a fake msg0 data set internally in eehack with unused bytes set to 0x00 to ensure all existing code works alright (and keep the log format consistent), but an adx could easily be set up to use it too...

[kur4o]

T side mode 1 msg 0 has 2 unused bytes that can be reconfigured.

Msg 5 and Msg 6 are the perfect candidate for patching. We can make msg 5 shorter with the only the data that`s displayed in the eehack and get very high refresh rates. Msg 6 is already short.

Msg 3 has all the inputs and outputs + all ad channels even the unused ones and e and t side so I think is very useful for now diagnostics and for other purposes like additional ad channel.

Msg 5 has some bytes that still have no clue what are doing.

Msg 6 is for auto transmission adapt learn values and are rarely used if at all.

Msg 2 is also not used in most of the programs I have tried it contains only dtc and some status bytes.

Lenght of the output message is defined in the fifth byte (data + checksum).
You can also reconfigure mode 2 lenght message up to 112 bytes in 16 bytes increment. Just change $41 to $51;$61 or $71 to make it longer.

Mode 0b can be hacked for something usefull. The main obstacle, there is only 28 free bytes on T-side.

Also mode 4 can be added on Eside for table switching or something else.

[steveo]

i was planning on msg 3; but i can use msg 5 and msg 6 if you think its a better idea. msg 3 might become useful as you map out the hardware end a bit better so i guess i'll leave it alone.

i guess i'll hit msg 5 instead.

do you have any areas of guaranteed unused bytes in e-side or t-side mapped out? i've started selectively killing transmission tables; so far manual transmission guys can save 1000 bytes of write time and never know the difference, but im sure there's more.

[kur4o]

Anyone tried my open loop idle cell 16 patch yet.

I am ready to test it on a car and was wondering if there is any input on it.

I found alots of old threads with missing attachments. Are they permanently gone or there is some problem with the forum.

[kur4o]

I tried the patch and it works fine. It needs some improvement though. I need to stop blm updating, even in open loop they correct fuel if not locked at 128.
I also want to add extenal switch to command open loop operation. I will post it when ready.

If anyone have a suggestions on need something specific I will be glad to help.

[dzidaV8]

I can test this, I have some LT1 cars to play with in the neighborhood...

[kur4o]

The idle open loop patch cell 16 is working very good. It doesn`t need an improvement for now. Maybe next release will be idle open loop cell 16 running SD mode, for maf running cars. I noticed that idle in SD mode is so much better.

Meanwhile I made another patch,
It forces SD mode while keeps display of Maf readings and adds display of VE table calculated airflow. I want to add a MAF frequency display too and it will be released.

As you can see on the screenshot VE tables are maxed out by 10%. What will be the best tuning strategy in that case. Increase of cylinder volume?

Steveo if you want to add the new patch in eehack I can give you details.
I test the eside ALDL patch. It works only at engine off. When engine is runnig processor is too busy to stream data.
In that case we can load eside custom tables when engine is off.

Dzidav8, thanks for the support. When I come up with something new you will be the test mule.

[kur4o]

So here is the latest patch.
There are two version. All tested and working.

Make sure you follow instruction exactly as written.

Use attached definition file with eehack. First rename it to .csv format.

Important info for MAF patch only, since it reconfigures some aldl bytes wideband on pin D27 won`t work(It will work fine with sd patch).
There is workaround though but it is complicated.

[jthompson122183]

I found alots of old threads with missing attachments. Are they permanently gone or there is some problem with the forum.

Permanently gone


here is the answer.

http://www.gearhead-efi.com/Fuel-Injection/showthread.php?6214-We-re-back!&p=63753&viewfull=1#post63753


Are you back to working on $EE again?
Im still filling in eextra with lots of stuff, what's weird is the $0D mask cals is very similar to $EE.
http://www.gearhead-efi.com/Fuel-Injection/showthread.php?303-16197427-PCM-Information-0D
Hope to see you around more. here soon i will have another eextra release.

[kur4o]

I now have a running engine around and can play with lots of stuff.

I am working on new patch now.
Mixed mode maf and speed density with some variables to choose from which mode is selected and lamp control to know what mode is runnig.
It is half done with streaming simultaneously data from maf and SD calculations{my earlier patch}

The ee_definition I posted have some errors and maf Freq will display incorrect values. Updated version coming soon

[kur4o]

Here is the first official beta release of my latest patch.
Patch allows you to monitor all airflow calculation at the same time. That way you can monitor SD calculated airflow, compare it to the MAF airflow and see if your ve table is off or spot on.
It also allows you to change between SD and MAF mode in real time through modified eehack program.

Important
For patch to work your bin shoud be set in MAF mode.
You can only change from MAF to SD.
If the bin is set to SD mode don`t use it.

How to install the patch.
Very imortant to follow steps exactly as written.
First flash your PCM with your favorite bin with eehack 4.7 program. You must set the eehack with following options checked :insert patches and skip unused regions.

Than read the PCM and save the file.

Now patch the saved file with MAF Airflow patch v2 and Enable m4 control for SD mode patch.
Important.
Enable m4 control for SD mode patch must be used only if MAF Airflow patch v2 is applied.
It only allows you to control SD mode through the modified eehack program.

VERY IMPORTANT
After you applied the patch of your choice, flash the bin with eehack program with the following options unchecked: insert patches.

Move the provided eehack49.exe to the folder where eehack is installed and run from there. Set eehack to use the supplied definition file.
Enjoy.

LIMITATIONS
There are some broken datastream and some parameters are visible on the hacker level.
The high res rpm will not work.
You can monitor rpm at the low res RPM datastream

[steveo]

sounds awesome, wish i still had an lt1 so i could try it. nice work

[kur4o]

This is a lighter version of sd control patch.

It lets you switch from MAF to SD through modified eehack program and enables display of current MAf cell number, SD airflow and calculated VE%.
All of the datastream works including pin d27 wideband.

Datastream that wont work is some trans error byte and egr DC%.

If anyone needs to switch from SD to MAF , let me know. It is one byte simple fix.

[johnny_b]

If I'm understanding you correctly we can switch between maf and speed density without flashing?

[kur4o]

That is right.
It works like regular mode 4 control.
There are some limitations though. It is not a permanent setting. It can be set with the engine running. It will be in effect until PCM is reset by cycling ignition.
If you apply the patch you will be running in MAF mode with the option to switch to SD mode anytime you want.
Another patch will be made if anyone needs to run in SD mode and switch to MAF mode.

[steveo]

after this is better tested i'd love to pull it back into the main eehack branch and include the patch in eehack itself. please report results

[kur4o]

I will be really happy if you do that.

Maybe make a checkbox, so users select which patches to add as an addition to the main patch.
I will post a log to see how it works. You can tell which mode is by looking at ve value. If it is updating it is in SD mode. When it freezes and MAF starts updating your in MAF mode.
I also tested thoroughly open loop idle patch. It works flawless. If you want you can add it too.

SD control needs to be 2 different patches.
1st will be for running MAF mode with the ability to switch to SD
the other will be for running SD with the ability to switch to MAF.

Next great thing that I am working on is a realtime delta change +-5% of calculated VE%.
Patch is almost done but I am missing the control interface at eehack level.
If you can add a slider bar similar to spark control bar we can get it work.

I will rework the eside aldl patch too. Now it has some data colision at SPI comm with main eehack patch and applying the patch is real pain.
I moved some spi address pointer, which is really not needed, so want that fixed.

[kur4o]

Here are some logs.

How hard will be to add mode 4 message in the logged datastream and play the control window with the main dash.

[steveo]

I will be really happy if you do that.

Maybe make a checkbox, so users select which patches to add as an addition to the main patch.
I will post a log to see how it works. You can tell which mode is by looking at ve value. If it is updating it is in SD mode. When it freezes and MAF starts updating your in MAF mode.
I also tested thoroughly open loop idle patch. It works flawless. If you want you can add it too.

SD control needs to be 2 different patches.
1st will be for running MAF mode with the ability to switch to SD
the other will be for running SD with the ability to switch to MAF.

Next great thing that I am working on is a realtime delta change +-5% of calculated VE%.
Patch is almost done but I am missing the control interface at eehack level.
If you can add a slider bar similar to spark control bar we can get it work.

I will rework the eside aldl patch too. Now it has some data colision at SPI comm with main eehack patch and applying the patch is real pain.
I moved some spi address pointer, which is really not needed, so want that fixed.

i don't see any reason to "opt-out" of single patches that "qualify as good enough for eehack", as they shouldn't do anything unless activated by eehack, and shouldn't affect a running engine before eehack is connected, or affect other datalogging tools.


i designed eehack around a 'patch level' with version support and i want to stick with it

trust me it's better that way, so eehack users don't have to worry about selecting certain patches or reconfiguring eehack to match them. it should happen automatically and they get all the benefits

[kur4o]

I see your point and we will keep it that way.
EEhack patches must be kept as simple as possible and only connected with the main features of eehack.
If anyone wants more stuff, than it should apply other patches manually.

I figured a real simple solution for the fuel mode control.

Before apply the patch make a simple check in the bin


check eside byte_2028 bit $02

if 0 load

6193 eside
B6 20 28 85 02 ==> B6 00 2F 85 08
Maf primary mode ==> switch to SD


if 1 load

6193 eside

B6 20 28 85 02 27 ==> B6 00 2F 85 08 26

SD primary mode ==> switch to MAF

I would like to keep the ALDL stuff separately.

Can you please on the next version of patch make some simple correction of the eside aldl patch

Keep stock bin data unchanged at 82f7 till 8336 and from 6f78-6f79 I add some pointers and move data that was really not needed

[johnny_b]

I've been searching the forums for the open-loop idle cell 16 patch. I thought it was posted somewhere but i haven't had much luck finding it?

I know I downloaded it form here at some point.

[kur4o]

Lot`s of files get lost on the site so here is the latest xdf.

[johnny_b]

maybe thats where the confusion lies another user also has an xdf called eextra.
anyhow, thanks I will report back on both when i have running vehicle to test.
All these patches seem very promising.
Can you explain how to run the modified version of eehack?

[jthompson122183]

maybe thats where the confusion lies another user also has an xdf called eextra.

the xdf posted is eextra from the original thread here: http://www.gearhead-efi.com/Fuel-Injection/showthread.php?6260-94-95-EE-xdf-(EEXTRA)

Kur40 has added his patches from this thread to eextra, he has his own way of labeling so he can keep track of what he has done.

[kur4o]

Can you explain how to run the modified version of eehack?

Install eehack 4.7. Than move eehack49.exe in 4.7 installation folder. Run eehack49.exe from there.


I need some beta tester.
There is my latest patch. Control VE% in real time +-5% through modified eehack4.91 programm.
Instructions in the xdf.

This beta patch is not good, so don`t use it. I will upload a working version soon.

[kur4o]

Hi Kur4o thanks for that.
So are you saying the End Of injection when its set to "6" STD is 33 Degrees ATDC from 0/720, because there is also TDC at 360 Degrees, the start of the intake stroke! We need to be talking about the same place!?
Based on the article(PDF) above posted by Jthompson it would appear there could also be a table attached to that value that is load/rpm based, that would be VERY useful to find.....
At idle the IPW is 1.4m/s and 18m/s is about 702 degrees at 6500 RPM, so that would be about 54.5 degrees of injection period at idle..
So the best place to end the injection would be about 460 degrees after TDC 0......which is approximately the maximum intake valve open point...see my chart above..
Something to try anyway!
Ok cool. is the EEhack patch available for my 94.
I have LT1 edit file for the 94 and 96..
I have the conversion program that converts 94 files to BINS, it does also convert 96 ones, but I dont know if thats the correct transfer algorithm for a 96.....I can see data in Tunerpro if I open the 96 BIN but its all over the place....as expected.
Shall I post a STD 94 BIN converted from LT1Edit and a 96 one the same?
Cheers
Kevin


X is the raw hex value converted to decimal so in your case 6 will be 180 degrees after top dead center when cylinder fires.
raw value is $60=96
720-(96*5.625)=180

The patch I have works only with 94-95 bins. If you have a running 94-95 car you can do some beta testing.

I need a 96 lt1edit virgin file. Please don`t try to convert it. I want to see what file format they use.

[kevinodb1]

Here are the Bins mentioned in the other thread regarding tuning for Injection Timing.

They are from my 1994 Corvette Y car manual and my 1996 Corvette Y car Manual LT4 GS. Both cars had never been edited, the GS had only 1 owner before.

I converted the original 94 file today to a BIN from LT1Edit using TUNECONV V1.0.0.1 Windows MFC App.

The 96 original file was converted a while ago from LT1Edit using TUNECONV DOSwindow version 1 for exchanging LT1edits to Tunercat format and back.

Cheers
Kevin

[kevinodb1]

So you want the virgin LT1Edit files?

[kur4o]

If you have one.

[kevinodb1]

Here they are:

From two 96 GS's....and the 94 Vette.

RENAMED FROM .LT1 to .BIN to be able to upload them! Just rename them back to .LT1

Cheers.

[kur4o]

Too bad they encrypted the 96 files. You are out of luck, modifying manually the file.
The 94 is unencrypted and the two halves of the file are flipped.
Your only option is to upgrade 96 car with 94-95 PCM or lt1edit provide you with a tool to convert the file to raw bin.

[kevinodb1]

Oh thats a shame!

The only way would to to de-socket the chips and read them back using some other device then?

If I purchased the JET product does that encrypt its files as well?

Cheers

[kevinodb1]

Ive already tried running the 94 PCM in the 96, the knock sensor issue I solved, BUT the ABS/TCS and CCM talk on the same PIN9 and all sorts of errors came up!

It did start though....

[kevinodb1]

Heres the two versions of TUNECONV for reference:

Change them from .BIN to .EXE

[kevinodb1]

Found this on LS1TECH!?

May or may not be useful!?

[kevinodb1]

Another, bigger converted from a JCL.

[kur4o]

Sorry for the late response. I ve been busy hacking some 96 bins.

What I found is that 96-97 pcm have ALDL line which is active and can be used.
It has only some modes available.
Mode 01 msg 00 and msg 04
Mode 03
Mode 07
Mode 08
Mode 09

96-97 Mode 01 msg 00 is one byte longer than 94-95 PCM mode 01 msg00 and can easily be hacked to output the same data as 94 PCM.

I need some idle traffic logs on 94-95 and 96 corvettes to make a patch for retro fitting older PCM to 96 model.


The last bin is good and can be used, It is way too big than necessary since PCM has two memory chips. Eside is 64kb and tside is 128kb. Some trimming is required to make it usable.

Burning chip is not an option for you. The raw data on the chip is scrambled.
JEt might be an option. I found a tunercat file that can be modified manually and opens through a jet programm. I guess it can be burned too.
Regular jcl files are also encrypted.

[jthompson122183]

X is the raw hex value converted to decimal so in your case 6 will be 180 degrees after top dead center when cylinder fires.
raw value is $60=96
720-(96*5.625)=180


so this is what the table looks like now?


12471

[Terminal_Crazy]

so this is what the table looks like now.


12471
180 degrees AFter the cylinder fires? The injectors stop spraying at the bottom of the power stroke ??
Presumably it would be around the end of induction stroke, before compression starts and the airflow slows to a stop.
Another 40-50 crank degrees and we’re in spark territory.

Also does the adx now allow intermediate hex values rather than multiples of 16?

Mitch

[kur4o]

This is my work chart for gm 846 cam.
Red and blue is total open duration at exhaust and intake.
Yellow and green is the duration at 0.05 lift.
I chart the data to find the cam overlap and decide how to tune it.
I couldn`t get a complete cam data for stock b-body cam, and don`t have a reference point. Some experiments will be needed to figure what is the best approach to tune end of injection.

Chart is from stock b body. The red line 4 is injector open time.
As you can see it closes exactly at 270 degrees. As it is at b-body and corvette calibration.
I am sure the pcm counts $10 for 1 low resolution pulse, and the space between pulses is divided by it. And you get 90/16=5.625 degree resolution. I hope it is pretty acurate but will have to be verified.

[jthompson122183]

Hi Kur4o

sorry to bring in a topic unrelated to the current discussion, but i wanted to bring this to your attention before i forgot about it.

if i remember correctly disabling the ccp via raising the temp enable out of range and setting the enable special cells to 0% will cause the pcm not to use the extra cells.

While looking through the $0D hack i came across this


L48EC: FCB $07 ; FLAG WD,
;
; b7 1 = not used
; b6 1 = not used
; b5 1 = not used
; b4 1 = not used
;
; b3 1 = not used
; b2 1 = SEPARATE BLM PK/NEUT CELLS
; b1 1 = SEPARATE BLM A/C IDLE CELLS
; b0 1 = SEPARATE BLM IDLE CELLS

maybe this could be ported to make a patch?

included the 0D hack below

[kur4o]

Here is some cleaned up and revised version of all the stuff that is tested and working.
It adds some interesting mode4 control like real time control of VE, maf/sd modes and end of injection time.
You also get some enhanced aldl parameters.

How to install.
1.You need to flash your PCM with eehack 4.7 with insert patches tickbox marked.
2.Than read your bin.
3.Apply all patches from the folder.
4.Burn the bin with eehack4.7 IMPORTANT the insert patches box must be not ticked.
5.Save the patched bin for future improvements.

To make available extra controls use the supplied eehack_v92.exe, which must be run from the eehack installation folder.
Load the supplied definition file for improved datalog.

Instalation notes.
You need to choose between MAF primary and Speed Density primary patches and apply only one of them.
If you have indeterminate data warning when you apply the patches, first press remove patch box, than apply as usual.

Warnings.
If you are runnig Speed density mode and apply the patch, make sure that the skip unused region tickbox is unmarked when you burn the bin.
If the box is ticked the eehack will wipe the MAF table to FFs and switching to maf will not be possible.

I am working on a future version of eehack that will apply the patches automaticaly, but for now you need to follow installation notes exactly as written.

[E-Ticket]

Here is some cleaned up and revised version of all the stuff that is tested and working.
It adds some interesting mode4 control like real time control of VE, maf/sd modes and end of injection time.
You also get some enhanced aldl parameters.

How to install.
1.You need to flash your PCM with eehack 4.7 with insert patches tickbox marked.
2.Than read your bin.
3.Apply all patches from the folder.
4.Burn the bin with eehack4.7 IMPORTANT the insert patches box must be not ticked.
5.Save the patched bin for future improvements.

To make available extra controls use the supplied eehack_v92.exe, which must be run from the eehack installation folder.
Load the supplied definition file for improved datalog.

Instalation notes.
You need to choose between MAF primary and Speed Density primary patches and apply only one of them.
If you have indeterminate data warning when you apply the patches, first press remove patch box, than apply as usual.

Warnings.
If you are runnig Speed density mode and apply the patch, make sure that the skip unused region tickbox is unmarked when you burn the bin.
If the box is ticked the eehack will wipe the MAF table to FFs and switching to maf will not be possible.

I am working on a future version of eehack that will apply the patches automaticaly, but for now you need to follow installation notes exactly as written.

Thanks for all this great work! I'm working to transition from LT1Edit/etc and would like to use EEHack along with adding wideband sensors to tune my VE's real-time after a full rebuild and cam swap.

Since i haven't used EEHack yet, I assume I run version 4.7, connect, download my existing program from the ECM before any of these steps you list above, or can I jump straight to 4.92?

THEN, I flash with 4.7 with insert patches checked and then read the bin back out. Then you say "apply all patches from the folder". How do I do that? I assume I am pulling in all the changes in your CSV file that was bundled with the 4.92 EEHack zip file; do I just go to the Settings/Advanced tab and point to your updated CSV, then does that "apply the patches"? Because then you say flash the new bin with 4.7.

And for this entire process when should I switch to running the 4.92 EEHack executable instead?
Thanks again for helping me get up to speed here.

I'm running a 94 Formula, bored/stroked/nitrous 402 LT1 with dry and wet kits plus nano nitrous setup, 6-speed.
E-Ticket

[kur4o]

To apply the patch you will need to use another program called tunerpro. You can get it at www.tunerpro.net (http://www.tunerpro.net).
Load your bin and the xdf file provided in tunerpro and you will see on the left side the folder. The patches are inside and you will have to apply them according to instructions. You can jump straight to 4.92. The reason I advertise using 4.7 to flash is because it is safer to flash with it, since 4.92 is not tested enough in that aspect.
When you get familiar with tunerpro and learn how to use it you
will get alot more parameters to tune also.

I see you will be using a nitrous kit. That will be a good possibility to develop custom nitrous patch to your needs. Just tell me how you need the PCM to behave and I will try to make it happen.

[E-Ticket]

Thanks for the reply. I am working to get my software environment set up with all this new software. I have been in the LT1Edit/Datamaster world for the last 20 years so it is taking a bit.

Full specs on engine is currently a 402 '95 LT1 (4.060 with 3.875 stroke), 256/264 solid roller Comp cam with .653/.656 lift (with Crower offset 1.55 rockers) with 114 lobe separation, monoblade TB, 1-3/4" long tube headers, ported heads and intake.

Nitrous kits are a single nozzle dry kit and a NOS pro race fogger soft plume kit, running separately and jetted for around 180hp and 300hp each, plus a Nano nitrous setup for bottle pressure.

Ignition is a Delteq 4 coil setup and gutted Opti (just optical sensor).

M6 transmission with viper OPS conversion, McLeod street twin clutch and SFI bellhousing, denny's nitrous ready driveshaft, Moser 9" with 4.10 gears and 35 spline axles (since I've broken and had to replace everything in this sentence).

I am planning to pick up the FAST dual WB sensor setup and wire them into the ECM so I can monitor at least one bank at a time and log WB's versus the OEM O2's.

E-Ticket

[kur4o]

Here is the second version of Open loop zero tps patch.

Well tested and refined. Now you can specify MPH threshold, really usefull at low mph, zero tps conditions.
It freezes blm cell 18 so you don`t lose the blm setting, when it enters open loop.

You can wire an external switch to command Open loop anytime you want.
Applying ground to pin b23 will force open loop.


Since most of the earlier patches are now part of latest eehack version, I recommend to use it from here http://www.gearhead-efi.com/Fuel-Injection/attachment.php?attachmentid=13364&d=1539435916.


EDIT:

Re upload of xdf due to some stuff missing.

Please download again and delete old one.

[Terminal_Crazy]

Hi
Excellent work.
I guess those are two separate controls ? as I'd prefer a switch for closed/open loop control.

I played with the EoIT last week with not so unlikely results.
My BLM's are slightly offset at idle. 120 & 122 when I started
As i logged every 4 points across the table the "split' increased.99 143 was the biggest difference (split of 44 at 388 degrees 0x3B)
***Note: At about 56C-60C my RHS injector leans out (flatlines) The stock table has 0x40 at this temp ??

The LHS went down lowest to 94 139

Rolling back around the table the split came down the other way to a best of 118 117 @ 163 Degrees (0x63 in the table)

It drove OK (OKish compared to usual) and fueling seemed to have richened up around the lower parts of the VE Table

Anyone else seen anything remotely similar ?

I have a full writeup if anyone wants it posting with Inj PW & fast & slow idle.

Mitch

[kur4o]

Hi
Excellent work.
I guess those are two separate controls ? as I'd prefer a switch for closed/open loop control.

Mitch


The switch is checked first, If closed it will go Open loop.

Than zero tps with mph threshold are checked. If conditions are good it will go Open loop.


If you need only a switch for CL/OL I can you fix you with something.


PLEASE redownload the xdf. I fixed it a little.

[WASyL]

Is there a chance by far for real time tuning for VE table ?

best regards

[kur4o]

Is there a chance by far for real time tuning for VE table ?

best regards

No need to ask. It is already done.

All of the current patches are incorporated in latest eehack version.

To use them you need to download the exe file from here http://www.gearhead-efi.com/Fuel-Injection/attachment.php?attachmentid=13364&d=1539435916

and flash your favorite bin with the patch box checked.


What`s available now is

Realtime control of
maf/sd mode
end of injection time
Ve table control
Maf table control
delta ve control
Individual cylinder correction
Maf pumpshot correction
All of the closed loop parameters

[WASyL]

No need to ask. It is already done.



sorry for my poor English but i'm international.

i have seen that version, i extracted both files (exe + csv) to eehack folder, changed path to new csv, i open up EEhack and can't find true VE table with realtime tracing cells and aadjust. all i see that i can is VE Control by adding -+x% (limited to +-5%) or choose cell by selecting row and cell number. I believe it does realtime but using it on street while tuning would be a nightmare. What i understand i would have to jump cell by cell, adjust with slider etc. memorise amount, jump to TunerPro and adjust then reflash with EEhack. That is a lot of hassle. That way it is easier to just log and go VE spreadsheet.

I'm asking if You are working on RTT like Tunerpro RT way. You and Stevo do lots of grate job any way.

[kur4o]

i open up EEhack and can't find true VE table with realtime tracing cells and aadjust. all i see that i can is VE Control by adding -+x% (limited to +-5%) or choose cell by selecting row and cell number. I believe it does realtime but using it on street while tuning would be a nightmare. What i understand i would have to jump cell by cell, adjust with slider etc. memorise amount, jump to TunerPro and adjust then reflash with EEhack. That is a lot of hassle. That way it is easier to just log and go VE spreadsheet.


What you want is not actually possible to happen. First my coding skills are not that good and second there is some limitions we have to cope with.
Eside of the pcm can`t communicate while the engine is running. So you are only option is to send data to tside and tside send it to eside over spi bus. With that said it is pointless to upload the whole table since it will take forever[0.2-0.5 seconds upload time on a cell * 200 cells].

If you focus on a particular area it is very usefull tool to quickly dial the needed range. 5% delta change in ve table is good enough to stall the engine. It is there for safety reason.
With all the other controls you can make a base tune in less than an hour that will be 80-90% close to the final tune. Basically for 2$ dyi cable and completely stock PCM it is not that bad. You get what you pay for.

You suggest some bad tuning practices I am no keen on.
Tune and drive is really wreckless idea. Just a disclaimer.


Under no circumstances shall tha authors of EEHACK be liable for any indirect, incidental, consequential, damages arising out of or in connection with improper use of EEHACK software.

Multiple Flashing on the interstate in the midlle of nowhere can lead to bricked pcm. Another not that good idea.


I see you are not following close enough the thread. Since it was already mentioned that the modified ve and maf tables can be extracted from pcm on the next ignition cycle.

[E-Ticket]

Thanks for the updates. :thumbsup: Purchased FAST dual wideband kit, plan to wire into D12 (with a switch) and D27 to log both sides. May also add switch to ground B23 to force open loop in case things still get weird at the dragstrip.

First going to just log my idle/cruise O2's to make sure everything is happy and get it all adjusted for regular driving/idling before going to tune WOT on a dyno.

[kur4o]

For a dual wideband setup you`d better use pins D12 and D21 or pins D27 and D31. The pullups resistors on this pairs match and there will be no ground potential difference between the two channels, thus more stable readings accross banks.
D12 and D21 have 50 kohm resistor.
D27 and D31 have 22.3 kohm resistor.

If you have troubles modifying the datastream it is a simple 2 bytes patch. Give me a note and will get an xdf for an easy reconfigure.

[E-Ticket]

For a dual wideband settup you`d better use pins D12 and D21 or pins D27 and D31. The pullups resistors on this pairs match and there will be no ground potential difference between the two channels, thus more stable readings accross banks.
D21 and D21 have 50 kohm resistor.
D27 and D31 have 22.3 kohm resistor.

If you have troubles modifying the datastream it is a simple 2 bytes patch. Give me a note and will get an xdf for an easy reconfigure.

Thanks! Yes let’s do 27 and 31 so I don’t have to deal with AC. I need to install all the tunerpro patches to get everything sync’d up first.

[kur4o]

Apply the patch labelled "Log pin D31 on AC pressure channel [Wideband patch]" and at the AC pressure you will log pin d31 instead of pin d12.

Pin d27 is already setup in the datastream so leave it like that.
Select pin d27 as wideband input in eehack settings. To get an accurate value for wideband channel 2 change the eehack definition file. Find the ac pressure and change the conversion so it matches the setting of the wideband input.

[Casey96SS]

Here is some cleaned up and revised version of all the stuff that is tested and working.
It adds some interesting mode4 control like real time control of VE, maf/sd modes and end of injection time.
You also get some enhanced aldl parameters.

How to install.
1.You need to flash your PCM with eehack 4.7 with insert patches tickbox marked.
2.Than read your bin.
3.Apply all patches from the folder.
4.Burn the bin with eehack4.7 IMPORTANT the insert patches box must be not ticked.
5.Save the patched bin for future improvements.

To make available extra controls use the supplied eehack_v92.exe, which must be run from the eehack installation folder.
Load the supplied definition file for improved datalog.

Instalation notes.
You need to choose between MAF primary and Speed Density primary patches and apply only one of them.
If you have indeterminate data warning when you apply the patches, first press remove patch box, than apply as usual.

Warnings.
If you are runnig Speed density mode and apply the patch, make sure that the skip unused region tickbox is unmarked when you burn the bin.
If the box is ticked the eehack will wipe the MAF table to FFs and switching to maf will not be possible.

I am working on a future version of eehack that will apply the patches automaticaly, but for now you need to follow installation notes exactly as written.

I want to try the open loop idle patch on my car. Do these instructions still apply when using Flashhack and EEhack 4.93?

[kur4o]

These are the latest files I have.
The xdf contains the zero tps open loop patch V2. Tested and working good.

Now the latest eehack exe contains all of the available patches[v5], so what you need to do is just flash your bin with patches checkbox enabled. If you want to use flashhack for flashing after that, than read the patched file and work from there.

With the v5 patch applied you can use some very good histogram tables with tunerpro adx for maf tuning. My favorite is maf cell vs average blm vs blm cell. It clearly shows that one size fits all in maf is vey hard to reach and some closed loop is mandatory.

Too bad we cant export eehack log files to tunerpro format.

Steveo any chance you can make some log conversion application.

[NomakeWan]

I think steveo mentioned he was adding MAF tuning tools in his v5 of EEHack. Neat stuff though!

[steveo]

Steveo any chance you can make some log conversion application.

maybe, do you have a good description of the xdl format or should i reverse engineer it

[kur4o]

No idea about the format. Open an xdl in hex editor and look for some patterns.

[NorthernCrew454]

I have a 94 auto, which one should I be using? I dont want to control it via a pcm pin, I want it in open loop at 0 TPS all th time so i think it is between these two.
16375

[kur4o]

Definitely use the v2. It is much better and you can add a mph threshold for low speed open loop too. I run it with 5-6 mph threshold with great drivability.

Switch the xdf to category view to find the threshold scalar. Pcm pin is optional and you can wire it any time you want to run full time OL[switchable] if needed.

[NorthernCrew454]

Sounds good, if i just apply the patch and dont touch mph threshold it will just go to CL once 1MPH is reached right?

one other question - do i always need to use this xdf for tune updates or can i patch it and go back to using steve's xfd after?

[kur4o]

Apply patch and save bin. Than configure

max MPH THRESHOLD for forced zero TPS Open loop

to your preffered settings. 4-6mph is the way to go. It is really needed on deceleration with throttle off. That is the reason I put it in there.

You can open the scalar after the patch is applied and check what it is set for.


ONce you apply the patch and save bin, you can edit it with whatever xdf you want. Make sure you use the same patched bin after that.

[NorthernCrew454]

Appreciate the feedback, looks like it was set at 50 MPH default. Is cell 16 the open loop target AFR table? So I will tune idle fueling in this table only correct?

[kur4o]

12A11 * Open Loop AFR Target

With this table you can set the afr target based on map vs collant temp. Usually the map column that you have at idle will be your idle target.

After that you can set ve or maf tables to fine tune idle fueling.

[Daemon]

kur4o, thank you very much! Zero TPS OL Patch V2 works perfectly!

Could you add a RPM trigger? Maybe it's possible? BLM has up splitty when I coasting at low speed (~10mph) on zero TPS and 2rd gear.

[Bent72]

Subd

[WASyL]

is there a way to add table or patch to enable radiator fan end/or control external fan vs trans temperature fluid ?

best regards

[kur4o]

is there a way to add table or patch to enable radiator fan end/or control external fan vs trans temperature fluid ?

best regards

There is already an engine oil temperature fan control in the code. It is used on vette applications. I can repurpose it to be trans temp control if that suits your need.

It will very easy patch, just changing the lookup value.

[WASyL]

that would be super cool to control radiator fan by TFT, very usefull when doing lots of burnouts and spins on lockal parking lot on hot days. will keep that trans a bit cooler to extend it's life :) My truck run 3000RPM converter :D

so yest please :)

best regards

[kur4o]

that would be super cool to control radiator fan by TFT, very usefull when doing lots of burnouts and spins on lockal parking lot on hot days. will keep that trans a bit cooler to extend it's life :) My truck run 3000RPM converter :D

so yest please :)

best regards
1b15 trans temp 0.75*x-40

1bd oil temp 0.8*x-40

fan1
change
86ae-[01bd->1b15]

tune
2657 x*25 rpm threshold for fan1
2658 timer for rpm threshold
2655 threshold on lower rpm 9c 40 on
2654 threshold on higher rpm 9c 40 off
2656 hysteresis

fan2
change
8779-[01bd->1b15]

tune
265a fan2 threshold if rpm lower
2659 fan2 threshold if rpm higher
2656 hysteresis

some initial findings.

Some tuning of oil thresholds will be needed. You can check some vette bins for data comparison.

[WASyL]

kur4o sorry but my english is not that good as it should be. by "You can check some vette bins for data comparison." You mean to compare couple bins if thay have same values or do You want me to do something else ? i know noting about disassebbling codes. Descriptions You gave actuall match of what i see in tune except of "2658 timer for rpm threshold", this one i can't find in any tune with EE xdf

best regards

[kur4o]

kur4o sorry but my english is not that good as it should be. by "You can check some vette bins for data comparison." You mean to compare couple bins if thay have same values or do You want me to do something else ? i know noting about disassebbling codes. Descriptions You gave actuall match of what i see in tune except of "2658 timer for rpm threshold", this one i can't find in any tune with EE xdf

best regards

You can check in a vette bin how this are set, since on other bins they are maxed out. That way you can have general idea how to set them.

The timer is some simple one. Wait some time before you switch to high rpm mode. For example you need to be xx seconds above 3000 rpm to switch.

This prevents some back and forth oscillations.

[WASyL]

Oh ok, so on Vette bins they are not maxed out and values are how they should look, so if You are able to add this patch i can test it text week. I know when they should turn on.

best regards

[WASyL]

any news on adding this patch ?

best regards

[kur4o]

I was just doing some clean up of the xdf laying around and include the patch. Hope you have a way of testing it first on some really low trans temps to confirm it works.

Enjoy

[WASyL]

thanks, i will test it on whole range of temps starting lowest possible and let you know next week.

best regards

[WASyL]

just tested, works on whole range of temps. thanks a milion

best regards

[WASyL]

kur4o i have went thru Your XDF and found wideband patch, how does it work?
Also wondering if you can do another patches:
1. 2/3 bar map sensor for boost application
2. Noticed that there is a lot of space and unused tables, maybe you can create patch that adds proper TPS Accel Enrichment in SD mode. Maybe it is just copying code form like 92-93 LT1 to proper space in 94-95 PCM.

I would love to see these and even pay for creating them rather then switching to any SA.
Best regards

[kur4o]

The wideband patch allows you to use some of the free pins on the pcm to log 0-5v. It just change some of the datastream byte to enable logging it.

I think some other guy add it to the xdf and there is some instruction.

Adding a second map sensor to one of the free pcm inputs is easy. Converting the signal to linear data is way harder. Some experiments and logging of the sensor[with pressure and vacuum applied] will be needed. Checking output of sensor vs raw pcm input for linearity is crucial. Than we can use the converted data to add some boost fuel. I am not quite sure how much airflow can the pcm calculates before it goes maxed out. It is still 8bit cpu that don`t have much resolution. In boost we can use map vs airflow adder. Not sure how this can be tuned, since the ve tables are pretty much maxed out on NA engines, you had to increase cylinder volume to get more airflow.

Accel enrichment is pretty complex loop and is not possible to copy from earlier stuff. They do have vastly different engine operation code.There is some table that adds airflow based on delta tps but not sure if it is used in SD mode.

Getting some free time and is another factor that will make developing any of this way slower. A possible winter brain exercise if we can get good initial data for map sensor output till than.

[WASyL]

2/3 bar map sensor is not crucial, i can go another way round. That Accel Enrichment is what I'm looking the most if possible. Just let me know how and I'll do all the testing you need.

Quote
They do have vastly different engine operation code.There is some table that adds airflow based on delta tps but not sure if it is used in SD mode.
/Quote

Which tables and i'll start testing from tomorrow afternon

[kur4o]

Made some quick patch to enable some of the maf correction in speed density mode.

Look in the pumpshot category @air fuel metering.

Added some better description too. The 12406-1240a are not enabled so don`t use them, all other parameters are now used in SD mode.

What it does is add or substract airflow on high negative or positive delta tps changes. Stock are very conservative so you might go a little higher.

Also change the threshold for burst knock enable to compensate since the same output is used there.

[WASyL]

Will start testing tomorrow and let you know. As for burst knock i disabled all knock feature long time ago. I just log knock and adjust spark table if needed.

[NorthernCrew454]

kur4o,

would there be a way to add only the open loop idle v2 to Steve's EEX4.1 xdf?

[WASyL]

so it looks lik it wants to work, but max value to input in table is 3.98 and that seems to be a little to low

best regards

[kur4o]

so it looks lik it wants to work, but max value to input in table is 3.98 and that seems to be a little to low

best regards

You can play with the multiplier table and ramp out to keep it longer in effect. I noticed some vette calibrations have these bumped up a little.

[WASyL]

Ramp out scalar is in Pump shot catalog, but where is that multiplier table? Maxed out table almost did the job :-)

[kur4o]

124b4 Derivative Gain Vs. Coolant Temperature

This one is the multiplier table corrected with baro multiplier 126af HIGH BARO TABLE. The result is used as a multiplier to the main table.

[WASyL]

Thanks a million, that did the job so SD mode can have fully functional Accel Enrichment. No more to MAF :-)

Best regards

[kur4o]

Thanks a million, that did the job so SD mode can have fully functional Accel Enrichment. No more to MAF :-)

Best regards

That is great news. Can you give more details on final settings. It can be tuned in maf mode too, since on light cammed cars it bogs down too.

If you haven`t noticed yet, it also works backwards, enlean on deceleration.

[WASyL]

my setup is LT1, alum heads with 1.6RR, shorties, 2,5 dual straight pipes, 4L60E with 3000 stall converter. Maxed out table except 0% TPS obviously, then multipied Derativ gain by 1.2 and my one runs like a beast now!

best regards

[NorthernCrew454]

kur4o,

Have you ever looked at a table to pull timing for nitrous using a pin on the pcm to activate?

[kur4o]

kur4o,

Have you ever looked at a table to pull timing for nitrous using a pin on the pcm to activate?

The traction spark retard table can be used for nitrous retard. It even have some blend out with timer when retard is over.
If you don`t have a vette car with Traction or other platform with traction than you can use external pin for activating retard.

The pin is C12 and you must provide a B+ voltage to activate.

[NorthernCrew454]

The traction spark retard table can be used for nitrous retard. It even have some blend out with timer when retard is over.
If you don`t have a vette car with Traction or other platform with traction than you can use external pin for activating retard.

The pin is C12 and you must provide a B+ voltage to activate.

I notice that table only goes up to 6400 RPM, will it just pull the same value in the 6400 cell above 6400?

[Lt1rob]

I seen you talked about having an patch that reads voltage at the injectors for the ls injector patch. Is it posted anywhere?

[NomakeWan]

I seen you talked about having an patch that reads voltage at the injectors for the ls injector patch. Is it posted anywhere?
It's included in the LS INJ HACK that's a part of EEXTRA, I believe. So enabling the patch will enable that function and set up the VACUUM VS VOLTS tables for you.

http://gearhead-efi.com/Fuel-Injection/showthread.php?5029-The-ultimate-LT1-EE-patch-thread&p=89095&viewfull=1#post89095

[Lt1rob]

What about the wire you added to get a more direct reading of injectors

[NomakeWan]

What about the wire you added to get a more direct reading of injectors
Where are you seeing this? Can you provide a link to such a modification?

The only reference I saw kur4o making to his LS INJ Patch was for...well, all the changes necessary to run LS injectors on our PCM, since the documentation on LS injectors is far more complete than any other injector we have available, and thus it's easier to fine-tune them.

[Lt1rob]

http://www.gearhead-efi.com/Fuel-Injection/showthread.php?7462-LS-Injector-Data-for-LT1

Post #4

[NomakeWan]

Ah, I see. Well considering it never went anywhere since 2018, I'm gonna bet he found out the benefits were so miniscule as to make the effort meaningless, which is why that function doesn't appear in any of his subsequent XDFs (including the one from only a few months ago I just posted). You're probably good without the wire and extra stuff. Just run the patch as-is.

But that's just me. kur4o can always jump in and be more specific for ya. Peace!

[Lt1rob]

I also need to know if need to change stock injector data in bin if I'm using ls patch

[NomakeWan]

I also need to know if need to change stock injector data in bin if I'm using ls patch
You do not. In the XDF I posted, it's included in the "misc PARAMETERS" part of the patch. After patching, if you want to go back to stock, you can just click "Remove Patch" and it will return you to the stock LT1 settings.

17213

[kur4o]

That patch never become public and there is no xdf in existence. Currently is too hard coded with other custom stuff and extracting is not on priority list.

The existing patch have some stock injector data for a very specific set [p/n] of injectors.

Anyone using the patch should provide and fill correct injector data to all the tables listed in the patch folder after the patch is applied and bin saved.

[WASyL]

Made some quick patch to enable some of the maf correction in speed density mode.

Look in the pumpshot category @air fuel metering.

Added some better description too. The 12406-1240a are not enabled so don`t use them, all other parameters are now used in SD mode.

What it does is add or substract airflow on high negative or positive delta tps changes. Stock are very conservative so you might go a little higher.

Also change the threshold for burst knock enable to compensate since the same output is used there.

can you repost latest .xdf file as this link is no more valid

best regards

[kur4o]

can you repost latest .xdf file as this link is no more valid

best regards

These are now part of the modded version of eehack. Or you need something specific. I have too many version laying around, and not sure they will help.

[WASyL]

i just want most recent xdf that was posted here or where can find thar modded eehack?

best regards

[WASyL]

i'm looking for XDF with SD AE patch and oil temp to trans temp fan patch you made for me and EEhack mod to play with EOIT

best regards

[kur4o]

The latest modded eehack is available here. No need to reupload, but the xdf opens as a png dot so here it is.

http://www.gearhead-efi.com/Fuel-Injection/attachment.php?attachmentid=16006&d=1598039824

[WASyL]

Thanks

[NomakeWan]

Any chance someone is willing to work on a patch to enable flex fuel interpolation? As you may be aware pump E85 isn't necessarily 85% ethanol. While here where I live it's mandated to be 85% via taxes on vendors who try to sell anything lower, elsewhere in the USA it can be anywhere from 51% to 85% and still be called "E85." So you'd want to run an ethanol content sensor on your fuel feed, and interpolate between two fueling tables depending on the ethanol content of the fuel (your normal E0~E10 gasoline table, and an additional table containing the E85 85% table). The ethanol content analyzers generally output 0-5V analog to represent 0%~100% ethanol content, so it'd use one of the free ADC inputs just like a wideband O2 sensor would.

Thanks y'all!

[NomakeWan]

So, question about the LS Injector patch for kur4o. Do these three tables override all the injector-related tables in the $EE Air-Fuel Metering category? So after applying the patch I'd only need to fill in the three LS tables, and can ignore the $EE Injector Flow Rate, Injector Voltage Offsets, and Injector Offset Adder? And am I also correct that to replicate the effect of changing the $EE IFR, I would need to multiply every entry in "Fuel Flow vs Vacuum" by the same amount I would multiply $EE's IFR, yes?

Thanks as always.

[kur4o]

So, question about the LS Injector patch for kur4o. Do these three tables override all the injector-related tables in the $EE Air-Fuel Metering category? So after applying the patch I'd only need to fill in the three LS tables, and can ignore the $EE Injector Flow Rate, Injector Voltage Offsets, and Injector Offset Adder? And am I also correct that to replicate the effect of changing the $EE IFR, I would need to multiply every entry in "Fuel Flow vs Vacuum" by the same amount I would multiply $EE's IFR, yes?

Thanks as always.

You can apply the low pulse offset adder separately. When applied all tables for fueling comes from patch, so that is the only ones you need to adjust. I think I added some math conversions in the description part. Maybe some fine tuning of the flow rate will be needed at the end.
If you have data you can input that too with some scaling. If the injectors are stock gm, we can rip the tables from a bin.

[NomakeWan]

So the Injector Offset Adder is the only table in $EE that I'd need to worry about? Sweet!

The injectors aren't stock GM, but they do have really awesome data. I got them from FIC, so they have really great data tables. The one I was sent was already configured for 43.5 PSI and E10 fuel, even, which was nice. And thanks to that spreadsheet from dzidaV8 it should be pretty easy to translate their data into your patch tables. Thanks again!

Okay, so after messing with this, I just want to make absolutely sure I'm doing it right. I found this discussion by 84Elky over on ThirdGen regarding the calculation for voltage offset, noting that GM apparently applies the value twice. Here: https://www.thirdgen.org/forums/diy-prom/764533-installing-bosch-iii-injectors.html#post6346200

I found that for my injector data, I have some times as high as 5496.246 microseconds in my datasheets, but the LS Inj patch only allows a maximum of 3891 (FF). Is this a limitation of the calculation, or should I be dividing all of my numbers by 2 before putting them in?

[steveo]

I found that for my injector data, I have some times as high as 5496.246 microseconds in my datasheets, but the LS Inj patch only allows a maximum of 3891 (FF). Is this a limitation of the calculation, or should I be dividing all of my numbers by 2 before putting them in?

you'd only divide by two if your xdf's conversion to usec was incorrect

if you're talking about injector vs voltage offsets, you only really have to worry about the data in the lets say 11.5-14.5v range.

if your injector's supply voltage goes outside that range it's because something is broken, so having incorrect values in those areas is the least of your concerns, you will be 'limping' anyway.

pretty common for datasheets to have crazy values outside of operating range

[kur4o]

3891 (FF) is 8 bit limitation, so that is the max you put for these cells. I guess they are in very unusual conditions so you don`t have to worry about it.

I suggest you apply the

low pulse injector extend hack
patch too
and fill the
low pulse inj width correction
table
It gives better resolution for low pulse conditions.

One other limitations is there is no negative values possible, so if you have negative values you can set that cells to 0.

The low pulse offset adder is done by eside cpu, but the main offset is handled by tpu so nobody knows how it is done.

Since I have already run the patch for long enough time, the provided sample tables have been tested well enough and you can use them for reference.

[NomakeWan]

Okay cool, I wanted to make sure. 84Elky noted the 8-bit limitation in his description as well, but that to get around it, GM engineers had the routine run twice back-to-back so it could get twice the maximum value.

I had a feeling that the patch just cuts off those top values since the voltages are so low, but like I said, just wanted to be 100% sure before flashing. I've gone ahead and applied all the patches and filled in all the tables. I won't be able to test the new injectors for a little bit, but definitely looking forward to it! Thank you again!

[kur4o]

Any feedback will be greatly appreciated.

If for some reasons pcm reads less voltage than actual, I have some other versions that can be run. Reading voltage directly from injector circuit, on a spare pcm pin.

If you change substantially the fuel flow, consider adjusting the prime pulse tables. We have a very good write up about it on some thread here.

I also have some version with fixed fuel flow on startup, because I decided that the patch was the issue for first longer crank issues I had, which proved not to be the case.

[Rocko350]

Good stuff, Good Stuff. Not really back to EOIT stuff, more of a question. Can the coolant axis for the lookup table for EOIT be pointed at rpm instead of coolant temp? The coolant temp reasoning from gm was to aid in cold engine warm up. The LT4 table allowed the hot cam to run in that car without tuning. We all know it wasnt great, but it got the job done. (6.0 in the entire table) Some really aggressive lobed cam combos i VE tuned were in the upper 90s and were wanting more than 100% in some cells. Clearly not possible. Those two got engine size upped a bit and fueling rescaled to get the numbers needed in the VE table. I know its not a huge deal for some. Ive backed off cam choices in some later builds to keep from doing a bunch of stuff like that. Two of the over 400" ones i was using 6.3 in the tables to make the upper rpm happy. near 20% in the idle area of the tune. I ended up going to an 65 lb/hr injector so i could get it to idle clean with such a narrow window of injection time. The stroke in them helped a bunch.

Again, you guys ROCK! I never got to get into the software this deep.

Chris

[kur4o]

I was also thinking about some rpm modifier for eoit target, but refreshing that realtime will be useless. Since there is some scalars so eoit target don`t jump off like crazy but update slowly overtime. Eoit is also handled by TPU and it is really hard to tell what is in there. If you are willing to test some quick patch can be made, but the outcome will be unknown. LT4 calibration have some extra map for baro but nothing rpm related. At some higher rpm the injector using 85+DC% will be on almost all the time, You will need some real big fat ones to make a use of EOIT target properly. I did some calculations for the max dc% to make any use of it. For a full 720* of crank you have 20ms time at 6000rpm, remove the degrees for a intake duration, to get the needed ms time for an injector.

Actually eoit temp compensation for startup and warmup is much more important than you think. I did some extensive testing to overcome a lean hole at some specific temp window, and still it is not dialed the way I wanted. Making the eoit target logic a little doubtful and not great to play with. I think there is some synchronization logic that goes out of sync for some specific conditions, and it needs some time to reset.

I think some higher rpm adder can be made, after engine has been warmed, that is used above some certain rpm points. We can make it refresh each low res pulse so it follows quickly. How that will be interpreted by tpu is in question.

[Hotrodhawk]

Made some quick patch to enable some of the maf correction in speed density mode.

Look in the pumpshot category @air fuel metering.

Added some better description too. The 12406-1240a are not enabled so don`t use them, all other parameters are now used in SD mode.

What it does is add or substract airflow on high negative or positive delta tps changes. Stock are very conservative so you might go a little higher.

Also change the threshold for burst knock enable to compensate since the same output is used there.

Hello kur40
Just doing some reading and came across this topic.
Is this feature in the current revision of eextra v.003.xdf ?

Thanks for the great tool!!!
Jeff

[kur4o]

Looks like we are talking for the speed density AE patch.

Here you can find the latest xdf and a link for the modded version for the eehack program.

http://www.gearhead-efi.com/Fuel-Injection/showthread.php?5029-The-ultimate-LT1-EE-patch-thread&p=92678&viewfull=1#post92678

[Hotrodhawk]

Looks like we are talking for the speed density AE patch.

Here you can find the latest xdf and a link for the modded version for the eehack program.

http://www.gearhead-efi.com/Fuel-Injection/showthread.php?5029-The-ultimate-LT1-EE-patch-thread&p=92678&viewfull=1#post92678

Thank you !

You mention at that link it is a PNG DOT so I take it it needs to be pointed to which format to work?

[kur4o]

Some time ago lots of file got lost, during site maintenance. I am referring to a file that get lost.

[Hotrodhawk]

Some time ago lots of file got lost, during site maintenance. I am referring to a file that get lost.
Oh, OK.

When I try to unzip the link that ends in (1598039824) I get either of these two error messages.

Share
View
Compressed Folder Tools
Extract Compressed (Zipped) Folders
Cannot Complete the Compressed (zipped) Folders Extraction Wizard
The compressed (zipped) folder is empty.
Before you can extract files, you must copy files to this compressed (zipped) folder.
To close this wizard, click Finish.


or


Date modified
Type
10/22/2022 5:10 PM
Compressed (zipp..
X
Windows cannot open the folder.
The Compressed (zipped) Folder 'C:\Users\hotro\Downloads\eehack_29_11_2019_v1.rar .zip' is invalid.

[NomakeWan]

The second file is WinRAR format, so you won’t be able to open it like a ZIP. You need a program like WinRAR or 7zip to open it.

[Hotrodhawk]

Ya, I feel real rookie about now. Its been forever since I've opened WinRAR stuff like windows 98...lol
Any how I've got the speed density AE patch installed into eehack and functioning. Thanks kur4o & NomakeWan for getting me pointed in the right direction.
Ill be getting back after this car once I get the optispark replaced next week. Nothing funner than having the low res signal causing some weird random "bumps" that have occurred very very randomly at highway speed over the last few weeks. 3 bump occurrences then total loose of fuel pump enable to relay followed by the dtc16 error setting.

[WASyL]

Ya, I feel real rookie about now. Its been forever since I've opened WinRAR stuff like windows 98...lol
Any how I've got the speed density AE patch installed into eehack and functioning. Thanks kur4o & NomakeWan for getting me pointed in the right direction.
Ill be getting back after this car once I get the optispark replaced next week. Nothing funner than having the low res signal causing some weird random "bumps" that have occurred very very randomly at highway speed over the last few weeks. 3 bump occurrences then total loose of fuel pump enable to relay followed by the dtc16 error setting.

Do you run SD (VE) mode only ? Cause this patch is only needed when You delete MAF sensor.

[Hotrodhawk]

Do you run SD (VE) mode only ? Cause this patch is only needed when You delete MAF sensor.

Yes, my goal is to go back too SD once I get this sorted out from the drastic elevation change. With my move from Michigan to Northern Utah. From 800 foot elevation and now I'm at 4500 foot and have had the car near 9980 foot elevation.

Been back on the MAF for about 800 miles and things were looking good until the opti got weird with the low res signal flaked out.

[WASyL]

I have never played with Baro correction so can't help You here. But i have been at 100 feet and at around 2900 feet too and never needed to adjust anything in SD mode.

[Hotrodhawk]

I have never played with Baro correction so can't help You here. But i have been at 100 feet and at around 2900 feet too and never needed to adjust anything in SD mode.

I'm hoping the stock baro settings will be close. A 1bar gm map in the technical info shows they are calibrated from sea level to 15,000 foot.
That testing will resume once they open those mountian passes around June 15th next year.

[steveo]

the stock math and strategy on everything regarding barometric pressure in VE should do a really good job above sea level if you floor it occasionally while driving through the mountains, which any human being with a heart and soul is bound to do. i wouldn't touch any of that stuff.

where things have gone wonky for me with barometric updates is if you floor it, and your air intake is restricted in some way, that's your new (false) baro pressure. if you have a dirty air filter you could easily be out a few kpa from the key on engine off baro init. can't really calibrate for that, though.

[Hotrodhawk]

the stock math and strategy on everything regarding barometric pressure in VE should do a really good job above sea level if you floor it occasionally while driving through the mountains, which any human being with a heart and soul is bound to do. i wouldn't touch any of that stuff.

where things have gone wonky for me with barometric updates is if you floor it, and your air intake is restricted in some way, that's your new (false) baro pressure. if you have a dirty air filter you could easily be out a few kpa from the key on engine off baro init. can't really calibrate for that, though.



Thanks for your input Steveo. I've felt that once I get the cells in the 20-45 kap logged with actual under load values and not just very light throttle to decal It will all come into line. As far as the ability to achieve the actual baro at elevation at key on hasn't been a issue, it either matches or is off by 1 digit less with this build. My concern has been the factored logic that recalculates the baro sensors seamless switch to that end of the range per say while climbing or descending into the atmosphere...lol

I'll shoot you a video of what I have going on with the induction.

[WASyL]

Any news on nitrous patch ?

[WASyL]

still working on that nitrous thru EGR control. I don't know how gm/sec value is calculated so is it possible to do patch that does this:

table "26c2 MIN EGR DC% vs airflow" change load value form gm/sec to MAP reading

best regards

[AngryCorvair]

I apologize if this isn't the right thread to ask. I want to make sure I'm using the latest released version of EEHACK. I have seen reference to a V5, but the current download on ecmhack.com is 4.9.3.

Thanks!
patrick aka angrycorvair

[NomakeWan]

4.9.3 is the latest version of EEHack.