As discussed on this thread I swapped my VVT cam actuator and cam sensor at the same time. After doing so, my absolute minimum VVT angle changed from 276 to 293 degrees. I narrowed the timing change down to the cam sensor. I was originally using an OEM sensor, but changed to a cam sensor sold through Ballenger after I cracked the OEM sensor

The cracked OEM sensor still worked, so I was able to swap between the two and isolate the timing change to the Ballenger sensor. Since the expected absolute minimum angle is around 275 degrees, it would seem that the Ballenger-sold sensor is not a drop in replacement unless you have an aftermarket ECU to allow you to adjust for it

Comparing the sensors, the plastic casting around the element is flipped relative to the mounting flange:


Edit to add the part number for people searching on the forum: SNSR-100565

 

Finally got a chance to review the composite logs and the output from the sensor is inverted. This not only changes the absolute timing of the triggers, but the spacing of the second pair of triggers as well
I'm going to try inverting the cam input signal and see if that fixes the problem

OEM on the left, Ballenger on the right. These images capture the same relative window of the engine cycle

 

alright, set "flip polarity on high-res tach/cam" to inverted, and now the VVT absolute minimum angle is 274 degrees with the Ballenger cam sensor. The single trigger is in the right spot, but only the second trigger of the pair seemed to show up (most of the time, see below). The car also did not start up as easily, but that could have been from repeatedly starting it, idling for a few minutes, and then shutting down (changing these settings require a power cycle)

OEM cam sensor on left, Ballenger on right



Question time
Anyone have an idea about the importance of the trigger pair? Over the duration of the log, there was one time where both showed up, followed by neither, and no sync errors were ever logged. I'm using a 36-2 crank wheel, but I thought that once sync was achieved with the cam sensor, missing cam sensor triggers would still show errors

As a followup, is the absolute cam angle used in any ECU functions? Or is it only the relative cam angle?

 

Any chance you swapped the GRY and BLK wires in the connector?

That composite log looks problematic. do you have the noise filter on?

 

Pretty sure I didn't. In my experience with the hall-effect sensors, they don't work at all of miswired. The Ballenger website has pretty clear wiring instructions and I triple-checked my work at the time

You're referring to the​ composite log after I inverted the cam signal, correct?
​​​​​​​I can't check the msq at the moment, but I'm pretty confident filtering is enabled. I would have left the filter setting untouched from the 01-05 base settings

 

Can confirm that the sensor is wired correctly per Ballengers website and that all noise filtering is off, as well as VVT tooth filtering. CPU noise filter period is set to 4

To be clear, everything was working great on the OEM sensor. Im just trying to see if this sensor is compatible since it cost 80 bucks, should work with the miata, and my engine harness now has the connector for it

EDIT: here is the same composite log as above showing the missing triggers, but with "render including non-interupt data" de-selected. All the edges are being detected. I think the question about filtering is intersting... maybe something about the inverted signal makes the ECU discard edges that it wouldnt normally with the un-inverted signal

 

What MS variant are you using?

Have you contacted Ballenger?

Edit: you say you aren't getting sync errors? Does the VVT angle jump wildly ever? I wonder if this is a TS issue. What does the actual text data look like? I am not familiar with the render with non interrupt data, and I had to develop a custom trigger for mine so I looked at this stuff in great detail about 2 years ago.

 

MS3Pro PNP for a 90-30 miata
I have not contacted ballenger, but will

No sync errors. VVT angle does not jump wildly either

I think if it were a TS issue, I would have found discussions where others have been fighting TS to getting these settings right. Datalogs are attached

Ultimately, the VVT should be unaffected since I can set the absolute minimum angle, and fuel injection timing can all be shifted 20 degrees to null out this change (though a 20 degree on fuel injector timing isnt massive anyway). I dont think spark timing will be affected, even though its set for sequential, since it uses crank position only for spark timing and cam position just to figure out which piston is on its compression stroke. Long story short, even if I cant make this sensor read into the ECU's processes like the OEM sensor, it may not be a substantive difference

 

The data looks good. You want to run the invert I believe.

It looks to me like you managed to hit the start button in a way that aligned with the data record length. Take another log and see what happens.

 

I'll get another log this weekend. I have some other trigger settings I've been meaning to experiment with anyway

Can you explain this more? I'm not sure what you're getting at. Are you saying something about when the log started affected the way it's appearing in megalogviewer?

 

Look at the logs in a text editor. The composite logger takes a limited number of samples. For continuous logging, it appends subsequent samples to the running log, this transition between log data shots is indicated by a "MARK" line in the file. You somehow managed to get that transition to occur during the trigger events in more than 1 location. IOW, the trigger events were "interrupted" by the data-shot/end-file append operation.

~
680 0 0 0 1 1.324 1756.048
681 0 1 1 1 0.691 1756.739 trig
682 0 1 0 1 0.677 1757.416
683 0 1 0 1 1.33 1758.746
684 0 0 0 1 1.329 1760.075
685 0 0 0 1 1.348 1761.423
686 1 1 1 1 0.786 1762.209 trig
687 MARK 001 OK here, but super close
688 0 1 0 1 126.626 1888.835
689 0 1 0 1 1.32 1890.155
690 0 1 0 1 1.399 1891.554
~

~
1711 0 1 0 1 1.355 3667.995
1712 0 0 0 1 1.401 3669.396
1713 MARK 004 missed trigger
1714 0 1 0 1 177.207 3846.603
1715 0 1 0 1 1.373 3847.976
~

