Davidv

Yeah if you were having problems with the VVTI it would end up not tracking well when you overlay target / actual position but it seems fine. If AFRs are looking good then I'd think you're getting some sort of misfire or spark issue as next thing to look into. Otherwise compression test / leakdown test I guess.

Hi, Injector Dynamics had a typo in their deadtime values on their website, which I emailed them about and corrected. However the stickied information shows the typo still. Easy to spot when you graph it: The great thing about the ID injectors though is that they have all of the deadtimes for all of their injectors listed on the webpage, so easy to reference that if anyone ever gets IDs: http://injectordynamics.com/injectors/id725/ So if they come out with something new they have great info available.

Hey Rob, There's a blacktop 3SGE basemap iin the standard ECU files that you can start from. I have started with the blacktop map and then just turned off the exhaust side VVTI, the factory trigger settings etc work for a redtop engine fine. Then from there you just need to reconfigure it to suit your wiring and the features that your motor has, I dont think a base map for fuel and ignition really helps much because it depends on so many individual factors from your engine. It's super easy using mixture map or datalogging to get your fuel sorted really quickly, the ignition timing in the base map is very conservative so you wont blow up your motor but you'll need to be wary of EGTs getting high as I melted an alternator from having a super hot exhaust thanks to this. I have some ignition timing and VVTI settings that I can share with you, which will be a "first start" but you'll still need to get your engine tuned to suit. The length of your intake runners will determine the shape of your fuel and ignition maps so my settings wont be exactly right for your engine, as well as that you'll be using TPS based load instead of MAP. Dont get too caught up on the idea of a base map to be honest it's all easy stuff. Where abouts are you based?

Wow thats a huge amount of positive pressure Adam! I need to sort out an airbox haha.

This is a pretty complex addition which ultimately wont tell you the actual power of your car. Virtual dyno is interesting but back to back runs in my car on the same flat piece of road on the same day in the same gear (Down meremere drag strip) provide quite different results. As in, even the shape of the power curve looked different between runs, as well as varying by say 5-10% power. Even with the smoothing set aggressively. Virtual dyno is very complex as it takes into account tyre size, diff/gear ratios, coefficient of drag, vehicle weight, driver weight, etc... It's a lot of things to add to PClink for what is not going to be an accurate output. I think there's merit in keeping the integrity of the information in PClink, as in, it reports IAT and that's what IAT is. Rather than stating that it's possible to calculate power when it's really a bit wishy washy how it does it.

Yes this is for 3SGE engine. When it starts knocking at low load, even if I pull the timing back by something like 15 degrees it still happens. Then other times it runs fine with way more timing. I am currently suspecting that my spark plugs are a range or two too hot - When it starts knocking spark plug temp gets way too high and then it keeps preigniting under some conditions. But I still think this other method for knock sensing has some merit. Yeah so for example you can have 0.1deg timing retard per % over the threshold that the knock value is. But this means setting you knock threshold correctly is super important, and needs to vary through the rev range, like it cant just be 20% above. Because the signal to noise ratio changes hugely through the rpm range. For example at 2500rpm I might have a background noise value of 10 or 20. Then when knock happens it spikes to 60. But at 5000rpm I might have a background noise value of 550 and when it knocks the value jumps to 600. So the % above either the value or knock threshold changes hugely, you cant set it to do both so normally this means to be on the safe side it will pull timing back to the minimum mount you've specified.

Yes something like that I think! It just needs to know "If engine is knocking, pull 0.1 deg per 10 milliseconds" or something like that. So to use the o2 sensor as an analogy,it would be nice if kncok sensing worked more like a narrowband o2 sensor. It doesnt know how much it is knocking, just that it is. If the knock level is any amount above the threshold, it just slowly pulls timing until it isnt anymore. This would make it more resilient to going over ripple strips / bumps in the road etc. Currently if you hit a big bump it will pull timing back by the maximum amount for a one off event, instantly. Here's a diagram of how knock sensing works currently (top diagram) vs how I think it would be more useful (bottom diagram) Theoretically, if you had the knock threshold set perfectly for every cell, and the knock settings perfectly then I think it could work pretty close to the 2nd example for genuine knock. But this seems impossible to do without inducing knock multiple times to set the threshold up or down in each cell. So most of the time, in my experience it works much more like the top example.

