new $EE tuning thing!

[kur4o]

I`ve been thinking to make complete mode 4 patch for eside.
With very expanded capabilities.
It will have it`s own mode 4 command in the same format as tside. It can be even longer than 12 bytes.
The big question is
Will it be possible for you to integrate the features of the patch in the eehack program, because without good quality command interface it will be useless.
I might also add some streaming data from eside.

[steveo]

Will it be possible for you to integrate the features of the patch in the eehack program, because without good quality command interface it will be useless.

absolutely. it fits all my design criteria for a patch, including not breaking other tools, or affecting engine operation unless commanded by eehack.

i've researched such a patch myself.. really, setting up the mode4 stuff itself is no big deal, but inserting commands into it is something else. you need to test for a status bit in the routine for what you're trying to modify, then override it. finding the space to do that can be tricky for sure.

but that's the reason i built eehack with passive patches and versions and all that junk, if we have to relocate a routine or a table to make more room, we can do it transparently at flash time without breaking external tools and XDFs.

the thing is, what exactly is on the e-side that you'd want to control?

i don't see much useful going on over there for realtime tuning, except maybe the o2 variables such as integrator delay and o2 swing voltage would be slightly useful

[steveo]

I might also add some streaming data from eside.

one thing eehack isn't built very well for is adding more arbitrary datastreams in a way that allows logging/graphing/whatever. i didn't build a good api for managing that stuff like i've done in other software, that stuff is all hard-coded. i could change that but i'd need a good reason (i.e. some really useful data) to go through all the effort.

[kur4o]

