utc_pyro

You want the calculated torque to roughly match what the motor is actually putting out, so they'd need to model that. The units are suspiciously close to Newton-Meters. The three tuners I listed above (especially the one posting in this thread) have already developed "maps" for this, but your tuner could also make one. If you use a Accessport, you're SOL. Yes. Especially if you've changed the injectors, and if you're stage 3 I presume you have. No, that has to do with other issues that haven't been identified yet. A guy over on Romraider was already looking for that in the JDM TCU code, and couldn't find any sort of delay counter. The shift buttons are wired up to BIU so the delay may actually be in there.

Wow, thanks for the help solidxsnake! Truth be told I haven't researched the optimal rom to run for this, but was leaning toward CyanogenMod 13 or AOKP MM (6.0.1) just from past experience. Unfortunately ElementalX and SlimLP arent supported on my devices (Galaxy S5, kltespr) so the modified USB host will need to be transplanted into a different rom series.

Well this is going down a path I was never expecting to attempt in life: building a custom Android image. The stuff I was reading over lunch they were just modifying some configuration files in the charging settings. So if I'm reading this right, you ripped out the USB fast charging function and replaced it with a new USB Host mode that supported fast charging?

Are you saying I should backfired 5V into the USB port even if running on external power? Also you may be right on the Qi not cutting it deal. I'm measuring 800ma with 4.65v input, but the charge rate with the screen on is close to nill. I'm not seeing an easy way to turn ACA (USB host + charging) on in the kernel source code, but people have done it on the similar S5 mini so it may be possible.

It will be a fixed install, but the Qi charging wont be Qi, it'll be straight into the power ports under the back cover: https://forum.xda-developers.com/showthread.php?t=2722657 Testing this with my bench supply works fine, haven't checked the charge rate though. I'm fine with building any sort of custom cabling as needed. My question on the power is more, what happens if I DON'T used the 5V+ from the USB OTG and instead power the USB devices by an external regulator that's switched? With the phone freak out or is this allowed by the USB specs? The idea of messing with the ID pin is a good idea though, I need to find an angled USB pigtail with the ID pin broken out.

He's just changing the calculated and requested torque tables in the ECU. This tells the TCU that the engine is outputting more power, and it responds accordingly. The TCU appears to have had a wider tuning envelope than a stock motor will output, so you're basically just telling it what you're actually doing. We talked about this in the ask your questions thread. West_minst (Xtreme Racing Tuning guy), Throttlehappy, and Fahr_Side all offer this tuning as part of their etuneing services, and are all active on these forums at some level. Carefuly review there post history and choose one. These tables are only avalible for Opensource and ECUtek, so the majority of shops that just do Cobb can't help you.

It's a bit more complex than that... Using the available tools you cant even pull the code from our TCU. I tried two weeks ago and got the same gibberish that the tool NSFW wrote back in 2010 did. It spits out something, but it's not what we're looking for. Shipping a TCU to Sasha to pull the ROM on the bench is looking to be the most probably method. Hum, need to get the test TCU back from ClimberD to send to Russia....

USB OTG+charging isn't a huge deal for me as I was planning on using the Qi charging port for power. Currently I have Cyanogenmod/LineageOS 14.1 on it, but cell data is being glitchy so I may need to change to something Android 6.0.1 based. I do need to ether find a way to kill OTG power with IG/ACC is off though. Is this best accomplished by powering the USB 5V separately, so doing something in tasker?

It will be in the dash, built into the cubby door actually. I have another mount for my iPhone that I'll keep using for music, calls, or whatever. I want to auto on-off functionality with it in a super deep sleep mode when off. When it turns on I'd like it to go to some launcher that would have BTSSM, waze, and android auto quickly accessable. I remember seeing apps that did the latter back when I was using android, so it's more the startup/super sleep automation that I need help with.

Eh, kind of three. There is a small one on the boost control lines, the blue one, and a big metal one combining the evaporative emissions lines. Then there is a metal pipe tee thing in the PCV system.

Is there a good way to go about this WITHOUT using Timur's rom? I'm trying to build a mini version with a phone, and have been using iOS so long I dont know where to even start over in Android land.

The wastage controll stuff does not touch manafold pressure at all. It's source comes from a nipple on the turbo, it flows through the boost control valve, then a tee (NOT THE BLUE ONE), then into the wastegate. This line should be going to to the blow off valve after the blue tee.

The tap off the BOV line via the blue tee goes to the top of the mechanically controlled purge valve. That plugs into a nipple on the back next to the PCV and break booster nipple. MAP sensor comes off it's own nipple on the front.

Yep, you have that hooked up correctly. The map sensor should go to the port on the front next to where you plunged the solenoid in. I think you have the pressure reference to the mechanical purge control valve plugged in there. Why is your boost control solonoid on the same line as your MAP sensor?

Under the intake manifold, next to the MAP sensor and boost control solenoid. it's a two port solenoid.

I zeroed out the MAF load compensation table this afternoon and things got MUCH smoother at idle and low load. That said, I don't think "zero" is the correct answer, there was still a lot of fueling compensations happening but it was subjectively smoother. fahr_side has a post about actually tuning this table, and empirically it appears Cobb's suggestion to tune if you screw with the FPR or it's reference is quite valid. My system is simular to the STI fuel pressure regulator/sti pulse damper setup but using Radium parts.

