Davidv

Thanks for the detatiled answer Adam! Appreciate that you took the time to test this, thanks.

It doesnt seem to, but it may be that the change is so small that it isnt able to be seen with a map sensor of this scale. And possibly because my copper line is too smaller diameter as well. I've parked this idea for now, I'll revisit it later on when I can redesign the pipes a bit better. But I'm just about there with my MAF based tune, might need a test driver at some point while I tinker if you're keen!

Hey guys, I've recently gone back to using a MAF sensor, and I notice that with modelled fuel there is the option to have as a load axis "Air per Cylinder Measured" Which is awesome. Since this figure comes directly from the MAF sensor I am assuming that a lot of the calcs for modelled fuel get bypassed. I also notice there's a seperate category for "MAF IAT" Rather than regular IAT, I assume this does the IAT calculation differently too. However I have a few questions. 1. Options for load axis in the fuel calculation are either MAP, BAP, or Off. I've set this to Off. Would that be best option? 2. Which of the modelled fuel settings now get ignored, since you're measuring air directly? I get the feeling that it air per cyl measured is used as part of the calc which then still generates "air per cyl estimated" which is what the fuel calc runs from? I realise that MAF isnt the suggested option but it offers some benefits while I'm doing some experimenting with cam timing, so I'd just like to get it setup to "best practice". So any advice/info on how it calculates would be appreciated. Thanks David It's pretty cool having grams/cyl as a load axis because the values are quite linear... This was the MAF basemap that I put together based on observation of my MAP based tune, and car ran awesomely on it! It's now changed shape a little after the first iteration of tweaking it but it's still very linear.

One thing that I've been curious about lately is advancing cam timing at part throttle for better fuel economy. So I did some tests, where I set the timing all to 0 degrees, then 10 degrees, etc, and then went for a drive at a set rpm on the same stretch of road with cruise control and closed loop lambda turned on. Interestingly, 0 degrees advance clearly gave the best results. At first I felt satisfied with this, but then the nagging problem in the back of my mind... Toyota documentation says that advancing the cam "about half way" yields best economy. So I took a closer look at the logs. When the cam advances, at same throttle angle, the MAP sensor reading goes up! In one case, up 60% higher. So the ECU is of course trying to dump fuel in, and pulls the ignition timing back which is why the economy was notably worse even though Closed Loop Lambda was trying its best to salvage the situation. Why does the map sensor value jump up? Because of internal EGR, when you introduce cam overlap, the low pressure in the intake manifold and high pressure in exhaust pulls exhaust gas back into the inlet manifold which raises its pressure. So this is obviously why the factory ECU uses a MAF sensor rather than MAP - A map sensor is including some "dirty" air in its readings (which has no oxygen left in it) where as a MAF only reads fresh air coming in. Since the factory ECU only has a narrowband sensor, using the internal EGR method allows it to run a greater airmass to reduce pumping losses while still operating at 14.7:1 as the recycled air has little or no oxygen left in it. Pretty clever. So I thought I'd wire a MAF sensor back into the car. But this presents the next problem, how do you get the 0-5v signal of the MAF into a grams/sec that the ECU needs for a calibration curve. So for starters I was just logging raw MAF voltage output, so depending on airflow it spits out somewhere between 0-5v to ECU My ECU currently has load source as MAP sensor, and one of the values it logs as part of the modelled fuel calculation is "Grams of fuel per cylinder Estimated" So we need to turn this into a grams per second, so some maths to create a custom field in Megalog viewer and now I've got Grams per second which I can compare to voltage: Which I can then use as an axis on a scatter plot, which shows me a very rough outline of a MAF curve starting to form... So I rough out a voltage vs grams per second to put in the calibration in Link And then go for another drive and do same thing again in megalog viewer... Starting to look better! (It would be cool if PClink allowed Maths functions like this... Just saying) Then from here have updated the MAF curve again to suit the trend seen there. I think another 1 or 2 iterations of this and I'll have that low airflow area cleaned up. If not, I will just switch to map or alpha N based tune around the areas where it sucks. But from here, once the MAF sensor data is accurate I'll build secondary ignition and fuel tables which have MAF as the load axis. Then I can start experimenting with cam timing at part throttle some more, without my load axis going bananas (map sensor value changing a lot) In order to find the sweet spot for economy though I really need to play with a few variables at once. As when you're introducing EGR gas, you might start getting misfires at 16:1 where as this is most economical if you are running no overlap. And when you introduce EGR gas you need more ignition timing as it slows the burn. So I think I'm gonna make a little box that communicates over the CAN network that has a few potentiometers which log as virutal 0-5v which I can use as trim tables for ignition table, cam angle, goal AFR, and maybe a little display that shows fuel economy. So I can very quickly go through a lot of combinations while someone else drives with cruise control turned on. It's a lot of effort to make only a small iterative improvement to the car's economy, as it's already getting 7-8L per 100km if driven nicely. But it's always bothered me that I've had no way to quantify how to best set the part throttle cam timing so I'm thinking there's something to learn here yet. I'll post the results once I've got my MAF curve dialled in nicely and I've put together a CAN box. Also, at the same time as wiring in a MAF I thought I'd wire in an exhaust pressure sensor. I wasnt sure what sort of pressures I would see on an NA car, so I bought a 30psi sensor. I drilled a hole in a spare wideband bung, which then goes to a line of copper tube to cool the gas, then to a rubber line, then to the pressure sensor. Results are interesting! At high RPM (Or high mass airflow more specifically) the measured pressure actually drops. Down to 91kpa which was quite literally the last thing I was expecting hahaha. Thoughts as to why? I think the airspeed past the hole in the wideband bung is creating a venturi effect and pulling the air out of the hose, rather than telling me what the pressure is. So I am thinking that having an angled bit of pipe internally that either faces towards or against the flow will prevent this from happening. Or maybe upsizing the diameter of the tube that I am using as it's very small. (maybe 2mm ID) The resolution isnt very good with a 30psi sensor so I'll perhaps switch it out for one from an NA car instead. I've got a spare Toyota one here somewhere. It doesnt really show any results that I was expecting though, so I might just ditch it from here. Was worth it just for curiosity's sake though! More useful on a turbo car though of course.

