Ballenger Cam Sensor Changes VVT Timing
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: https://cimg3.ibsrv.net/gimg/www.mia...e4ecf814ed.jpg 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 https://cimg8.ibsrv.net/gimg/www.mia...ff30c6f800.png |
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 https://cimg2.ibsrv.net/gimg/www.mia...56cec303ca.png 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? https://cimg4.ibsrv.net/gimg/www.mia...90a5d9876d.png |
Any chance you swapped the GRY and BLK wires in the connector?
That composite log looks problematic. do you have the noise filter on? |
Originally Posted by Ted75zcar
(Post 1574701)
Any chance you swapped the GRY and BLK wires in the connector?
Originally Posted by Ted75zcar
(Post 1574701)
That composite log looks problematic. do you have the noise filter on?
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 https://cimg7.ibsrv.net/gimg/www.mia...4d555d2af6.png |
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. |
3 Attachment(s)
Originally Posted by Ted75zcar
(Post 1574763)
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. 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
Originally Posted by Ted75zcar
(Post 1574766)
It looks to me like you managed to hit the start button in a way that aligned with the data record length.
|
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: https://cimg9.ibsrv.net/gimg/www.mia...b37075e7d4.png And Ballenger waveform: https://cimg8.ibsrv.net/gimg/www.mia...2b172caeb9.png 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: https://cimg8.ibsrv.net/gimg/www.mia...2d5bc7c2b1.png 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... https://cimg6.ibsrv.net/gimg/www.mia...4d10551451.png OEM third pulse: Again, falling edge happens during the crank pulse, so there would be a prilevel pulse in the composite log: https://cimg5.ibsrv.net/gimg/www.mia...601c10bb60.png 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 https://cimg3.ibsrv.net/gimg/www.mia...47986a266a.png 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 https://cimg2.ibsrv.net/gimg/www.mia...fb943a1501.png 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 https://cimg9.ibsrv.net/gimg/www.mia...d2c6f0a991.png |
8 Attachment(s)
Originally Posted by Ted75zcar
(Post 1574890)
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. 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?
|
All times are GMT -4. The time now is 07:00 AM. |
© 2024 MH Sub I, LLC dba Internet Brands