Rabbid
Full Member
Karma: +0/-0
 Offline
Posts: 55
|
 |
« on: January 08, 2013, 07:12:03 AM »
|
|
|
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.
|
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #1 on: January 08, 2013, 10:41:55 AM »
|
|
|
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.
|
|
|
|
|
Logged
|
|
|
|
Rabbid
Full Member
Karma: +0/-0
Offline
Posts: 55
|
|
« Reply #2 on: January 09, 2013, 04:49:38 AM »
|
|
|
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.
|
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #3 on: January 09, 2013, 05:34:53 AM »
|
|
|
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.
|
|
|
|
|
Logged
|
|
|
|
Rabbid
Full Member
Karma: +0/-0
Offline
Posts: 55
|
|
« Reply #4 on: January 09, 2013, 06:02:40 AM »
|
|
|
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.
|
|
|
|
|
Logged
|
|
|
|
|
Bische
|
|
« Reply #5 on: January 09, 2013, 07:56:04 AM »
|
|
|
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. That is superinteresting information, is it described in the FR? |
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #6 on: January 09, 2013, 07:57:39 AM »
|
|
|
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.
|
|
|
|
|
Logged
|
|
|
|
|
phila_dot
|
|
« Reply #7 on: January 09, 2013, 08:17:57 AM »
|
|
|
That is superinteresting information, is it described in the FR?
Yes, VS_VERST. Apparently the McMess protocol is difficult to implement though. 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.
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. |
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #8 on: January 09, 2013, 08:49:37 AM »
|
|
|
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.
|
|
|
|
|
Logged
|
|
|
|
|
phila_dot
|
|
« Reply #9 on: January 09, 2013, 10:11:30 AM »
|
|
|
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. |
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #10 on: January 09, 2013, 10:41:49 AM »
|
|
|
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. |
|
|
|
|
Logged
|
|
|
|
|
nyet
|
|
« Reply #11 on: January 09, 2013, 10:43:53 AM »
|
|
|
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
|
|
|
|
|
Logged
|
ME7.1 tuning guideECUx PlotME7Sum checksumTrim heatmap toolPlease do not ask me for tunes. I'm here to help people make their own. Do not PM me technical questions! Please, ask all questions on the forums! Doing so will ensure the next person with the same issue gets the opportunity to learn from your ex
|
|
|
|
prj
|
|
« Reply #12 on: January 09, 2013, 10:49:14 AM »
|
|
|
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. |
|
|
|
« Last Edit: January 09, 2013, 10:51:47 AM by prj »
|
Logged
|
|
|
|
|
phila_dot
|
|
« Reply #13 on: January 09, 2013, 11:01:56 AM »
|
|
|
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? |
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #14 on: January 09, 2013, 11:42:12 AM »
|
|
|
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. |
|
|
|
|
Logged
|
|
|
|
|
