If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

new $EE tuning thing!

beta version of my new tool, should work on most computers.

This simple program is a work in progress designed to aid tuning and diagnosing $EE based vehicles.

Features:

Non-destructive real-time parameter testing!
Add/subtract ignition timing in real-time while driving!
Disable individual cylinders by cutting their injectors
Automated cylinder strength test (not done yet)
Change idle target speed
Force air fuel ratio in open loop (not done yet)
Trimmed down heads-up display organized for tuning
Diverse data analysis (not done yet)
Many of these features are possible due to a special GM diagnostic routine. This is totally non-destructive, and all changes are lost when the program is closed or the car is restarted.

It's currently a work in progress, and in early beta stages, with most key features disabled. Testing is required. If you'd like to help test it, please provide feedback.

If you want to clear all the effects just send full command with zeroes.
I just saw the panic button which is what is doing I guess.
The programm is great.
Actually i have some ideas for things that it needs to do.
I hope you accept customs requests.

I have tested previously the AFR command and it works very well. Sets custom AFR and also when its set it goes to something like semi open loop.
The problem is blm are still active where they are and still triming.
The solution is to add clear blm + froze blm command and then set AFR target.

I have tested previously the AFR command and it works very well. Sets custom AFR and also when its set it goes to something like semi open loop.
The problem is blm are still active where they are and still triming.
The solution is to add clear blm + froze blm command and then set AFR target.

good to know! my car actually doesn't run closed loop, so I wouldn't have noticed that until others tested. I'll throw that in. so i guess it stops updating BLM (obviously) but the open loop AFR is trimmed by the existing cell.

If you want to clear all the effects just send full command with zeroes.
I just saw the panic button which is what is doing I guess.

yeah, and sends several times, just to be safe. when closing the program it hits the panic button in the background too.

one giant reliability problem is there's no sane reply to the mode4 command; you are never 100% sure it succeeded. i've thought about sending it twice just to be safe, or re-sending at interval as a keep-alive.

The programm is great.

i'm only partially happy with it right now, but couldn't have done it without ya! thanks for your help

Actually i have some ideas for things that it needs to do.
I hope you accept customs requests.

requests are welcome for sure! see latest version 0.5, i am adding/fixing stuff daily right now. my site now has a changelog.

this is just a hobby project so i'll add things slowly. right now the code is a bit shoddy in terms of how adaptable the event loop is, im going to have to clean it up before adding any substantial new features. this program is non-blocking single-threaded just because QT's serial driver seems to barf its guts out if you even look at it sideways.

i want to keep this fairly noob-friendly, it's designed for someone reasonably experienced with tuning but not experienced with hacking or datastreams.

im currently experimenting with Mode 3 requests, and making a new tab for extended parameters that are pulled right from memory. these will be fetched interleaved with regular requests at a controlled rate, so regular datalogging still happens (but slower as you enable more extended parameters).

also plan to integrate my prototype flash tool and test it (once i get some sockets in my spare ECM...). the analyzer will be really nice too, when it's done, as I already have a very useful analyzer written, i just have to port it.

neat, basically a full mode4 controller. I've played with those commands quite a bit for my applications, I do believe some code expects them to keep being sent for keep-alive purposes... in any case it wouldn't hurt to send them once a second, but that obviously wouldn't be necessary for the Reset BLM bit or anything else along those lines.

That looks very promising. In $ee mask there is some timer settings for some of the mode 4 parameters but they are disabled by default in most of the bins i checked.
It will be one time set until cleared for most of them.
Recently I have been working on patch to enable Eside aldl stream in mode 1. I also enabled mode 2 and mode 3 request from eside.
Patch is done and tested and will be released soon.
You will be very happy with mode 2 for extended memory coverage.
It dumps 64 bytes of memory from the address you specify.
Command is the same as mode 3. Just replace 03 with 02.

I will make request list for the features that will aid in tuning.
I`ve been thinking for poping window that have 5-6 parameters(which are also configurable from a list) to modify. Enter the data and send all the parameters in one string.
One limitation of mode 4 is that when you send new single command for example set AFR, all previously set commands are zeroed.
So all the modification must be contained in one single thread or every next parameter must be added to the existing command thread.

having things setup for mode 3 like that, you're essentially working with an OBD2 style PID request string, which has its significant overhead drawbacks. sending a request for 6 bytes is going to take something like 16 bytes sent, then receiving 10.

I don't remember how much free PROM area there is, but I'm sure there is probably a huge portion of the 6811's internal EEPROM left open... perhaps modifying the mode 1 command code to reference a table in the EEPROM(which is able to be changed without a full flash) which could send out smaller(than mode1), predefined packets, which could remove something like 11 of the sent bytes for a packet request. could either keep those bytes off and have a lean response packet or use the now-freed space to throw in a few more values?

One limitation of mode 4 is that when you send new single command for example set AFR, all previously set commands are zeroed.
So all the modification must be contained in one single thread or every next parameter must be added to the existing command thread.

only a limitiation when working in something like tunerpro that is merely designed to transmit a byte array and not construct one. i just have a byte array[] and modify it as i go, transmitting the entire thing when changed.

having things setup for mode 3 like that, you're essentially working with an OBD2 style PID request string, which has its significant overhead drawbacks. sending a request for 6 bytes is going to take something like 16 bytes sent, then receiving 10.

totally. 8192 baud isn't a lot of bandwidth. any 'extended parameters' as i call them will have their own checkbox to enable them, the idea being you only view them when needed, then disable them.

The solution is to add clear blm + froze blm command and then set AFR target.

i got freeze BLM working, but i can't make it reset the BLM. maybe i've noted the wrong byte. do you happen to know the mode4 command for that?