Maths Channel Question - Dwell

Ask any questions about using PicoScope 6 Automotive software here.
Post Reply
User avatar
FioranoCars
TwoWaves
TwoWaves
Posts: 386
Joined: Thu Dec 13, 2012 11:26 am
Location: London, UK

Maths Channel Question - Dwell

Post by FioranoCars »

Hi all
Having done a bit of searching of online and old presentations/application notes I have saved away, I seem to be unable to figure out how to get a duty cycle/Dwell calculation to perform :oops:

While I don't have a Snap-on device, someone recalled with Snap-on "scope/scanner" being able to display dwell, and as most automotive DMM's have a Dwell feature it surely can't be that hard ... :roll:

There has been lots of talk of distributors of late on the forum, and dwell has come up a few times, sadly in my case it was chasing a busted DMM which worked fine 4 weeks ago, but now has dwell reducing with RPM, only caught the issue by manually measuring some waveforms, see below. Oddly it's still reading true at idle but by 3,000 rpm it's dropping massively, and repeatably, so was not obviously busted.

Here is an illustrated example, using Current as the indicator of dwell:
Dwell based on Coil Current, measured at Coil +
Dwell based on Coil Current, measured at Coil +
The maths is pretty simple, take 360 degrees and divide by your cylinder count (Ok, no of dizzy, and contact breakers also matter- see below) - so a 4 cylinder is 90° and 8 cylinder is 45°- this is the maximum dwell based on the rotation of the Dizzy arm per contact breaker points. If you have 2 contact points like a European 6 cylinder 246 Dino then your max dwell is 120° verse a USA which is only 60°as it has a single set of points, likewise dual Dizzy - one for each bank or 4 contact breakers increase the max dwell proportionately too. In my example, it's a basic single contact breaker 8 cylinder, so 45°

To calculate the dwell using time, is simply the total Charge cycle time (charge of the coil and discharge) verse the "charge" part, expressed as a percentage of the Maximum Dwell.

In the example above it's a charge time of 14.27ms DIVIDED by total time of 19.21ms MULTIPLIED by 45°
so 14.27 / 19.21 = 0.74284227 * 45 = 33.42790213 - so 33.4°

By hand this is both tedious and slow, and does not allow the continuous display or visual telltales of spurious activity, say at key PRM (often high) or during WOT or lift-off. So I did start to have a look at Maths Channels, but despite a few attempts I failed to get anything of value (either got 0% or 100% :oops: :cry: )

If Dwell could be calculated, then a mask could be used to monitor the signal (for me probably +/- 1.5° although this is car dependent) which would then highlight your issue ...

I looked at the 3 keys methods of capturing Dwell on the car, and due to issues of stability using the King lead (see attached waveform file - ChB) for your source it's probably not the best place to start, and equally the Coil voltage (see below) makes an easy visual for hand calculations, but for math channels is not as clean and clear as the Current (Above) measured at coil +
Coil Voltage for Dwell
Coil Voltage for Dwell
I've not zero'd precisely the clamp, but it's going to float, so for a Math channel, some sort of filtering might be needed. A threshold is needed to convey the floating, which I tried to compensate using maths, but sadly it did not help get a result! I tried to get a binary on off (high / low) and then apply duty to that, but brain fade set in ...

Anyway, I'm a little stumped still and had no inspiration this morning as to how or if this is possible, or if this is a development request, to add a new Math operation to generate binary 0/1 based on a threshold, which could then use duty and your dwell to encapsulate into a bigger formulae ... or even just an add a full-fledged dwell feature?

I know dwell is a dying art for distributors, but most of those cars that still survive will be out there for years to come as they are now classics in the most part ... and it's still valid for coil packs which have remained popular until quite recently, though probably not used on many current models, which have gone to individual coils, and that becomes a different equation!

Anyway, if anyone has already done using a different method, or filtering/maths etc or feels their intellectual muscles bursting at the challenge, then please do share

thanks
Richard
Attachments
Mercedes-Benz_SL-Class_1974_Petrol_dwell calc.psdata
Idle and circa 3,000 rpm captures
(2.06 MiB) Downloaded 665 times

User avatar
STC
Banned
Posts: 790
Joined: Sun Sep 13, 2015 2:10 am

Re: Maths Channel Question - Dwell

Post by STC »

Richard

I have just added 30 KHz Filtering to your Primary (CH A) and added a Math Channel DUTY (A+2) the result is not so bad

The percentage calculation, which you have to invert, is some 7% off so not ideal for setting up Points, dizzy etc. You will have to measure and calculate that to get it exact.

However it will ""allow the continuous display or visual tell tales of spurious activity, say at key RPM (often high) or during WOT or lift-off.""

