Maths is cool

Ask any questions about using PicoScope Automotive software here.
Posts: 7
Joined: Tue Feb 25, 2014 7:17 pm

Re: Maths is cool

Post by rossk » Thu Nov 15, 2018 8:45 pm


With reference to the 0.1 Ohms resistor and extended battery drain testing and specifically the maths channel, the idea being this is mainly beneficial to monitor over long time bases, I assume we could make a custom probe to scale the live readings to amperage as apposed to having to wait for the screen to complete before the maths channel is plotted / rendered?

As I want to monitor say a complete shut down cycle but also want to be able to read the current as things change, and at present have to read the voltage and do the maths myself which makes maths boring and not fun :D

Keep up the great work...

Pico Staff Member
Pico Staff Member
Posts: 282
Joined: Thu Aug 11, 2011 7:43 am
Location: Cambridgeshire

Re: Maths is cool

Post by Martyn » Fri Nov 16, 2018 10:45 am

Yes a custom probe would work fine :) it's just cool maths using a different menu.
Technical Support Manager

Steve Smith
Pico Staff Member
Pico Staff Member
Posts: 674
Joined: Sun Aug 25, 2013 7:22 am

Re: Maths is cool

Post by Steve Smith » Mon Nov 19, 2018 11:23 am

Once again thank you for the feedback.

I know the following may not be for everyone but I thought it worthy of sharing based on the events discovered during these captures and if nothing else, revision of ignition theory

We are often asked about “Dwell Angle” by Classic Car Enthusiasts, Racing teams and Restorers.
There is frequent disbelieve and dismay when users are informed there is no “Dwell Feature” within PicoScope!

I fully understand their response as a Technicians of a certain age (I include myself here) would measure Dwell Angle daily either via “The Crypton Machine” or a Multimeter. So why is it not included within PicoScope?

To be completely accurate it is, but requires maths to reveal the Dwell event of the primary ignition circuit. The down side however is the techniques required to obtain the dwell and interpretation of the results.

An average Dwell angle at cranking, idle and high engine speeds measured by early generation engine analysers would have been exactly that, “an average” over time with a questionable refresh and sample rate.

PicoScope however will measure every single primary ignition dwell event and present the results to the user in graph or table form. This sounds like over-kill but does reveal some characteristics that once again I was not aware of.

I must refer to the following post here: topic17551.html?&p=76391&hilit=Dwell+angle#p76391 and thank Richard, STC and Kim for their invaluable contributions.

Dwell Angle is defined as the amount of time the contact breaker points are closed (current flowing through the primary ignition circuit) and is measured in degrees of distributor shaft rotation.

Concentrating on a 4 cylinder engine, the total Cycle Time (expressed in degrees of distributer shaft rotation) for each ignition dwell event would be:

360° of distributer shaft rotation / 4 Cylinders = 90° Cycle Time

Cycle Time refers to the total amount of time between each ignition event, or to express this another way, the total amount of time the primary ignition current is switched on and off between each ignition event, better known as Duty Cycle.

The following link will help here: ... duty-cycle
Cycle Time.jpg
Cycle Time
In order to now calculate the dwell angle for this 4 cylinder engine we use the formula:
duty(B) / 100*90
“duty B” indicates the percentage of time our signal is positive during our cycle time.
Dividing by 100 converts our positive duty percentage into a decimal value.
Multiplying by 90 allows the software to display the dwell period, expressed in degrees of distributer shaft rotation.

For 6 Cylinder engines (360° / 6 = 60°)
duty(B) / 100*60

For 8 cylinder engines (360° / 8 = 45°)
duty(B) / 100*45

This is one of those rare occasions where the formulas use positive duty cycle given we are measuring current not voltage as it provides a more stable signal for maths to function.

I have included the primary voltage on channel A if you wish to use the negative duty of the primary voltage. Here you will use the formula: duty(-A)/100*90. (To view Channel A, right click on the scope grid and select “Channels”)
Dwell Angle maths 2.jpg
Dwell Angle Maths
I mentioned earlier about the techniques required when using maths to calculate dwell angle.

