new $EE tuning thing!

[steveo]

if you run open loop, will it still get closed loop timming?

if you have stored long term trims and switch to open loop, in some conditions they're used

[ony]

I haven't got the newer ecm or pcm but the 288 has a table for when it restarts in open loop for added or subtracted timming

[kur4o]

I went through the disassembly to clear some of the closed loop configuration stuff.

Here is what I found out so far.

There is a switch that enables the usage of the first cell of the following tables 26F1,26F6,26FB,2700,2705,270C.
It is used at low TPS<8 low MPH<18.
The thresholds are located at 26e6=tps, 26e7=mph.
So at low speed low tps,and low mph conditions and at idle the first cell of the tables is used for closed loop configuration.

Here is short descriptions of the tables
26f1,26f6= Left, right 02 swing voltage
26fb=Integral Delay
270c=Corrcl adder to INT
2700,2705= 02 smooth out table LR.[It smooths out rapid changing values of 02s. Example if value change from 300 to 600 this table
smooth the change from 300->350->400->450->500->600. Higher value of the table leads to slower transition.]
and two more tables these are multipliers.
2711=Corrcl adder multiplier vs how far from swing voltage, 02s are
271d=Int delay multiplier vs how far from swing voltage, 02s are.

And here is some more
CORRCL left calculations

270c - =byte_191 vs airflow
2711 - =byte_192 vs byte_199*2 [byte_199 = 17f/smoothed 02s/ - 18d/swing voltage/]
byte_186=CORRCL add or sub to int
byte_186=[byte_192*byte_191] result a [stock =1 or 2 ]

INT L calculations

26fb -=byte_194 INT delay vs airflow
271d -=byte_195 vs byte_199*2[199=17f/smoothed o2s/ - 18d/swing voltage/]
byte_198=[195*194] result a stock[$20 to $3f] cpu cycles . When timer expires INT is updated by 1.

So what is the best strategy to tune this out.
Why mixture is always leaned and never enriched?

Utmost importance will be individual cylinder trims and the smooth out 02s table

[kur4o]

I am thinking to add support for real time tuning of most of the closed loop parameters.

mode 4 message slots are 99% full so I will need to come up with something like extending the mode 4 message.

Steveo,
will it be possible instead of 12 bytes eehack to send 14 or 16 bytes message. How hard will be to achieve that.

[steveo]

I am thinking to add support for real time tuning of most of the closed loop parameters.

mode 4 message slots are 99% full so I will need to come up with something like extending the mode 4 message.

Steveo,
will it be possible instead of 12 bytes eehack to send 14 or 16 bytes message. How hard will be to achieve that.

not too hard. i should have made a #define for the mode 4 message length, but i never thought it would change. lets make it a define.

in config.h, add a line:

#define M4_LENGTH 12

in datastream.h:

byte construct_mode4[M4_LENGTH + 4]; // mode4 buffer

then in mode4.cpp:

void datastream_control::m4_comm_init() {
...
for(x=3;x<M4_LENGTH + 4;x++) construct_mode4[x] = 0x00;

QString datastream_control::m4_getpkt() {
...
t.setRawData((char *)construct_mode4 +3,M4_LENGTH);

bool datastream_control::m4_get_request(byte *buf) {
...
for(int x=0;x<M4_LENGTH + 4;x++) buf[x] = construct_mode4[x];

void datastream_control::m4_get_raw(byte *buf) {
...
for(int x=0;x<M4_LENGTH + 4;x++) buf[x] = construct_mode4[x];

void datastream_control::m4_set_raw(byte *buf) {
...
for(int x=0;x<M4_LENGTH + 4;x++) construct_mode4[x] = buf[x];

then in datastream.cpp:

bool datastream::m4_send_if_requested() {
  if(control->m4_get_request(buf_out) == true) {
    return aldl_request_reply_length(M4_LENGTH + 4,4);
  } else {
    return true;
  }
}

bool datastream::m4_send_force() {
  control->m4_get_raw(buf_out);
  return aldl_request_reply_length(M4_LENGTH + 4,4,100);
}

i'm pretty sure that covers it, now you can change M4_LENGTH in config.h and recompile for a different length of mode 4 message

if i missed something i'm sure it'll crash and you'll figure it out ...

(edit: fixed bug)

[steveo]

oh there is a UI field for displaying the mode 4 raw string too, but i doubt it'll cause trouble.

of course after you test all this, you could carefully make length changes at runtime if you used a variable everywhere that we just used that #define, based on presence of your patch, if you care

[kur4o]

Great I will test it in a couple of days.

How about keeping the 12 byte message and extend it only if needed. For example, when the new CL parameters are commanded on in M4 window.

The pcm don`t care how long the message is. So we can use variable lenght message and make a switch to load the extra bytes when needed.

I have to delay some of the patch development due to lack of time and pcm to test. Hope I can get the PCM soon and do some testing.