AFR datalogging and ECU maps

Hi Meinolf, first of all my compliments for your bench set-up! Very interesting. It would be useful to have another one of this (having the possibility to find all the bike parts, of course).
Regarding the fact of accessing OBD data while running, it was only the tipical fear of a firmware engineer, that worries about the fact that service communication maybe is not foreseen to be active in standard condition. Of course I don't know if one can only "listen" on the OBD, or something like "connect" or "session open" is required. But, anyway, it's only my (excessive?) doubt.

In any case, this topic is really interesting, thank you to all of you

Hi Alberto?,

albertoge wrote:

... of a firmware engineer

interesting, very few people knowledgeable in firmware are also motorcyclists. Are you interested in joining the reverse engineering of the code? John, Beard and myself have spent considerable time in analysing the code, the results are already quite impressive. But, not every bit is understood yet. I can provide the current results in i64 (Idapro 6.6), ASM and text format. The CPUs used in the recent Marelli ECUs are C166 derivates, the opcodes are upwards compatible.

Cheers
Meinolf

Hi Meinolf, yes, I would be happy to be able to give my little help. I've not too much time (like everybody, I suppose), but the argument is very interesting. Let me know if you like.

Just to explain a little bit, my (current) goal was this one:
After some, let's say, "engine rework" (...) the combustion is now very lean (the spark plugs are white).
And, in addition (also before the modifications), the 1100 engine is knocking if you suddenly open the throttle at low RPM.
So, instead of having the ECU re-mapped by a professional shop, I decided to do it myself (typical engineer approach, always criticized by the typical engineer's wife ).
I have read the map with IAW reader (from GuzziDiag website), loaded in TunerPro, and done some - for the moment "blind" modifications:
1) enriched the mixture above 4000 rpm by some 15%;
2) slightly reduced the ignition advance where there was knocking.
Then written back with IAWwriter.
At least the knocking has disappeared, and this is for the health of the engine.
As next step, I want to measure AFE vs RPM vs throttle position to make more coherent actions on the map. I've bought a wideband lambda with its controller from Innovate Motorsport. The controller has 2 analog output, one is linear 0-5V, and one is 0-1V; both can be scaled as desired. I want substitute the stock lambda with the wideband one, then feed the 2nd analog output (which can emulate the "hysteretic" response of the stock lambda) to the ECU.
With the 1st output (0-5V) I want to feed a gauge on the dashboard, and also record the values on a datalogger - synchronized with RPM measure and TPS position. If these 2 values could be retrieved by the ECU, the job is quite simple. My only concern, as I said, was to keep the OBD active while riding, but if you experienced it's safe, OK.
have a nice day.
Alberto

Hi Alberto,

very good, I'll send links to the respective files vial PM.

Please allow me suggestions re your plans.

The OEM fuel maps typically aren't lean and the ignition values are not optimized for highest performance, so an overly lean mixture requiring advanced ignition (whereas you retarded ignition?) most likely was not the root cause of the pinging. But, I don't know which reworks you applied to the engine. I would have used the acceleration fuel enrichment functions under your circumstances instead, they are barely utilized in the code.

Sorry to hear that you already purchased Innovate, their products gave me nothing but pain, highly unreliable and defect prone. The only usable part is the software. I eventually moved to Zeitronix, using a master/slave combination of the ZT3/ZT2. Costwise about the same and not a single defect so far. The only shortcoming of Zeitronix is the absence of analysis functions in their SW.

You will find that you will need massive amounts of logged data to extract reliable information to change the fuel maps. One hour of logging two lambda probes, TPS and rpm results in close to one million datapoints.

Using the scaling option to feed a shifted lambda voltage is one approach I'm using on a Yamaha GTS 1000, which ECU I can neither read nor write to. With the option to read/write to ECU this is not neccessary, a direct modification of fuel values is better if the closed loop is disabled. Which you need to do anyway if you want to change fuel values based on logged data.
And, closed loop operation is not a bad deal. The CARC engines work very well at lambda of 1 and give better fuel economy and catalysator efficiency. And in the operating envelope of the closed loop operation  (TPS < 26°, rpm < 4k, no accel/decel) you wouldn't be going after highest power anyway. In fact I'm planning to extend the closed loop envelope up to 5k, which is a bit more than 130km/h in 6th gear (= long distance Autobahn cruising speed).

Replacing the narrow band with a (single) wideband sensor won't work. The basic problem of a single narrowband sensor, apart from it being a narrowband type, is that it measures a mixture of exhaust gas from both cylinders. Combined with the poor OEM delta fuel values for the right cylinder this leads to a down- or upward trend of the SFTF, especially if the resulting lambda of both cylinders is not closely sync'ed.

My experience is that sync'ing the lambda values of both cylinders is the lowest hanging fruit. Get this right and you'll achieve 90%+ of what can be achieved. Almost everything else is cream on top, you won't notice the difference.

So, get a dual channel logging setup, a single channel is not sufficient.