These include:

1. AC Coupling the primary ignition current (Channel B) to define a clear crossing point at zero Amps
2. Low pass filtering of channel B (4 kHz) to remove excess noise so improving the outcome of the math channel (This is essential)
3. An increase in the number of samples (6 MS) improves the performance of the math channel to ensure accurate results

Looking at the above waveform we can see a deviation in the dwell angle from approx. 46° at idle speed to approx. 36° at WOT. (A deviation of approx. 10°) This would initially suggest a worn distributer shaft bearing/bush, so creating a deviation in dwell at higher engine speeds (during the transition from idle to WOT)

In the waveform below I have included the rpm math channel 60 / 2 * freq(B) to clearly indicate the change in engine speed and so the effect on dwell angle
RPM Maths
At this stage I cannot confirm if the variation in dwell is due to wear in the distributer or activity of the distributer base plate centrifugal advance mechanism! What I do know is the vehicle performs fine with no running or timing issues and a mechanical inspection for lateral movement of the disturber shaft confirms no significant wear.

What I find intriguing is that the deviation in dwell angle (approx. 10°) at high rpm is approximately half that of the 20° ignition timing advance specified at the crankshaft! This is far too coincidental and so I shall return to this vehicle to confirm the advance in ignition timing, whilst also investigating the effect on dwell angle as a result of distributer base plate rotation/advancement.

Theoretically the frequency of our dwell event should change but the duty/dwell should remain the same. With that said, when the distributer base plate changes the relationship between the “heel” of the contact breaker points and distributer shaft, the dwell angle will momentarily change.

Given we can now measure each and every ignition cycle with extreme accuracy, we maybe revealing an event that has always been present but not captured due to “average dwell values”

Using the Deep Measure feature of PicoScope topic17711.html we can drill deeper into every ignition cycle to reveal how the duty cycle (and so dwell angle) alters at higher speeds. The waveforms below highlight the change in the negative duty at idle speed and then WOT.

To obtain the positive duty from “Deep Measure”, subtract the values highlighted below from 100
Deep Measure at idle speed
Cycle 83 highlighted at idle speed below:
Cycle 83 at idle speed
Idle speed the Duty Cycle (low) is given as approx. 48% (52% high or positive)

Deep Measure at high speed
Cycle 187 highlighted at WOT
Cycle 187 at high speed
At WOT the Duty Cycle (low) is reported as approx. 59% (41% high or positive) indicating a difference of approx. 11%

The Deep Measure feature certainly helps to confirm the behaviour of math channel during WOT and of course further investigation will be required. It would be great to carry out a similar test to a vehicle with a worn distributer shaft bearing/bush, as this would highlight how the results compare with the capture above.

Moving onto Dwell Angle expressed as a percentage:

You may often see Dwell Angle stated as 46° or 51%! Both refer to the same “event” but using different units:

To convert a dwell angle of 46° to 51% for this 4 cylinder engine:

We know that 360° / 4 cylinders = 90°
We also know that for 46°of 90° distributer shaft rotation our points are closed (dwell angle)
To convert dwell angle to a percentage value: 46° / 90° x 100 = 51%
51% also happens to be our positive duty.
See the waveform below with the additional “duty(B)” math channel included
duty(B) maths
Food for thought:
Here is a 1985 Vauxhall Astra Van with the 1.3 S OHC engine utilising a traditional distributer but with electronic ignition. (Engine performs fine)

The Deep Measure function measures the change in Duty (low) of our primary ignition current between the time rulers from approx. 82% at idle speed (18% high) to 65% at WOT (35% high)
Astra duty low
Notice the behavioural pattern of the dwell angle math channel which is extremely low at idle speed (16.55°) and increases to 27.08° during WOT. This is the complete reverse of our mechanical contact breaker points and demonstrates how far ignition systems had advanced even during the 70’s and 80’s.

A big thank you to Kevin Ives for digging up these vehicles and the use of his workshop which no doubt I will be returning too to discover more!

