cj

Yep that black box about the size of a cigarette packet stuck to the side of the right hand fan shroud is a fan controller on the 3.0's. It is indeed fed pwm by the ECU. I can stick a meter on one in the next couple days and let you know

I dont know much about that exact kit, but if you put a cable throttle body on any engine engine, run a cable from the accelerator pedal, and mount a TPS on it, then yes you can convert to cable throttle. For idle, you either need an idle air valve of some sort, or you need to use ignition idle control combined with careful adjustment of the throttle stop screw.

I'm not sure if the altezza factory wiring (and therefore plugin) have this, but all wire in ECU's need an ethrottle relay wired to them. If the ECU detects a malfunction it cuts power to this relay and the throttle goes back to its mechanical idle position (usually 3-5% open). If it's not in the factory wiring you could certainly cut into a couple wires to add a relay that does this. There is nothing that can be done however if the blade mechanically jams open as even cutting the power will not close the throttle. You cant have a fully configure cable & ethrottle at the same time. If you configure ethrottle and all the safety's, the engine might cut out in an error condition but it should prevent the type of dangerous fault you describe where it gets forced open.

Is this something you've measured? the spec sheet for a couple of the lambda controllers for 4.9's (inc link's can-lambda) say max 8amp during heating. It wouldn't be the first time a spec sheet has been over-zealous with its safety margins so i'd love to know the real world number. I should go put an amp clamp around one myself....

the sensors can draw up to about 8amp each during heating phases. if the fuse behind that factory wiring is say 20 amp then its fine. if its a 5 or 10 amp fuse, you will probably pop it

You have a wiring problem. It sounds like you checked a lot of it already, so maybe a pinout problem on the sensor? Have you checked continuity of the "signal" wire back to the right pin on the link ecu? (an volt 2 should be pin10). It could also be that somehow that signal wire is grounded somewhere else in the chassis - unplug the sensor and the ecu and with a multimeter check for continuity from that pin to ground, and from the pin to each of the ground wires in the ECU plug. One way or another, the ECU is seeing ground on that MAP input, not a real signal. Tuning cant fix that. Your actual received voltage on that input is 0v. When the ECU considers this a "real" value (not an error condition), it reads this as 0kpa MAP (so -100kpa/-14.5psi MGP), which will throw you into a bad part of your tune and it wont start. When you tell it 0.05v is the threshold for error condition, this causes it to go into error state and use the default value of 100kpa (anv2 error value), which just happens to equal 1v on that calibration by the looks of it. This is going to be very close to what your MAP really is during startup, so the engine starts. It probably runs like a dog though because it wont be seeing 100kpa at idle so again you will be in the wrong part of your tune for fuel/spark.

How are you testing this? If its by switching the AC on, thats likely because the "AC is active" signal from the ECU isnt getting back to the AC computer (AC amplifier in the toyota manuals), so the AC amp probably isnt turning on the fans in response. There are no wires directly from the ECU to any rad cooling system. The only wires from the AC amp to any engine related systems are: (on 3sgte's) 1)AC Amp receives a tacho signal from the ignitor. It uses this to disable ECU above a certain rpm, so this has no impact on cooling fan behaviour. 2)ECU receives an input signal from the AC clutch relay so it knows then the AC amp has turned on the AC clutch. (on non turbo's) 1) ACT signal from ECU to AC amp when grounded disables AC - ie at high RPM 2) ACA signal from AC amp to ECU to tell the ECU when AC is active (for idle control) - pretty sure it grounds it when AC is active Best guess... you have the ACT pin grounded because of a config in the LinkECU, and you are testing the fans by turning AC on. In this scenario, the AV wont actually turn on and so the fans probably wont either. At idle it can take quite a long time to get the radiator up to temp to have the fans come on normally. If you want to force a test, mess with the water temp sensor in the radiator - either pull it out and put it in boiling water while still connected (if you can block up the hole), or disconnect the sensor and it should turn the fans on (if that fails, try shorting the pins instead).

Which model car is this in? The sw20's factory wiring has the radiator fans controlled independently from the ecu - non AC models its just a temp switch in the radiator, AC models its a temp sensor that feeds back to the AC module and this controls the rad fans.

can you also post a log of you trying to start it? I suspect fuelling as that fuel map is pretty messy. Its closer to a modelled fuel map than traditional mode, but its probably a long way off.

good point... is that 20 deg from a ecuflash dump or similar, or is it a live runtime value from freeSSM/obd data?

