RomRaider

Z0rr0 and I talked about this briefly and we think it's do-able, the basic idea is to have a 0-5v signal come in through a TGV sensor and use it to control the "map switch ratio" (MSR) parameter. Plus a hack to alter the effective injector scaler in real time as well. Z0rr0 is looking into the flex-fuel sensor hardware, and I'm looking into the software.

Note that this could be used to transition smoothly between gasoline and E85 tunes based on a sensor, or between pump-gas and race-gas based on a simple knob, or between pump-gas and pump-plus-water-injection, based on a flow sensor (which is where my own interest comes from).

In ROMs that already have the MSR stuff fully implemented this should be pretty easy, but the LGT has some of that logic disabled, and some of the unused tables shrunk down to 2x2. So for starters I thought I'd make a list of what needs to be done.

Boost: There are already pairs of tables for target boost and WGDC, the ECU only uses one of them in stock form because the MSR is always 1.0. With the MSR trick we could call the unused tables the "E85" tables and the regular tables "gasoline" and flex-fuel boost control should just work.

Base Timing: There are two base timing tables, but one of them is only 2x2. That will need to be moved into unused ROM space and given the same dimensions as the stock table. For ROMs that actually use the map switch ratio, there will probably be no extra work needed here.

Advance Timing: There are two "knock correction advance max" tables, but the unused table is only 2x2, so that will also need to be relocated. There's also logic to do the MSR thing, but it is preceded by some code that computes an alternate value for the switch ratio, and that will need to be defeated (which will be easy as there's a flag in the ROM that controls it). For ROMs that use the MSR, the table relocation won't be needed, but the "alternate MSR" code might need to be defeated.

Fueling: Both the normal and 'failsafe' (low IAM) primary open loop tables have 2x2 siblings that will need to be relocated and resized. Again, no extra work here for ROMs that already use MSR.

Map switch ratio itself: this is set by a function at 0x4D994, which can be hijacked to set the map switch ratio based on the TGV sensor input. Perhaps using a 2D table to accommodate whatever voltage curve the ethanol sensor puts out, or a 3D table to accomodate the fact that a flow sensor signal should vary in proportion to air flow, fuel flow, or boost. The same trick would be needed for ROMs that already use MSR.

Fuel injector scaling: this is read by a short function at 0x2A104. That function can be revised to read injector scaling from a RAM address instead. Then, the one place the calls that function can be revised to call a new function that sets the value in the RAM address, based on the existing injector scaler, a scaler for E85 (or maybe E100), and the signal from the ethanol sensor. The same trick would be needed for ROMs that already use MSR.

I want to finish up the SD stuff first, but this might be my next project...

I started working on this for the 16bit ROM but hit a road block with the flex fuel sensor output. It sends out a 50hz-150hz square wave frequency instead of a voltage output. So some sort of frequency to voltage converter needs to be built in order to send the correct signal through the tgv input

There are a couple ICs available to do this but I can't find a good schematic to implement them. Andy and I were going over things as he wanted to implement this system on his 04 wrx rom as well, he said a friend of his was going to build a converter but I'm not sure what happened with that.



Some good information on the sensor.

http://www.megamanual.com/flexfuel.htm

There is a commercial alternative that would do excatly what is needed.
its the Zeitronix ECA: it takes the 50-150hz output and converts it to 0-5v, also displaying the content on a small readout.
http://www.zeitronix.com/Products/ECA/ECA.shtml

it is, however, very expensive. $200 Without the Flex Fuel sensor


