Recently, I went down a rabbit hole with the Crank math channel. I wanted to be able to graph the engine RPM while doing some signal capturing. The test vehicle, a 2022 Toyota Tacoma 3.5L V6, didn’t provide easy access to the Crankshaft Position Sensor (CKP). On this vehicle, it was going to be quite time-consuming to gain access to the CKP sensor or the ECM to acquire the signal.
I began to hypothesize about using the Crank math channel in conjunction with the COP probe. I set out to do a Mass Air Flow (MAF) response test, where I would need to see engine RPM so I could determine where the engine was revving up from Wide Open Throttle (WOT) and doing some power-brake testing. I connected my 4425A with a TA398 COP probe on Ch A and x1 lead on Ch B for the MAF signal.
This vehicle uses an HF digital MAF sensor, so I already knew I would need to apply a Freq math channel to Ch B. This shows the response of the MAF sensor very well. With the Freq B math applied, you can easily see I have a nice response when I perform two no-load WOT accelerations and then three power-brake accelerations with the engine in gear and brakes locked.
Next, I attempted to graph the engine RPM, based on the COP capture of the easily accessible cylinder 3. In my first attempt, I tried to use the Crank math channel. The Crank math has the inputs of (Channel Reference, number of reluctor teeth). I created a new math channel with the formula (Crank(A,1)*2). This was to try to get the software to recognize the secondary ignition pattern that happened one time every two crank revolutions. Unfortunately, this was not successful.
I then reached out to my teammate, the great Mr. Smith. Steve suggested that I also contact another brilliant teammate in the UK, Martyn B. Martyn very quickly explained that the Crank math is rooted in the Frequency math channel and that using a modified Freq math would likely do what was necessary.
Martyn spent some time and came back with a few key pieces of information. The first being that the Crank math likely wasn’t working because it’s designed to look for a repeatable and uniform signal. The secondary ignition has a nature to be spikey and the peak voltage build-up will vary greatly based on engine speed and placement of the COP probe. The second was the real homerun; the COP signal needed an offset so that the signal crossed uniformly across the ground or 0 V reference line.
This would require an offset to be applied to Ch A in the math formula so that the saturation and spark line would be moved below the 0 V reference. This would allow the Math channel to only see the single positive voltage spike from each firing event above the ground (0 V reference). A quick measurement across the capture with a voltage cursor showed that the highest burn line amplitude was about 16 mV.
We now had a base Freq math channel to try. Freq(A-20) where A is the channel input and -20 is the offset, in mV, to get anything other than the voltage spike below the ground reference (0 V). The offset doesn’t need to be exact, just close enough to get the secondary ignition spike to be the only part of the waveform above the ground reference. In the wizard for adding a math channel, I entered the formula Freq(A-20), then labeled the units as RPM, No SI prefix, and set a limit of 0 and 10,000 RPM.
This resulted in a math channel that vaguely showed the RPM response of the engine, but it was not very usable.
Steve reminded me that the Freq math channel is based on seconds and we needed minutes as in Rotations Per Minute (RPM). A quick edit of the math channel to account for seconds to minutes, Freq(A-20)*60. This really woke up the RPM graph, but the values are inaccurate. When performing the first WOT event, I witnessed the tachometer go over 5000 RPMs, however, the Freq math now showed 2800ish RPMs.
After taking a quick second to think, the solution to this incorrect RPM value from the Freq math channel was realized. The ignition coil is fired 1 time every 720 degrees (2 rotations of the crank). The current math channel was ½ the value it should be because it was measuring each ignition coil activation as 1 RPM and it should be 2 RPMs. Another quick edit to the math channel, (Freq(A-20)*60)*2.
Success! We now have an accurate graph of engine RPM graph based on the COP probe capture. Admittedly, the process was long, but now with the information that has been discovered, this can be repeated quickly and easily. Meaning that anytime we need engine RPM but don’t specifically need the crankshaft position signal, we can now just grab the most accessible ignition coil. Then, using the COP probe, we can achieve an accurate engine RPM graph within a few short minutes.
‘RPM of COP’ = (Freq(A-20)*60)*2)