Black wire to s-gnd, green wire to any of volt4-6. Then configure that ANVolt channel to be lambda1 in the ecu. connect red & white to switched power (from any relay) & to chassis ground.

Couple of things to check 1) are there 2x timing marks on the pulley / does the service manual say that the 1x mark you have is at TDC or at -10deg? If the mark is 10deg off where you think it is, your whole tune could be 10deg out and so 20deg factory is exactly equal to 10deg on your tune. 2) if you look at the crank pulley is there any damage or cracking where the outer part of the wheel attaches with a rubber section to the inside section. If the outer edge of the crank pulley has moved 10deg then this would have the same effect. Depending on how much access you have to the front of the engine you could set it to TDC from the crank pulley, then pull the pulley off and see if the marks on the block etc match TDC - maybe the marks on the pulley are wrong.

Your high idle is caused by 2x things The first 4-5 seconds is because for the first 4.5 seconds after initial startup, the ecu adds the "startup step table" value to the TPS target. So instead of 7% TPS you run ~10% for 4.5 seconds then it goes back to normal ethrottle target at about 1400rpm. You probably want a bit of this behaviour but can tweak it down a little bit so its only adding 0.5 or 1% maybe. Fix this second once you have the base idle values correct. The second problem is that your base idle table is quite high, so in open loop idle you would be running 7-8% TPS which is why you get 1400-1500 rpm idle for the first 30 seconds or so. After that, closed loop idle control pulls enough% out of the target to lower your RPM to ~1200. At this point you are more in the 4.5-5% TPS range. Remember TPS target is ethrottle table value + base idle value + any other values. "3% base idle step" does not mean 3% of your target number (ie 3% of 5%), it means 3+5 = 8%. To fix this, i would take 2% off either all cells in your base idle table, or 2% off all values in the 0 row of your ethrottle target table. Either change will means your open loop idle is ~5% where it needs to be, and so closed loop will have very little to modify. This will also mean your inital startup TPS% is 2% lower, which may be enough to fix that issue as well, hence why you fix this first.

sounds like a triggering issue. grab a trigger scope while cranking the engine and see if you are getting any signal on crank and cam sensors.

Run each of the spark tests and confirm you have the correct coil firing for 1-4, and that there is spark occurring during each test. If no spark, check the wiring to your coils. If you do have spark during a test, then start looking for trigger errors - do you see rpm while cranking? Can you grab a trigger scope while cranking?

I suspect you have 2x inputs configured as lambda1, one of them is dicsonnected or in error state of ~32:1 lean, and the "Lambda1 AFR" number in runtimes is the average of both. Your gauge down the bottom says "AN2 lambda" on it so the sensor connected to AN2 is showing 14.5:1 which I assume is correct. Check you config for another AN input also configured as lambda 1 and change it to off/lambda2/figure out why its stuck in error state

From the help file Most of what people are talking about is the ~500Hz limit on the non-thunder models. In reality these allow a fair bit over 500Hz (maybe a few hundred higher depending on model + other input confgs), but they start reading 0 if you exceed 500Hz by too much. The thunder can accept 6.5Khz on DI11-16, which means with a 45 tooth ABS wheel & a 285/35 R19 tyre, you will be doing ~1000kph to max out the frequency input. So as long as you wire the ABS sensors to the high numbered DI's on your thunder, you'll be fine.

From a couple docs on the EMP site it looks like you either need to sign up to get access to their docs pages, or you buy/build a serial->usb adaptor and wire that into the serial pins on the 6 pin connector. You then download the control software for their pumps and connect your laptop to the pump. It looks like you can then start setting up CAN id's that it will respond to. I imagine you either give it some paramaters for on/off & then send coolant temp over CAN, or you send it an on/off control over CAN and do the hot/cold/post run logic within the ECU. Either way, it looks like you need to see from that software what info the pump wants, then configure CAN transmit from the ECU to provide it on the correct ID + bytes. regarding the pumps, there are probably a dozen ways to do this, but heres a couple... If you have enough inputs & outputs you configure each pump with a relay controlled by its own aux out. you configure the first one as Fuel Pump, then set the next 2 as GP output with conditions of something like inj Duty cycle 30%+ and 60%+. For the 4th pump you configure it with a condition of "Virtual aux 1 ON" You then set virtual aux1 to be labelled something like "fuel pump failure", and you set it to enable if any condition matches, then put a big stack of conditions around ANV1 too high/too low, ANV2 too high/low etc, or if your diff fuel pressure drops below a cetain value. This way pump 4 comes on if any of the other 3 show an error condition from your arduino feedback boxes, or as a final safety if fuel pressure drops low for any reason. Because thats a lot of conditions you may need to chain 2 or 3 virtual aux's together to catch them all. if you're handy with an arduino you could make a fuel pump controller out of one with a canbus shield & do this same logic in there, and just feed the arduino "instant fuel consumption cc/min" over CAN, then configure the arduino with some simple logic about expected per pump flow so it turns on relays to individual pumps when the ECU is using say 75% of the currently enabled pump capacity. feed the arduino "diff fuel pressure" and/or that "fuel pump fault" status via CAN and have it kick the 4th pump on if any of those are set. [edit] or you wire the first 3 pumps to individual solid state relays, and control them all off a single ECU output configured as fuel pump speed or GP PWM, and you configure one of the various PWM options in the ECU. that wont "stage" them as I assume you wanted, but it will mean they are always running all the time so you wont get the "higher up" pumps failing silently, or inrush current happening repeatedly if you are just on the edge of a duty cycle threshold.