~
2392 0 1 0 1 1.402 4971.203
2393 0 0 0 1 1.442 4972.645
2394 0 0 0 1 1.403 4974.048
2395 0 0 0 1 1.391 4975.439
2396 0 0 0 1 1.414 4976.853
2397 MARK 006 missed trigger
2398 0 1 0 1 162.04 5138.893
2399 0 1 0 1 1.431 5140.324
2400 0 1 0 1 1.375 5141.699
~

 

hm. that is interesting (and just my luck)

I'm still learning here, and I just realized that past posts probably used the wrong terms, so to explain it correctly -

What I have been trying to chase down is the missing pulses in the prilevel trace. The MARK lines split the log into the pages rendered in MLV and around those page breaks there may be missing data, but within a page there are missing prilevel pulses. The cam signal is clean, the tooth logger looks good and triggers are being sensed at the right relative times now. But, in the past (oem sensor and non-inverted ballenger sensor) there was always a prilevel pulse at the same time as every trigger. The prilevel pulse is not showing up consistently anymore

What I noticed before but disregarded is that inverting the cam signal did not actually flip the trace and then trigger on falling edges like I expected, it just inverted the logic; its now triggering on rising edges. Crank trigger is still falling edge. I wonder if there is an issue from this

 

Can you provide an example from the data (not a logger viewer) where a trigger is missed that doesn't coincide with a MARK event?

You want the cam triggers to occur on the same crank tooth, and in the same approximate location on that crank tooth. Select the logic that provides this relationship. To me it looks like it is the invert configuration with the Ballenger sensor.

The developers offer that config for a reason, it is possible it is to support this sensor.

 

So I think I found the problem
tl;dr: the Ballenger sensor puts out a different waveform than the OEM sensor. The ECU can still interpret it for full RPM sync, however. When the Ballenger waveform is inverted to correct the cam angle measurements, the missing prilevel pulses happen when the sensed edge falls on a gap between the crank trigger wheel teeth. Not sure exactly what this does to the ECU's processes (no sync errors) but the car idles rougher

I swapped between sensors and polarity settings several times, and found:
Ballenger with normal polarity: Throws off VVT timing (detrimentally, if not adjusted for. I deactivated the VVT for this testing however) and injection timing is thrown off, but probably not enough to matter. Car idles and revs just fine (again, VVT deactivated)
Ballenger with inverted polarity: VVT and injection timing would be seemingly fixed, but the car periodically runs rougher. I think this happens when the cam triggers are not occurring during the crank pulses

If I were to use the Ballenger sensor, I would keep it on normal polarity and adjust timing settings for the angle error. I might get a new OEM sensor though

I found out about the "log crank&cam" spark mode which just gives the raw digitized crank and cam signals. The car won't run in this mode, since the waveform is not interpreted against the spark mode settings. Below are some screen grabs:

Here is the OEM waveform:


And Ballenger waveform:


Looking at the crank/cam pulses in detail now:

OEM first pulse: falling edge happens during a crank pulse, so this creates a prilevel pulse in the normal composite log:


OEM Second pulse: its really long, but the falling edge again happens during a crank pulse (barely), so this creates another prilevel pulse in the composite log:
Note: despite how close it is to the edge, I have not seen it miss yet...


OEM third pulse: Again, falling edge happens during the crank pulse, so there would be a prilevel pulse in the composite log:


Ballenger first pulse: Whether trigger is normal (falling edge) or inverted (rising edge) both happen during the crank pulse and would create a prilevel pulse in the composite log


Ballenger second pulse: If trigger is normal (falling edge) the trigger happens during a crank pulse. If trigger is inverted (rising edge), it is marginal and misses the crank tooth consistently


Ballenger third pulse: If trigger is normal (falling edge) the trigger happens during a crank pulse. If trigger is inverted (rising edge), it is again close. I have seen this one miss

 

I think you replied while i was writing my novel above, and hit on exactly what I found out looking at data.

I don't have any missing triggers. What I realize now is that Ballenger+inverted causes the second cam trigger to not fall on a crank tooth. Ballenger+normal always has cam triggers aligning with crank teeth (but throws off the cam angle measurement; the triggers fall on different crank teeth). I also found that the OEM sensor second trigger is super marginal on overlap with its crank tooth

I attached some more composite logs

 

I may be chasing something that doesnt matter, now that I think about it

While I have an explanation for why there are missing prilevel pulses in the composite log (when non-interupt data is rendered) I'm not sure that the missing pulses matter. With VVT active, the cam angle changes relative to the crank, so there is no guarantee that the cam triggers continue to line up with the crank tooth pulses. Having them line up must not be important to the engine running

this means I also dont have an explanation for why the car runs better with the Ballenger signal un-inverted than inverted

 

I am bumping this as I ordered one of these to hopefully fix my heat-soak sync loss issue. I suspect it is either caused by a bad connector/wiring or a bad sensor that gets heatsoaked. Issue happens with multiple OEM sensors, unaltered wiring.

Did you end up running the ballenger and recalibrating the min/max VVT angles to compensate for it? Trying to figure out the best way to get the sensor working similar to the OEM one, minus the heatsoaking weakening the signal.

 

I have the Ballenger installed but they never mentioned anything to me about recalibrating my VVT angles. Could damage possibly occur if I do not do this?