944 Turbo DIY TunerPro Chips

[whalenlg]

Hi Folks - my side project building a software simulator for the DME system is showing signs of life - I'm able to load a bin file and run the code, observing the main outputs (injectors, ignition, ICV, dme relay, tach), but what I don't have is a set of input conditions that are valid.

So - if any of you have static (single datapoint) or log data showing the following for a well running 1986 or 1989 turbo, it will help validate the simulator results:
RPM
AFM (2 sensors - DME pin 7 and DME pin 22)
Batt_Voltage
AFM_NTC temp
Coolant_NTC temp
ADC_Data_Field
ADC_Ch5
TPS
FQS
AFR

Thanks!
Mike

Not sure what you mean by single datapoint? What would that mean with respect to the RPM input for example?

By single data point I mean a snapshot in time of these input values. Ie at 3000 rpm the timing data showed this info - afr, afm, batt volt, etc - kind of like what shows up on the f9tech screen

[Tom]

Hi Folks - my side project building a software simulator for the DME system is showing signs of life - I'm able to load a bin file and run the code, observing the main outputs (injectors, ignition, ICV, dme relay, tach), but what I don't have is a set of input conditions that are valid.

So - if any of you have static (single datapoint) or log data showing the following for a well running 1986 or 1989 turbo, it will help validate the simulator results:
RPM
AFM (2 sensors - DME pin 7 and DME pin 22)
Batt_Voltage
AFM_NTC temp
Coolant_NTC temp
ADC_Data_Field
ADC_Ch5
TPS
FQS
AFR

Thanks!
Mike

Not sure what you mean by single datapoint? What would that mean with respect to the RPM input for example?

By single data point I mean a snapshot in time of these input values. Ie at 3000 rpm the timing data showed this info - afr, afm, batt volt, etc - kind of like what shows up on the f9tech screen

Ah, I see. I have the ftech so can do a log for you. If you are looking for anything in particular just let me know.

[whalenlg]

Corrected list:
RPM
AFM (2 sensors - DME pin 7 and DME pin 22)
Batt_Voltage
AFM_NTC temp
Coolant_NTC temp
Altitude correction
TPS
FQS
AFR

[whalenlg]

Ah, I see. I have the ftech so can do a log for you. If you are looking for anything in particular just let me know.

Yes - everything on the FTECH data grid page is even better!

[whalenlg]

This map is stored at 1140. It's actually 2 maps (split in half).

These maps modulate the fuel pulse (the value on the vertical scale is a multiplier, so a value of 1 does nothing).

I don't see any reads from 1140 in my 8 sec simulation. I also don't see it in any XDF that I have (it does show up in OpenDME info I downloaded, but nothing else).
Any clues as to which addresses might be read from the table?

[johnb]

This map is stored at 1140. It's actually 2 maps (split in half).

These maps modulate the fuel pulse (the value on the vertical scale is a multiplier, so a value of 1 does nothing).

I don't see any reads from 1140 in my 8 sec simulation. I also don't see it in any XDF that I have (it does show up in OpenDME info I downloaded, but nothing else).
Any clues as to which addresses might be read from the table?

Yeah it's because its not looked up like the normal maps, it's read directly from the constants section. The read happens at 0190. If the flag 21h.6 is not set, then 16 is added to the index which effectively selects the second of the 2 maps. The value looked up is multiplied by the fuel pulse value via the 8x16 routine called at 01A4.

The map lookup index 4Dh gets incremented every ignition cycle. Of course, fuel is injected on every rotation, which means that each fuel pulse is only half of the fuel required for combustion - that's why I had to do some processing with the raw map values to create that graph showing its actual effect on the fueling.

[Tom]

This map is stored at 1140. It's actually 2 maps (split in half).

These maps modulate the fuel pulse (the value on the vertical scale is a multiplier, so a value of 1 does nothing).

I don't see any reads from 1140 in my 8 sec simulation. I also don't see it in any XDF that I have (it does show up in OpenDME info I downloaded, but nothing else).
Any clues as to which addresses might be read from the table?

Yeah it's because its not looked up like the normal maps, it's read directly from the constants section. The read happens at 0190. If the flag 21h.6 is not set, then 16 is added to the index which effectively selects the second of the 2 maps. The value looked up is multiplied by the fuel pulse value via the 8x16 routine called at 01A4.

The map lookup index 4Dh gets incremented every ignition cycle. Of course, fuel is injected on every rotation, which means that each fuel pulse is only half of the fuel required for combustion - that's why I had to do some processing with the raw map values to create that graph showing its actual effect on the fueling.

I wonder if it's just hard-coded transient modifier to smooth the transitions back to fuel -- to avoid harsh rich and lean conditions, jerking, backfires, etc. The batch fire injection probably makes these transitions even harder, since there's no way to fuel the first bang of all 4 cylinders correctly. Anything similar for spark? @Dave W. might recognize the strategy...