You shouldnt need to convert the speed pulses. The 17 pulse per rotation should be ~500mph when it maxes out the frequency limits on a DI which is probably enough. Depending on how far apart these steps are in your calendar, you can either a) not worry about the gearbox speedo drive, just dont have a speedo for a bit then swap to using ABS inputs when you have them wired/configured. The ECU doesnt care where it got the signal from, as long as you can tell it at least 1x wheel speed it can be configured to work as vehicle speed etc. More wheel speeds just gives you more options. It doesnt strictly need a speedo input either, it just means you can have various settings change based on vehicle speed. b) configure the gearbox based speedo as RL or RR wheel to start with so you have working speed input (and I assume pass through to vehicle speedo via an Aux out). Then once you wire in all the ABS wires, change this back to a GP speed input so it becomes just a data point but not used for anything. This way you wont have 2x speed inputs for the same wheel.

Can you post a log of you starting it up so we can see the surging behaviour? The last log shows it already running

The problem with GP speed inputs is that they cant be assigned as driven/non driven wheel speed, so while you can log it etc and even pass it through to an output PWM signal to other devices in the car, the internal logic in the ECU wont treat it as a vehicle speed source - so things like idle control wont be aware of vehicle speed & the speed based lockouts wont work. Have a look in the Chassis -> speed sources section of the config. To get traction control to work you need to set a source for driven & non driven wheels, and your options are only combinations of the 4x wheel positions. If you are planning to pull in per-wheel speeds in via ABS signals or something, you dont really need the gearbox speedo drive at all. If you are not planning to use ABS sensors, you need to think about how you are going to measure speed on a non-driven wheel as you need this for traction control

From what I can see about factory tyre size & diff ratio, 17 pulse per rev on the output shaft is roughly equal to the "standard" 4000 pulse per mile used in a lot of vehicles. You should be able to read this on any DI - you dont even have to use the special high frequency ones on the thunder. As you say, just 1 wire to ground (or sensor ground from the ECU), and the other to the ECU input. Pick any digital input and configure it as LR or RR wheel speed input. Set the calibration number to 235 to start with and see how accurate that is compared to a GPS. This should be similar to the hall effect sample config except you dont have the 12/5v wire running to the sensor.

those dead times are very close to what's in your tune already. I dont think dead times are the problem. At the lower end of the static flow rate slope, injectors start to flow non-linearly. Some manufacturers put out short pulse adder tables to allow compensation for this, but I cant find one for those injectors online. You could try emailing bosh directly? A 2200cc injector at idle will almost certainly be running in the non linear range. Or you could try very gently adjusting the couple of cells it is moving between at idle until you get it pretty close.

what injectors do you have and can you get short pulse adder data for them? You are running ~0.7ms @ idle which is probably in the non linear range for the injector and so the ~0.1ms change in fuel the ecu is requesting may be 20 or 30% difference in actual fuel injected. ignition angle, stepper motor dont change at all so its not the ECU changing them badly. VVT is not set up, and especially on the run where you have the idle screw set at ~1krpm, the fuelling is the only thing changing with rpm. you might be able to tweak the fuel table up or down a tiny bit in the cells its bouncing between at idle, but better injector data is probably the long term fix.

can you get a scan tool hooked up to it or some other thing that can display steering position/torque sensor output as the EPS ECU sees it? then go wiggling some wires between the torque sensor and the EPS ecu. if the sensor test ok, and you have intermittent (cold) errors thrown for it, then I'd be suspicious of wiring issues like corrosion in one of the connectors or a loose female side in one of them