The psdata file for the Sherpa Van (with contact breaker points) can be found below.
Remember to activate a 4 kHz low pass filter to Channel B and please be patient when loading the file as there is a lot of data for the PC to crunch through with maths, filtering and Deep Measure
Freight Rover_Sherpa_Idle to WOT.psdata
Sherpa psdata file
(8.84 MiB) Downloaded 32 times
I hope this helps, take care…….Steve

Posts: 7
Joined: Tue Feb 25, 2014 7:17 pm

Re: Maths is cool

Post by rossk » Tue Nov 20, 2018 10:46 am

Martyn wrote:
Fri Nov 16, 2018 10:45 am
Yes a custom probe would work fine :) it's just cool maths using a different menu.
Thanks Martyn
I have made a new custom probe that allows live reading without waiting for maths channel to be drawn, to include resistor, cables and clamps etc - seems to work great.

Also found interesting during setting up and checking accuracy that I can run exactly the same test without going across a resistor, but using my DMM in amperage and going across this instead - although maths was of course slightly different, but it did allow me to confirm how accurate the test was as I am now able to see a digital amperage reading against plotted maths :D

Keep up the good work

Steve Smith
Pico Staff Member
Pico Staff Member
Posts: 674
Joined: Sun Aug 25, 2013 7:22 am

Re: Maths is cool

Post by Steve Smith » Sat Dec 01, 2018 8:48 pm

I finally got to revisit the above vehicle (Sherpa Van) to determine why we experience a fluctuation in dwell angle (approx. 10°) during the transition from idle to higher engine speeds

The first consideration was movement of the distributor base plate due to the vacuum advance device, or the centrifugal advance mechanism.

Unfortunately the vacuum advance diaphragm on the test vehicle was leaking, rendering the use of a vacuum pump near useless.
(25.68 MiB) Downloaded 34 times
However, application of a continual intake manifold vacuum was sufficient to overcome the diaphragm leak and rotate the distributor base plate.

The waveform below displays the raw data before getting to work with maths, filtering and graphing
Raw data
The waveform below utilises the raw data above to visualise and graph the “real-time” effects of the distributer vacuum advance mechanism upon engine speed, ignition timing and dwell angle.

A WPS500x pressure transducer (Channel D) was place in line with the distributer vacuum hose in order to plot intake manifold pressure acting upon the vacuum diaphragm. The engine here was idling and the vacuum released to atmosphere by momentarily removing the vacuum hose from the diaphragm.
Vac advance
The effects of the vacuum advance (even with a leaking diaphragm) are dramatic for sure.

Channel A utilised an optical pick up aimed at the crankshaft pulley ... sensor-kit generating 1 pulse per revolution, so allowing for accurate representation of engine speed. Note the drop in engine speed when the vacuum is released from the diaphragm given the ignition timing retards

(The optical pick up also proved invaluable during the following ABS case study) ... -operation

Channel B looks at the frequency of the peak firing voltages or to put this another way, ignition timing. Note how the ignition timing graph mirrors the engine speed graph.
See “How did we calculate ignition timing?” later in this post

Channel C (Dwell Angle) remains fixed throughout this whole event and therefore we can conclude the vacuum advancement of the distributor base plate is not influencing dwell angle

The next step was to determine if the centrifugal advance mechanism had an influence upon dwell angle during the transition from idle to WOT. Here the distributor base plate was locked in the advance position using a TX20 Torx bit, whereby the engine was then run from idle to WOT.
Locked base plate
Below we have the engine now running from idle to WOT and returning to idle with the distributer base plate locked in the full advanced position
Locked base plate at WOT
Here we conclude the deviation in dwell angle is not linked to the operation of the vacuum advance device, or the centrifugal advance mechanism. Therefore the deviation must be characteristic behaviour of the distributer assembly!

Previously I mentioned “What I do know is the vehicle performs fine with no running or timing issues and a mechanical inspection for lateral movement of the disturber shaft confirms no significant wear”.
Whilst the vehicle does run fine, “no significant wear” was not truly accurate under closer inspection.
(20.24 MiB) Downloaded 35 times
The above video highlights significant lateral movement to alter the contact breaker gap from 15 thou (0.381 mm) to 24 thou (0.6096 mm)

