This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Duty cycle measurement logic

Other Parts Discussed in Thread: CD4063B, SN74F521

Hello All,

I would like to design a duty cycle measurement logic for one of our customer with a adjustable cutoff.

i.e. 50% duty cycle is best desired sate to be in. anything more than that or less than that is an error. If this error goes below certain threshold let's say less than 30% duty cycle or greater than 70% then we need to trigger an alarm.

PWM pulses are of 5V  signals. Frequency will be fixed. 482Hz in our case. 

I can do it with microcontroller easily however, we like user to configure the threshold level them selves (using potentiometer may be) and would like to make it independent from timers because there will be many of such signals all at the same time. Which could be heavy pulse detection code for my controller.

  • Jigar,

    As far as I know, there is no "simple" TI device or circuit combination which solves this problem in lower cost/board area/effort than a CPLD. My suggestion would be:

    • Use a counter in your CPLD to get adequately high-resolution measurements of your duty cycle based on your CPLD's "high frequency" clock. The time resolution can be decreased by dividing down the CPLD high frequency clock; this minimizes the number of required logic elements (perhaps based on the resolution of the ADC measuring the potentiometer, or some other duty cycle resolution limit) and allows you to ignore timing analysis in the CPLD (since even long chains of asynchronous logic will complete quickly relative to a slower clock).
    • Instantiate as many blocks as needed to monitor every PWM signal. Each block is composed of:
      • A counter (start from 0, begin ascending on rising edge of PWM, stop ascending on falling edge of PWM or a greater-than comparison)
      • A magnitude comparator with HIGH/LOW inputs provided somewhere
      • Logic to latch the LOW comparison and restart the counter on the falling edge of PWM
      • Logic to latch the HIGH comparison as soon as it goes high
      • Asynchronous resets for the counter and latches from outside the block (i.e. MCU servicing the alarm)
    • Wire up the PWM inputs of the blocks described above to the PWM signals in your application (you may need a level shifter to match CPLD I/O levels). Wire up the comparator outputs to individual I/Os so you can decode which one failed later, and to a giant OR gate internally to send only one ALARM interrupt back to your microcontroller.
    • The accuracy is dependent on the absolute frequency error between the 482Hz clock and the CPLD high-frequency clock. Ideally you can find a CPLD with a PLL and scale the system reference frequency, so the 482Hz and the high-frequency clock are frequency-locked. If this isn't possible, you can count the number of high-frequency clocks per PWM rising edge and automatically apply some offset if needed to correct for frequency mismatch.
    • You likely need a way to communicate with the CPLD after power-up, which could be as simple as instantiating one SPI/I2C/UART with a few addressable "registers" for the high/low limit values, maybe the PWM HIGH/LOW alarm states for each block, etc.
    • Limits could be periodically sampled by the MCU and sent over the communication interface to the CPLD, or maybe the CPLD has its own ADC peripherals that could be used. Consider adding a register buffer for high/low limits to each measurement block described above so that new limits are only loaded when the counter is restarted.

    For a solution in the polar opposite direction, you could construct an extremely low-cost solution using:

    • A current source (e.g. an adjustable series LDO/reference with a resistor between output and adjust pin)
    • A capacitor on the current source output to generate a ramp, and a discharge NFET driven by inverted PWM input
    • A sample and hold circuit (there are some simple designs with two op-amps) with the switch driven by PWM input
    • A dual comparator to set the high/low thresholds (and a discharge NFET tied to the LOW comparator positive input, driven by PWM input)
    • An OR-gate into an S-R latch to stabilize the alarm

    Conceptually this is very straightforward: control the ramp rate at the current source capacitor so that a known, reasonable voltage is achieved (maybe VCC/2) after one 482Hz period, ramp while PWM is high, and sample/hold while PWM is low. If the ramp voltage is too high or too low, trip an alarm. The BOM will probably be higher cost, and the board area will be much larger than a comparable circuit using a CPLD, but it doesn't really require programming. There will be circuit-to-circuit and temperature-dependent variation, but there's lots of ways to calibrate this out by slightly tuning the comparator limits.

    Another idea: You could get a CD4046 PLL to lock to each 482Hz clock signal using an edge-sensitive phase detector and a discrete frequency divider circuit. Then you can use one or more discrete magnitude comparator(s) (e.g. CD4063B or SN74F521) on the N-divider stages, AND the LOW comparison with ~PWM, and S-R latch the OR'd alarm output. This uses a lot of board space, but it's cheap and self-aligning to the 482Hz clock signal. Unfortunately it involves using a CD4046.

    Another idea: if your microcontroller has a common frequency reference with the 482Hz clock, you can have the microcontroller (or some other synthesizer/divider) generate some exact binary multiple e.g. (482 * 2^8) Hz clock, and preset two ripple counters with some serial shift registers such that the final bit goes high at the low/high limits. This is probably fewer parts than the prior two discrete solutions, but still takes up a bunch of board space. It also requires a central frequency reference capable of generating some binary multiple of 482Hz, which may not be available; this could probably be handled with a CD4046 on an always-active PWM input, but I don't advise doing this.

    Regards,

    Derek Payne