Great, now it`s time to get coding.

For the datastream I can use the same format.The only difference will be the f4 to e4[mapping most used stuff at the same locations, map,maf bpw,temp] . We can get alot of tuner usefull info from eside.
Detail information on Maf and Ve lookup, for example maf frequency, different maf adders, the same applies to VE calc. Base BPW without corr and after BLM correction. Total correction applied to BPW at closed loop.
I have a map of all spark adders and retarders that can be used to see how spark advance is formed. Different knock retard components.
Quality of optispark signal, Numerous switches and so on.

For eside mode4 the list is long.
Some of things I consider are delta afr corr, Delta Maf freq Adder, Delta ve result adder, Knock retard manipulation, Full disable or Max value setup
delta BLM corr. The list will be long, These are some of the features I`ve been thinking. Of course open to ideas.
Switching of preconfigured tables , loaded via mode 5, or hardcoded.
The hardest part will be selecting what is needed. With so much space you can preconfigure 5,6 spark tables And operate them with mode4 or external switch.
Adding extra 2d or 3d tables that don`t exist, but will be very usefull.

[steveo]

With so much space you can preconfigure 5,6 spark tables And operate them with mode4 or external switch.

but isn't spark on the t-side? i think it's pretty packed over there

look forward to seeing what you come up with!

the most commonly requested feature i have for eehack is modifying the individual cylinder trims in real-time. that'd only eat 8 bytes of ram for the table, but it's on the t-side. maybe we can figure out a smart way to do it.

[Terminal_Crazy]

I've always wanted a switchable lower rev limiter in case someone else drives my car. Is that possible to do ?Just to let you guys know I do follow these threads with extreme interest. Keep up the good work.Mitch (England).

[fbody_Brian]

last two flashes I've gotten this message:
Attachment 10134
Guess I'll uncheck compression and try. Just started happening though, which is weird.
Great thing is that it hasn't bricked my PCM despite the error.

[steveo]

last two flashes I've gotten this message:

that error does usually mean that a write error occurred - which usually isnt a problem writing to the chip, more like the ecm didn't like the data or its checksum, or perhaps it was transmitted too quickly? could be a very slight serial error, like a dirty contact in your aldl port or some interference.

i think other flash tools just continue silently after retrying until the write succeeds...

i'll explain the error handling a bit for cases where a particular chunk of data wont flash.

what eehack does in the event that a non-standard message is returned during a write operation (i.e. ANY error) is go "oh f#@k! if that keeps happening, something will break!" so it goes into kind of a safe mode.

that 'safe mode' is like unchecking the following boxes, compression, large block size, and fast comms. without fast comms checked, it waits a minimum of 80 milliseconds between transmitting data (which is a hell of a long time in the scheme of things, with fast comms checked, it's 20 milliseconds).. that's just in case they were the cause of the problem or whatever, at least they're out of the way now.

this safe mode is permanent until the entire flash operation is complete.

if write errors occur MORE THAN ONCE IN A ROW and FLASH_WRITE_MAX_RETRIES is exceeded (which 5 in the default build but is easily increased at compile time) eehack assumes it's a hardware problem or something is haywire, and says ok.. this wont work.. lets go back and erase that eeprom again and start over.

it's possible you're having problems with timing in 'fast comms' mode, which is fairly new and not as well tested as it should be. i'd try unchecking it. it's not related to "compression", trust me on that one.. the only reason i disable that is because if there's a bug in the algorithm that selects packet size or whatever, at least it has a way to bail out.

the flash ERASE routine has a similar failsafe mode, but with one caveat, since we don't know exactly how long a flash erase takes, it can take up to two minutes if a flash erase fails before it goes back to try again.. obviously failing during an erase is a very bad situation since you now have a blank chip. i wanted it to be really long just to be sure that it's not still erasing, and that it's actually returned to the main diagnostic mode so we can upload the erase routine again. this is not a bad thing but you might kind of have a panic attack while you're waiting, thinking eehack is frozen... but really, don't close it, just wait.

[steveo]

I've always wanted a switchable lower rev limiter in case someone else drives my car. Is that possible to do ?Just to let you guys know I do follow these threads with extreme interest. Keep up the good work.Mitch (England).

totally can have a valet mode. in fact since you already have two rev limiter settings, there's 1st gear and other. just need to hack it so instead of using park/neutral to select them, you look at some other status bit. i'll look at the code a bit later but kur4o might understand it a bit better than me.

[fbody_Brian]

it's possible you're having problems with timing in 'fast comms' mode, which is fairly new and not as well tested as it should be. i'd try unchecking it. it's not related to "compression", trust me on that one.. the only reason i disable that is because if there's a bug in the algorithm that selects packet size or whatever, at least it has a way to bail out.

Disabled fast comms and did not get the error. I'll turn it back on next time and see if it returns.

[steveo]

could you tell me your computer specs etc?

[fbody_Brian]

could you tell me your computer specs etc?

Compaq CQ56 somewhat older laptop, dual boot win7 and openSuSE

cpu: Intel(R) Celeron(R) CPU 900 @ 2.20GHz, 2194 MHz

cat /etc/os-release
NAME=openSUSE
VERSION="Tumbleweed"
VERSION_ID="20160111"
PRETTY_NAME="openSUSE Tumbleweed (20160111) (x86_64)"
ID=opensuse
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:opensuse:20160111"
BUG_REPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://www.opensuse.org/"
ID_LIKE="suse"

Believe I'm using the same usb ftdi interface as you
soldered it to an odb1 connector

I'll try it in both windows and linux to see if the fast comms issue remains.

[steveo]

linux timers certainly are a bit different so there might be some variance. if you're willing to experiment, you can change these post delays, they only affect data transmit. in flash_routine.cpp @ line 40:

  // get timing
  int write_post_delay = 70;
  if(ui->flash_fastcomms->isChecked() == true) {
    write_post_delay = 20;
  }

maybe try 30 or something. i would happily make it the new default if it's not crazy high, or i could make linux builds specifically use a higher delay.

no matter what you set here, if an error occurs, it's bumped up to 80 further down.

[kur4o]

Cylinder trims and spark are all on eside.
The only engine related work for tside is blm trims and the result is send to eside by 2 bytes, and they trim the bpw.
Cylinder trims will be easy to do, but it will need eside mode4 control for sure.
That will be good choice for the first version to try.
Do you want it to trim all at once or single mode only.

We need to find some free ram also.
Can you make continuos scan of memory region 0245 to 2ff and 188a til 18ff via mode2 on runnnig engine. I suspect this region as not used, but it needs to be confirmed on running engine.

I've always wanted a switchable lower rev limiter in case someone else drives my car. Is that possible to do ?Just to let you guys know I do follow these threads with extreme interest. Keep up the good work.Mitch (England).

Alot of external switches can be added, much easier will be to use existing ones, If you don`t use performance switch, a vallet mode can be patch using the existing wires. You need to tell me how would like the vallet mode to work. And provide your bin so I can add the changes.

[fbody_Brian]

linux timers certainly are a bit different so there might be some variance. if you're willing to experiment, you can change these post delays, they only affect data transmit. in flash_routine.cpp @ line 40:

  // get timing
  int write_post_delay = 70;
  if(ui->flash_fastcomms->isChecked() == true) {
    write_post_delay = 20;
  }

maybe try 30 or something. i would happily make it the new default if it's not crazy high, or i could make linux builds specifically use a higher delay.

no matter what you set here, if an error occurs, it's bumped up to 80 further down.

I changed it to 25, no error. I'll change it back to 20 and confirm that it returns. I think that maybe 20 is right there on the edge.