Hey, At the moment knock sensing works based on the amplitude of the signal over and above the set threshold. As in, if the knock signal spikes to 50% above the set threshold then (for example) it will instantly pull timing by 100% of the maximum timing retard. Which is great for instances where you want to instantly react to a knock issue to minimise damage to the engine. (full throttle) But the downside of this is that the knock trim maps never stabilize, the values go up and down over time like a sawtooth pattern. For example, let say 3500rpm and 30% throttle with 25 deg ignition timing and 23 degrees is what the engine can run to without knocking. With current system: Reported knock value is 50% higher than threshold, so it pulls 5 deg timing instantly, now at 20deg. Now no knock is detected, so it slowly reintroduces timing. When it gets to 23.5 degrees, it knocks again, and instantly pulls timing back to 20 degrees. At full throttle areas I'm happy with this system and how it works, I would rather pull 5 deg timing instantly than have my pistons hammer themselves into oblivion. However at part throttle/cruise conditions, knock does little to no damage, and it seems pointless to be stuck in this loop where the knock values never stabilize. The ratio of knock noise vs background noise changes through the rpm and load range too, so I cant just set the threshold to 20% over background noise values and have it work consistently across the whole range of cells. So I think it would be nice to have an alternative system for low load areas which works like this: Same situation, 3500rpm and 30% throttle with 25 deg ignition timing and 23 degrees is what the engine can run to without knocking. The engine runs at 25 deg and notices knock, (irrespective of how much its over the threshold) so it subtracts 0.25deg timing. (or 0.1 deg or whatever) The engine is running at 24.75deg timing and checks again, still knocking so subtracts another 0.25 deg timing. And so on, until it reaches 23 degrees. Then its happily under the knock threshold at 23 degrees, so it advances to 23.25 and it knocks. So it pulls back to 23 and it's fine again. Then maybe, it could have a maximum number of attempts to advance beyond the "safe" 23 degrees, at which point it will stop trying and hold it there. (If this is possible) If you pull and reintroduce timing over a longer timespan in smaller increments using this method, (Basically mirroring the timing reintroduction logic for timing pulling as well) then at the end of a drive you can look at the knock tables and get some results that likely reflect how you need to update your main ignition table. Currently you might look at the cylinder knock retard tables and see that half of it is at -5 degrees, but it doesnt mean anything because it might be that the engine hasnt run in that cell since the last timing retard. Another cell might show -3 deg timing pulled, but realistically it could run at -1deg but it just hasnt had time to get there yet.

Thanks! I've been tinkering with a few other things, however for the better part, the car is now running great. I am going to enter a series here called "Superlap" which is a time attack sort of contest that goes around to a few different tracks around the country. One of them is based in Cromwell, which is a 21 hour trip each way for me: Which is where cruise control just really shines! This is one of my favourite features so far, and one that I wasnt expecting to be available when I initially purchased the ECU. (I didnt have E-throttle initially either) I setup an injector test bench and used the advanced injector test function to work out accurate deadtimes and short pulsewdith adder tables for both sets of my injectors: Which made the staged injection work much much much better with changing temps etc. Also switched over to modelled fuel which works well. So just fine tuning things, because my outer injectors are 1000cc and spray at a reasonably low pulsewidth, injector timing is something worth spending time getting right. I tested this out and found that at lower rpm (when mainly using inner injectors) it's best to spray very early, onto the back of hot valves and let it vapourize the fuel. But as RPM goes up and switches over to outer injectors, it prefers the injection timing to occur as the valves are open and air is flowing into the cylinder. Which makes sense! I tested this by statically settting the injection timing to one setting across the whole rpm range, datalogging a run, then incrementing the timing forward, and testing again. Whereever the AFR shows as richest, that's where the best injection timing exists, as it's more efficiently mixing air/fuel so there's more fuel left over on the way out. The below graph shows degrees before TDC combustion on the left hand side, and RPM across the top, and the air fuel ratio in each of the boxes. Yellow highlights the best AFR acheived for each RPM range, it's pretty clear to see the trend where it starts transitioning after 5500rpm from 450BTDC down to 250BTDC.

I had my car up on axle stands for other reasons where I was time limited, so didnt test that unfortunately. However I do remember that my car was more jerky on the fllat initially but fine uphill, on default PID settings. Then it seemed to improve its behaviour everywhere once I'd toned down the settings. But is still a bit jerky on downhill. This isnt a particularly scientific observation though so I'll get some better data. Once I've fixed my speedo sensor, hopefully tonight or some time this week, I'll go out for a drive with some diffferent PID settings on the same uphill/downhill sections and report back.

