Automatic program BLM's - Third Generation F-Body Message Boards

okfoz · 10-07-2009, 02:33 PM

I was wondering if there was anyone ever considered making a program to recalibrate the pulse width to adjust for the BLM.

More or less random thinking here, but I would not think it would be a stretch to take the BLM if it was above or below 128 at a particular point on the chart then have it automatically adjust the pulse width at that point in the chart, in real time. IIRC we do this manually now, why not let a computer do it for you?

It has been a while since I did any tuning, but for some reason it does not seem impossible, or is there just too much going on to really tackle this in that manner?

John

This ad is not displayed to registered members.
Register your free account today and become a member on ThirdGen!

mtwlkn122 · 10-07-2009, 06:37 PM

This is the kind of thinking that got us to the moon.

...i admire your thoughts.

RBob · 10-07-2009, 06:59 PM

There are several programs available to do this. VePhd, VeMaster and another come to mind. Can't recall the name of the 'other' one. Then WinALDL does it for the 160 baud ECMs. Which the '165 will do.

RBob.

okfoz · 10-08-2009, 09:50 AM

I just do not see it as being impossible, I have never done any IO programming so it is really alien to me.

John

RednGold86Z · 10-08-2009, 10:07 AM

Do you mean Inside the ECU, or just in the windows calibration editor?

Inside the ECU is darn near impossible, other than adding say a 3rd layer of closed loop = INT, BLM, and next layer that is the BLM of the BLM (but what's the point). The software/hardware doesn't have the ability to permanently change its own calibration.

Doing this in a windows editor is easy, as stated above (several programs available). It would probably take <30 minutes to make an Excel program to read a log file, make a pivot table of the BLM + INT vs RPM and MAP (rounded to 500 RPM, and 10 kPa), apply it to the VE, copy paste done.

For MAF systems, it's probably better to calculate a multiplicative error, and an offset, and apply that to the MAF tables. BLM is based on LV8 in $6E, which is quite similar to a MAP value, not MAF, but there's no way to apply a 3D BLM table to a 2D MAF curve. Again, a pivot table of the logs in Excel would quickly solve the problem.

okfoz · 10-08-2009, 10:27 AM

I would think that inside the ECM would be impossible as well... I think some ECU's (ECM) or PCM's do this on a small scale. I was thinking about on a PC, and have it do it real time, and have it do the base line tuning for you.

I will have to check out those programs above.

John

okfoz · 10-08-2009, 12:33 PM

Ultimately I think the biggest obstacle would be taming the program. Since you have two computers working against each other it may end up that they would be caught in a loop, where your PC would adjust a point, one time in the positive, the next time it would adjust to the negative because of the constantly changing BLM's. I am not sure if it would be better to have it realtime adjust in Closed or open loop either. Maybe both have it do it in both or either. I do recall that it is almost impossible to actually get the desired 128 at every point... Close is close enough IIRC...

I would think that small increments would be ideal.

As I thought about this, it would be really great for those who would use it for drag racing. Consider this, I have owned cars that ran great when it was arid, and horrible when it was really humid. I know that there are some performance changes for altitude, humidity etc, the more I think about this, it has more and more merit. Or I am completely crazy...

John

RBob · 10-08-2009, 02:32 PM

I missed the 'real time' part in your original post.

The EBL Classic when used with an emulator can do real time learning. Although it isn't instantaneous. In conjunction with the WUD it will learn for a while (time is user settable) and then update the emulator.

So you can drive around and every 1 to 5 minutes or more have the VE tables updated. This can be done via the BLMs in closed loop. Or with a WB via the WB reported AFR in open loop.

Now, for those that like to write assembly, the '7727/'7730/'7749 all have a location on the PCB for a SRAM chip. 2KB IIRC. The code can use this space for a live real time VE table. The ECM can learn the VE table as you drive.

Note that at key-off this SRAM data is lost. So you need to down load it prior to key-off if you want to save it.

There is a member here on TGO that did this many years ago. I don't want to name him as I don't want to be responsible for the many PM's he will get regarding this modification. However, he is free to post if he wishes.

And back to an emulator. Anyone with some C skill could write something for a laptop that would do the same as the EBL Classic.

Although I will state that I don't like real time WOT learning via a WB. Too many opportunities for a melt down. And yes, people have melted engines attempting this.

RBob.

okfoz · 10-08-2009, 02:45 PM

That was one of my fears, you would have to keep a close eye on things, and adjustments would have to be minimal.

John

anesthes · 10-09-2009, 09:22 AM

Quote:

Originally Posted by RBob

Now, for those that like to write assembly, the '7727/'7730/'7749 all have a location on the PCB for a SRAM chip. 2KB IIRC. The code can use this space for a live real time VE table. The ECM can learn the VE table as you drive.

Note that at key-off this SRAM data is lost. So you need to down load it prior to key-off if you want to save it.

I've noticed that if you watch with datamaster, the $58 and $8D code will "learn" the correction for the VE cells. This seems to store key off, and it basis everything off those corrections.

I don't see why a code patch couldn't allow dumping of those corrections via ALDL into something like tunerpro.

-- Joe

JP86SS · 10-09-2009, 11:55 AM

As in $8D, Memory locations L001B to L002A are BLM cells.
There are only 16 correction cells for the entire VE range.
The integrator value is not stored.
The correction numbers can be dumped out using one of the alternate modes on the ALDL lines. Some poeple have done this and the mode is already in the code, just need to change the addresses in the bin at that part of the code to get the locations to be dumped out instead of the standard Mode 1 datastream.

Code:

 ***********************************
                           * MODE 2 SELECTABLE MEMORY DUMP
                           *
                           * ALDL DEV MUST REQUEST MODE 2 BY
                           * XMITING THE FOLLOWING MSG TO
                           * THE ECM:
                           *
                           * DEVICE ID = 0xF4
                           * MSG LEN 3+85 = 0x58
                           * MODE = 0x02
                           * START ADD MSB = 0xaa
                           * START ADD LSB = 0xaa
                           * CKSUM = 0xnn
                           *
                           * THE ECM WILL RESPOND WITH:
                           *
                           * DEVICE ID = 0xF4
                           * MSG LEN 65+85 = 0x96
                           * MODE = 0x03              (Shouldn't that be $02)
                           * ADD CONT = 0xdd
                           * ADD CONT = 0xdd
                           * .
                           * .
                           * ADD (+63)CONT = 0xdd
                           * ADD (+63) CONT = 0xdd
                           * CKSUM = 0x29
                           *
;        ***********************************

I haven't tried it but it should work easily.
Again, this is only the 16 "blocks" of correction based on the RPM and MAP breakpoints defined in the bin.

IMHO, I don't think its really needed to have that kind of automatic control. Since I've never had the luxury of such an automated correction, I don't really know the issues with it. The BLM IS that system for me although I don't tune allot of cars, it serves its purpose.
A data log dumped out of TP V5 can give you error correction on a spreadsheet type display for each of the VE table cells. (New features are nice) That can be copied into a spreadsheet easily.
A quick paste/copy and your closer than you were on the last drive and nothing can really lean you out without you knowing what was done.
The 16 block corrections are better translated to table correction use.
And that is all it is is translated, its not an individual cell correction.
You still have to tune the WOT yourself but I kind of like it that way.
It would be nice to have WB control but the risks for me are pretty high at that point so I don't know if I would chance it without a good backup plan.