The filter is supposed to be inline with your MAP sensor, not purge valve. It smooths out the pulses to get a cleaner signal. You can also just delate the mechanically actuated purge valve, the main electronic one does 98% of the job anyway and it wont toss codes.

Wow... So far the list of things that can screw up an O2 sensor reading AFTER air and fuel are metered: Ignition Timing Spark gap AVCS/CAM advance/duration Injector Timing Based on the that logic I'd also expect if ones valves are out of adjustment to cause odd readings as well. Maybe the tech who did my airbag wasn't wrong about adjustment being off, even though my heads were refreshed 4000 miles ago. I wonder if the ELH have an effect as well. Did you notice a direct change in your logs just from swapping the headers? If you want a fun read the official does timing change afr debate thread over on romraider has some other theories.

Ignition dwell on A2WC522N (ecuflash def): <table name="Ignition Dwell" address="cd70c"> <table name="Engine Speed" address="cd6b8"/> <table name="Battery Volts" address="cd6f8"/> </table> Edit: I'd advise anyone else that runs across this to be extremely careful. A little bit goes a long way, and it's probably not needed unless you're messing with the gaps. Edit2: Just FIY Subaru uses the same dwell calibration on the GroupN roms as our stock table

This is making my head hurt... So with all of this, the standard method of adjusting a MAF curve using a wideband appears like it'd give bogus data if the rest of the tune wasn't perfect. It also sounds like this might be involved with my lean above 6000 RPM issue: maf and injector pulse width stay about the same, but wideband starts reading significantly leaner. If you're going through the hassle of increasing the gap on your plugs to try and improve flame front propagation, have you considered using NGK SILFR6B8 or LFR6ARX-P plugs instead? The SILFR6B8 is stock in the '10+ Legacy GT and 3.6R and has a different ground electrode to expose more of the spark. http://legacygt.com/forums/attachment.php?attachmentid=248718&d=1493920657 This is of course sales data so take it with a gain of salt, but it's sowing the propagation from time of spark with a highspeed camera. Top is the one with the projected platinum nub, middle is like our OEM iridium plug with a rounded ground, bottom is a standard copper plug with flat ground. This should produce an effect like you're going for while keeping the gap shorter. Also not sure if making the gap larger alone incenses the spark energy. True voltage will go up, but the fatness/hotness of a spark is related to the current flowing through it and total energy has a time component. There is only so much energy in primary winding to generate the spark, so ether current or time is likely to decrease with an increase in gap. To keep these the same you may need to increase the coil dwell. I've not done a lot of research into this though so could be off base.

Found a study that talks about O2 in the exhaust and engine timing. It appears that advancing the timing more can cause higher peak pressures resulting in both fuel and oxygen getting taped in areas it wont burn. These come out at the end of the cycle after the flame is quenched, and thus can screw with O2 sensor readings. Optimally gaped plugs should make the mixture light off and propagate quicker, so should have the same effect as advancing the timing. Study and the effects of ignition timing on gasoline engine performance and emissions So the question is does this change the true effective AFR, or is it just messing with out ability to measure things?

Ok this is bothering me, why would regapping your plugs effect fueling? Air entering the system is metered at the MAF way up at the intake. The ECU takes this and calculates how long to open the injectors to create a given air fuel ratio. How does this change due to anything happening after the intake valves close? Also if your spark was being blown out, shouldn't that cause the AFR to READ lean due to more unused oxygen being present in the exhaust?

Even though I'm 7 years late on the project, do I get to be your intern if I crack it? Looking at the code in a hex editor this is simpler than the ECU code at least. Lots and lots of lookup tables, and blank space in the code. I suppose we're going to have to use to find the SSM routine and start by looking at the variables that populate those values. I think this is how they got started pulling apart ECU's. You can kind of make out where some of the shift point tables are just looking at the values, and they are a lot bigger than the Subaru XT TCU tables that have been published. Trying to get IDA setup now..... Edit: Anyone figure out the code entry point yet? The bootloader (or at least all of it) isn't in the ROM file. It looks like the first two pages of the flash (0x0000, 0x4000) are maybe part of the bootloader code of calibration data. The 0x8000 page starts looking more like the "program" portion of the code, but I havent found the entry point yet.

There hasn't been a good quality dump really avalible. Some more private groups appear to have had them before (subi disable crew has the '08+, a well know tuner from Australia mentioned looking through the tables in the earlier ones). IDA should be able to work with this the same was as some earlier evos and Subaru ECU's. Not sure if a flashing method is on hand but if you can see how the thing responds to inputs, you can modify what you're handing it from the ECU to optimize what's there. Edit: if you want to try and take a stab at it, they have the M32R documentation showing it's memory maps and want it here: http://www.evoscan.com/technical-vehicle-manuals/17-evo-ecu-dissassembly Edit2: The data sheets on that page aren't quite the right ones, you'll need to find one for a M32170F3, M32174F3, or M32182F3 depending on what's really in there. Likely it's the former, but the memory map appears to be the same other than total ram space.

Yes. Flexconverter.com has a plug and play harness to do that if needed.