Who knows how accurate any Dwell meter is or where it takes the crossover point. For sure we know it will be averaging something.
Last edited by STC on Mon Aug 07, 2017 4:05 pm, edited 1 time in total.

User avatar
FioranoCars
TwoWaves
TwoWaves
Posts: 386
Joined: Thu Dec 13, 2012 11:26 am
Location: London, UK

Re: Maths Channel Question - Dwell

Post by FioranoCars »

Thanks STC, you got 1 step further than me ...

I made a fundamental error, a bit like building complex formulae in Excel, I worked with the Maths Channels to "build" my formulae :oops: so maybe there is a bug or unintended limitation within the Maths Functions ... :!:

By this I mean I first perfected the filter, then toyed adding the Duty element and then would add the maths for my 45°

First, please take note for development request, add a preview function to the formulae page!! when you edit the filter in the channel section you can see a direct redraw of the new representation, in maths editing you really need that too, especially if playing with bandpass and bandstop !! Needing to not just save, but actual close the Math Channel dialogue before a redraw is painful. :idea: :idea: :idea: :idea:

Anyway, so I built a math filter first

Code: Select all

LowPass(A, 5000)
(""LowPass(A, 5,000)" " extra comma's purely for readability of the big number!) - although I did toy with BandStop, I was unable to get the same clean image, maybe I need to learn some more!

Next, I added Duty, and I used numbers from -2 to +2 (unsure if this was moving my signal to cross a zero threshold), but all I got was a flat zero. I tried using norm() to see if that would help (wanting to achieve a binary outcome) but sadly not!

Code: Select all

Duty(LowPass(A, 5000))
My fundamental flaw was to build a multi-function formulae and hence to preserve the original Current Capture (not wanting to apply a filter that might mask an issue (Steve's E-Type case study problem might not be as clear to spot if filters were used).

It seems that you cannot apply nested functions within Maths if it involves a filter?, or in this instance anyway, it fails.

But as STC suggests apply a 5KHz filter (I think it's better than 30KHz!) to the channel directly and then do a maths Duty on the channel gets you an in the ball park figure. but the use of +2 or +7 or -7 for that matter does not affect the result.

There appears to be no way to set the threshold, the duty calculation is "self" correcting (maybe a manual override is a possible feature request in future?). The suitability and reliability of using duty to calculate dwell would be something for the development team to comment on?

While the above works reasonably well at idle speed, at 3,000rpm it not as successful, and reducing the filtering to say 500Hz makes a prettier picture, it's not correct or stable, so makes the whole process thus far void :cry: :cry: :cry:

Code: Select all

Duty(A)/100*45
with the Active filter used at 5kHz within the Channel options. However, it's purely an indicator, and the Duty calculation might round/normalise the data meaning any issues are masked anyway (comments?)

Of course, if you can out STC, STC then please tell all :shock:

But good news, an unexpected operation of the maths channel has been spotted, so please can the Software Dev Team add it to the bug list :!: :wink:

PS For the feature request list, tool tips for the Math functions would be handy too, and a few examples within the help file would be tremendous :D

Thanks
Richard

User avatar
STC
Banned
Posts: 790
Joined: Sun Sep 13, 2015 2:10 am

Re: Maths Channel Question - Dwell

Post by STC »

Thanks STC, you got 1 step further than me ...
I should stop doing that - become a bit of a bad habit lately :) :) :)
Of course, if you can out STC, STC then please tell all :shock:
That I don't understand !?


Back to dwell measurement - I wonder if reducing the sample rate to a bare minimum would take away the need to filter. The Pico will be over analysing that, all we need is a sensible crossover point. Plus what is the need to over analyse dwell ?? If there is little or no wear in the dizzy mechanicals then its good to go. It is only a narcissistic way to set up the points gap - No More !!
sadly in my case it was chasing a busted DMM which worked fine 4 weeks ago,
that my friend is now questionable ??

Perhaps you should have had the DMM Rebuilt and not the Distributer. Did / Does the DMM have fully charged batteries in it ?

The maths is pretty simple, take 360 degrees and divide by your cylinder count (Ok, no of dizzy, and contact breakers also matter- see below) - so a 4 cylinder is 90° and 8 cylinder is 45°- this is the maximum dwell based on the rotation of the Dizzy arm per contact breaker points. If you have 2 contact points like a European 6 cylinder 246 Dino then your max dwell is 120° verse a USA which is only 60°as it has a single set of points, likewise dual Dizzy - one for each bank or 4 contact breakers increase the max dwell proportionately too. In my example, it's a basic single contact breaker 8 cylinder, so 45°
Simple ! Really ?? How many Variables up there that have to be part of the equation.

The math could be simpler. Measure Dwell as a percentage not degrees - We are in the EEC now :D
All you need is Cycle time and Coil On time - (On time/Cycle Time *100) = Dwell %

That takes away lots of stuff so it can be treated as a Duty Cycle - As you have now acknowledged following my earlier post on the Math Channel to display Dwell - Again as a Percentage. It is the way forward !

KimAndersen
TwoWaves
TwoWaves
Posts: 246
Joined: Fri Nov 30, 2012 2:53 pm
Location: Denmark

Re: Maths Channel Question - Dwell

Post by KimAndersen »

Richard

It's an interesting topic you've raised here regarding dwell angle. It reminds me of my apprenticeship education at Ford - back in mid eighties where the breaker points system were on its way out in favour for the distributorless ignition system.

Steve Smith have made an excellent diagnostic training regarding how to implement a duty cycle math channel - look here. https://www.picoauto.com/library/traini ... duty-cycle

I have tested his method and it works very well - you may need a small correction for the frequency math when you switch between idle speed and 3000 rpm

As seen in this picture, the duty cycle at idle speed is 33.05% and fluctuates about 1.936% which I think is within the specfication.
IDLE SPEED DUTY CYCLE
IDLE SPEED DUTY CYCLE
I know it´s another story when you raise the rpm.


Regards
Kim :wink:

User avatar
FioranoCars
TwoWaves
TwoWaves
Posts: 386
Joined: Thu Dec 13, 2012 11:26 am
Location: London, UK

Re: Maths Channel Question - Dwell

Post by FioranoCars »

Hi Kim
Thanks for your considered input and highlighting Steve's most relevant article, which has been a while since I've read, so was a useful refresh.

As you say the 3,000RPM page really is not being compliant, and I'm not sure that some of the spikes or dips are readily apparent from the source data, and could be related to the Duty calc, but not knowing how the duty function is being calculated at a low level it's hard to speculate, and without doubt certain "best fit" and assumptions or compromises need to be incorporated to achieve this using only 1 input, the channel.

If you take the logical next step and add RPM to the mix, which for a longer capture allowing WOT and snap test within a single buffer would be pertinent to know (might try this today if I find a few minutes), then you can do this by adding some simple Maths:

Code: Select all

Freq(A-5)/8*2*60
To explain, Freq(A-5), we need the "-5" as the current is not reliably crossing "ZERO", to set the crossover I've used a higher number to avoid any "ringing" of the coil adding falsely, as the higher current levels have less chance of this, 5Amps is showing robustly, we use the "-5" to shift the signal to the FREQ functions measuring point.
We are monitoring current at the coil, on a single coil 8 cylinder engine, so we need to divide the Frequency by 8 as the cylinders, multiply by 2, as we have 2 rotations of the crank for a full 8 sparks (divide by 4 would be shorter, but might lose some clarity of the theory!) and finally RPM is per minute not per second, so multiply by 60.
Dwell and RPM at Idle
Dwell and RPM at Idle
At idle, all appears relatively OK, about 750rpm +/-. However as already stated verse a manual calculation of Dwell (33°+/-<1°) the PicoMaths Calculation is 29.2° to 30.5° some 10% off. From a statistical point of view the 1.3° variation is possibly a little higher than my hand calculations but is within Specification for the vehicle.

So maybe like the FREQ function, maybe a manual offset "DUTY" function, or optional parameter to allow "user" guidance to the function or some other tweaks might improve the ability to derive Dwell, especially when using Current as the source data. Equally, Pico Dev Team/Bug Team embedding the Filters within functions would be very nice to have working correctly!

Moving back to the bigger problem - the 3,000RPM phase:
Qwell and RPM at 3,000RPM
Qwell and RPM at 3,000RPM
At circa 3,200RPM the manual calculations show extremes of 29.7° to 33.5°but that is also using extremes of measuring too, so possibly a little tighter range in reality, but anyway not a ridiculous number. The Maths Channel is now showing considerably more variation, from 7° if including the lowest dip to 31° with the highest peak - 24° of variance! The 7° of Dwell, is visually present in the current measurements, so something has gone wrong within the Pico Function?

Excluding the 3 peaks and 3 dips still a wide 19.5° to 29° still a range not reflected in the manual calculations.

Changing the filter to 300Hz removes these 3 Hi / 3 Lo exceptions, and leaves Dwell moving between 18° and 28°. This level of filtering is just too extreme. I'm not confident that this erratic data is due to sample rates (under), but if I get a chance I'll retest at both lower and higher rates, and then there will be proof!

It's been a fun exercise, while for the car, it's all a bit Mute as it's done. I'm still keen to hear others views, so I've uploaded the file again with the extra Maths channels.

Pushing the scope and software with old school needs has certainly reminded me of the need to play more with the Maths functions and often you need to play with a "working" (I'll refrain from using "good") car before using the tools with confidence to fault find a broken car. Confidence and awareness of limitations or pitfalls are key to avoid Rabbit Holes!

Thanks for all the input, hopefully, someone at Pico has picked up the Bug found and feature requests? :?: :?:

Richard
Attachments
Mercedes-Benz_SL-Class_1974_Petrol_Dwell and RPM maths.psdata
Dwell and RPM at Idle and 3K RPM
(2.06 MiB) Downloaded 599 times

User avatar
STC
Banned
Posts: 790
Joined: Sun Sep 13, 2015 2:10 am

Re: Maths Channel Question - Dwell

Post by STC »

Excluding the 3 peaks and 3 dips still a wide 19.5° to 29° still a range not reflected in the manual calculations
Quite, and it would be difficult to have that level of drift, the distributor and associated mechanicals would be so bad that I doubt it would start.

Your last capture, on page 1 I can see something that resembles coil primary current, on the second page, higher rpm that looks more like an inductive WSS, certainly not a coil primary I have ever seen. That's either a bad amp clamp or bad set up ? that will explain your calculations being duff !
while for the car, it's all a bit Mute as it's done
What is done ?

User avatar
FioranoCars
TwoWaves
TwoWaves
Posts: 386
Joined: Thu Dec 13, 2012 11:26 am
Location: London, UK

Re: Maths Channel Question - Dwell

Post by FioranoCars »

STC wrote:Your last capture, on page 1 I can see something that resembles coil primary current, on the second page, higher rpm that looks more like an inductive WSS, certainly not a coil primary I have ever seen. That's either a bad amp clamp or bad set up ? that will explain your calculations being duff !
Amp clamp in same position for both buffers, I've not up and moved it part way through a capture!
It is a new battery on a 60/20 Amp Clamp in 60amp mode, looks perfectly fine to me, surprised at the responsiveness of the clamp being so good, visually anyway. Zoom in and take a look, if you need your glasses I know where they are!! :lol: :lol:

This however, does raise one area of potential cause for the strange Math Channels results, as the data rate verse the clamps response rate could be causing a sampling issue ... not checked it out, just a thought.
STC wrote:
while for the car, it's all a bit Mute as it's done
What is done ?
Well the Distributor is in, dwell is set, timing adjusted, HC and CO are within spec, it's pulling strongly enough in all gears and loads, so the initial complaint is fixed, while it's not perfect, indeed far from it, that's about it for us.

It does need a major overhaul, probably a full engine rebuild ... but the required budget to do it properly is unlikely to be economic. So done, is done, not perfection, but that's what can happen to old cars.

Richard

User avatar
STC
Banned
Posts: 790
Joined: Sun Sep 13, 2015 2:10 am

Re: Maths Channel Question - Dwell

Post by STC »

it's pulling strongly enough in all gears and loads, so the initial complaint is fixed,
Ok, I thought you were still battling with it. Good news you got it out the door.
Zoom in and take a look, if you need your glasses I know where they are!! :lol: :lol:
I think you may need to keep them :D :D
RL Dwell Delete.jpg
That is a terrible example of Ignition Primary ?! If that was put in front of me I would never guess what it was :cry:
Aside from the fact that it gets nowhere near 0 amps, there is nothing in there that resembles a switch being turned On & Off - A volume switch perhaps :). At the end of the dwell the "switch off" surely should drop like a hot brick ?

The current ramp up is its only good feature.

And then I noted and removed the filtering and indeed we have a "text book" primary - Now I must do humble pie and back track :cry: :cry:
does raise one area of potential cause for the strange Math Channels results, as the data rate verse the clamps response rate could be causing a sampling issue
Again there are no obvious or measurable switch on / off points - too much filtering.
Try that capture with 2Khz filtering rather than the 300Hz, it looks far more viable and measureable. There are distinctive points to home in on.
RL Dwell - Less Filtering Delete.jpg
An yes I can see the rogue crossover points, I could live with those. On the whole a great case study

With it done and gone all this is immaterial, however worth noting down for the benefit of some one in the future.

Moral of the story is that you cannot build the Filter factor into the Dwell math channel - it is bespoke to each capture, even on the same car in the same workshop, with the same scope, same laptop & the same nut behind the wheel :D :) :D :)

I think I may have saved Pico half a dozen "Feature Developments" with little return here.

Merry Christmas !!!

Post Reply