Measuring duty cycle of short duration pulses with long period

[HenrikOlsson]

795us over 45ms is 1.76%, not 17.6% as I wrote earlier.

Anyway, here's a piece of code that may do what you want. It uses TMR1 and CCP1 to measure the input signal, calculates the dutycycle and displays it with .1% resolution. It compiles for a 16F88 but I have not tested it.

' Program expects 4MHz oscillator.
' CCP1 inputpin is either RB0 or RB3 depending on the CCPMX bit in CONFIG.

CapRise CON %00000101		' Value to configure CCP1 for capturing every rising edge
CapFall CON %00000100		' Value to configure CCP1 for capturing every falling edge

CCP1IF 	VAR PIR1.2		' Alias to CCP1 Interrupt flag

Period 	VAR WORD
Width 	VAR WORD
Duty 	VAR WORD
Dummy	VAR WORD

T1 	VAR WORD
T2 	VAR WORD
T3 	VAR WORD

T1CON = %00100001		' TMR1 clock from FOsc/4, Prescaler 1:4

Main:
    ' Capture the the time where the pulse starts
    CCP1CON = CapRise
    CCP1IF = 0
    WHILE !CCP1IF : WEND
    T1.HIGHBYTE = CCPR1H : T1.LOWBYTE = CCPR1L

    ' Capture the time where the pulse ends
    CCP1CON = CapFall
    CCP1IF = 0
    WHILE !CCP1IF : WEND
    T2.HIGHBYTE = CCPR1H : T2.LOWBYTE = CCPR1L

    ' Capture the time where the period ends (which is when the next pulse starts) 
    CCP1CON = CapRise
    CCP1IF = 0
    WHILE !CCP1IF : WEND
    T3.HIGHBYTE = CCPR1H : T3.LOWBYTE = CCPR1L


    Width = T2 - T1
    Period = T3 - T1
    Dummy = Width * 1000
    Duty = DIV32 Period

    ' Duty is now in units of .1% (111 = 11.1%)

    LCDOUT $FE, 1, "W:", DEC Width, " P:", DEC Period
    LCDOUT $FE, $C0, "Duty:", DEC Duty/10, ".", DEC Duty//10, "%"

Goto Main

/Henrik.

[NickMu]

I’m not sure how much this will change things but shouldn’t maximum period expected be 20 ms not 200 ms?
And if it is so, should the timer setup be changed or it will still work?

Nick

[HenrikOlsson]

Hmm, if maximum period is 20ms then the timer would need to be reconfigured but Bill said: variable frequency (5-55hz = 600-6600rpm). At 5Hz the period is 200ms, at 55Hz the period is 18ms. So the the timer must be able to measure at least 200ms. Or am I doing a stupid mistake somewhere?

/Henrik.

[NickMu]

No Henrik, as usual I'm wrong.
Sorry for false alarm.

Nick

[wjsmarine]

Hi Henrik,

Thanks for your help and code sample, I'll use this as a guide for other timing tasks if it doesn't work for this particular role.

I understand the ratio calcs for Duty Cycle and have done this a few times before, but with gasoline injectors where their on time is proportional i.e. let's say max rpm limits maximum duty cycle to 20ms. In such circumstances DC is easy - 10ms = 50%, 20 = 100%, etc.

But with modern diesel common-rail injectors (extremely high fuel pressure so inj open times are in microseconds) the ratio between on-times and period blows out so much to be unusable in normal math for DC. It doesn't need to be exact but does need to be reliable and repeatable as DC will form an axis in a lookup table to control vnt turbo characteristics and boost curve via a PWM solenoid valve. I will start a different thread soon and request suggestions on how to do 3D mapping.

It's a catch-22 situation in that I don't know what a particular engine's max DC is unless fully loaded on a dyno and 'scope measurements are taken - expensive. In a gasoline engine this isn't needed due conventional math taking care of it. I can make an educated guess and set the diesel's max DC as 1000us (typical full load) then measure on-the-fly using this as the reference to derive some data as the engine is loaded - if it exceeds 100% then code could update the ref and store this along with the max pulse length... do you see another way?

Kind regards,
Bill

[HenrikOlsson]

OK, so you're not really interested in the actual dutycycle of the signal.
You're interested in how long the pulse is relative to its maximum length and the pulse maximum length is NOT equal to the period of the signal (which would be 100% duty cycle by the standard definition).

This means that the timer doesn't need to be able to resolve the complete period of the signal, only the maximum width of the pulse - and this is good because it increases your resolution substantially. All you need to do then is to capture the TMR1 value on the rising edge and then capture again on the falling edge, that's your actual width. Calculate percentage relative your maximum width.

You could certainly guestimate the initial value (1000us) and the apply some "adaptive learning" to the code.

/Henrik.

(This was my $0BB8 post, yay)

[wjsmarine]

Hi Henrik,

Yes, I think conventional DC doesn't apply here. Thanks for the confirmation of what needs to be done.

Congrats on the milestone in postings - makes my $32 look fairly miserable in comparison

Cheers,
Bill