Notices
ECU Flash

question about evoscan knock sum!

Thread Tools
 
Search this Thread
 
Old Jun 28, 2007, 11:41 AM
  #106  
Evolved Member
iTrader: (2)
 
l2r99gst's Avatar
 
Join Date: Mar 2004
Location: CA
Posts: 3,499
Likes: 0
Received 4 Likes on 4 Posts
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

Last edited by l2r99gst; Jun 28, 2007 at 11:43 AM.
Old Jun 28, 2007, 02:50 PM
  #107  
Account Disabled
 
lemmonhead's Avatar
 
Join Date: Nov 2006
Location: wexford,pa
Posts: 1,296
Likes: 0
Received 2 Likes on 2 Posts
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.

Originally Posted by jcsbanks
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.
Old Jun 28, 2007, 03:52 PM
  #108  
Evolved Member
 
jcsbanks's Avatar
 
Join Date: May 2006
Location: UK
Posts: 2,399
Likes: 0
Received 5 Likes on 4 Posts
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.
Old Jun 28, 2007, 04:53 PM
  #109  
Account Disabled
 
lemmonhead's Avatar
 
Join Date: Nov 2006
Location: wexford,pa
Posts: 1,296
Likes: 0
Received 2 Likes on 2 Posts
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!
Old Jun 29, 2007, 01:40 AM
  #110  
Evolved Member
 
jcsbanks's Avatar
 
Join Date: May 2006
Location: UK
Posts: 2,399
Likes: 0
Received 5 Likes on 4 Posts
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

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.
Old Jun 29, 2007, 02:20 AM
  #111  
Newbie
 
gtpumps's Avatar
 
Join Date: May 2006
Location: Sydney
Posts: 71
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by jcsbanks
If it always runs zero the tune is too conservative and you are on a knock limited engine (like ours on pump fuel) leaving timing and performance on the table.
I 100% agree if you tune for zero knock count it won't haul however it does depend on what fuel of course!
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
Old Jun 29, 2007, 03:21 AM
  #112  
Evolved Member
 
jcsbanks's Avatar
 
Join Date: May 2006
Location: UK
Posts: 2,399
Likes: 0
Received 5 Likes on 4 Posts
Will go better if you tune it for the 100 RON then
Old Jun 29, 2007, 03:36 AM
  #113  
Newbie
 
gtpumps's Avatar
 
Join Date: May 2006
Location: Sydney
Posts: 71
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by jcsbanks
Will go better if you tune it for the 100 RON then

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
Related Topics
Thread
Thread Starter
Forum
Replies
Last Post
Ray521
Evo X General
8
Sep 10, 2015 11:10 AM
darksideauto
Lancer Engine Management / Tuning Forums
1
Jun 13, 2012 05:34 PM
jcsbanks
ECU Flash
64
Sep 19, 2009 01:34 PM
RedV
ECU Flash
17
Apr 2, 2007 10:38 AM



Quick Reply: question about evoscan knock sum!



All times are GMT -7. The time now is 11:16 PM.