Jump to content
SAU Community

Recommended Posts

As title says In the last month after turning the car on to warm up and on 3 occasions when I turn the headlights on the whole car shuts down.

I then have to turn ign off and start again and its fine.

I have a 1 year old battery which I replaced with a bigger one. I dont think its a battery thing.

Has anyone else experienced this before?

As title says In the last month after turning the car on to warm up and on 3 occasions when I turn the headlights on the whole car shuts down.

I then have to turn ign off and start again and its fine.

I have a 1 year old battery which I replaced with a bigger one. I dont think its a battery thing.

Has anyone else experienced this before?

never heard if it before........ something to consider even tho the likelyhood isnt great.

all M35's have an auto/park/low beam setup ?

if so could the auto selection be shorting out on something ie: you had foggies and they cut the wires and they are shorting out...... but this should blow the fuse not mess up the ECU.

also the power consumption of the headlights shouldnt have enough of a serge to make the car stall, but in saying that maybe a coilpack is playing up? (just another idea)

also check ur relays there could be a damaged one.

maybe an auto electrician can tell you more............. i usually play with 240V not 12V :)

cheers, Theo.

i usually play with 240V not 12V :)

cheers, Theo.

I usually play with anything upto 275000V also. Yes your right I would blow a fuse if I had a short.

I dont think its a coil pack yet because its only shut down when the lights are turned on. But I am thinking something HV. I think the headlight transformers are breaking down to earth on the HV side and the ecu isnt liking it.

so unplug the headlights at the headlight unit one at a time and test by turning the switch on.

see if it only does it with one etc. you appear to be a sparky, use your head :P

if it still stalls with both headlights unplugged, its somewhere in the switch or the loom.

when they automatically turn on, does it stall too? if not, its not the headlights, its probably the switch. i have a spare if you think thats what it is

Sounds like a bad earth somewhere, I changed the battery terminals over to the larger ones for a better connection and fitted earthing wires around the engine bay, do you have an earthing kit? Check all the earth connections on the engine as they are known to corrode.

The BCM under the inside fusebox controls the headlight switches, I would think it then goes to the relay board behind the battery. Check all the plugs on that too.

so unplug the headlights at the headlight unit one at a time and test by turning the switch on.

see if it only does it with one etc. you appear to be a sparky, use your head :P

if it still stalls with both headlights unplugged, its somewhere in the switch or the loom.

when they automatically turn on, does it stall too? if not, its not the headlights, its probably the switch. i have a spare if you think thats what it is

I smell what your cooking. The problem is it has only happened 3 times in the month I cant fault it when I try it again a few times. I hate finding intermittent faults. I will try leaving the lights on auto and see if it does the same thing over time.

Also it dosent just stall it goes completely dead all dash lights everything goes off and stays off until I turn ign off and on.

Its like a relay trips off and is reset when car is turned off.

Sounds like a bad earth somewhere, I changed the battery terminals over to the larger ones for a better connection and fitted earthing wires around the engine bay, do you have an earthing kit? Check all the earth connections on the engine as they are known to corrode.

The BCM under the inside fusebox controls the headlight switches, I would think it then goes to the relay board behind the battery. Check all the plugs on that too.

Ive checked all the earths and yes I have an earthing kit around the engine bay that I made up. I think this has only started since the turbo rebuild. But I think the problem was there before I took the engine out.

I havent had any thing else play up yet but the problem is like if you unpluged the BCM and then nothing happens.

Ill have another look around that area and maybe ill unplug the ecu again.

Brad, another thing to look at is your ignition barrel. I had a bad connection in the ignition barrel so that all the accessories would turn off at random times. Turned out to be a bad connection on the barrel so that if the key moved slightly power would be cut.

Cheers

Andy

Ive checked all the earths and yes I have an earthing kit around the engine bay that I made up. I think this has only started since the turbo rebuild. But I think the problem was there before I took the engine out.

I havent had any thing else play up yet but the problem is like if you unpluged the BCM and then nothing happens.

Ill have another look around that area and maybe ill unplug the ecu again.

Engine out for a turbo swap? Who told you that was a good idea? :)

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

    • Nah. For something like boost control I wouldn't start my design with PID. I'd go with something that originates in the fuzzy logic world and use an emergency function or similar concept. PID can and does work, but at its fundamental level it is not suited to quick action. I'd be reasonably sure that the Profecs et al all transitioned to a fuzzy algorithm back in the 90s. Keep in mind also that where and when I have previously talked about using a Profec, I'm usually talking about only doing an open loop system anyway. All this talk of PID and other algorithms only comes into play when you're talking closed loop boost control, and in the context of what the OP needs and wants, we're probably actually in the realm of open loop anyway. Closed loop boost control has always bothered me, because if you sense the process value (ie the boost measurement that you want to control) in the plenum (after the throttle), then boost control to achieve a target is only desirable at WOT. When you are not WOT, you do not want the the boost to be as high as it can be (ie 100% of target). That's why you do not have the throttle at WO. You're attempting to not go as fast as you can. If the process variable is measured upstream of the throttle (ie in an RB26 plenum, or the cold side pipework in others) then yeah, sure, run the boost controller closed loop to hit a target boost there, and then the throttle does what it is supposed to do. Just for utter clarity.... an old Profec B Spec II (or whatever it is called, and I've got one, and I never look at it, so I can't remember!) and similar might have a MAP sensor, and it might show you the actual boost in the plenum (when the MAP sensor is connected to the plenum) but it does not use that value to decide what it is doing to control the boost, except to control the gating effect (where it stops holding the gate closed on the boost ramp). It's not closed loop at all. Once the gate is released, it's just the solenoid flailing away at whatever duty cycle was configured when it was set up. I'm sure that there are many people who do not understand the above points and wonder wtf is going on.  
    • This has clearly gone off on quite a tangent but the suggestion was "go standalone because you probably aren't going to stop at just exhaust + a mild tune and manual boost controller", not "buy a standalone purely for a boost controller". If the scope does in fact stop creeping at an EBC then sure, buy an EVC7 or Profec or whatever else people like to run and stop there. And I have yet to see any kind of aftermarket boost control that is more complicated than a PID controller with some accounting for edge cases. Control system theory is an incredibly vast field yet somehow we always end up back at some variant of a PID controller, maybe with some work done to linearize things. I have done quite a lot, but I don't care to indulge in those pissing matches, hence posting primary sources. I deal with people quite frequently that scream and shout about how their opinion matters more because they've shipped more x or y, it doesn't change the reality of the data they're trying to disagree with. Arguing that the source material is wrong is an entirely separate point and while my experience obviously doesn't matter here I've rarely seen factory service manuals be incorrect about something. It's not some random poorly documented internal software tool that is constantly being patched to barely work. It's also not that hard to just read the Japanese and double check translations either. Especially in automotive parts most of it is loanwords anyways.
    • If you are keeping the current calipers you need to keep the current disc as the spacing of the caliper determines the disc diameter. Have you trial fitted the GTS brakes fit on a GTSt hub or is this forward planning? There could be differences in caliper mount spacing, backing plate and even hub shape that could cause an issue.
    • Hi there I have a r33 gts with 4 stud small brakes, I'm going to convert to 5 stud but keep the small brakes, what size rotor would I need?
    • 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.
×
×
  • Create New...