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
While I don't have a Snapon device, someone recalled with Snapon "scope/scanner" being able to display dwell, and as most automotive DMM's have a Dwell feature it surely can't be that hard ...
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:
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 liftoff. 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% )
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 +
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 fullfledged 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
Maths Channel Question  Dwell
 FioranoCars
 TwoWaves
 Posts: 378
 Joined: Thu Dec 13, 2012 11:26 am
 Location: London, UK
 Contact:
Maths Channel Question  Dwell
 Attachments

 MercedesBenz_SLClass_1974_Petrol_dwell calc.psdata
 Idle and circa 3,000 rpm captures
 (2.06 MiB) Downloaded 192 times
Re: Maths Channel Question  Dwell
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 liftoff.""
Who knows how accurate any Dwell meter is or where it takes the crossover point. For sure we know it will be averaging something.
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 liftoff.""
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.
 FioranoCars
 TwoWaves
 Posts: 378
 Joined: Thu Dec 13, 2012 11:26 am
 Location: London, UK
 Contact:
Re: Maths Channel Question  Dwell
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 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.
Anyway, so I built a math filter first (""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!
My fundamental flaw was to build a multifunction formulae and hence to preserve the original Current Capture (not wanting to apply a filter that might mask an issue (Steve's EType 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 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
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
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
Thanks
Richard
I made a fundamental error, a bit like building complex formulae in Excel, I worked with the Maths Channels to "build" my formulae 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.
Anyway, so I built a math filter first
Code: Select all
LowPass(A, 5000)
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))
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
Code: Select all
Duty(A)/100*45
Of course, if you can out STC, STC then please tell all
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
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
Thanks
Richard
Re: Maths Channel Question  Dwell
I should stop doing that  become a bit of a bad habit latelyThanks STC, you got 1 step further than me ...
That I don't understand !?Of course, if you can out STC, STC then please tell all
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 !!
that my friend is now questionable ??sadly in my case it was chasing a busted DMM which worked fine 4 weeks ago,
Perhaps you should have had the DMM Rebuilt and not the Distributer. Did / Does the DMM have fully charged batteries in it ?
Simple ! Really ?? How many Variables up there that have to be part of the equation.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°
The math could be simpler. Measure Dwell as a percentage not degrees  We are in the EEC now
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 !

 TwoWaves
 Posts: 221
 Joined: Fri Nov 30, 2012 2:53 pm
 Location: Denmark
Re: Maths Channel Question  Dwell
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 ... dutycycle
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.
I know it´s another story when you raise the rpm.
Regards
Kim
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 ... dutycycle
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.
I know it´s another story when you raise the rpm.
Regards
Kim
 FioranoCars
 TwoWaves
 Posts: 378
 Joined: Thu Dec 13, 2012 11:26 am
 Location: London, UK
 Contact:
Re: Maths Channel Question  Dwell
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:
To explain, Freq(A5), 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. 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: 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
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(A5)/8*2*60
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. 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: 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

 MercedesBenz_SLClass_1974_Petrol_Dwell and RPM maths.psdata
 Dwell and RPM at Idle and 3K RPM
 (2.06 MiB) Downloaded 153 times
Re: Maths Channel Question  Dwell
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.Excluding the 3 peaks and 3 dips still a wide 19.5° to 29° still a range not reflected in the manual calculations
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 !
What is done ?while for the car, it's all a bit Mute as it's done
 FioranoCars
 TwoWaves
 Posts: 378
 Joined: Thu Dec 13, 2012 11:26 am
 Location: London, UK
 Contact:
Re: Maths Channel Question  Dwell
Amp clamp in same position for both buffers, I've not up and moved it part way through a capture!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 !
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!!
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.
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.STC wrote:What is done ?while for the car, it's all a bit Mute as it's done
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
Re: Maths Channel Question  Dwell
Ok, I thought you were still battling with it. Good news you got it out the door.it's pulling strongly enough in all gears and loads, so the initial complaint is fixed,
I think you may need to keep them That is a terrible example of Ignition Primary ?! If that was put in front of me I would never guess what it wasZoom in and take a look, if you need your glasses I know where they are!!
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
Again there are no obvious or measurable switch on / off points  too much filtering.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
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. 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
I think I may have saved Pico half a dozen "Feature Developments" with little return here.
Merry Christmas !!!