Using OBD data can be done, but it's difficult. Innovate and Zeitronix log 4-10 faster than the highest speed at which OBD can deliver. The OBD bandwidth of < 16Hz is shared OBD sources, which would give you 8 data points for each per second at best. And especially for TPS in the lower range this is not sufficient enough by far. And, you don't have a common time base to sync the two data streams.

The only usable OBD data would be which of the 11 engine running modes is the current one to eliminate logged data not relevant to the main fuel tables. Which is easier to do by keeping the throttle steady at as many breakpoints as possible. Once the engine is warmed up and no longer in warm-up mode it's engine run mode 6 or 7 most of the time anyway.

Suggestion, try my current BIN for the Norge. As chance has it I posted the latest version today,
[You must be registered and logged in to see this link.]
Change the speedo correction factor to get the correct roadspeed on the dashboard, and try both the closed/not closed loop version.

Cheers
Meinolf

PS Alberto, send me a PM with your email, please. The Capture screen is driving me crazy, I always get it wrong.

Hi Meinolf,
I had a look at Zeitronix website. Very interesting, thank you for the suggestion.

Hi Meinolf,
some answer to your points.
Just to compare my ideas with yours - and I imagine that you have a far greater experience.

meinolf wrote:

(whereas you retarded ignition?)

from my understanding of the combustion dynamic, the flame front is fastest @AFE around 12.5, and slower above and below. The cylinder pressure should peak when the piston is already descending (let say 20°), otherwise there is knocking (dangerous) or at least waste of power. (another cause of knocking being detonation for hot points, but that's another story).
My bike was knocking (still with the stock motor and only filter+muffler changed, and worse after the other things) when suddenly opening the throttle (TPS >> 20°) and RPM < 4500. I'm running with closed loop ON, so till 4000 I would assume AFR ~14.5. To "cure" the knocking by enriching the mixture I should put too much fuel (and maybe switch off the closed loop, which instead I want to keep ON). So why not decrease the ignition advance? It should be the root cause. And in fact the knocking has disappeared, probably with a small loss of power. What do you think?

meinolf wrote:

You will find that you will need massive amounts of logged data to extract reliable information to change the fuel maps. One hour of logging two lambda probes, TPS and rpm results in close to one million datapoints.

Yes, I was aware of this...

meinolf wrote:

Using the scaling option to feed a shifted lambda voltage is one approach I'm using on a Yamaha GTS 1000, which ECU I can neither read nor write to. With the option to read/write to ECU this is not neccessary, a direct modification of fuel values is better if the closed loop is disabled. Which you need to do anyway if you want to change fuel values based on logged data.

That's clear. But my intention (tell me if it's a bad idea) was to keep the lambda ON (just to be polite when riding in urban areas) and enrich the main fuel table or whatever above 4000.

meinolf wrote:

Replacing the narrow band with a (single) wideband sensor won't work. The basic problem of a single narrowband sensor, apart from it being a narrowband type, is that it measures a mixture of exhaust gas from both cylinders. Combined with the poor OEM delta fuel values for the right cylinder this leads to a down- or upward trend of the SFTF, especially if the resulting lambda of both cylinders is not closely sync'ed.

Here I don't understand. I already have only one stock sensor, which is narrowband. I imagine the need for the delta fuel table comes from the fact that, because of the 2-to-1, the backpressure creates interaction between the 2 cylinders. My idea (assuming to have a 1-channel setup, then you suggested a better idea below) was to put a wideband sensor in place (but not connected to the ECU) of the original one, and then use the appropriate output of the Innovate amplifier (assuming that I've understood the specification) to re-create a narrowband-like signal to feed the ECU (I still need to put a load across the lambda heater wires to not have the specific ECU error). If the reasoning works, the ECU shouldn't notice the difference, and I have an analog value to log the AFE on some datalogger. Why it should not work?

meinolf wrote:

So, get a dual channel logging setup, a single channel is not sufficient.

Do you mean soldering another "bung" on each exhaust tube before the 2-to-1, to fit one wideband on each tube?

meinolf wrote:

Using OBD data can be done, but it's difficult. Innovate and Zeitronix log 4-10 faster than the highest speed at which OBD can deliver. The OBD bandwidth of < 16Hz is shared OBD sources, which would give you 8 data points for each per second at best. And especially for TPS in the lower range this is not sufficient enough by far. And, you don't have a common time base to sync the two data streams.

OK, this was my suspect and you confirmed.

Cheers
Alberto

Hi,
you've touched an hot point: the GRiSO is ageing.
I'm resisting to the idea to buy a 1098

Hi Alberto,

albertoge wrote:

from my understanding of the combustion dynamic, the flame front is fastest @AFE around 12.5, and slower above and below.

Your understanding is correct. Strictly speaking, the impact of Lambda is more on the inital speed of igniting the mixture and less on the flame propagation speed once completely ignited, but to all intents and purposes it boils down to the same for our purposes.

[You must be registered and logged in to see this image.]

albertoge wrote:

The cylinder pressure should peak when the piston is already descending (let say 20°)

Again, completely right. The accepted best value range for street engines is a peak pressure at 12-15° after TDC.

albertoge wrote:

So why not decrease the ignition advance?

