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
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
1994 LT1/4L60E Formula
Attachment 9820
Pin 27 is working for me with my innovate lc-2. 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
97z28 A4 obd1 swap(16188051)
Tunerpro Newbie
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..
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...
Last edited by steveo; 12-02-2015 at 09:07 AM. Reason: off-by-one error as usual
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.
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.
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.
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.
I can test this, I have some LT1 cars to play with in the neighborhood...
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.
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.
Last edited by kur4o; 08-26-2017 at 10:47 PM.
Permanently gone
here is the answer.
http://www.gearhead-efi.com/Fuel-Inj...ll=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-Inj...Information-0D
Hope to see you around more. here soon i will have another eextra release.
97z28 A4 obd1 swap(16188051)
Tunerpro Newbie
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
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
Last edited by kur4o; 09-03-2017 at 04:46 PM.
sounds awesome, wish i still had an lt1 so i could try it. nice work
Bookmarks