question about evoscan knock sum!
#106
Evolved Member
iTrader: (2)
Thanks for sharing the factual evidence, John.
It's always nice to crush people's opinions (that they believe to be fact) with factual data. So many people come in here and regurgitate what some 'tooner' has told them without understanding how the ECU works. But, just because they heard it from this guy or that guy, it must be the truth.
I have tried to explain some of these things numerous times, only to be told that I have to be wrong because Tuner A agrees with him. That's what I get for trying to help people out.
Thanks for all of your hard work with the disassembly and all of the new modifications that you have been making to the code. It's truly appreciated.
Eric
It's always nice to crush people's opinions (that they believe to be fact) with factual data. So many people come in here and regurgitate what some 'tooner' has told them without understanding how the ECU works. But, just because they heard it from this guy or that guy, it must be the truth.
I have tried to explain some of these things numerous times, only to be told that I have to be wrong because Tuner A agrees with him. That's what I get for trying to help people out.
Thanks for all of your hard work with the disassembly and all of the new modifications that you have been making to the code. It's truly appreciated.
Eric
Last edited by l2r99gst; Jun 28, 2007 at 11:43 AM.
#107
Account Disabled
first im not talking about just "your software" im talking about software in general. For one that looks not like a memory dump that Im talking about, that is shifting data to be transfered to you. The data is overwritten if not transfered, if you miss it then your out of luck. Data can get collected in #$#$#$# location, then shifted to #$#$#$# location where it is then dumped into the database. that not exactly a memory dump where all data is collected then dumped. Then erased or overwritten.
Decay interval knocksum > sample interval
In this case can you explain how knock sum data is ever missed?
"The OEM ROM is not transfereing memory dump to the datalog software."
Perhaps you can explain the following code then that shows that it is?
ROM:000217BA mov.l @(h'DC,pc), r0 ; [00021898] = REQ_MUT_0
ROM:000217BC mov.l @(r0,r1), r10
ROM:000217BE mov.b @r10, r8
(r0=MUT table base, r1=request ID offset, r8=byte to the serial port)
That MUT table contains the addresses of real RAM variables. The logging is easily fast enough. Some values are clipped or heavily quantized, but practically I don't see the limitations, and if I did I would be addressing them by rewriting them.
In this case can you explain how knock sum data is ever missed?
"The OEM ROM is not transfereing memory dump to the datalog software."
Perhaps you can explain the following code then that shows that it is?
ROM:000217BA mov.l @(h'DC,pc), r0 ; [00021898] = REQ_MUT_0
ROM:000217BC mov.l @(r0,r1), r10
ROM:000217BE mov.b @r10, r8
(r0=MUT table base, r1=request ID offset, r8=byte to the serial port)
That MUT table contains the addresses of real RAM variables. The logging is easily fast enough. Some values are clipped or heavily quantized, but practically I don't see the limitations, and if I did I would be addressing them by rewriting them.
#108
The variable is being logged at a higher frequency than it is allowed to decrement, so no knock sum data is missed and you will always see the peak. Have you noticed how slowly knock sum decrements even for a brief knock event?
I'm not at all interested in the raw, unfiltered, undifferentiated, pre-threshold knock sensor input to the ECU as it would be dealing with more data than any sensible automotive digital IO method could handle (CD quality audio recording would be about right for capturing the raw signal - although even then it would miss harmonics only 3-4x the base frequency of knock - which I've done and it is less useful than the knocksum because without DSP it isn't efficiently processed in a convenient method to be of any realtime use). I am very interested in the post-processed knock sum which changes slower than I can log, and which has a direct effect on my ignition timing.
Some data that I can dump does indeed change faster than you can dump it through relatively low speed but robust automotive IO links. For example, logging the ADC input of a hall effect sensor at engine rotation speeds would be fruitless with our ECU technology. If you logged some of the knock control intermediate stuff it would appear nonsense at our logging speeds because it is data that isn't designed to be logged. The request IDs are there in Evoscan, but it is a waste of time logging them.
The most interesting data in engine management is stuff that happens about 10 times a second. For post-processed common ECU data, much faster seems to be superfluous.
If it was really useful to stuff all the knock sum data into a buffer every time it was calculated (but more often than it was usually logged) then it would be possible to do, I think though I'd just end up recording a time stamp when it changed, and the end result would be of no practical advantage over the knock sums we already log.
I'm not at all interested in the raw, unfiltered, undifferentiated, pre-threshold knock sensor input to the ECU as it would be dealing with more data than any sensible automotive digital IO method could handle (CD quality audio recording would be about right for capturing the raw signal - although even then it would miss harmonics only 3-4x the base frequency of knock - which I've done and it is less useful than the knocksum because without DSP it isn't efficiently processed in a convenient method to be of any realtime use). I am very interested in the post-processed knock sum which changes slower than I can log, and which has a direct effect on my ignition timing.
Some data that I can dump does indeed change faster than you can dump it through relatively low speed but robust automotive IO links. For example, logging the ADC input of a hall effect sensor at engine rotation speeds would be fruitless with our ECU technology. If you logged some of the knock control intermediate stuff it would appear nonsense at our logging speeds because it is data that isn't designed to be logged. The request IDs are there in Evoscan, but it is a waste of time logging them.
The most interesting data in engine management is stuff that happens about 10 times a second. For post-processed common ECU data, much faster seems to be superfluous.
If it was really useful to stuff all the knock sum data into a buffer every time it was calculated (but more often than it was usually logged) then it would be possible to do, I think though I'd just end up recording a time stamp when it changed, and the end result would be of no practical advantage over the knock sums we already log.
#109
Account Disabled
ya hopefully DSP technology will be incorporated in the future, that would be great. We can look at the convolution integrals, design our own filter, use fourier transforms to intellegently understand whats going on more. Wouldn't it be great to look at the frequency domain of the signals without having to resort to a $30,000 O-scrope to see it. Like matlab, that would be splendid!
#110
Ion sense cylinder pressure monitoring would be more useful as is done on recent grocery getters as I think you call them.
However, starting to do some work on Bosch ECUs I don't think direct injection, CAN bus, fly by wire throttle, checksums, torque models/targets and limits galore will be at all friendly to the tuner compared to what we have on the Evo now! I think for many it will shut them out![Frown](https://www.evolutionm.net/forums/images/smilies/frown.gif)
At present the Evo is a dream to tune because it is relatively simple (but with some decent underlying ECU code even though the maps are few are low resolution), but still very effective in all areas except gas mileage.
I really wouldn't wish the present Evo ECU to be any different, I can't think of anything as modification friendly.
However, starting to do some work on Bosch ECUs I don't think direct injection, CAN bus, fly by wire throttle, checksums, torque models/targets and limits galore will be at all friendly to the tuner compared to what we have on the Evo now! I think for many it will shut them out
![Frown](https://www.evolutionm.net/forums/images/smilies/frown.gif)
At present the Evo is a dream to tune because it is relatively simple (but with some decent underlying ECU code even though the maps are few are low resolution), but still very effective in all areas except gas mileage.
I really wouldn't wish the present Evo ECU to be any different, I can't think of anything as modification friendly.
#111
We (land of Oz) normal use 98RON pump fuel I typically see 2-4 counts from time to time on my EVO6TME on a 18psi 300wHP (DD number) tune.
However we also have Shell Vpower 100RON available at a limited number of service (gas) stations on the same tune knock count disappears completely
![Smilie](https://www.evolutionm.net/forums/images/smilies/smile.gif)
#113
Dynoed it 320wHP@20psi same timing as 18psi tune (still no knock). Dyno time costs money maybe next time I will play more just did two runs at 20psi. Wideband on dyno died so did not do any more runs. Also MAF maxed out from 5500RPM and injectors maxed. Need to spend $$$ to go to next level.
How much is left in it hard to say I have stock engine, stock cooler only 3" exhaust and straight intake setup.
I must be getting old it's quick enough for me
![Smilie](https://www.evolutionm.net/forums/images/smilies/smile.gif)
Thread
Thread Starter
Forum
Replies
Last Post
darksideauto
Lancer Engine Management / Tuning Forums
1
Jun 13, 2012 05:34 PM