Maybe we are mixing our terms here. If the mixture is (to) lean and the pressure peak occurs before TDC (= pinging), then the ignition needs to be retarded. If it worked, then probably because of the following comment

albertoge wrote:

My bike was knocking (still with the stock motor and only filter+muffler changed, and worse after the other things) when suddenly opening the throttle (TPS >> 20°) and RPM < 4500. I'm running with closed loop ON, so till 4000 I would assume AFR ~14.5.

I mentioned engine run modes earlier. Each of the modes applies to specific circumstances. Once the engine has passed the warm-up stage and exceeded a temperature threshold it moves in mode 7. Which is characterized by a non-moving TPS, meaning the vehicle is in a steady state. At this point the main/delta fuel tables are used as starting point for the fuel calculation.
If the TPS change speed exceeds a limit (+/-0,72°/s) the mode changes from 7 (steady state) to 6 (acceleration/deceleration). At this point another subroutine(s) gets active and trims the fuel calculation to higher or lower values. The details are well described here [You must be registered and logged in to see this link.] and in a Youtube video of C.F.Aquino.
In addition to above the lambda mode also changes (yes, there are also several lambda modes). Lambda control is turned off for a moment.

So your change of adding fuel by using the main fuel table leads to a richer mixture in an engine run mode where its not needed, namely steady state. Changing the acceleration/deceleration relevant values would achieve the same.

albertoge wrote:

But my intention (tell me if it's a bad idea) was to keep the lambda ON (just to be polite when riding in urban areas) and enrich the main fuel table or whatever above 4000

I'm with you, keeping the closed loop on is a very good idea. Once the target of having equal lambda for both cylinders is reached. In fact I suggest that extending the closed loop envelope to a higher rpm is preferable. The CARC engines run very well at Lambda 1.0 and higher.

Enrichening the main/delta fuel tables is best done with a clear target in mind. For me it would be to have the highest power when its needed - by me and the engine. Let me explain what I mean.

Some years ago I temporarily connected a MAP sensor to the intake tract and logged the pressure, or rather the vaccum. And was not very surprised to find that the throttle losses amounted to almost -600mBar (vs ambient pressure) with throttle closed and at higher rpms. But even in the medium cruising range the throttle loss is significant. Why throw fuel into a highly throttled engine to get to the best power lambda. So I normalized the logged pressure data and created a target lambda table with intermediate steps of 0,04. Ranging from 0,86 to 1.0 and then tried to get the fuel values so that the lambda values were in the respective areas.

albertoge wrote:

I already have only one stock sensor, which is narrowband. I imagine the need for the delta fuel table comes from the fact that, because of the 2-to-1, the backpressure creates interaction between the 2 cylinders

Right. The (required) delta values vary a lot. This is not reflected in the OEM BIN.

albertoge wrote:

My idea (assuming to have a 1-channel setup, then you suggested a better idea below) was to put a wideband sensor in place (but not connected to the ECU) of the original one, and then use the appropriate output of the Innovate amplifier (assuming that I've understood the specification) to re-create a narrowband-like signal to feed the ECU

The reasoning is sound, but what is the effect? Instead of a on/off signal from the narrowband sensor the ECU will get a on/off signal from the wideband sensor. This setup can be used to shift the target lamba up or down, but this doesn't seem to be you intention. Otherwise you would disable closed loop and just change the fuel values.

albertoge wrote:

Do you mean soldering another "bung" on each exhaust tube before the 2-to-1, to fit one wideband on each tube?

Exactly.

Cheers
Meinolf

I'm really into reading all this stuff and a great fan of meinolf's work,

but I have a pressing question , seeing as beetle has already made perfect maps for almost every imaginable set up of GRiSO, wouldn't it be simpler to just get one of his maps??

I would really be surprised if there was room for improvement over his GRiSO map

My bike's fueling is literally perfect and I'm a picky bugger!!!

Lazlokovacs wrote:

Seeing as beetle has already made perfect maps for almost every imaginable set up of GRiSO, wouldn't it be simpler to just get one of his maps??

I know this thread is a couple years old at this point, but I have the same question! Are you guys trying to make a new map that keep the closed loop function? If so, why?

Using a wideband sensor to emulate the narrowband signal works extremely well to reach your target AFR. You can get the bike running pretty near perfectly without the hassle of logging hours of data in all conditions.


There are a couple of caveats, however. When lambda is active in the map, the ECU monitors both the lambda signal and the sensor heater current. This is fine when using the stock narrowband sensor. The wideband sensors have their own separate controller, which means the ECU cannot monitor the heater current. If you try to run a wideband sensor with emulated narrowband signal in closed loop mode you will get a service warning and the ECU will not operate in closed loop. You need to install a dummy load attached to the heater circuit so that the ECU can monitor the current, and will happily plod along adjusting the fuel to reach your target AFR.

Adding a dummy load and futzing about with relays and other jiggery-pokery to get this working is a massive pain in the arse. I've tried it, and guess what? I don't use it. I've already done all the hours of AFR logging in all conditions to get the maps I've made as near as perfect as possible, so you don't have to...

Thanks for the response, beetle. All very good to know.