RomRaider

I don't mean to take this off topic, maybe a new knock investigation thread is in order.
I made a few recordings directly off the knock sensor trying to correlate real or false knock with a log file. I haven't been very successful yet.
In my tuning thread topic5433-30.html last post on page 3 there is a recording and log.
I used Spectogram to try and isolate a voltage spike at a particular frequency in the time-frame the log showed an increment of knock sum, but there is so much other noise there it's difficult.

I too agree there must be a sensitivity threshold in the ROM. Even if there is a DSP isolating the knock, it has to feed that info into the ECU (on one of the A/D channels or peripheral bus?) for interpretation. I'm very new to IDA and have been trying to learn in order to look over the knock logic, but with little success or time so far. I'm looking at my 32bit ROM A2WC522S (ECU ID:2F12795606). I also took a few pictures of my ECU printed circuit board to try and trace the signal path from the sensor input connector to see how it's processed on the board. But I need to pull the ECU out again and do some tracing with an ohm meter to validate some of the pass-through connections on the PC board. If this is a multi-layer PC board that will make it even more challenging.
...so little time and so much to learn...

For this particular ECU\ECU_ID it is helpful to add 1000-2700 pf capacitor in parallel to the knock sensor in order to avoid false knock ignition retard.

post46839.html?hilit=2700%20pf#p46839

Thanks, good info that I missed.

Anyone got a good starting point to play with the dwell setting on a 02? If I just bump up .20ms across the board is that a huge change? I'm just trying to get a feel for this. Reading up on ignition dwell on EFI now. I'm used to doing it with point/coil distributor ignitions where it was done by a dwell meter.

Someone posted this in another thread, very good read: http://www.tonyfoale.com/Articles/Ignition/Ignition.htm
I think to correctly tweak the dwell settings, you would really need to the know actual dwell time for our coils. Without this you are shooting in the dark, too little dwell time and you sacrifice current, too much and you generate un-needed heat. Just my $.02.

Very good read,thanks!

i don't want to add more complication to the topic, but ideally one would open the plug gap at the same time as increasing dwell. what we want here is as big a kernel as possible to give the flame front a head start.

i ran a .040 gap for a while on copper ngks. with the additional gap i noticed a bit lower knock margin--leading me to believe that the combustion process was slightly quicker. it wasn't much but it was there.

unfortunately as the gap got even a few thous larger it lead to misfires at highest load. those may not have happened with another few ms of dwell.

fwiw
ken

We also have a "cranking" Dwell that will be released as well (was missed, my bad)

Ken anything else you can think of to look for that would be useful?

There are so many things to look at, and having a "hey maybe this is there" would help.

I cannot find anything but knock signal/voltage/threshold - there is no sensitivity table that I can find.

Also no "noticable" tip out either. Still working on that one.

CEL has no code, but still a light

-Jerod

Hi:
I did some poking around in my ROM (A2WC522S) which you can grab from here.

I found something that looks like a Dwell table. I'm just not sure of the data unit conversion though. I assumed uint16 and a multiplier of 0.001 to get to milliseconds.
Can anyone confirm this for me as the 3D table def has no multiplier or additive defined?
Dale

EDIT: After reviewing the code more the conversion is more likely the unit16*4 which results in a value most likely in micro-seconds. Once this conversion is made the result is very similar to this table:

Great stuff on the dwell time comp and idle speed error timing. These will help quite a bit on cammed cars. I have a request. Overrrun injection. Aka,decel fuel. I know that there are atleast 3 tables for this. They are all 1D as well.

-You have Overrun injection rpm=this dictates an on and off rpm for overrun fuel.

-Overrun TPS=below this tps the overrun will be engaged.

-Overrun pulse width=below this injection time overrun can be engaged.

These help alot with tuning for large injectors. They apply to 16 and 32 bit cars.

Also,many ecu's have a minimum injector pulse width. On cars with very large injectors,this helps. Otherwise you may not be able to acheive a proper low PW timing. In turn it can run too rich at idle and under conditions that require a very low PW.

I am almost certain that it is dwell, I have not started defining it for the 32bit ecus yet though. I did take a peek at your ROM and it most certainly seems like it is. I am not sure what the second axis value is though. One is Battery V, the other should be RPM but it didn't seem to match up. I may have just been rushing too much though, or it could be based on something else in the 32bit ecus.

The conversion used for the 16bit ecu is x*.0625 I didn't try it out for the 32bit but you might give it a shot.

Andy

Thanks! We always appreciate new things to look for. I know Jerod had mentioned finding something like overrun, but I'm not sure if he did anything with it. Next time I talk to him hopefully we can get it all worked out for you guys.

Andy

I will start to look for some maps as well. I'm just now starting to get into disassembly. And one of my programming buddy's is using IDA Pro now. Hopefully we can help out soon. Too bad Mercgod has moved on. But it's better for him. And the company that hired him. Lol. Bet he is watching though.

I followed this table structure:

Which you can see in the first 20 bytes of data. If FLOAT has no scaling then the values are the real numbers. Converting them directly from FLOAT to decimal I get the values you can see in the mock table I posted (second image). As for the data conversion, using a uint16 value matches up with the data in the ROM. If there is no scaling then the uint16 number must be a raw time representation. Unadjusted it may be microseconds (or some other CPU unit of time), but to fit with a standard unit of measure as in other ROM tables I multiplied it by 0.001 to get what could be milliseconds. The question is, are these values close to what a dwell time might be? My car has grey col packs and if i reference your 16bit ROM table with grey coil packs my values are much smaller.

2 dschultz:

DwellDef.JPG is not a good candidate to be InjectorDeadTime(ms) and IgnitionDwellTimeCorrection(ms).

They have exactly the same nature and should not depend on RPM.

But it may make sense if for some reason at low RPMs ignition coil break current is allowed to be greater.