Notice in the video below how the “floating” design of the base plate lends itself to characteristic movement which alters the contact breaker gap
(22.27 MiB) Downloaded 23 times
So I guess the question here is “what does a good one look like?”

Once again thanks to Kevin Ives who pulled out of the bag a brand new Lucas 59D4 distributer destined for a British Leyland A Series engine (I kid you not)

In the video below, this brand new Lucas unit (complete with points and condenser) exhibits similar lateral movement of the distributer shaft, sufficient to alter the contact breaker gap from 16 thou (0.4064 mm) to 22 thou (0.5588 mm)
(2.51 MiB) Downloaded 32 times
To conclude on dwell angle (and thank you for reading) the deviation we capture with PicoScope is a true event based on the design of the distributer and the dynamics that occur during the transition from idle to WOT. What we have therefore highlighted is typical behaviour and not a faulty or excessively worn distributer shaft bearing/bush, demonstrating one of the many reasons these ignition systems are no longer viable for today’s vehicles

Moving on:

With reference to Channel B capturing the secondary ignition event of cylinder 1, I want to clarify a number of questions that might be raised:

How did we calculate ignition timing?

Using Deep Measure topic17711.html we can locate each and every secondary ignition event for cylinder 1 whilst also revealing the time span between each event.

With the engine at idle speed the time span between each cylinder 1 firing event should remain near equal. However, when we apply vacuum advance, the time span will reduce, so resulting in an increase in frequency and advancement of the ignition timing. We can qualify this advanced timing using the rotation rulers to accurately measure the peak firing voltage in relation to the TDC marker (reflective tape) placed on the crankshaft pulley

Ignition timing with -304 mbar of vacuum applied to the distributer
Ignition advance
Ignition timing with NO vacuum applied to the distributer
No advance
How do we graph ignition timing?

Realistically we graph the change in time between each firing event for cylinder 1. If the time between ignition events decreases, the frequency therefore increases and so we conclude an advancement in ignition timing.
Trying to graph secondary ignition voltages is challenging once we get above idle speed. Typically secondary ignition waveforms are well defined at idle speed which helps both the math channel and Deep Measure because to calculate frequency, you need a clear and well defined crossing point.
Locating the crossing point
If we are to graph the peak firing voltage events, we cannot use zero volts as our crossing point given the activity about zero volts from neighbouring cylinders and EMI (Electromagnetic Interference)

To overcome this hurdle we can raise the crossing point of our signal to the chosen level above (2900 V) as only the peak firing voltages for cylinder 1 reach this threshold.

Amending the crossing point of a math channel

To raise the crossing point for channel B use the math formula freq(B-2900) and this goes for any math channel where zero is not the desired crossing point in which to determine the frequency of a signal. (Choose a crossing point relevant to your signal)

I mentioned how secondary ignition is challenging to graph given PicoScope can detect the slightest deviation or glitch in frequency. The results of such events can be seen below in the form of 4 peaks that deviate from the trend line.
Timing frequency
Here the math channel has captured a momentary increase in frequency within the ignition voltage, resulting in a deviation from the trend line. Bear in mind this is at idle speed where ignition events are well defined.

Finding a clear crossing point (for cylinder 1 only) at higher engine speeds without deviation or glitches is far more challenging. With that said, (at idle speed) we can clearly see the trend of ignition timing over the ten second capture above.

I hope this helps, take care…..Steve

Steve Smith
Pico Staff Member
Pico Staff Member
Posts: 674
Joined: Sun Aug 25, 2013 7:22 am

Re: Maths is cool

Post by Steve Smith » Sat Dec 15, 2018 2:47 pm

Calculating theoretical MAF

With reference to the following case study ... -mil-p0172

I thought it would be good to revisit the maths and modify the technique to calculate the theoretical MAF. Thanks to Andy Crook at GotBoost and the comments left at the end of the case study which are always appreciated, thank you again.