[johnb]

I don't see any reads from 1140 in my 8 sec simulation. I also don't see it in any XDF that I have (it does show up in OpenDME info I downloaded, but nothing else).
Any clues as to which addresses might be read from the table?

Yeah it's because its not looked up like the normal maps, it's read directly from the constants section. The read happens at 0190. If the flag 21h.6 is not set, then 16 is added to the index which effectively selects the second of the 2 maps. The value looked up is multiplied by the fuel pulse value via the 8x16 routine called at 01A4.

The map lookup index 4Dh gets incremented every ignition cycle. Of course, fuel is injected on every rotation, which means that each fuel pulse is only half of the fuel required for combustion - that's why I had to do some processing with the raw map values to create that graph showing its actual effect on the fueling.

I wonder if it's just hard-coded transient modifier to smooth the transitions back to fuel -- to avoid harsh rich and lean conditions, jerking, backfires, etc. The batch fire injection probably makes these transitions even harder, since there's no way to fuel the first bang of all 4 cylinders correctly. Anything similar for spark? @Dave W. might recognize the strategy...

Actually there is some complicated stuff happening with the spark timing too. I only skimmed that part a while back but if I remember correctly, when you lift it gradually reduces the timing first, and then cuts fuel when the timing gets to some minimum. Also the way that the index of that 1140 map is controlled is tied into spark timing in some complicated way that I haven't untangled yet. So yeah it might be just one of those "mess around with it until it feels right" things.

Researching this stuff, I learned that there's some very subtle stuff that goes on with fueling in transient conditions. In steady state operation, some fuel always pools in the intake and so the actual fuel draw into each cylinder comes partly from the injectors and partly from the pool. When you accelerate, the DME can only increase the injector portion instantly, and in fact the portion that comes from the pool actually reduces (because of the increase in manifold pressure). That would make the cylinder go lean briefly. The funny thing is that the US fuel maps don't compensate for this, except during warm up. Once the car is warm, this acceleration compensation only comes from the overshoot of the AFM vane. I'm sure there are tons of other weird transient things that just have to be tuned away.

[whalenlg]

This map is stored at 1140. It's actually 2 maps (split in half).

These maps modulate the fuel pulse (the value on the vertical scale is a multiplier, so a value of 1 does nothing).

I don't see any reads from 1140 in my 8 sec simulation. I also don't see it in any XDF that I have (it does show up in OpenDME info I downloaded, but nothing else).
Any clues as to which addresses might be read from the table?

Yeah it's because its not looked up like the normal maps, it's read directly from the constants section. The read happens at 0190. If the flag 21h.6 is not set, then 16 is added to the index which effectively selects the second of the 2 maps. The value looked up is multiplied by the fuel pulse value via the 8x16 routine called at 01A4.

The map lookup index 4Dh gets incremented every ignition cycle. Of course, fuel is injected on every rotation, which means that each fuel pulse is only half of the fuel required for combustion - that's why I had to do some processing with the raw map values to create that graph showing its actual effect on the fueling.

Thanks for the clues….

[whalenlg]

My most recent simulation ramps from idle to 6500rpm over 8 seconds and that section of code isn't touched.

Then again - that scenario of off the throttle isn't exercised and I'm currently not making and dynamic TPS ramps or AFM inputs, so still a ways to go to mimic valid inputs.

Here's the log info from that area of the simulation starting at PC: 0177 - you can see it jumps past 190:


label376 4529873 PC: 0177 jb 1Ah, label31 OPCODE:20 1a 41 0x23.2 [0x1a], 0x01b count: 1
Read1 4529874 PC: 0177 Addr:001a Data:00 RPMBelow160
4529875 PC: 017a jnb 0Dh, label35 OPCODE:30 0d 2d 0x21.5 [0x0d], 0x01a count: 1
Read1 4529877 PC: 017a Addr:000d Data:00 UseMap1140
4529878 PC: 017d mov A, 4Dh OPCODE:e5 4d A, 0x4d count: 2
Read8 4529880 PC: 017d Addr:0018 Data:00 lmbdadj_unchanged
label35 4529881 PC: 01aa jnb 0Fh, label31 OPCODE:30 0f 0e 0x21.7 [0x0f], 0x01b count: 1
Read1 4529881 PC: 01aa Addr:000f Data:00 AccelEnrich
4529882 PC: 01ad clr 0Fh OPCODE:c2 0f 0x21.7 [0x0f] count: 1
Read1 4529884 PC: 01ad Addr:000f Data:00 AccelEnrich
4529885 PC: 01af mov B, #40h OPCODE:75 f0 40 0xf0, #0x40 count: 2
Write1 4529885 PC: 01af Addr:000f Data:00 AccelEnrich
Read8 4529885 PC: 01af Addr:001d Data:88 bank3_R5