Thanks Steveo! I'll give this a go this evening after work. Looks interesting and will be very useful for sure.
Thanks Steveo! I'll give this a go this evening after work. Looks interesting and will be very useful for sure.
do it! i need testers!Thanks Steveo! I'll give this a go this evening after work. Looks interesting and will be very useful for sure.
if you give useful feedback i'll put you in the credits.
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?
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.
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.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 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?The solution is to add clear blm + froze blm command and then set AFR target.
Tunerpro defenitely is not the right tool for mode 4 control.
It is such a pain to use it.
I got very happy when I saw you`re working on this new software.
Here is the commands you may be interested in
SET BLM to 128
20 00 00 00 00 00 00 00 00 00 00 00
It is used once
If you want to run it again send
00 00 00 00 00 00 00 00 00 00 00 00
and then
20 00 00 00 00 00 00 00 00 00 00 00
Forced open loop use this
00 00 00 40 00 00 00 00 00 00 00 00
Forced closed loop
00 00 00 40 40 00 00 00 00 00 00 00
BLM update (LEARN) disable
00 00 00 20 00 00 00 00 00 00 00 00
BLM UPDATE (LEARN) FORCED ENABLE
00 00 00 20 20 00 00 00 00 00 00 00
I think BLM enable was labelled wrong as open loop so you can check what you have on file
Anyway these are the correct settings
see new version:
0.6b:
Make welcome warning a bit more friendly
Optional hack-keep-alive packet at interval
Enable AFR override after some fixes, thanks kur4o!
Added a settings window, we'll need one
Add two timing skew range modes (for bumpy roads)
Hover over BLM cell for a reminder chart
Bookmarks