Like all measurements, accuracy is paramount and there will always be variables where maths is applied to raw data. Hopefully the information below will help minimise inaccuracies attributed to how maths and filters are applied

Here we have a 1.8 litre, 4 cylinder normally aspirated Toyota Celica (Engine code 2ZZ-GE)
Our capture focuses on the relationship between the crankshaft sensor, throttle position and MAF from idle to WOT
Initial capture
In order to accurately determine the maximum engine speed during the WOT event, I have zoomed in at the point of peak amplitude to measure a single engine revolution using the Time Rulers.
N.B amplitude increases in proportion to engine speed with an inductive style crankshaft sensor.

The math channel Crank(A, 36) is also included to graph engine speed topic11511.html
Crank maths
As we can see above there is a discrepancy at higher engine speeds between the measured value using the accurate Time Ruler method on the left (6807 rpm) and the crank math channel on the right (7000 rpm)

We also have the presence of those “nuisance spikes” where the software detects the instantaneous dramatic increase in signal frequency immediately after the missing teeth.
This has been documented and will be resolved given the crank math channel should not draw data where the missing teeth pass the crankshaft sensor; instead it should seamlessly display data as the remaining teeth continue “en route”

We can tackle the crank math channel concern (nuisance spikes) by using the filtering function of math channels.

The crank/rpm math channel would (as usual) utilise “frequency” and be re-written as LowPass(60/36*freq(A),8) to incorporate an aggressive low pass filter of 8 Hz
Filtered rpm maths
Above we can clearly graph an overview of engine speed without the intrusion of nuisance spikes

Below we can compare the crank math channel with the filtered rpm math channel
Crank and filtered maths
The LowPass(A, 8 ) section of our equation applies an 8 Hz low pass filter to the rpm math channel which has the benefit of removing the nuisance spikes (for ease of viewing) but at the expense of peak accuracy.

Our initial rpm measurement using the Time Rulers confirms our peak rpm to be 6807 rpm whereby the blue low pass math channel above indicates 6547 rpm which is 260 rpm adrift.

If we are just after an indication of rpm activity then this rpm math channel is fine, but if we want to calculate theoretical airflow we need an accurate peak rpm value where our math channel matches our measured value obtained using the Time Rulers

We can achieve the correct peak rpm by amending the amount of low pass filtering we include in the math channel

Below we have “LowPass(60/36*freq(A), 50)” where our peak rpm is now accurate (6802 rpm) with minimal intrusion from those nuisance spikes thanks to our 50 Hz low pass filter included in the math channel. Depending on the type of crankshaft sensor in your application, choosing the correct low pass filter setting to include in the math channel will be trial and error.
IMAGE 5.jpg
Increased filter for rpm
Now we have an accurate math channel indicating the correct peak rpm we can move onto our theoretical MAF calculation.

Calculating theoretical MAF values
Whilst there are a number of routes to arrive at the same MAF value, I will break it down as follows.
Using the process below, we can estimate MAF for a normally aspirated engine (assuming a WOT)

Our normally aspirated Celica uses a 1.8 litre, 4 cylinder 4 stroke engine.
Assume now this engine is running at 3000 rpm (WOT) the airflow consumed could be calculated as follows:

3000 RPM / 60 = 50 rev per second (Hz)
For a single revolution of our 4 cylinder engine we have 2 x intake strokes
Therefore 50 rev per second x 2 = 100 intake strokes per second
Each intake stroke = 1.8 litre / 4 cylinder = 0.45 litre (450 cc) per cylinder
100 intake strokes X 0.45 litre = 45 litres per second
Note: Air mass is approximately 1 gram per litre at sea level (pressure and temperature dependent).
Therefore 45 litres per second is approximately 45 grams per second (45 gm/sec).

With that said, aerodynamic calculations are based upon air mass at sea level at 15 degrees centigrade being approx. 1.223kg/m3 or 1.223g/l

Here then we multiple our 45 litres per second by 1.223 to obtain 55.035 gm/sec

Be aware that all the above assumes the volumetric efficiency (VE) of our engine to be 100 % where in reality we can pray for 90% at peak torque! (A true reality check is more like 86 to 88 %)