I had a similar problem when initially trying to get my Toyota e-throttle calibrated, with it initially not calibrating and then when it did, I'd get the fluctuations. In my case it was solved by replacing the TPS, since then has been perfect. I am thinking that on a normal car the TPS only moves as often as the persons foot does, but with e-throttle where its controlling idle speed and other similar situations. It's swiping over the same part of the resistor back and forth almost constantly so "wears out" quicker but the problem only becomes apparent at certain throttle angles. I'm using Altezza e-throttle and apparently it's common for the TPS to need replacing.

Interesting, I could see this helping to make mixture map work a bit better. As sometimes you get massive see-sawing between cells due to interpolation.

Hi, I see in the documentation that the pins for DI9 and DI10 can alternatively be used as canbus on the Xtreme. I've been redoing some of my loom / reorganising some things so I've set aside these two wires for an upcoming can project. But I would have thought I'd need to specify them as being allocated to can in the DI list? It doesnt show up any option to allocate them to anything can related, do I just leave them "off" and then from there, configure in the CAN screen? Thanks David

I've been thinking about making something like this using arduino / canbus. As I've got an interesting situation when trying to tune intake cam angle on a VVTI engine for best fuel economy. When using MAP as a load source, when in steady state, when I advance the cam. The map sensor reading goes up. Because when there is cam overlap the exhaust gas pulls back through to the inlet and raises pressure. So in response, the ECU pulls timing and adds fuel. So I have to readjust these with every adjustment to cam timing so its very finnicky to try find best setting. Also since EGR gas is being internally introduced, indicated AFR may need to change as there is some non oxygenated air present and you'll misfire if you've got a goal AFR already on the lean side of stoich. (Which this leaner setting may be best when no EGR gas is involved with low overlap) Also when there's EGR you need to add more ignition timing. Having a box of trim pots would help speed up optimizing this immensely as I've got 3-4 variables that I need to adjust at once. Tuning for best economy is a lot more challenging than just for max power in each cell! If there was an off the shelf option I'd be keen on it.

EWP is an advantage because you can disassociate your water pump speed from engine speed. So you dont get cavitation/pumping losses at high rpm or insufficient circulation at low rpm... Think about what happens in a normal engine when your thermostat is shut. Coolant still circulates around the block, its just partitioned the engine coolant circuit from the radiator one. when you use an EWP as a thermostat, you have no choice but to introduce new cool coolant every time you want to circulate coolant around the engine. Depending on where your coolant temp sensor is, this can lead to see-sawing of the EWP turning off and on when the temp sensor sees this coolant change. In my opinion, best way to use EWP is to set it to pretty much constantly circulate engine block coolant and then just keep a thermostat in place to do the job of a thermostat. Which is to introduce cold coolant when necessary.

Either way it doesnt matter though - because your main fuel map represents that one cylinder, and then the other 3 represent variations away from it.

Are you talking about monitoring how much the engine is adding or removing fuel to reach lambda target? If you have closed loop lambda turned on, then you can monitor "CL Lambda Fuel Corr. (%)" You dont need to setup tables for this, it's a value you can just look at in a time plot etc. You only need to setup those trim tables if you are wanting one cylinder or another to receive more or less fuel than the rest, which doesnt sound like what you're wanting to acheive here.

Ahhh cool thanks! Yes that's what I was meaning, if via CAN the ECU could output the data at a greater rate than 100hz to an external item. Rather than CAN info coming into ECU. 200hz would be cool for some situations, so I think I'll give it a try.

Hey, I've not played with can bus stuff before, but looking to set something up for sake of interest. One thing - ECU is limited to log at 100hz internally, or 40hz when streaming to a connected PC via the cable. How does this work with CAN, when logging at maximum data rate? If you were only logging a few values, would it potentially go higher than 100hz? I'm not sure how the rate of transmitting / receiving the frames relates to the data rate, and whether that potentially means higher than 100hz sending/receiving of frames. Thanks