I plan on making something very similar, utilizing an arduino (since that's what i have lying around) to use for testing NSFW's software.

That would be great if you could get an arduino to do the conversion. Those are only like $15 right?

On a similar note, have you tried getting an arduino to communicate with SSM? If so it should be simple to build a small LCD readout that could show engine parameters and even ethanol content like the zeitronix for a lot less money. A friend of mine built one and got it to communicate with his EVOX CAN system, it was pretty cool.

It appears that the Ford and GM sensors both output the same 50-150hz signal, and are made by the same manufacturer.

EDIT: they DO NOT output the same scale. in my program for the arduino, i'll have a selectable switch that will scale either the ford or GM sensor, so the 0-5V output will remain the same for ethanol content.

see this link: http://www.supraforums.com/forum/showthread.php?647997-Whats-the-wiring-pinout-for-a-ford-3-wire-flex-fuel-sensor

The interesting thing is the ford sensors will accept fittings, and aren't tied to the barb fittings that the GM sensors come with standard.
So, in a custom application like this, where most users would want to use AN fittings, the Ford sensor might be the better choice.

there is also the requirement of flow, and these sensors only flow about 200l/hr.. with a lot of e85 guys turning to 400l/hr pumps..
they can't just be placed into the return, they need to be "Y'd" in so they still see fuel, but the fuel system can bypass enough fuel at idle.

there's one on ebay right now for a touch over $100, i may go ahead and purchase it.. im going to call a few junkyards around here to see if i can get one any cheaper.


there is a great thread on evom on how they did the integration with 0-5V, they had a 2D table with eth % to voltage that was great... i'll see if i can find it.

Why wouldn't we be able to put it in the return?

you can. that's where it should go. the problem arises when you are flowing so much fuel @ idle..

i.e. with a huge pump.. you need to bypass more than 200l/hr worth of fuel, you need to add 2 "Y's" in order to bypass fuel through the sensor, without it becoming a bottleneck..

like this

______Fuel Return_____
\____FF Sens____/

^^^ I think with Subarus it may not be an issue because we can easily turn down the fuel pump duty cycle at idle.

Agreed with Carbibbles, although if you're running a pump large enough to have to worry about too much fuel flow you've probably hard wired the fuel pump...
But at that point you should have a good understanding of how the fuel system works.

Did anyone see the post that Visconti made on NASIOC about him using the Kenne Bell boost a pump with E85 to change his air/fuel ratios? That post still bothers me...

I think if I do ever change my fuel system I will probably run a dual pump setup with the main pump being on switched ignition power, and the second pump controlled by the ECU... that way I can just kick in the second pump based on boost pressure so that I don't have to worry about the fuel pumps over running the return line/FPR.

here's the way that they are sort-of implementing it in the EVO world.
voltage to eth content lookup scaling.

http://forums.evolutionm.net/alternative-fuel/421070-ces-eth-content-sensor-installed-flex-fuel-patch-coming-soon-7.html

I like the idea of a "pump" timing/fueling map, and a "high ethanol" timing/fueling, with interpolation between the 2, based on ethanol content.

the other scenario could be engine load related, because you should be able to use the same low-load timing on either blend, it's really just the higher loads that need to be compensated for.. i'm not sure though..

Z0rr0's Arduino-Based ECA is a reality!

I have finished adding the code needed to switch between types of sensors, Ford or GM.
all i have to do now is get the parts to make a low-pass filter for stable output of the 0-5V scale.

i have some 2X20 VFD displays coming, and when they get here i can install the prototype in the car, and see how it works in the real world.

NSFW, i am ready to test new code, whenever you are done writing it

If it all works out, i'll release the source code, and schematics to the community, so anyone can build their own.

also, Carbibbles, i have a friend here in town that runs your SD code, and E85, so we could do some testing for you as well.

It occurred to me the other day that the map switch stuff might have been disabled because the CPU in the LGT ECU isn't fast enough to do all of the extra table lookups that are required. I'm pretty sure the STI from the same model year was using the map switch ratio and I suspect that the ECUs are probably the same, but it's worth investigating because I don't know what would happen if the CPU can't keep up with the engine.

I'm going to look through the Renesas documentation for ideas. Hopefully there's a register that indicates the clock speed, and we can compare the clock speed on the LGT to the clock speed on an ECU that uses the map switch ratio.

If that turns out to be an issue, then it's probably still possible to add code to adjust the injector scalar, and scale back the WGDC, since those would only take a small number of extra clock cycles. So then you'd tune fueling and timing at wastegate boost for gasoline, and at full boost for E85, and so on. It would make gasoline even more disappointing but at least you could safely run gas when necessary and not worry about reflashing unless you were going to run it for an extended period.

From what I can tell, going off the ODB-II and SSM baud rates and reverse calculating the bit rate register setting, I believe the the LGT/OBXT and most likely any ECU of 32bit nature is running the peripherals at the 20MHz clock setting (crystal frequency x 2).
My bench ECU has a 10MHz crystal installed on it.

The code maintains the internal PLL at x4 which is the default.
The low byte of 0x3C04 (0x04) contains the multiplier setting in bit7, which is 0 (x4). If you read a byte from SYCSR2 (0xFFFFF70B) and get back bit 7 as a 1 then the multiplier was set to x8 somewhere in code. I see in the 2012 STi a place where 0x3CFB is written to SYCSR2.

NSFW it would be great just to have map switching as say Tephra has done with the EVO software
Just being able to switch fuel and timing maps alone by some type of trigger (like holding WOT for three seconds ign on engine stopped) and having like the check light or some other indicator flash when using the Alternate maps would be enough for most to run E85 without the hassle of integrating a flex sensor.

If you could work out same way of changing the MSR with some hijack routine that doesnt require external switches and then have the system indicate by way of one of the dash lights etc which maps it is running...AND you could compine the injector scalar hack you have a pretty tough solution!

Happy to test AZ1G201G for you