Jump to content
SAU Community

Recommended Posts

I have an R34 GTT sedan running with an R32 RB26 in it(R32 engine loom was modded to suit an R34 body, not sure who did the work), controlled by a ViPEC plug and play to suit an R32, my issue, is that the ECU has constant power - I can connect to it thru my laptop with the key off and out of the ignition. This causes a few issues - ie running my battery flat... and it also has the effect of not performing the tachometer sweep and fuel pump prime when the key is inserted and turned to the on position as well as causing the the car to run on for a few seconds after being keyed off. It still starts and runs fine and NONE of the other items in the car - stereo/defis/boost controller stay on with the key off.

The tacho sweep and fuel prime issue are definitely caused by the constant power as the ecu cannot tell that it is being keyed on, since its already on and so will not perform these functions like its just been turned on - If cranked but not allowed enough time to start, when the key is returned to the on position from start, the pump primes and tacho sweeps like normal.....

There is a brown relay(not definite on what it's for) that is situated near the ecu under the kick panel on the passenger side, I have found that it has power to the switch/coil side all the time as even with the key off you can hear the relay click when plugged back in, which means whatever it is a relay for would be getting power all the time - perhaps the ecu. I think it IS for the ecu as when this relay is not plugged in I cannot connect to the ecu at all and the car won't start. Also when i remove the relay instead of turning the key off with the engine running, it shuts off immediately, thus fixing the running on issue, which I was sure WAS related to the constant power problem.

I've checked the plugs/wires etc for any obvious breaks/shorts but have come up with nothing so far. The problem here is the harness isn't in the best condition, but still functioned fine up until a couple of days ago.. - like I said before I'm not sure who did the work to join the two harnesses together.. I've had the good fortune of being able to compare voltage readings on my harness to an actual R32 GTR that works fine and found that mine had constant battery voltage at pins 49 & 59 with the key off, while the GTR did not, which is what originally led me to believe the ecu was on all the time.

At the moment I'm convinced i'm just going to have to check the whole harness and hopefully find something that doesnt look right.. this will be harder than it sounds due to the harness not being a single factory harness, but an very average amalgamation of two factory harness' :/ and not a lot ACTUALLY looking right anyway :P

Sorry about the long post, anybody else got any other ideas or come across something similar. Oh and the car had been running fine with this setup for around 12 months prior.

Josh

Link to comment
https://www.sau.com.au/forums/topic/373279-ecu-constantly-powered/
Share on other sites

Sounds like you're close to the money with that relay. Start by tracing the switching side of the relay backwards. It'll have to go to an IGN relay or the IGN switch somewhere. See what you find. You'll need a good multimeter to check continuity. Check for dodgy taped-up wiring, that may be touching a 12V constant together with another wire.

I'm still wondering what the relay is exactly for, its not a normal relay, it has six pins, instead of the regular four, and going by the diagram on the relay itself two pairs of the pins are switches, the third pair being a coil... With it unplugged and the key switch in the on position, the fuel pump runs constantly, but no ecu power, with it THEN plugged in it does its normal tach sweep and pump prime for a few seconds. It must be the power relay for the ecu yeah?

The ECU turns itself on and off using the ECCS relay. This gives it time to save settings etc before it turns off.

So...start by replacing the relay, maybe it has failed and is constantly on. Or even easier, replace the ECU with a known good one and check again because it could be a simple short internally

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...