Hey guys It looks like there's a plethora of products that monitor tyre temp/pressures, using transmitters in the wheel stems which is cool. I've recently bought some semi slicks and want to get the most out of them and ensure they arent going too high on pressure. Has anyone setup CAN-BUS with a G4+ to datalog tyre temps/pressures so they're viewable in the datalogs? Or otherwise, I've yet to find a setup that is a stand alone system that can datalog the results rather than just monitor in realtime. Does anyone know of a product which does this? Thanks

Hey, Just a few thoughts about cruise control. Firstly it's very cool and I love it Over the last few weeks my speedo signal has been very jumpy, which obviously prevents the cruise control from working well. I'm working to resolve it this weekend, but this had me thinking... It would be cool if you could set the cruise control to use engine RPM as the input rather than vehicle speed. Obviously would only work in a manual transmission car but would be cool to have the option of it seeking a goal rpm. Because the rpm signal is a lot more precise, and potentially a lot more stable too. Also I've found that cruise control will work nicely at a given speed (say 100kph) but then be too jerky at lower speeds. Thinking about this, I think it needs to scale its sensitivity based on engine load. If I have the car up on engine stands and in 5th gear so car is doing 80kph or whatever with hardly any load applied, holding that speed. If I turn on cruise control it will blip the throttle and it will rev up, then revs fall again and then a rev right up, it's quite jerky on settings that are otherwise fine while driving on the road. I think this is part of why cruise control seems to work nicely on the flat or uphill, but becomes a bit jerky on downhill, as this is when there is the least amount of load on it and it overcompensates with its throttle plate movements when it actually only needs very very fine changes in throttle angle. Maybe it could have a scaling sensitivity based on throttle angle or something like that. I think this would help it make it drive better at all speeds, including downhill sections. Also as previously mentioned it would be cool to have a button allocated to populate the target speed, for example have a button that sets cruise control to 55kph or 105kph or whatever. Rather than having to pay attention to speedo to set a speed, when there's only likely to be 2-3 goal speeds that you're ever trying to set.

Hi Mike, I've been planning to run a nitrous setup like this: Aux in - 1600psi Bottle pressure sensor aux in- arming switch Aux out - relay to bottle heater aux out - relay to nitrous solenoid(s) aux out - relay to purge solenoid and then run it as a dry shot, activated by a virtual aux that ensures bottle pressure is high enough, arming switch is armed, and it's above a minimum RPM. Also have a virtual aux that runs the bottle heater if you've armed the system, until the bottle pressure reaches a goal target. When nitrous activates I was planning on having the ECU switch over to a 2nd fuel map that has RPM and bottle pressure as the axes. As your nitrous flow varies with bottle pressure. I'm not a fan of a wet shot, because the nitrous delivered changes with bottle pressure but the fuel delivered doesnt. So if you tune it for say 900psi bottle pressure and its spikes to 1000psi you'll run lean. If you've got enough inputs and outputs, and injector capacity then an ECU controlled dry shot with a pressure map is way superior in my opinion.

It's a log file that's been recorded directly to a laptop, so it includes all known loggable values

Hey, If viewing a datalog, the runtime values seem to be frozen at the last instance of time from the log. Is there a way to view them through the log? Or get the same information some other way. Thanks

Just an update on this... Recently I've found that closed loop feedback from the wideband sensor hasnt been working, I saw that there was potentially a firmware issue so presumed that was the cause. Updated to next firmware, but still the same issue. Hmmm. I check the runtime values and find that the wideband is disabled because launch control is armed. (weird?) I find out that part of the launch control setup (I havent used this in 6 months) was to be partially activiated by Virtual Aux 2 which I've since reused for something else as I assumed it was unused. Hence launch control armed, hence wideband not working. I never thought to look under the launch control menu because I thought from memory launch control was only activated by a DI. If under the menu of virtual aux 2 though, it told me that it currently triggers the launch control condition. I would have known straight away to disable it. (or use a different virtual aux) Currently the only way for me to find out if virtual aux 2 is used by something is to scour through every single menu. Maybe each DI / cal table etc could have something like this? Having the "links" between DIs etc would be an extra safety net to help prevent some absent mindedness on my part (and other peoples) from causing some unexpected issues! On a similar topic, being able to label DIs and cal tables etc is now a bloody awesome addition, and certainly cuts down the odds of the above situation happening hugely. So thanks for that. Part of the reason I had this problem above is that I had not labelled the virtual aux when I was using it for something else. So I make sure to always label everything now, 100% of the time. But I still think it would be nice to have some sort of extra safety net, especially for people running the Thunder etc where there are so many inputs and outputs to manage, which can be set up for all sorts of weird and wonderful things. Thanks

