NefMoto

I am working on cars which are setup with 95 RON in mind but now are being run on 99 RON. We obviously play with ignition angles to make more power under load but what about cruise.

From what I understand the burn speed of 99 RON is slower than that of 95 RON. Now with the assumption the stock timing map is hitting MBT at part throttle regions of the map when on 95 RON running the car on 99 RON the power output will be the equivellent of retarding timing a few degrees.

My question is at low load and low RPM roughly how much timing is required to get back to MBT, finding these values on a chassis dyno isn't as easy as it is for the OEM with pressure monitors and an engine dyno. But the reason for this is surely getting back to MBT equals more output torque which means less throttle which means better fuel economy. Maybe only a few percent but some is better than none.

Does anyone have any information about the physics of this or any hard data or research about the burn rate differences of the fuels. I've seen some tuners go to the map and just across the board add 3 degrees or 5 degrees. I've seen others take more complex approaches but I'd like to understand the best way to work this.

Obviously this all assumings no knock but tuning off the knock sensor or det cans isn't possible when no knock is present and going past MBT will ultimately lower torque again and then lower fuel economy.

The way I've done this is chassis dyno with detcans and instantaneous torque readout.
Yes, it will never be as good as using pressure senders on an engine dyno, but you can get very close.
At some point the torque will stop increasing and then you know you found the right spot.

Hmm, perhaps it will have to be some dyno testing to do this. Unfortunately without live mapping it makes it difficult to dial in the exact throttle everytime between flashes and is very time consuming.

I was under the impression that chassis dynos really weren't accurate enough for proper spark hook tests as theres a good range of angles where there is only 1-2% of difference in output torque so it can be difficult between sessions to find your MBT point.

You can emulate the flash chip.
Alternatively you can use the calibration interface and you can adjust these things over OBD without having to re-flash every time.
It is not required to use emulation to dial in a timing map on ME7, there is the calibration interface for that.

I don't see what you mean about throttle position - you fix the dyno to a certain RPM, and then you adjust the throttle with your foot to hold it in a load cell.
If you want to be super precise, you can adjust the throttle position via specific codewords.

I'm not working on the VAG ECU's I am working on the Opel ME7.6.2 and ME1.5.5 ECU's but these are hybrids so emulation is not possible.

That is superinteresting information, is it described in the FR?

Yes...
But this is nothing new, it is how lemmiwinks operates for example.

You can use the same adaptation channel to add or remove timing per-cell, then note the timing values per-cell and write it down.

Yes, VS_VERST.

Apparently the McMess protocol is difficult to implement though.


Not exactly. Lemmiwinks writes RAM in the EEPROM and doesn't work in real time. The true cal interface can read and write RAM in real time over McMess protocol.

Ah, I thought it works in real time. I never toyed with it myself.

In the other case you will need to use McMess.
Or it is possible to write RAM over KWP2000 also.

AFAIK, RAM can only be written over KWP2000 in boot or programming mode.

I don't think so, else setzi's logger would not work.
There is writeMemoryByAddress which works in a developmentSession.

I believe phila is right; you don't have to be in boot mode or programming mode to READ ram, but to write to ram, you do. Granted, this is from my understanding of KWP2000, not real life experience

Your understanding is wrong, because this is exactly how ECUx works.
It allocates a table with variables, then changes the pointer of the LocalIdentifier data table in RAM.

None of the loggers read the variables one by one. That would be so slow it would be unusable.

I have written loggers for KWP1281 and currently working on one for KWP2000, so you could say I have some experience with this.

Can we hijack the VS_VERST variables then?

Sure, if you disassemble ZUE you can easily find the addition from the calibration interface.
All you'd have to do is write that over KWP2000.

Though I think implementing McMess would be a more universal solution, because you would have to find the variable in every binary.
I don't think it's that hard either, it's just another protocol.

Wow, this is heavy stuff.

Im thinking of a mini-logger that can log or at least display the varibles needed to tune timing, then a this feature to alter the timing.

Would it be possible to do that? Read a couple of varibles and write the timing channel at the same time?

I don't see why not...
I don't have any interest spending my time on this though, because I have an emulator, so there is no point for me to do this.

Bische: i am interested in this project.

I am too but what is the compatibility of all this with the ECU's used in the Opel world which are ME1.5.5 and ME7.6.2?

IIRC, the calibration interface via McMess can write the 17 VS_VERST variables and read up to six bytes synchronous to the crank.

I really don't know alot about serial communication or Bosch comm protocols, but is my understanding that the protocol is difficult to implement because it requires 9 bit transmission with a start and stop bit at 10400 or 125000 baud.

I brought this up a while back, but it didn't draw much interest. I think mostly because Setzi was critical of the McMess protocol itself, but his perspective was mainly from a datalogging standpoint.

I have only come across a few documents on this subject and they are scattered on this site. Tony posted a document on the calibration protocol from the Journel of European Communities, NVR posted and EDC document on McMess, and Setzi also posted a small writeup.

Works just fine here with a dumb mode K-line cable... The 10400 9 bit thing.
If you look up KWP 1281 it is also 10400 and 9 bit, at least that is how it is setup in the code of the older '90s CPU's.

Found this - is interesting reading on the McMess protocol & session init

http://www.mikrocontroller.net/attachment/115911/mcmess_protocol.txt

Definitely something I would like to explore further.

This is from an older MCU documentation...
And such data can be received through the dumb K line->serial cable without any extra work.

Setzi's "notes"

If it could modify parameters without an emulator however, it would certainly warrant investigation, but phrases like that worry me!

I don't think logging speed is an issue for this purpose. Assuming 125000k baud is achievable, crank synchronous logging of dwkrz(0...5) is suitable.

125000 might be achievable through the custom baud rate settings of the FTDI chip.
But you will need to use the D2XX driver to do this I think.
So quite a bit of extra work.

Then again, do we really need it to be crank synchronous?
There is 20ms between the time you can change variables, so let's say you change the variable every 20ms and you have 6 variables.
This means you still get a logging rate of 8-9 samples per second.

I think that's plenty for real time dyno tuning of ignition advance, is it not?
You will have like 1/8th of a second delay on a 6 cylinder engine. I don't think it's bad at all.

I'm convinced.

IMO, following the least path of resistance just getting it up and running is best anyways, then improvements can come later as needed.

Unfortunately, I'm behind the curve on this subject, so it will be awhile and alot of reading before I could bring this to fruition.

I could easily develop this from start to finish with a nice UI, but then I'd charge for it.
There is no sense for me to spend time otherwise developing something I don't need... Not trying to be selfish, but just the way it is.

Makes sense.

Flat rate for source?

I started looking at the FTDI documentation a while back; is that the right place to start?

Forget about start to finish; id be happy just to see proof of concept source (like 360's checksum code). The rest wiill just take some long term tweaking.

I think right place to start is how to open a com port and write to it.
You don't need anything FTDI direct. Just serial comms.

FTDI have some code examples on their website, one specifically shows how to open a port & set baud / comms parameters. Handling the 9 bit transfers looks ok too, with 8 data + 1 parity bit. Change the odd / even parity parameter to set the parity bit 0 or 1 depending on the transmitted byte, and you will end up with 9 bits to sent. Receives can be handled by inspection of the parity error bit from the driver & some logic to set the 9th bit appropriately. I cant think of any other way to do this.

I'll try to have a play when i get some time....