The math channel would be written as follows:
LowPass(60/36*freq(A),50)/60/2*1.8 for air mass at 1 gram per litre

For air mass at 1.223 g/l the math channel would be written as follows
LowPass(60/36*freq(A),50)/60/2*1.8 x 1.223
MAF Math
Above we now graph the theoretical MAF across the entire rev range using both values for air mass (assuming 100 % VE) I guess the question now is which values are used for air mass by the vehicle manufacturer ( 1 gm/l or 1.223 gm/l) and what values are displayed on their data lists? Food for thought for sure.

VE calculations.
Calculating VE is challenging regardless of ability or formulas as the complexity surrounding manifold configurations, throttle positions, valve duration/lift and aerodynamics do not lend themselves to a simple formula
However as a base line calculation of VE we can use airflow figures.

We can never assume an engine has a 100% VE, but if we calculate airflow assuming our engine has 100% VE using the air flow formula, then using a scan tool (gm/sec), we can obtain an approximation of the actual VE using the difference obtained from the scan tool compared to the value obtained via the scope formula. (Assuming air mass meter is performing correctly, no air leakage post MAF meter and the engine has no performance issues)

In the case study ... -mil-p0172 the math channel used below, “60/36*freq(A)” indicates an rpm of 7004 rpm with theoretical MAF of 106.2 gm/sec (assuming 100% VE and air mass at 1 gm/litre).

Interestingly enough the throttle is closed at the peak rpm and MAF measurement points of the math channels! This may be due to a combination of how math channels are applied/calculated and how engine speed does not immediately fall at the instant of closed throttle. Remember we are calculating peak MAF based on calculated rpm.
Case study file
The Scan Tool reveals MAF to be 111.85 gm/sec at a similar rpm of 7021 rpm
Case study scan data
If we now do the maths on these figures, the scope has calculated MAF to be 106.2 gm/sec where as the Scan Tool reports MAF to be 111.85 gm/sec at a similar rpm
111.85 / 106.2 = 1.05 x 100 = 105 % Volumetric Efficient (VE) ……..It’s a miracle!

Whilst this engine utilises VVT-iL “Variable Valve Timing and Lift” (valve lift increases at high rpm) it is certainly not over 100 % volumetrically efficient and does not suffer with external air leakage (post MAF meter) to warrant such airflow

If we now use MAF at 1.223 gm/litre its starts to look more applicable
The scope has calculated MAF to be 106.2 gm/sec x 1.223 = 129.88 gm/sec
The Scan Tool reports MAF to be 111.85 gm/sec
111.85 / 129.88 = 0.86 x 100 = 86.11 % VE

We can therefore conclude the manufacturer in this instance is displaying MAF values using 1.223 gm/litre based on our calculations, with the vehicle performing correctly

To summarise: If we know the engine speed, number of cylinders and the engine capacity we can calculate the theoretical airflow.

One final amendment to your math channel could include an average VE value of 88%
If we had used the math formula LowPass(60/36*freq(A),50)/60/2*1.8*1.223*0.88 within the case study, we arrive at a typical MAF value assuming 88% VE rather than 100%
129.88 gm/sec * 0.88 = 114.29 gm/sec (Scan Tool = 111.85 gm/sec)

I am not sure if this helps as it is useful to calculate VE (post capture) based on the theoretical MAF at 100% VE against the reported MAF from the scan tool, but it remains an option if required.

The psdata file can be found below. You will need to download the latest PicoScope software from here to view the file
Celica psdata file
(2.55 MiB) Downloaded 43 times
I hope this helps and reveals a number of challenges we face using these techniques……

Take care……Steve

Pico Staff Member
Pico Staff Member
Posts: 144
Joined: Tue May 16, 2017 1:02 pm

Re: Maths is cool

Post by ben.martins » Mon Feb 04, 2019 3:30 pm

Hydraulic Pump Theoretical Flow Rate and Volumetric Efficiency

I’ve have been recently carrying out some work using the engine and hydraulics kit Pico have to offer along with the flow meters. This allows us to look at both the engine and the hydraulics side of a machine in order to determine faults with either or both sides of the system.

