Timing calculation on CA18

Vetal · Post by **Vetal** » Wed Jun 27, 2007 12:08 am

I was dicussing with Matt this subject.
What I do not understand is a) how it is calculated b) why it comes out some 6 degrees higher at medium load

Vetal · Post by **Vetal** » Wed Jun 27, 2007 4:30 am

Was looking at my yesterday logs and there are few strange things...
I have suspicion that
a) reported timing value is calculated on knock map, because when I change main ignition map, reported value doesn't seem to change (did one series of test though)
b) real timing is not affected by knock map, because when I changed knock map, I didn't see change in torque, but when I changed main map - I did.
I'll have to recheck this to be sure

GZ@hybridka · Post by **GZ@hybridka** » Wed Jun 27, 2007 11:35 am

You may want to modify the code's table pointers so that only one timing advance table is used. This will both solve this potential issue and make tuning easier as you will only have one functional table to deal with.

I like to do this with the fuel correction tables as well.

All that you need to do is find where the ignition tables are loaded into the timing advance routine and set the knock table address the same as the primary.

Only 2 bytes of code need to be modified, or 4 bytes if you want to do the fuel correction table as well.

GZ@hybridka · Post by **GZ@hybridka** » Wed Jun 27, 2007 11:47 am

Also, I forgot to mention.

There is probably a coolant temperature correction applied to final timing advance. What this will do is add or subtract from the timing advance value, after it has been picked from the table.

I have seen eccs code make use of 2 seperate 16 point coolant temp correction scales. One used as an addition table, for colder engine temperatures, and the other as a subtraction table for hotter engine temperatures.

The CA18 probably uses at least one, an addition table for colder engine temps.

This is applied globally to the timing advance value pulled from the table, so when analyzing your logs be sure to note coolant temperature and compensate in your analysis. You may already be aware of this, but if not ask Matt, he probably knows where this correction is applied (if this ecu uses it).

Matt · Post by **Matt** » Thu Jun 28, 2007 3:24 am

This was mentioned in the email about the other timing tables. I assume that there would be not much/any adjustment at 80 deg C from the logs that I have receive

I'll have to look for those tables and see if they appear to be in degrees

The latest software version released uses a new offset for tables

so my address file has this now for CA18
CONSULT_TIMING_OFFSET=16
IDLE_TIMING_MAP_OFFSET=16
TIMING_MAP_OFFSET=22

the timing offset applies to timing map, using 22 gets us back to 15 BDTC at around idle. seems to be agreed value

the decel/idle timing map pulls the translated graph view (when enabled in File-Configuration) down to 15 at idle ... this gradually increases

this ECU is a nightmare. the S12/S13 CA18 have different offsets applied to the maps. It also appears like there is some linkage between high/reg timing tables which I posted the assembly to in another section ...

The timing routine looks idential to the R32, so this is why I chose this memory address for display. there are several others which are used, but this seems to be the final one. On the RAM trace if you view in DEC and minus 16 from the values, you can see which ones are timing if you view 1000-10FF

The values I found for timing are 103D (displayed in NIStune) and also 110D, 1106 (which is saved into 1116)

For injection 004D/004E are used. These together form a 16 bit number which is then divided by 100 to get ms... same as Nissan consult calculation

GZ@hybridka · Post by **GZ@hybridka** » Thu Jun 28, 2007 8:08 am

Hey Matt,

I ran through some ca18 code finally, the ignition advance routine, kind of interesting.

It would seem to me that there is a 16 point table at 3B20 that is, at least at certain times, used for coolant based timing advance correction.

Also as far as I can tell the ecu only really uses the first ignition table at 3A00, at least for timing advance itself. The other it would seem is used to derive some sort of knock feedback value, 10C2? Its derived by subtracting first timing advance table value from the second.

