Octane number update information - 1-3=increment/4-5=no change/6=decrement
Aug 28, 2006, 10:10 AM
#1
Evolved Member
Thread Starter
Octane number update information - 1-3=increment/4-5=no change/6=decrement
If the knock sum is 0,1,2,3 then the octane number will be increased by 1 on a timer.
If the knock sum is 4 or 5 then the octane number is left alone.
If the knock sum is >5 then the octane number will be decreased by 1 on a timer.
This is very similar to the DSM. I've found equivalent code in my JDM Evo IX ECU with the same rules.
Hope this helps in the ongoing debates about what knock sums are significant.
I can also confirm that the octane number is used to interpolate between low and high octane fuel and timing maps.
If the knock sum is 4 or 5 then the octane number is left alone.
If the knock sum is >5 then the octane number will be decreased by 1 on a timer.
This is very similar to the DSM. I've found equivalent code in my JDM Evo IX ECU with the same rules.
Hope this helps in the ongoing debates about what knock sums are significant.
I can also confirm that the octane number is used to interpolate between low and high octane fuel and timing maps.
Trending Topics
Aug 28, 2006, 01:36 PM
#9
Evolved Member
iTrader: (19)
Join Date: Oct 2004
Location: CT
Posts: 885
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by MalibuJack
If you think this is cool.. you should see where all this research is coming from.. Lots of good stuff on the horizon..
Aug 28, 2006, 01:45 PM
#11
Most of the inner workings of the rom is his efforts of disassembling the rom for the project on Aktivematrix, where we're attempting (actually for the moment, its mostly Him) to document the entire rom and its functionality, with the intent of creating mods and patches specifically to add or enhance the rom.. Not just finding new maps.. But in a few months I'm sure all the maps, tables, configuration parameters, and OBD-II stuff will be fully documented..
I feel bad, he has had much better results than I have in the disassembly effort (my project file just doesn't look right) but he has also contributed invaluable data as he goes through the code.. He's WAY more proficient in assembler than I am. As he starts extracting sections of useful code, there are some of us who plan on patching/modify/add/remove the segments to enhance the ECU even more..
I feel bad, he has had much better results than I have in the disassembly effort (my project file just doesn't look right) but he has also contributed invaluable data as he goes through the code.. He's WAY more proficient in assembler than I am. As he starts extracting sections of useful code, there are some of us who plan on patching/modify/add/remove the segments to enhance the ECU even more..
Aug 28, 2006, 01:53 PM
#12
Evolved Member
Thread Starter
MalibuJack, you overestimate the inspiration and underestimate the perspiration. I just did a bit of 6502 and 68000 assembly as a kid to do a Mandelbrot set when I was geeky and that kind of thing was cool 
And more recently a bit of Atmel AVR fiddling.
The DSM 1g disassembly commented on the yahoo dsm-ecu group has given some pointers too.
These serial routines are doing my head in. I've found a routine that chucks a byte out of the serial port, but I cannot for the life of me find the equivalent to the OBDtable in the DSM that reverses the Evoscan requestIDs into RAM locations.
The SH2 has a nice instruction set that is RISCish, quite simple. I never ventured into the horror that is x86 assembly, it looks horrific. Microcontrollers are nice though because everything is integrated.
And more recently a bit of Atmel AVR fiddling.The DSM 1g disassembly commented on the yahoo dsm-ecu group has given some pointers too.
These serial routines are doing my head in. I've found a routine that chucks a byte out of the serial port, but I cannot for the life of me find the equivalent to the OBDtable in the DSM that reverses the Evoscan requestIDs into RAM locations.
The SH2 has a nice instruction set that is RISCish, quite simple. I never ventured into the horror that is x86 assembly, it looks horrific. Microcontrollers are nice though because everything is integrated.
Aug 28, 2006, 01:58 PM
#13
I actually stopped programming in assembler BECAUSE of my frustration with x86.. I dont think there is anything similar to the OBDTable.. This might have been by design, since OBD-II codes are static it might be directly coded and not xrefed.. Once you find a few more of the communication stuff it should get clearer.. which I hope because the thing I'm looking for is more data on the communication protocols and code, so I can finish my logger and have access to parameters never before seen.. 
Okay so thats optimistic..
Okay so thats optimistic..
Aug 28, 2006, 02:27 PM
#14
Evolving Member
iTrader: (2)
Join Date: Sep 2004
Location: South Bay
Posts: 287
Likes: 0
Received 0 Likes
on
0 Posts
John your parents must speak Assembly at home and English must be your second language j/k
I don't know how you are doing this stuff so fast. I'm still trying to review the earlier stuff from aktivematrix.
Great work, BTW!
j/kI don't know how you are doing this stuff so fast. I'm still trying to review the earlier stuff from aktivematrix.
Great work, BTW!