A common test to determine the hydraulic pump serviceability is something called a PQ test. This is where the pump is pushed to its maximum system pressure to ensure the pump is capable of still producing the correct flow at certain pressures. Done at regular intervals, this test can be used to track the pump and catch any sign of significant wear or drop in performance before it is too late.

With Pico’s 300lpm and 600lpm flow meter’s it’s possible to carry out a PQ test and record the data rather than file everything on paper as we can utilise the loading valve to ‘load’ the pump. Not only this but once a stored file has been created then the setup is done for you and only the connection to the machine needs to be made. Where does the maths come into it?

Something we find useful in hydraulics is comparing a theoretical flow rate to that of the actual and therefore we can calculate the volumetric efficiency of the pump. In order to set up our scope and understand what signals we need to capture will be based on the formulae we will be using. To begin with we need the theoretical flow rate which is as follows:-

Theoretical Flow (LPM = Pump Displacement (cc/rev) x Pump Speed (RPM) / 1000

If in using gallons per minute then the formulae will read:

Theoretical Flow (GPM) = Pump Displacement (cu ins/rev) x Pump Speed (RPM) / 231

Being in the UK I will be using the first formula as the pumps here are marked in cc/rev. For this exercise the pump has a displacement of 51cc/rev. We need to be mindful that this theoretical calculation is based on a pump being 100% efficient, which is not possible due to internal leakage. However, having both will allow us to calculate the efficiency.

You will notice from the above we need to gain the pump speed. For most mobile hydraulic machinery the pumps will be directly connected the engine there engine speed = pump speed. This makes it easy to gain pump speed as we can use the engine crankshaft position sensor or other signals to determine the pump speed. If the pump is driven externally from the engine maybe from a belt or a gear, then the speed can be acquired from an optical pick up, or calculate the ratio between the crankshaft and the gear and factor this into the formula. For the example I have engine and pump are directly linked but we still need to convert the crankshaft position sensor output into RPM.

During this test I will be fixing the engine speed to set figure of 1500 RPM. This keeps is a good operating speed for most machines but also acts as a constant when we carry out the test again in the future. Remember all this information can be added to the notes section in PicoScope and remains with the file. That way if someone else had to carry out the test in your place they can follow the same test plan. We could opt in the case to use the crank math channel but as the RPM is fixed I’m not really that interested in the fluctuations of engine speed from a diagnostic point of view. For this reason I will use a filtered frequency math channel as per this topic, topic19271.html?&p=86681#p86291. This will provide me with a much smoother line but will still show larger engine speed changes due to loading and unloading of the pump.

The math behind this comes from the topic but has been adjusted slightly to adjust for RPM on this machine as we have a 37 tooth pick up ring on the crank shaft sensor so to ensure our RPM is correct we need to add a scaling factor. In this instance I’ve used 1.616. The formula therefore reads as follows:

RPM = 1.616 x LowPass(freq(A),4)
Crank Maths.png

To confirm your RPM it is good practise in this case to zoom in on your crank signal and use the time rulers to confirm RPM.
RPM confirmation.png
1. Ruler overview with measured math channel.
2. Math channel
3. Frequency and RPM measured between time rulers.

From the above I’m happy that there is minimal difference between the two and so the math channel can be saved and renamed for future use. From here to calculate our theoretical flow rate we need to put the math channel we have created for RPM into the formula from earlier. This means creating a new math channel of the following:

Theoretical Flow (LPM) = Pump Displacement (cc/rev) x Pump Speed (RPM) / 1000
= Pump Displacement (cc/rev) x Pump Speed (RPM) / 1000
= 51 x (1.616 x LowPass(freq(A),4)) / 1000

Theoretical Flow.png

Now we have engine speed and a theoretical flow rate based on our pump speed and pump displacement of 51cc/rev. Onto the PQ test which requires us to make the connection into the hydraulic system to measure the flow and the pressure. Please ensure you have the relevant training, correct PPE and prevent any potential contamination that could occur. This includes checking any hoses, fittings, WPS600C as well as the flow meter for cleanliness.

With the system installed and making sure you are aware of the working pressure of the machine, begin to load the pump whilst always observing the pressure. Pico’s flow meters do come with a safety burst disc giving you some protection in the event of a pressure spike or if the loading valve is wound too far, however, replacement of the discs will be required in order to carry out further testing. The below capture is from a machine with a working pressure of 260 BAR.
PQ Test.png

1. Engine RPM math channel
2. Pump pressure
3. Measured flow
4. Theoretical flow
5. Unloading of the pump
6. Ruler overview

Focusing on the first part of the capture between the time rulers we can see the pump pressure is 255 BAR. Due to the connection we are not protected by the relief valve which is why I’ve limited the pressure to below the working pressure. This ensures safety but also gives me a good indication of the pump output. The important measurement here is the flow rate because flow makes it go. Using the rulers we can see that at 255.5 BAR we have a flow rate of 70.25 LPM. Comparing this to our theoretical of 78.75 LPM we are losing about 8 LPM. Knowing that all pumps are never 100% efficient this could be down the natural internal leakage we spoke of earlier. To calculate the volumetric pump efficiency all we need to do is divide the actual flow rate by the theoretical and then multiple by 100 to get the percentage.

Pump Volumetric Efficiency (%) = (Actual Flow Rate / Theoretical Flow Rate) x 100

In the above capture this would read as follows:

Pump VE = (70.25 / 78.78) x 100
=0.89 x 100

We could leave it at that or we could include this in the capture using another math channel. Remember we can add as many math channels as we like post capture as our original data is unaffected. The resulting formula is therefore:

Pump VE math.png
To make it a little easier to read I’ve added an average measurement to the math channel between the two rulers placed whilst the pump is being loaded.

I have attached the PSDATA file with the appropriate formulae. The power of math has the potential to reveal so much more and there are many more calculations we can do with hydraulic formulae which I hope to bring more in the future.
PQ Test with math.psdata
(2.4 MiB) Downloaded 36 times

Posts: 1
Joined: Thu May 19, 2016 2:17 pm

Re: Maths is cool

Post by maxgas » Thu Jun 06, 2019 8:29 am

Hi All I am trying to get to grips with the maths channels, currently trying to use an inductive crank waveform to establish an engine misfire (no misfire monitors). when I use "crank(B,36)" very little information appears.
Land Rover_Range Rover_1998_Petrol_20190606-0002.psdata
(4.23 MiB) Downloaded 13 times

User avatar
Posts: 367
Joined: Wed Nov 20, 2002 4:19 pm
Location: Washington State USA

Re: Maths is cool

Post by Autonerdz » Thu Jun 06, 2019 4:16 pm

maxgas wrote:
Thu Jun 06, 2019 8:29 am
when I use "crank(B,36)" very little information appears.
Either use freq(B)*1.67 or apply some filter to B. 900 Hz seems to bring up your crank(B,36).

Steve Smith
Pico Staff Member
Pico Staff Member
Posts: 674
Joined: Sun Aug 25, 2013 7:22 am

Re: Maths is cool

Post by Steve Smith » Tue Jun 11, 2019 10:38 am

Many thanks for the posts and continued views of this thread as the power of maths certainly adds new dimension to post capture analysis.

I want to add in here 2 other forum posts that should be included looking at RMS values of AC signals.
Whilst the maths can be challenging, once you have the math channel loaded into your library, it will always be ready for use.

The first post looks at graphing the RMS voltage of an AC Signal

AC RMS Math Single Signal

To calculate the RMS voltage of a single AC Signal
The psdata file containing the above math channel can be found below:
Single AC Signal
(1.56 MiB) Downloaded 5 times

The second post looks at graphing the RMS current of a 3 phase electric motor under acceleration from rest

RMS Current 3 Phase

To calculate the RMS current we then use the math channel formula:
The psdata file containing the above math channel can be found below:
Pulling away with Math
(19.68 MiB) Downloaded 7 times
I hope this helps, take care......Steve

Post Reply