LB073:
ldx X10C4
stx X0069
aim #$1FX007D
oim #$10X007D
ldx #$BA00 ;Load first ign table
stx X0074
ldx #$BBF0 ;Load Ign RPM scale
stx X0076
ldx #$BBE0 ;Load Ign TP scale
stx X0078
jsr ((16x16.Table.GenRoutine)) ;Jump to full table routine
psha ;Push A, first table ignition value
aim #$1FX007D
oim #$10X007D
ldx #$BC00 ;Load second ign table
stx X0074
ldx #$BBF0 ;Load Ign RPM scale
stx X0076
ldx #$BBE0 ;Load Ign TP scale
stx X0078
jsr ((16x16.Table.GenRoutine)) ;Jump to full table routine
pulb ;Pull B, first table ignition value
sba ;Subtract first/second ignition value, store in accumulator A
staa X10C2
tba ;Transfer accumulaors? B should be clear, else it still stores first ignition table value
staa X110D ;Clear? Or must be still be first ignition table value
ldab X0058
bitb #$40
beq LB0C0 ;Branch to finish normal advance
suba XB92D ;Subtract value
bcc LB0D4 ;Branch to finish as alternate advance #1
clra
bra LB0D4 ;Branch to finish as alternate advance #2 (0 degrees)
;
LB0C0:
ldab X1055
cmpb XBFD4
bcc LB0D4 ;Skip final correction and store 110D as timing
ldaa X105F ;Coolant temperature ram variable?
ldx #$BB20 ;16 point ignition advance correction scale
jsr ((16x1.Table.GenRoutine))
adda X110D ;Add degrees to 110D
LB0D4:
staa X103D ;Store final ignition advance
LB0D7:

GZ@hybridka · Post by **GZ@hybridka** » Thu Jun 28, 2007 8:13 am

It also appears like there is some linkage between high/reg timing tables which I posted the assembly to in another section ...

My mistake, I couldnt find this post. I am curious and would like to help pin it down if I can.

Matt · Post by **Matt** » Thu Jun 28, 2007 7:39 pm

the timing discussion was in the bugs section

you will see my version of disassembly here. yours is more accurate. as you say the second timing table is used in addition to the first table depending on knock (and temperature.. as you found) conditions

viewtopic.php?t=262

GZ@hybridka · Post by **GZ@hybridka** » Sat Jun 30, 2007 9:18 am

Perhaps it also may have something to do with the fact that the ignition tables use a different TP load axis variable? This would indicate that the fuel/ignition table plots are manipulated differently.

Fuel TP = 1013
Ign TP = 10C4

Matt · Post by **Matt** » Sun Jul 01, 2007 10:01 pm

are those linked together at all? i have to go over the disasembly again. but sometimes TP from one address is simply copied to another address. Seen that on a few ECUs

GZ@hybridka · Post by **GZ@hybridka** » Mon Jul 02, 2007 10:35 am

I have found only a very distant relation between the two within the code, they are far from being a couple cloned values. If I had to take a guess I would say it would be a rare occasion that these two variables are identical.

The ignition table TP has its own distinct final modification routine, and uses one of the potential derivatives of fuel table TP (Of which I see 6 or more so far). I can send you some lightly deciphered code if you would like.

They may perform in similar fashion during most conditions, someone would have to stream and compare the two ram bytes.

A quick fix would be to decide on a good TP load variable and set both table routines to use the same.

Matt · Post by **Matt** » Mon Jul 02, 2007 1:19 pm

i have a standard consult table in NIStune for the Type 1 board. The last two bytes 0x26,0x27 I use for the TP MSB/LSB.

Might have to add a special case for CA18 for the Ign TP in a separate area and 'hack' it into the NIStune to use that. In the I'll have a look at the RAM trace window and see what the values are

GZ@hybridka · Post by **GZ@hybridka** » Mon Jul 02, 2007 4:39 pm

Rom byte &HB92D/&H392D appears to be knock retard amount, is this a known location?

I keep posting in this thread because it seems appropriate, but perhaps it should be moved to bugs or 6303 section?

Matt · Post by **Matt** » Tue Jul 03, 2007 2:55 pm

no it isn't something we have used before. you must be looking a fair bit into this code!

GZ@hybridka · Post by **GZ@hybridka** » Tue Jul 03, 2007 3:10 pm

It is much easier code to read than the ka24e in some ways, it seems condensed in comparison, more to the point.

ECCS 4cyl (6303 based)with native COP ignition, and good tools (Nistune).

Why not?

I wouldnt mind helping out with other popular systems as well, so long as they are not 16 bit