Hey Ken, I believe that the reason wasted spark gets the engine going quicker is that the ECU only needs to find crank angle position in order to get the motor firing. Instead of waiting for cam angle as well. In 720 crank degrees of rotation you get two crank angle sensor signals but only one cam angle sensor position. Engines which have reluctors as the cam/crank angle sensors sometimes have a little trouble establishing when the engine rpm is very low (like 100rpm or whatever) so reducing its dependency to just one of the sensors means that it'll start up a lot quicker.

Thanks guys. Last night I tried the different options for rising or falling active edge, and turning off the pullup resistor. Seemed to improve when set to rising edge and no pull up. But it would still have issues, especially past 100kph. Interestingly it seems to get worse with a rise in engine rpm, if I try hold the engine at 4000rpm the speedo signal throws its toys out of the cot. Even if at a lower vehicle speed. So perhaps that is indicative of needing shielded wire. I'll check the sensor first and then report back. It's a 3 wire type that has a 12v power supply to it, is there any chance that perhaps it's supposed to be 5v supply?

Hey guys, Just wondering if any ideas on this. My wheel speed signal jumps around a bit, it will spike to a very high value momentarily then go back to normal. I've examined the length of wires that run to the sensor for any exposed wire or breaks etc but it seems fine (although I guess it could still be an issue) and I suppose a faulty sensor could be a problem as well. But it just seems weird that it only happens once in a while, just wondering if anyone's had the same thing before. It's a Toyota altezza 6 speed box with the speedo output wired directly to ECU, does not go through the dash etc. I guess next thing to try is replace the speedo drive, then if not that replace the wiring if there are no ECU settings that I've selected wrong etc. Here are the settings I'm using for it as a DI.

In the release notes it says "Fury Internal Lambda now updates Lambda Average correctly." However I was having the same issue with Lambda1 not working to correct fuel trims etc (fixed when rename it to Lambda 2) on a red xtreme. Will this have fixed it for the xtreme as well or just the Fury?

If you're running Injector Dynamics injectors, their website has full 3D deadtime info for you to use. http://injectordynamics.com/injectors/id850/

Ahhh never mind I think I just answered my own question... The axes of the fuel table are independent to the load axis that is specified in the modelled fuel setup (which is currently MAP) So it always references to MAP (which is good!) Cant wait to give this a go

Hey guys, I'm going to setup nitrous using modelled fuel and just wondering what best practice would be here. I'm going to have a bottle pressure sensor, and since nitrous only triggers at WOT I figure that it probably makes sense to have a second fuel table with axes as RPM and bottle pressure. But how does this work when MGP is a necessary part of the fuel equation? Like if it says VE 150%, 150% of what if it's not looking at MGP? Or does that just happen in the background to establish VE anyway. Or does it just look at bottle pressure. Another issue is that when nitrous activates my goal AFR changes from say 13:1 to 11:1 at the same WOT part of the map. Due the the incredible cooling effect of nitrous, I'm going to see a massive drop in IAT that isnt necessarily accounted for in time, Also the fuel charge cooling coefficient changes dramatically. Thoughts on this? I'm thinking none of the above is likely to actually matter as it'll be running fairly rich anyway. But wondering if anyone has done something similar. Thanks

The knock sensor puts out a knock signal all of the time, so if it's only showing for 1 cylinder then it'll be something in your config. If you post up your tune file here someone will steer you in the right direction.

When you've changed away from MAP referenced, do you still have a vaccum line on the FPR? If you dont have a vaccuum reference, then you need a 3D deadtime table. If you're using a 2D table, it's possible that the ECU is extrapolating the deadtime just from that single row and coming up with some weird numbers. Check in the log and sanity check the deadtimes / make sure they match your table. Your injector deadtimes stay a lootttt closer to values on a 2D table when you keep the FPR vaccum referenced. (regardless of whether you're monitoring fuel pressure)