It has been a while since we posted a math’s feature, and so here we go looking at engine power output (BHP) thanks to the joy math channels
We often discuss “non-intrusive testing” and the following is a perfect example of this philosophy using an accelerometer to determine engine power output
The first step in the process of engine power output calculation is the acquisition of the accelerometer calibration factor (ACF). This process is automated in our Pico Diagnostics NVH software, however, for this test procedure we are using PicoScope 7 Automotive
The ACF acquisition process is very straight forward indeed and requires the X-axis of the TA259 NVH interface to be connected to a PicoScope channel (See image and text below)
Image 1
ACF acquisition procedure
1. Connect the TA143 3-axis accelerometer to a TA259 NVH interface
2. Connect the X-axis output of the TA259 NVH interface to PicoScope (Above we have used channel C)
3. Set the scale of your chosen channel to x10, the input range to +- 2V (DC coupled) and a timebase of 5 sec/div (Total buffer time = 50 seconds)
4. Hold the accelerometer with the screw thread hole positioned vertically down and start recording.
5. After 20 seconds, turn the accelerometer over so that the screw thread hole is now pointing vertically up.
6. Continue recording for a further 20 seconds and then stop the capture
7. Activate lowpass filtering and set to 10 Hz for your chosen channel
6. Align both signal rulers on the captured signal as shown above and record the delta (Δ) measurement
7. Divide the Δ measurement by 2, to obtain a value typically of 0.101 mV
8. Divide 9.81 (Acceleration due to gravity) by the value obtained in Step 7 to arrive at the Accelerometer Calibration Factor (ACF)
E.g., 9.81 m/s/s / 0.101 = 97.129 m/s/s/V. (Record this value for later use)
Set-up
With the ACF acquired, attach the Acc to the driver’s seat frame, vertically with the screw thread facing forward as in the image below. We are interested in measuring the X-axis only; the fore-aft movement of the vehicle under acceleration
Image 2
1. Connect the TA143 3-axis accelerometer to a TA259 NVH interface
2. Connect the X-axis output of the TA259 NVH interface to PicoScope (In our test we have used channel C)
3. Set the scale of your chosen channel to x10, the input range to +- 2V (DC coupled) and a timebase of 5 sec/div (Total buffer time = 50 seconds)
4. Drive the vehicle to a straight / level road and roll to a halt rather than brake to a stop. Braking will result in “nose diving” and the vehicle posture may not return to its natural ride height
5. With the vehicle at rest, start the recording but do not accelerate for approximately 5 seconds. During this period, we need to capture the DC value of the accelerometer relevant to the vehicle posture and acceleration due to gravity (This is referred to as the DC component of the accelerometer) We also use this significant value at the end of the road test to qualify the vehicle has returned to its natural ride height identified at the start of the test run. If we allow 5 seconds at the end of our test run to confirm the ride height pre and post power test we have approx. 40 seconds in our buffer to carry out a WOT acceleration test
Road-test (now for the fun part)
1. Follow all relevant safety precautions and road traffic laws
2. Do not run this test alone, one person is the designated driver who will be instructed by the laptop operator
3. If applicable, set the vehicle driving modes to Sport or “I want my mommy” mode (in the case of Tesla)
4. Turn off Traction control VSC / ESP if applicable and be aware of the implications of deactivating these systems (The vehicle will inform the driver of such)
5. With the scope running accelerate the vehicle at WOT such as to achieve maximum power at the specified rpm
6. Remember the purpose of this test is to determine the power output of the engine and so manual upshifting must take into consideration the specified rpm at which peak power is acquired (Do not upshift too early)
7. Be conscious you have 40 seconds of recoding time and during this period you will have to brake the car to near rest
8. Allow the vehicle to finally roll to a halt and note the DC component voltage of the accelerometer which will hopefully match the value obtained prior to the test run
9. Stop the scope and save your data (See below)
Image 3
Above I have included a road speed math channel derived from the ABS tooth count (48 teeth per wheel revolution) to help explain the response from the accelerometer (Channel C) More information on road speed via math channels can be found here viewtopic.php?p=96821&sid=b2891430de61e ... 573#p96821
Note how the vehicle accelerates rapidly from rest (vehicle squats) where you experience that “pushed back into your seat” feeling, followed by a recovery of the vehicle posture during the upshifts
We then have an over-run period of little or no acceleration followed by a gentle increase in road speed (I may have been trying to fill the buffer with data at this point)
Finally, the brakes are applied to reduce road speed and bring the vehicle to a rolling halt.
Note how the accelerometer value at the start of the test with the vehicle at rest = 936.8 mV (DC component) does not quite match the value obtained as the vehicle rolls to rest! This may well have been due to an inclination in the road surface or, insufficient time for the ride height to return to its natural position. Where possible (to prevent errors accumulating in the math channel) try to bring the vehicle to rest in such away as to accurately match the value obtained at the start of the test run
So how do we calculate BHP from the above data?
Here is the math channel returning BHP for the accelerometer data captured on channel C above
1.341*97.129 *97.129 *1765/1000derivative(integral((C-0.9368)*integral(C-0.9368)))
Using a combination of conversions (Watts to BHP) calculus (Integral & Derivative) accelerometer calibration factor (ACF) and DC Component of the accelerometer at rest, we can graph engine power
1.341 converts Watts to BHP
97.129 (ACF^2) converts the voltage output (measured by PicoScope) into Acceleration
1765 is the weight of the vehicle during the test run (kg)
1000 converts Watts to kilowatts
“Derivative” defines to rate of change with respect to a variable (e.g., “time”)
“Integral” (area under the curve)
“C” is the PicoScope channel connected to the accelerometer
0.9368 V is the DC Component of the accelerometer (Volts)
Please do not dwell on the math’s above and except that the formula above will return engine power assuming your Channel letter (“C” above) ACF (97.129 above) DC Component (0.9368 V above) and vehicle weight (1765 kg) are accurate and entered correctly
Image 4
Above we have the Power BHP math channel returning an average peak of approx. 164.5 BHP and a 0...60 mph time of 7.51 seconds
The vehicle in question is a BMW 320 d Auto X Drive Touring which is specified at 181 BHP and 0… 62 mph in 7.5 seconds; so why the difference between measured and specified BHP?
Vehicle manufacturers quote engine power based on engine dyno results and not a chassis dyno. In other words, the engine is run purely on a dyno and not connected to the transmission /vehicle. Therefore, there are no losses to account for and the true engine power output can be acquired
With our test above, the engine is subjected to load and therefore losses such as the Auto Transmission, X-Drive-train, rolling resistance of the tyres, traction loss, vehicle weight, wind resistance, road surface undulation and coefficient of drag.
As a general rule of thumb, we lose 15% of the specified engine power via the aforementioned items
Therefore: 181 BHP x 15 / 100 = 27.15 (BHP loss)
181 – 27.25 = 153.75 BHP (Expected BHP measured on the road)
The above calculation highlights the variables to consider during the road-test and the accuracy of the data entered, all of which have a huge influence on the acquired figures
Have I been a little ambitious with my peak measurement point for BHP?
Note below, peak power is 153.3 BHP in 2nd gear and appears to be an average throughout the road test (look between 4th & 5th gear) Perhaps this is a more desirable and accurate measurement point given the load on the engine will be at its greatest from rest, once we are rolling the load is reduced, however we then need to factor in wind resistance and drag
Image 5
Whatever and wherever you decide to measure, keeping your road tests and measurement criteria identical will return accurate relative measurements on which to base your diagnosis and qualify any repairs. (Be mindful about variables such a vehicle weight and consider fuel level and cabin occupant weight!)
Moving onto additional measurements, below we have added engine speed via the crank sensor signal, but not using “Crank(A,60)” math channel due to the low sampling rate. (Remember math channels favor a high sample count/rate) Instead we have introduced a “Low Pass filter” into a “Frequency” math channel “(60/60LowPass(freq(A),8)” to smooth out the aliasing we see at high engine speed and therefore plot the “Trend” of the RPM which will help with the additional calculations to follow.
Image 6
So why do we want to graph engine speed? Well, if we have engine speed and power, we can calculate Torque!
The formula for Torque requires engine Power to be expressed in Watts and not BHP
Engine Torque (Nm) = Power (Watts) / x ω where ω is the rotational speed in radians/s
97.129 (ACF^2) converts the voltage output (measured by PicoScope) into Acceleration
1765 is the weight of the vehicle during the test run (kg)
“Derivative” defines to rate of change with respect to a variable (e.g., “time”)
“Integral” (area under the curve)
“C” is the PicoScope channel connected to the accelerometer
0.9368 V is the DC Component of the accelerometer (Volts)
The above will return engine power in Watts………
(2*π/60)*RPM will return engine speed (RPM) to angular velocity in radians per second (rad/s)
Image 7
Note above the Engine Torque value obtained (292 .7 Nm) at our average peak power (153.3 BHP)
The maximum Engine Torque achieved was approx. 338 Nm with the specification being 380 Nm @ 1750-2750 rpm. Remember once again that specified Engine Torque is calculated using an engine dyno not a chassis dyno. The engine torque figures above incorporate engine power with approx. 15 % loss which of course will reduce torque by the same amount. If we add 15 % to our maximum engine torque figure of 338 NM we arrive at:
338 Nm x 15 / 100 = 50.7
338 + 50.7 = 388.7 Nm (Specification 380 Nm)
Working with the above data, it occurred to me we have engine and road speed data thanks to the crank and ABS sensor signals. If you then incorporate the differential ratio, you have transmission input and output shaft speeds and if you have these, you can calculate gear ratios!
For example: Gear ratio = Input speed (RPM) / Output speed (RPM)
Given we know engine speed (RPM) using the math channel “(60/60LowPass(freq(A),8)” we have the transmission input value ready to go.
We know road speed (MPH) using the math channel 1.03*3600/63360*2*3.1416*13.016*freq(B)/48 therefore we can modify this formula to return wheel frequency (Revolutions per second) multiply by the differential ratio (2.81) to find propshaft/transmission output frequency (Hz) and then multiply again by 60 to convert to RPM
The math channel to determine Propshaft/transmission output speed (RPM) from ABS tooth count looks like this “freq(B)/48*2.81*60”
To find gear ratios we the divide the transmission input speed by the transmission output speed by joining the above math channels together as below:
60/60*LowPass(freq(A),8)/(freq(B)/48*2.81*60)
Image 8
As you can see above the gear ratios are displayed clearly except of course for 1st gear (from rest) where we have to factor in torque convertor slip and multiplication. With that said, from 2nd gear onwards the accuracy is near identical to the specifications below (ZF 8 Speed Transmission)
Image 9
All-in-all the above techniques demonstrate how measuring engine Power and Torque for any vehicle (petrol, diesel or electric) can be performed in a non-intrusive fashion so providing another string to your bow during diagnosis and qualification of repair.
Please note, the tests above return a relative measurement for indication of Power and Torque and be aware of the numerous variables that can creep into the obtained results between testing. (One of which might be the weather!)
I will follow up this forum post looking at Hub Torque, Wheel Torque, and Braking Force which make for an interesting twist on the above Engine Power and Torque figures
It is mind blowing when you think we have gone from this, to this…..
Image 10
To this…….
Image 11
I must say a big thank you to the team here at Pico, naming Barney, Ben and Martyn and a HUGE THANK YOU to Martin Rubenstein for his assistance with this adventure that started in the summer of 2018!
Hi Steve
Thanks to you and all the team for another fascinating post!
A few questions ... well what do you expect from me!
On the Pico Diagnostics tool, what are the requirements in terms of the NVH kit to get chassis dyno results? Is there a follow up (or previous?) article?
In terms of braking (and acceleration) is there any ability to discern "pull" ?
I clearly need to spend a bit more time digesting and considering the vast possibilities that this offers, but amazing stuff.
Hi Richard, I hope you are well and thank you for the feedback
Forgive me here, I do not follow “what are the requirements in terms of the NVH kit to get chassis dyno results”
All the above test results are obtained using PicoScope and math channels and not NVH software.
The only requirement is a TA143 accelerometer and TA259 NVH interface
Just quickly skipping back through the post, I may have introduced confusion by using math’s to display gear position and then included a screen shot of the NVH “Advanced vehicle settings” dialog box from NVH.
Sorry, this was just used as a quick way to show ratio’s and I could have listed them in Excel (There is no link to the NVH software)
Regarding, “In terms of braking (and acceleration) is there any ability to discern "pull"?”
Looking at image 3 in the above post, acceleration is denoted by the fall from 0.937 V and this is what I interpret by the term “pull” (I hope I have that correct?)
Braking is denoted by the rise from 0.937 V
Once again, I hope I have interpreted your feedback correctly
We all know that the math functions within PicoScope can unlock the potential to show you new things about the signals you acquire. From the simple A+B and A-B for CAN BUS analysis to the more advanced formulas to calculate volumetric efficiency, torque output of a starter motor and phase shift.
To quote Wikipedia the derivative can be described as -
“In mathematics, the derivative of a function of a real variable measures the sensitivity to change of the function value (output value) with respect to a change in its argument (input value). Derivatives are a fundamental tool of calculus.
For example, the derivative of the position of a moving object with respect to time is the object's velocity: this measures how quickly the position of the object changes when time advances.
For this reason, the derivative is often described as the "instantaneous rate of change.”
If we take the example which references the derivative of a moving object with respect to time is the object's velocity and change the moving object to a sample collected by PicoScope, we can plot the rate of change between samples.
But where else could it be used?
Being at Pico I’ve been fortunate enough to spend more time looking at alternative industries outside of automotive where Pico could be used. Pico and hydraulics isn’t something new of course and with WPS600C, Pico have been supporting a number of technicians in the agricultural and construction industry and we have introduced a range of kits for use in these industries - https://www.picoauto.com/landing-page/off-highway
Hydraulics turns up in a number of different places though with industrial settings, marine, mining, aviation and even wind turbines all taking advantage of the ability to move and turn things using the power of fluid. When it comes to understanding leaks, accumulator activity and pressure spikes within a hydraulic system it’s not always the fact that a failure is caused by over pressurisation but instead how quickly that pressure change took place. It is something that I touched upon in the following post - viewtopic.php?p=101741#p101741
The principles of hydraulics can also be applied to systems like common rail diesels where we see a change in pressure as the pump pressurises the fuel before it’s delivered to the rail. There is also a change when an injection event takes place and the pressure in the rail changes again. Remember, pressure is just resistance to flow.
Below I have a capture taken from a truck where the cylinder one injection has been cut.
Channel A - Crankshaft sensor
Channel B - Camshaft sensor
Channel C - Fuel rail pressure sensor
Channel D - Cyl 1, 2 & 3 injector power supply
I’ve already included the crank math channel which shows the crankshaft slowing down which we know is on cylinder 1. Worth noting that cylinder one follows the double pulse reference on the camshaft. Always useful to know how to identify cylinders with the camshaft sensor on diesel engines!
The derivative function is quite fussy about the amount of noise a signal has. If using a 4425 or 4425A, you can make use of the floating input and reference the rail pressure signal to the sensor ground rather than the chassis ground. This does help with cleaning the signal up. Failing that, adding a lowpass filter post capture of around 1kHz will also help but it is recommended to also use a heavy low pass filter within the math channel. Typically I have found that 10Hz is enough to still have the detail required without too much interference creeping through from the original signal. Below is the derivative math channel on Channel C with no lowpass filter on either the Channel C or in the math channel.
Including the Lowpass filter for channel C, it still does not clean the math channel up.
To create the derivative math function start with selecting Math Channels (1). Click New (2) in the bottom of the pop out menu. As we need to add additional lowpass filtering, select the Filter drop down and click LowPass(3). This will automatically add the function to the formula along with the additional items required to complete the function.
As we want to apply this LowPass function, the signal part of the formula is now the derivative function. This is displayed in the scientific section as d/dx (4). This will now add the word derivative to the formula where we have to add the channel we wish to apply the math channel too. In this case it is Channel C (5).
Finally to complete the formula we have to come back to the first math channel being the LowPass filter. We have to include the cut off frequency we would like the filter to use. As I’ve said earlier, the derivative function requires a heavy filter and I’ve found 10Hz works pretty well. This will depend on the application though so more or less may be required. Click (6) which will highlight the section and type in 10 using the keyboard or the calculator (7). Once completed the red border around the formula box will disappear and will be able to click Next (8).
The next window allows you to rename the math channel, change the colour and most importantly set the range. One thing you’ll notice is that units aren’t recognised by the software so it will label it with a ? This can be used as it is and really we’re looking for a visual change rather than an actual measurement.
The range may be something that takes a little trial and error. For this application I’ve found that +-10V works well (1). Finish up the math channel by clicking Finish (2).
As we know that cylinder 1 has been cut electronically, there is a lack of current flowing when cylinder one should be firing but if this was a genuine misfire situation where cylinder one was still firing, could you determine more for just these 3 signals. I have already scaled the rail pressure signal in the attempt to see if there are any fueling issues and it isn’t that easy to determine. We have some pumping element that you can see in the stepped nature of the pressure signal but it isn’t that clear. By adding in the derivative function it makes it quite clear that there is something wrong. One thing to note is that as the derivative function is the rate of change, we don’t see a lot of movement when the fuel in the rail is fairly static, not changing in either direction. I haven’t been doing this with fuel rail pressure for too long so I’m sure there will be a situation where this isn’t as clear but having another tool to use which is built into the software and doesn’t involve repeat captures can only be a good thing.
As mentioned right at the beginning of this article, hydraulics is one area where seeing this rate of change can be particularly useful. Rapid changes in hydraulic pressure can sometimes cause adverse stress on components and seals, despite the fact that the system is operating in its safe working pressures. In the image below I’ve captured the hydraulic pressure at the pump whilst a service is being activated, held on a stop to produce maximum pressure and then being released.
As expected we can see that as the service is operated we get a rapid increase in pressure as the actuator is forced to move, much like the inrush current of a starter motor. This falls slightly before increasing further as the service is held in a stop position where the full flow rate of the pump is required. As the flow has nowhere to go, the pressure rises to the system working pressure around 330 Bar. As the pressure doesn’t really change in the held position the math channel shows little movement but as the service is released from the hold, there is a rapid change in pressure as the pump is backed off to stop producing flow. This is highlighted in the derivative math channel but in the opposite direction.
Early I mentioned the rising rate values for the fuel rail pressure system don’t really have a lot of meaning. When it comes to hydraulics, this rising rate is useful, especially for designers where components are failing prematurely. We can use the measurement for rising rate to determine the change in pressure against time around one of the spikes we see when the service is operated.
With this measurement you must use the measurement between rulers as using the whole trace does not reflect the parts of the waveform that we are interested in. By selecting channel B (2) and the Rising rate measurement (3), click the measurement (4) to select the between rulers (5) and drag the time ruler to the point where the pressure ramps up and where it levels out. It should work out that it sits either side of the spike in the math channel. From the measurement we have a reading of 1,635 bar/s! Considering our working pressure is set at 330 bar, this is considerably higher! The math channel can be used as a first look but due to filtering it cannot be relied upon, it’s not far off though measuring 1,466. These types of measurements are particularly useful when it comes to proving a system component issue or a design issue.
I hope this helps and adds another math function that can provide additional information to help with understanding systems and diagnose when problems arise.
Hello and thank you very much for this knowledgebase.
I have a question about the compression test with the wps500.
instead of calculating the factor from the compression ratio, is it possible to calculate it from startermotorpower / RC Test ?
For exampel: if it takes 1,2 kw with the spark or glowplug screwed in and 1kw with wps500 factor should be 1,2 (20%) ?
If possible this will be easier than finding compression ratio etc.
thank u in advance and i really appreaciate your work.
Hello and thank you for the post, sorry for the late feedback as ever.
Another great suggestion and one that requires further investigation, thank you
Traditionally, these forum posts describe how compensation is applied when compression testing with intrusion into the cylinder topic16131.html and viewtopic.php?p=97815#p97815
In the above scenarios, knowledge of the cylinder volume and our intrusive test equipment (compression hose etc.) are required
With your suggestion, we carry out a non-intrusive relative compression test whilst capturing battery voltage and starter motor current as we have here viewtopic.php?p=96371#p96371
We should also include a synchronization signal to help with cylinder identification for both the best performing and worst performing cylinders
Using Voltage x Current, we can obtain Watts (Power) delivered during cranking
As you have described, if we then repeat the test with our pressure transducer installed, we can derive the correction factor to apply to our obtained compression value (So compensating for the intrusion of the test equipment)
I think it would be “best practice” to use the best performing cylinder (identified during the non-intrusive relative compression test) in order to find the correction factor.
I will give this a go in our workshop ASAP and feedback here.
Following on from a forum post here viewtopic.php?p=104327#p104327 a question was raised surrounding compensation using a “correction factor” when compression testing
“Instead of calculating the factor from the compression ratio(viewtopic.php?p=97815#p97815) is it possible to calculate it from starter motor power / RC Test?
For example: if it takes 1,2 kw with the spark or glow plug screwed in and 1kw with WPS500 factor should be 1,2 (20%)?
Using an Audi A2 1.6 FSI (engine code BAD) we carry out a Pico Diagnostics Relative compression test where the results are derived from the voltage drop during cranking
Picture 1
As we can see above, all cylinders look good with our lowest performing cylinder at 95%
W now repeat the test using a pressure transducer to return Absolute compression values using the compensate feature in the image below
Picture 2
As above, all cylinders are returning exceptional compression values which I need to clarify!
Below we carry out the relative compression test once more but using PicoScope in order to determine our worst performing cylinder using a synchronization signal (Channel C COP#1)
Picture 3
Note above, I have added the math channel A*B to derive the power (Watts) generated by the starter motor (See here viewtopic.php?p=96371#p96371)
Using any of the above waveforms we can determine our best and worst performing cylinder. (I have chosen channel B, the current waveform)
Whilst there is not a lot to choose between cylinders, I think we can agree cylinder 1 is good and cylinder 4 is not so good (rather than use the word “bad”)
Below we now add a pressure transducer to cylinder 1 (our best performing cylinder)
Note the effects on cranking current (reduction) during the compression event of cylinder 1 compared to our Reference Waveform (black AMP NO INTRU) which is cranking current in Picture3 above, imported into our capture below
Picture 4
The above waveform also includes the IGT #1 signal from Picture3 and I have used the Reference Waveform “Delay” feature to delay each reference waveform by 98.11 ms so they now align with the cranking current and IGT signal captured on channels B & C in picture 4 above
To now determine if cranking current can be used to find a correction factor for our compression waveform let us look at the maths
Below we use the “measurement between time ruler function” to capture the maximum starter motor current values during the compression event of cylinder 1 with and without a pressure transducer.
Picture 5
Starter current without pressure transducer intrusion 149.1 A
Starter current without pressure transducer intrusion 139.8 A
Difference 9.3 A
139.8 / 149.1 = 0.94 (x 100) = 94%
139.8 A represents 94% of 149.1 A
Intruding into the cylinder with our WPS has influenced (reduced) our peak current draw for cylinder 1 by 0.06 (x100) = 6%
Our correction/multiplication factor for our compression waveform using current is therefore 0.06
Below we add the math channel D*1.06 to correct (compensate) our peak cylinder pressure value due to the intrusion of our Pressure transducer (which ultimately increases cylinder volume)
Picture 6
Once again, note above how the measurement feature between time rulers makes it very easy to display the maximum values in the precise location of the graph view (15.66 bar & 16.60 bar respectively)
If we now use the volumetric method of compensation as described here viewtopic.php?p=97815#p97815 we can compare the two (Starter current v Volumetric compensation)
Cylinder displacement / (Compression Ratio -1) = Combustion chamber volume
Combustion chamber volume + Sensor volume value (5 ml) / Combustion chamber volume = Multiplication Factor
The Multiplication factor is then used to multiply the pressure results obtained by WPS500x
Audi A2 1.6 FSI (engine code BAD)
4 Cylinder engine displacement 1600 cc Compression ratio 11.5:1
1600 / 4 = 400 cc Displacement per cylinder
400cc / (11.5 -1) = 38.10cc Combustion chamber volume
38.10 cc + 5 ml / 38.10 cc = 1.13
1.13 is the Multiplication factor required to correct peak cylinder pressure.
Below we now add in the math channel D*1.13 to display the peak cylinder pressure using the volumetric method of compensation where we can see a clear difference!
Picture 7
Based on all the above, we must consider the variables when using either battery voltage, starter motor cranking current or power to determine a compensation factor
These include:
• The electrical integrity of the cranking circuit
• Starter motor and battery performance
• Channel filtering
• Signal noise
• Current clamp zero
• Engine design
• External influences upon the starter motor during cranking (i.e., a “tight spot” about the engine rotation)
I am sure there are more, all of which have the ability to throw a curve ball when determining the compensation value to apply to peak cylinder pressure. Using the volumetric method eradicates all the above variables.
With all that said, if our engine is rotating normally without interruption and our starter motor/ battery are in good working order then using starter current has some real merit
Given we know starter motor current and cylinder 1 pressure, can we determine the pressure in the remaining cylinders without installing the pressure transducer? YES
We now know 139.8 A is proportional to 15.66 bar
1 A is therefore equal to 15.66 /139.8 = 0.112 bar
1 A = 0.112 bar
Armed with this knowledge we can create the math channel D*0.112 to derive the cylinder pressures of the remaining cylinders without installing the pressure transducer!
Picture 8
As we can see above, we have calculated the pressure in the remaining cylinders (approx. 16.62 bar) without intrusion in a similar fashion to the Pico Diagnostics Absolute Compression Test in Picture 2 earlier. The advantage here being we can add more channels to assist with diagnosis (e.g., MAP & MAF sensor)
The proof as they say, is in the pudding!
Below I have captured cylinder 1 pressure and cranking current (Ch A & B respectively) to determine a compensation factor of 0.116 using a cranking current of 134 A to achieve 15.6 bar of cylinder pressure (15.6 / 134 = 0.116 1 A = 0.116 bar)
I have then physically measured the compression of all the remaining cylinders using a pressure transducer and created reference waveforms of each
These reference waveforms have then been imported into the capture below and delayed such as to position them in their timing order (1342)
Picture 9
Using the math channel B*0116 we derive the pressure in the remaining cylinders (non-intrusively)
I think we can agree, both the non-intrusive and intrusive methods are not far apart at all!
Typically, the math channel will return a higher value for the closed cylinders (i.e., no transducer installed) WHY?
Please bear in mind the physical cylinder measurements (intrusive) will be lower than the math channel due to the increase in cylinder volume by the pressure transducer (hence “compensation”)
Following on from our forum post introducing the Delay math channel here viewtopic.php?p=104326#p104326 I came across a potentially useful application for such a math channel when identifying fuel strategy (in terms of injector duration) during WOT events
The vehicle in question is an Automatic 2015 Mini Cooper S (F56) with the B48 A20A engine
Below we are qualifying B1 S1 O2 signal (wideband) response against fuel pressure and strategy whilst accelerating under WOT to establish peak air flow figures from our connected scan tool
Image 1
Note above the high frequency noise during the first half of the capture (under WOT load) and the reduced noise level during over-run in the second half. This noise we can attribute to typical EMI from ignition and predominately injection events.
In order to determine the fuel strategy/duration at any given point during the acceleration of the vehicle we have several tools at our disposal
1. Manual measurements (inc. zoom and measure)
2. Deep Measure
3. Math channels
Starting with Manual measurements, we need to clean the graph view in order to improve clarity
Below we have applied a low pass filter to channels A, C & D, and repositioned all waveforms (click on Views > Auto arrange) to focus predominately on channels B and D, ignition coil pack and fuel injector current for cylinder 1 respectively. (Note, Phase rulers have been used an indication only of the 4-stroke cycle events)
Image 2
Note above left (Scope 1) we have the original waveform with filtering, repositioning, and scaling applied. On the right (Scope 2) we have zoomed into the beginning of buffer 7 (prior to WOT) and used our phase rulers to denote 720 degrees of crankshaft rotation based on our ignition events for cylinder 1
We can see above how our injection event (duration 1.536 ms) occurs approx. midway through the approximated intake stroke as expected.
At this stage it would be ideal to include an engine speed signal to indicate the engine condition (acceleration/deceleration) This is normally achieved using the crankshaft sensor, however, on this occasion the crank signal was not acquired!
We can however adapt our ignition signal (Channel B) to reveal engine speed using a “frequency” math channel via our ignition signal to determine engine speed. How?
To obtain engine rpm from the ignition signal (Channel B) we need to know the number of cylinder 1 ignition events per engine revolution.
Given the cylinder 1 ignition event is present once every 2 revolutions of the crankshaft, we represent this as: 1 (Ignition event) / 2 (Engine revolutions) = 0.5
We now need to convert “cycles per second” (Hz) to “cycles per minute” (RPM)
One to remember here: Frequency (Hz) x 60 = RPM and likewise RPM / 60 = Frequency (Hz)
So how does this all fit together into a math channel?
The formula required to obtain engine rpm from channel B is written
60/0.5*freq(B)
Below we now have an indication of engine speed and can see the periods of hard acceleration which occur predominately on the left had side of the graph view
Image 3
Now we have engine speed we can look at the fueling strategy/duration during hard acceleration (WOT)
Below we have captured an injection duration of 5.302 ms that would appear to extend into the “approximated” compression stroke
Image 4
As we know, this is intended behavior given both ignition and injection timing will increase and decrease in proportion to engine speed/load.
In contrast, an increase in engine speed and load will result in a reduction in ignition dwell time accompanied with an increase in injector duration.
Hopefully, we can see how manual measurements (using the techniques above) are time consuming for sure. Please remember, we could also use “Measurements” between time rulers (i.e., positive pulse width) but how do you quickly find the smallest and largest positive pulse width in our 20 second capture? We use Deep Measure.
The true beauty of Deep Measure is that we can enter the threshold level upon which we wish to measure (and so determine) the pulse width of interest.
Below I have opted to use 1.5 A as the threshold upon which to determine our injector pulse width (duration) on channel D. As we can see, “Cycle 44” is clearly identified as having the largest pulse width (5.1787 ms) across our 20 second capture which occurs at 4640 rpm (How easy is that?)
Note how this value differs from our manually measured 5.302 ms given Deep Measure is using 1.5 A as the crossing threshold upon which to accurately determine pulse width
Image 5
If we export this Deep Measure data, we can graph our high pulse width (injector duration) in Excel (See image below)
Image 6
Once again, time consuming and in an ideal world, we need to plot this data against other signals within the graph view. We have discussed this here viewtopic.php?p=102933#p102933 with SENT signals but very time consuming indeed!
So how can we plot injector duration against all other signals within the graph view? We use Math channels
Here is a great explanation from the software team.
Delayis the measure of time between equivalent reference points on 2 waveforms (usually rising or falling edges). This concept is closely related to phase, but the interval is measured in time, rather than an angle representing how much of the cycle has elapsed. Delay can be used to describe how long the waveform has taken to travel between these two points.
To summarize, while they are related concepts, they represent different aspects of waveforms and are measured in different units.
With this in mind, if we graph the delay “between equivalent reference points on 2 waveforms” (in our example injection and ignition events) we are able to plot the time difference between our injection event (which occurs before ignition) and our ignition event during engine acceleration/deceleration
As described here, viewtopic.php?p=104326#p104326 the time delay between channel D and B can be derived using the math channel “delay(D, B)”
Image 7
Note above how the time delay between injection and ignition events falls dramatically during our initial acceleration. i.e., the increased injector duration is closing the gap between injection and ignition
Note below how the math channel has used the rising edges of both the injection and ignition events to derive a delay time of 14.06 ms (Also confirmed using the time rulers)
Image 8
So, what about graphing injector duration?
Well, this can be challenging using Duty cycle math’s due to the peak in-rush current during the initial injector open event.
Ideally, we need to ask the math channel to ignore the time between in-rush peaks and focus on the positive pulses as we requested of Deep Measure using a 1.5 A threshold. (I will create a new feature request for this feature)
All is not lost however as we can filter out the high-frequency in-rush peak so as to leave us with the typically injector pulse width upon which to graph injector duration
Note below the effect on the in-rush peaks of channel D with a 200 Hz low pass filer applied!
Image 9
A word to the wise at this stage, the low pass filter has clearly influenced the injector duration due to the “rounding” (edge softening) of the signal and therefore is not a true representation of each positive pulse (injector open event)
With that said, this “rounding” is applied evenly across the entire capture to all positive pulses and therefore the derived math channel serves as an accurate indication of each pulse in relation to engine speed and load range
If time allows, I will repeat this test using the crankshaft signal with a frequency math channel rather than a crank math channel. Why?
Using a frequency math channel on a crankshaft signal results in repeated falling spikes as the missing teeth of the crankshaft pick up move by the crankshaft sensor.
These falling spikes may serve to provide a timed “edge” (one per engine revolution) upon which to time other events such as injection and ignition!
Below is an example only (without delay math) of the theory above where the intention would be to graph the delay between the crank signal missing teeth and the injection events of channel C
Image 10
At this early stage, there may be some development work required with incorporating a frequency math channel (“freq(A)”) into the delay math channel (“delay(freq(A), C”); this will be triaged for review by the software teams
There could also be an issue with my choice of channel C as these pulses include Pre, Pilot and Main injection events which may present a further challenge for the software when deciding upon which “edge” to calculate delay
All food for thought at this early stage but well worthy of continued investigation
Please feel free to experiment with the above math’s and highlight any limitations or success stories you find
Just to recap on how we calculate road speed (using our ABS sensor signal from channel A)
Using a tyre size of 215 x 45 17 and an ABS pole/tooth count of 48 we require:
• Number of teeth or pole count at the ABS pick up ring. (Physical count = 48)
• Tyre circumference. = Diameter (0.625 meters) x π (3.14)
• The number of wheel/tyre revolutions in one minute. 60/48 poles x signal frequency = RPM
The formula for wheel speed in km/h is written:
Wheel/Tyre Speed (Frequency Hz x 60 = RPM) x Tyre Circumference (Meters) = Meters per minute
Meters per minute x 60 = Meters per hour
Meters per minute / 1000 = Kilometres per hour
The math channel looks like this: Speed in km/h: 60/48*freq(A)*(3.14*0.625)*60/1000
If you require road speed in “mph” then the math channel requires the following addition.
Kilometres per hour x 0.621371 = Miles per hour Speed in mph: 60/48*freq(A)*(3.14*0.625)*60/1000*0.621371
Calculating Distance (m)
Distance = Speed x Time, therefore the math channel looks like this:
Note below we multiply by “T” (Time)
Distance in meters (m): 60/48*freq(A)*(3.14*0.625)*60/1000*T
Referring to the image below we can see at 10 seconds into the capture (denoted by the time ruler) we are travelling at approx. 38.03 km/h and have covered a distance of 381.2 meters since the start of the recording
Image 1
Calculating Velocity (m/s)
Velocity is expressed in meters per second (m/s) and given we have road speed in km/h, this is a reasonably straight forward conversion
The math channel looks like this: Velocity (m/s): 60/48*freq(A)*(3.14*0.625)/60
Please note, the above math channel returns a conversion of km/h to m/s, (which are the units of velocity) it does not however indicate the true vehicle velocity as we require the direction of motion
The following link has this covered https://en.wikipedia.org/wiki/Velocity
Calculating Acceleration (m/s²)
Acceleration is the rate of change of Velocity and expressed in meters per second squared (m/s²) https://en.wikipedia.org/wiki/Acceleration
To graph our acceleration, the math channel looks like this:
Note below we divide by “T” (Time)
Referring to the image above, at 10 seconds into the capture we are travelling at approx. 38.03 km/h or 10.56 m/s, with an acceleration of 3.801 m/s² and covered a distance of 381.2 meters since the start of the recording.
The keen eyed will notice that the Acceleration math channel appears to indicate a rapid deceleration (tumbling) at the start of the capture prior to acceleration!
This can be attributed to the 1 kHz low pass filtering applied to channel A that ultimately results in insufficient samples at the start of the buffer. (The more aggressive the filter, the more noticeable are the effects on the math channel) In this scenario, the maths behind the scenes are momentarily compromised until sufficient samples are acquired further into the capture/buffer.
With all that said, the frequency of channel A (during the first 0.5 seconds of our capture) is momentarily decreasing and as such, there can be no acceleration
In order to accommodate this “math” characteristic, we can zoom on the graph view from the start of acceleration so as to exclude this tumbling event from view
Image 3
Note above how careful use of the marque zoom tool enables the user to exclude the tumbling acceleration at the start of the buffer.
Whilst the use of the low pass filter has thrown a slight curve ball at the acceleration math channel, the benefits of smooth, clean plots across the graph view far outweigh the glitch at the start of the buffer
I have attached the above psdata file below; please feel free to amend the filtering and note the effects on the displayed maths