Jump to content
SAU Community

Recommended Posts

Well the most likely reason for it is the TCS, or lack of it. As I transplanted this engine into a GT shell, at the time I decided to scrap the traction control as it was going to be a bitch to wire up and I had no use for it. Had been planning on going forward facing anyway, so I would have just had to delete it again anyway.

I wasn't aware at the time that it would cause so much trouble with DTC's. Even with the feedback switched off, the ECU would still pull timing. So after talking with Matt and Pete, I sent the ECU to Matt and he bench tested it and reprogrammed it with a SII Stagea image to get rid of the DTC's. Since then I haven't had it back on the dyno so I never 100% confirmed that this had been the issue, but it didn't once misfire since being reprogrammed, so I think that did sort it out. Then I decided that if I needed to get it back on the dyno anyway, I may as well upgrade to ID1000's and put on the Plazmaman plenum beforehand. And that brings us to now, with an ECU that no longer works :(

the r34 thats giving me hell on e85 has the plazaman plenum too... it went backwards too. Its fine on 98 but lost lots of mid and same top end as std plenum.

Sounds like you exhausted all avenues.

  • Replies 125
  • Created
  • Last Reply

Top Posters In This Topic

We use the GT101 sensor and get a mounting bracket made. Currently CRG are making them for us and we are going to try the Kulig Engineering ones.

If you hit up R33_Racer on the forums here he could possibly give you more information on their kits as we are yet to use it but it's very small and compact.

The ones we use from CRG are larger but so far very stable.

  • 1 year later...

Right, just a lil recap.....

Since this thread was started for recommendations for a piggy back ecu for the 1JZ, I thought i'd just keep it here one time....

I have a JDM 2Jzgte vvti auto in an Atisto and have been busting my balls trying to find a simple ecu just to tidy up the afrs and timing with the addition of a wmi kit (only 95 here) and boost up of a few psi. Its going to remain stock turbs, inj etc.

Was also looking for one that would have a boost cut control(clamp) and a speed cut control so I was leaning towards the emanage ultimate. I browsed through the supra fourms and have gotten lots of conflicting reports about the emu so just throwing it up here for advice.

My main concern is timing control and the issue of the stock ecu fighting the emu

So what do you guys think? And any other recommendations without busting the bank?

Thanks, will have a look into it now smile.gif

Also...anyone who has used the current wolf ECU's...is there any way of changing the load scale from percentage to a pressure readout?

because to me % of load means nothing

Know this is a really old post but there is good reason for that. Load doesn't equal PSI or anything like that, with a MAF load equals airflow and you can have 10x the airflow at 10psi at 7000rpm than you do at 3000rpm with 10psi, hence the scale is in load.

When using a MAP sensor pressure * temperature is used then scaled in a curve that looks very similar to the torque curve to give you a fairly linear load scale. MAF will always be more accurate as when using MAP you basically have to guess airflow.

Right, just a lil recap.....

Since this thread was started for recommendations for a piggy back ecu for the 1JZ, I thought i'd just keep it here one time....

I have a JDM 2Jzgte vvti auto in an Atisto and have been busting my balls trying to find a simple ecu just to tidy up the afrs and timing with the addition of a wmi kit (only 95 here) and boost up of a few psi. Its going to remain stock turbs, inj etc.

Was also looking for one that would have a boost cut control(clamp) and a speed cut control so I was leaning towards the emanage ultimate. I browsed through the supra fourms and have gotten lots of conflicting reports about the emu so just throwing it up here for advice.

My main concern is timing control and the issue of the stock ecu fighting the emu

So what do you guys think? And any other recommendations without busting the bank?

Piggy back is always a hack and a bad idea, do it once do it properly, just because people make them work doesn't make it a good idea. Get a full aftermarket ECU and piggy back it if needed for other functionality (eg auto etc), however never piggy back the fuel and ignition, it just makes them fight each other making tuning a nightmare.

Can you get a nistune equivalent for supra ECUs? If not adaptronic at ~$1k will be fantastic, tuning is always going to be the bulk of the cost with a full tune from scratch getting close to $1k, if you are just doing small mods a few hundred might be all thats needed to get it up and going.

Edited by Rolls

Yea I know the gremlins associated with piggybacks but I just cant justify spending that kind of money on a standalone just for a little 'tidy up' of the maps.....Tuning however wouldn't be an issue because it will be done by myself.

Haven't seen anything similar to nistune for these engines either, and the majority of guys who do go standalone go for the fcon vpro wired together with the oem ecu to control the auto box, as I think it also does the vvti.....and I dont think I need to mention tuning for this! :yucky:

Problem is there is info floating around, most based on the USDM supra, but not the 98 vvti models which either way seem to have problems with the emu, and on the flip side, some say the JDM versions work ok with it .

And there is lots about the aristo with the 2jzgte also, but again the older models without the vvti

Seems like the vvti ecu is a lil sophisticated like the r34, and hence very limited aftermarket tuning options available

Edited by Don Dada
  • 2 weeks later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



  • Similar Content

  • Latest Posts

    • First up, I wouldn't use PID straight up for boost control. There's also other control techniques that can be implemented. And as I said, and you keep missing the point. It's not the ONE thing, it's the wrapping it up together with everything else in the one system that starts to unravel the problem. It's why there are people who can work in a certain field as a generalist, IE a IT person, and then there are specialists. IE, an SQL database specialist. Sure the IT person can build and run a database, and it'll work, however theyll likely never be as good as a specialist.   So, as said, it's not as simple as you're thinking. And yes, there's a limit to the number of everything's in MCUs, and they run out far to freaking fast when you're designing a complex system, which means you have to make compromises. Add to that, you'll have a limited team working on it, so fixing / tweaking some features means some features are a higher priority than others. Add to that, someone might fix a problem around a certain unrelated feature, and that change due to other complexities in the system design, can now cause a new, unforseen bug in something else.   The whole thing is, as said, sometimes split systems can work as good, and if not better. Plus when there's no need to spend $4k on an all in one solution, to meet the needs of a $200 system, maybe don't just spout off things others have said / you've read. There's a lot of misinformation on the internet, including in translated service manuals, and data sheets. Going and doing, so that you know, is better than stating something you read. Stating something that has been read, is about as useful as an engineering graduate, as all they know is what they've read. And trust me, nearly every engineering graduate is useless in the real world. And add to that, if you don't know this stuff, and just have an opinion, maybe accept what people with experience are telling you as information, and don't keep reciting the exact same thing over and over in response.
    • How complicated is PID boost control? To me it really doesn't seem that difficult. I'm not disputing the core assertion (specialization can be better than general purpose solutions), I'm just saying we're 30+ years removed from the days when transistor budgets were in the thousands and we had to hem and haw about whether there's enough ECC DRAM or enough clock cycles or the interrupt handler can respond fast enough to handle another task. I really struggle to see how a Greddy Profec or an HKS EVC7 or whatever else is somehow a far superior solution to what you get in a Haltech Nexus/Elite ECU. I don't see OEMs spending time on dedicated boost control modules in any car I've ever touched. Is there value to separating out a motor controller or engine controller vs an infotainment module? Of course, those are two completely different tasks with highly divergent requirements. The reason why I cite data sheets, service manuals, etc is because as you have clearly suggested I don't know what I'm doing, can't learn how to do anything correctly, and have never actually done anything myself. So when I do offer advice to people I like to use sources that are not just based off of taking my word for it and can be independently verified by others so it's not just my misinterpretation of a primary source.
    • That's awesome, well done! Love all these older Datsun / Nissans so rare now
    • As I said, there's trade offs to jamming EVERYTHING in. Timing, resources etc, being the huge ones. Calling out the factory ECU has nothing to do with it, as it doesn't do any form of fancy boost control. It's all open loop boost control. You mention the Haltech Nexus, that's effectively two separate devices jammed into one box. What you quote about it, is proof for that. So now you've lost flexibility as a product too...   A product designed to do one thing really well, will always beat other products doing multiple things. Also, I wouldn't knock COTS stuff, you'd be surprised how many things are using it, that you're probably totally in love with As for the SpaceX comment that we're working directly with them, it's about the type of stuff we're doing. We're doing design work, and breaking world firsts. If you can't understand that I have real world hands on experience, including in very modern tech, and actually understand this stuff, then to avoid useless debates where you just won't accept fact and experience, from here on, it seems you'd be be happy I (and possibly anyone with knowledge really) not reply to your questions, or input, no matter how much help you could be given to help you, or let you learn. It seems you're happy reading your data sheets, factory service manuals, and only want people to reinforce your thoughts and points of view. 
    • I don't really understand because clearly it's possible. The factory ECU is running on like a 4 MHz 16-bit processor. Modern GDI ECUs have like 200 MHz superscalar cores with floating point units too. The Haltech Nexus has two 240 MHz CPU cores. The Elite 2500 is a single 80 MHz core. Surely 20x the compute means adding some PID boost control logic isn't that complicated. I'm not saying clock speed is everything, but the requirements to add boost control to a port injection 6 cylinder ECU are really not that difficult. More I/O, more interrupt handlers, more working memory, etc isn't that crazy to figure out. SpaceX if anything shows just how far you can get arguably doing things the "wrong" way, ie x86 COTS running C++ on Linux. That is about as far away from the "correct" architecture as it gets for a real time system, but it works anyways. 
×
×
  • Create New...