NB Cam Angle Sensor Heatsoak/Failure
 

Hi had some problems when my car get hot on trackdays. Losing signal from the cam angle sensor on my NB 99.

Running Diypnp ecu.

Only occurs on track after 10-15min driving. Driving without a hood helps (small track ~45mph average speed).

Been having this problem for some time now and it only happens on track. But today on my way home my car died 2 times. Seems like i heat-soak the sensor. If i let the car cool down for 10-15min it runs fine.

when it hapens the rpm guage start flippering and 5-6sec later the car dies and wont start agen.


Is this and know problem or do i just need to replay my sensor?
Any other "know" fix to solve the problem?


Hope you can excuse my shitty english :) (i know you understand. but there is A LOT of hate on this forum) ;)

Have you tried replacing it to see if its simply a bad sensor?
I don't think that's a common problem, so I'd rule out the sensor 1st.

Actually, Emilio and John (of 949 Racing) have documented this to be an extremely common failure mode in cars used on the track. Allegedly (and I have not seen scope traces to prove this), the sensor's signal degrades somewhat when it becomes extremely hot, and the input circuits which are commonly used on the lower-level MS products (basically anything build on a standard 2.2 / 3.0 / 3.57 / "X" circuit board) are unable reliably to decode it.

The better-filtered and more tolerant input circuits (those using the MAX 9924/9926 chip, such as in the MS3Pro and the ECUs which I build) do not seem to suffer from this problem.

Any known solution except change ecu(if not bad sensor)?

I stand corrected then.

Well, I don't own an NB personally, so this is all conjecture. And a lot of folks (who aren't track-rats) will say "no, there's nothing wrong."

I've posited that adding an external signal conditioner will fix the problem. Just a simple little circuit with a MAX9924 to properly decode the signal. But I don't have a proper solution in hand.

Sorry to bring this thread back from the dead, but better than posting a new topic I guess.

I am experiencing issues with my NB CAM sensor when it gets heat soaked, I haven't had much luck using the DIYPNP's LM1815 VR Conditioner.

I have the sensor's signal going to VR+, signal ground to VR-, and VR Out to VR2. Engine doesn't want to start :P

Anyway, I'm planning on getting jbperf's MAX9926 board:
Dual VR Conditioner Board V2.1

Anyone have real world experience with using that board in a DIYPNP? Or tips on wiring it in?

Thanks!

This is not a VR sensor and should not use the LM1815 VR conditioner. It needs to be set up according to the standard DIYPNP build guide.

(The MAX9926 VR conditioner can work with it, but that circuit works with a lot more than VR sensros.)

It sounds like a dying sensor to me.

That's what I thought when I first encountered this problem on one of Emilio's cars. A dozen sensors later and I'm convinced that the stock sensor is just a marginal design.

I scoped one, and found that when they heat up, the voltage differential between on and off shrinks. I can't remember if the on state voltage went down or the off state voltage went up. Either way, the 3.0 / 3.57 design had a hard time with it.

Thus far, the 9924/6 chip has failed to disappoint me.


Edit: I realize that what I've written here slightly contradicts what I wrote a few posts ago in this thread, which I'd forgotten about. Put simply, I'm slightly more sober now.

I've replaced the sensor with two 2nd hand sensors already, and it now has a brand new sensor. Works most of the time, but if I've been driving over an hour and I'm in traffic, it will start to lose sync.

The 2nd hand sensors lost sync A LOT, the brand new one only when it's properly heat soaked. But still less sync loss than the 2nd hand sensors.

On the jbperf site, it says to float VR- when using a hall effect sensor?

That's exactly the problem the track guys were having. Worked fine in the garage, failed on the track.

It's not a well-designed sensor, and requires a very tolerant circuit to decode it. The 9926 is a very tolerant chip.

And your question is... what?

Is it where it's picking up the signal? Cause I don't feel like VVT motors (same sensor, different location) have this issue.

Strange. I've never seen this failure mode myself during extended driving/track time nor have any of my customers reported this.

Perhaps this is an issue with people using the VR decoding for a hall effect sensor.

Are you using the lower-level MS products Joe described in post #3?

I've seen the problem only on NBs using the standard MS3/X assembly, employing two copies of the old 3.0 / 3.57 style VR decoder; the one based on the LM2904 op-amp.

So yes, as you posit, this is using the "VR" decoding for an open-collector sensor. I've never liked this design, but it's the Officially Sanctioned Recommendation of The Creators, and is also the only circuit provided on the X board for dealing with cam input. It's a bad design that worked just well enough to get itself approved, and then started failing under real world conditions.

I assume that you don't commonly deal with this circuit topology?

Our MS3 based ECUs use dual optoisolators. Our MS2-based ECUs use the uS module's VR2 input for the cam circuit, with no problems so far.

I've seen it on AEM Series 1, the EMS-4, and stock ECUs as well. The stock ECU simply shuts off, the AEMs manifest the issue as misfires.

IOW, the NB sensor is uber-junk and I guard good ones with my life.