The only thing I can see that's varying similar-ish to your RPM spikes is changes to your dwell time Maybe try change the value in the table so it's a bit more stable at idle.

Mine idles with VE numbers somewhere around 25 at 45kpa. Modelled fuel really needs your injector data to be really good to work well though, so if you're considering changing injectors in the near tearm I'd probably just stick with an MS based fuel map for starters. Then switch over when you get your new injectors in (with good deadtime and flow rate data) Building a fuel table is by far the quickest and easiest part of setting up a map, if your injector data etc is good. If someone deleted mine I'd have it back to within 95% of what it was within a very short time.

Thanks guys. Cruise control is definitely an interesting tool for minimising variables for tests like this. (As well as being cool!)

In my case, the fuel rail is on plastic upstands that hold it up away from the head - But the bolt that goes down through the top touches both the fuel rail directly and the head of the engine. So it was conducting heat through it. If your fuel rail is held in place by anything metal straight from the rail to head then you'll be getting stacks of heat transferred that way. Not the same situation for every type of fuel rail though I guess. Out of interest, is your fuel tank steel or plastic? A lot of cars that now have factory plastic fuel tanks have a fuel cooler on the return line as they're no longer able to radiate heat out through the fuel tank. But yeah leaving your fuel pumps running while the engine is off is a way to isolate the temperature increase from either engine heat or fuel pumps etc. Thermal camera is a cool toy but a cheap IR gun can still give you some good comparative info.

Slightly off topic but perhaps relevant to the intentions of this thread. I did some tests with a thermal camera, with the fuel pump running and the engine turned off. In this case, what heats up the fuel is/was when the fuel flows through the hot fuel rail bolted to the head, and then circulating down to the fuel tank and back through hot fuel rail again and so on. Which is even worse when you have a surge tank to the fuel rail, which is probably why people think its the pumps making all of the heat. If you slow down the speed of your fuel pump, and the fuel is flowing slower through the fuel rail then you're still transferring the same BTU of heat. (Half as much fuel flowing for twice the time through the hot rail) If I leave the fuel pump running with a cold engine, it took something like half an hour to increase by 5 degrees. But with the motor running the fuel temperature increases almost immediately. Insulating the fuel rail from the heat of the head and I never had fuel temp issues again. Fuel rail is dark blue item near the left hand side after insulating it with thermal paint, and putting plastic washers under the bolts that hold the fuel rail to the head. EDIT: Found a pic of a close up of the fuel rail, you can see the hot bolts (now insulated) against the rest of the rail (darker colour)

If you send "end of injection" injector timing, is this end of effective pulsewidth or end of actual pulsewidth? Also, I've been doing some experimenting with a 3d table for injector angle to try optimise fuel consumption at cruising. It feels like when there is a transition in timing, the engine hesitates. More than I would expect from just injection timing changes. Is there anything weird that happens when it tries to change the calculated value perhaps? Using a red G4+ xtreme with latest firmware.

Weird! Can you post up the fuel cut decel setup page and the overrun deactivation table? But does seem to look like a bug. I'm running a red G4+ xtreme as well, latest firmware version - You know what version you are on?

Instead of duty cycle have a look at the log of Injector Actual Pulsewidth When the injector cuts you'll see a delay in the reading changing which I believe is for two reasons: 1. The amount of gas coming past the wideband sensor under these conditions is very low so its slower to respond 2. There is still the fuel film build up on the port walls which is coming into the cylinder, although the amount of fuel is low the amount of air is very low too when the throttle is shut. But I see a delay in the readings here, and look how long it takes to register again once the injectors turn back on.

Hi Robin, The above responses are correct, one wire goes to your Aux output (This is the earth side of it) So the other wire needs to supply power to the solenoid or it's not going to do anything It's essentially wired the same way that an injector is. The ECU earths the connection, rather than supplies power. Note - you need to wire a VVTI solenoid to aux 1-4, none of the others.

I mention 40% as that's the current allowable maximum. The main thing that would be nice would be able to specify seperate percentages for adding or removing fuel.

Okay I've tested again with proportional gain table set to zero, and now the anti stall works. You can see it spike every once in a while to maintain idle. But it would be nice if it could work to maintain idle under changing conditions as well, in my case mainly alternator load requiring more power to idle on target.

Hey, Lately I have been experimenting with having closed loop lambda turned on under all conditions. From recent experiences having seen Motec M1 ECUs do this effectively I thought I'd give it a go. And it works well, even at WOT and high RPM. However it would be nice to be able to set a finer level of control over how much it can add or remove. For example under cruising conditions I might be completely happy for the ECU to add or remove 40% fuel. But at WOT, it would be nice if I could specify only say 10% change and enrichment only so it's never going to run leaner than the tune specifies. So if there is a sensor fault, it's not going to nuke the engine.