Variable Pulse Generator

Generate ideal, time varying pulse signal

Since R2020b

• 

Libraries:
Simulink / Discontinuities

Description

Use the Variable Pulse Generator block to create ideal modulated pulse signals.

Generally speaking, the output pulse of the block is described by

$$y(t)=\{\begin{array}{cc}1& t_k<t<t_k+pw\\ 0& t_k+pw<t<t_{k+1}\end{array}$$

where pw is the output pulse width.

For an implementation of Pulse Width Modulation, see PWM.

Examples

Voltage Controlled Oscillator

This example shows you how to model an ideal voltage controlled oscillator using the Variable Pulse Generator block to create the frequency oscillations.

A voltage controlled oscillator uses an input tuning voltage to produce waveforms of varying frequency. Over a small range of voltages, the relationship between the input voltage ()and the output oscillation frequency () is proportional and can be expressed as

where

• is the oscillator sensitivity in Hz/V

• is the quiescent frequency, or nominal frequency of the oscillator at

In the included vco_using_vpg model, the desired oscillation frequency signal F_{in}(t) is generated using the formula shown in equation (1). In this model, the tuning voltage is a sinusoidal waveform.

Ports

Input

D — Duty Cycle

scalar

Desired duty cycle of the pulse P, specified as scalar within the range [0,1].

Data Types: double

P — Period

scalar

Time between rising edges of consecutive pulses of the output signal. A smaller value represents a higher frequency pulse.

Data Types: double

Output

Port 1 — Modulated pulse signal

scalar

Modulated output pulse signal corresponding to input duty cycle.

Data Types: double

Parameters

Allow zero pulse width — Allow zero magnitude of output signal

off (default) | on

Enable this parameter to allow the output pulse signal to support pulses of width 0.

Note

Enabling this parameter causes the block to have direct feedthrough. This can cause algebraic loops in your model.

Run at fixed time intervals — Choose continuous or discrete-time behavior

continuous (default) | discrete

Select whether the block should operate in continuous or discrete sampling modes.

By default, the block uses continuous sampling mode as it improves simulation performance with variable step solvers.

Select discrete sampling mode if you need to:

• use a fixed-step solver

• generate code

• sample the block output

Sampling rate — Set pulse resolution

0.1 (default) | scalar

Specify the rate at which the block samples input duty cycle signal. This sampling rate becomes the resolution of the output pulse signal.

Dependencies

This parameter requires that Sampling mode is set to discrete

Block Characteristics

Data Types	double
Direct Feedthrough	no
Multidimensional Signals	no
Variable-Size Signals	no
Zero-Crossing Detection	no

Algorithms

Continuous Sampling Mode

For a pulse starting at time t_k

$$y(t)=\{\begin{array}{cc}1& t_k<t<t_k+pw\\ 0& t_k+pw<t<t_{k+1}\end{array}$$

where pw is the pulse width. For a given period P, pw is proportional to the duty cycle D

$$pw=D(t_k)*P(t_k)$$

Discrete Sampling Mode

In Discrete sampling mode, the input duty cycle signal is sampled at the rate specified by the Run at fixed time intervals parameter.

For a specified sampling rate t_S , the number of samples needed for a pulse of width pw can be expressed as follows

$$\begin{array}{l}{n}_{pw}=\begin{array}{cc}\lfloor \frac{D_k.P_k}{T_S}\rfloor & 0<n_{pw}<n_P\end{array}\\ n_P=\lfloor \frac{P}{T_S}\rfloor \end{array}$$

where n_P is the number of samples needed to simulate a pulse of period P.

Consider a nominal pulse of period P with the sampling rate of the block set to be t_S= 0.25 P. The number of samples needed for one period of the pulse, n_P= 4. Thus, for the input duty cycle D= 0.47 , the number of samples n _pw is floored to $$\lfloor \frac{0.47P}{0.25}\rfloor$$= 1. Therefore, the pulse is high for 1 of the 4 samples in the period.

Extended Capabilities

C/C++ Code Generation

Generate C and C++ code using Simulink® Coder™.

Not recommended for production-quality code. Relates to resource limits and restrictions on speed and memory often found in embedded systems. The code generated can contain dynamic allocation and freeing of memory, recursion, additional memory overhead, and widely-varying execution times. While the code is functionally valid and generally acceptable in resource-rich environments, smaller embedded targets often cannot support such code.

In general, consider using the Simulink Model Discretizer to map continuous blocks into discrete equivalents that support production code generation. To start the Model Discretizer, in the Simulink^® Editor, on the Apps tab, under Apps, under Control Systems, click Model Discretizer. One exception is the Second-Order Integrator block because, for this block, the Model Discretizer produces an approximate discretization.

Version History

Introduced in R2020b