Store 
| Products & Services | Industries | Academia | Support | User Community | Company |
 |
Download Product Updates | | |  |
Get Pricing | | | |
Trial Software |
| Documentation → Signal Processing Blockset |
| Products & Services | Industries | Academia | Support | User Community | Company |
|
Download Product Updates | | | |
Get Pricing | | | |
Trial Software |
| Documentation → Signal Processing Blockset |
| Contents | Index |
| Learn more about Signal Processing Blockset |
Signal Management / Buffers
dspbuff3
The Buffer block redistributes the input samples to a new frame size. Buffering to a larger frame size yields an output with a slower frame rate than the input, as illustrated below for scalar input.
Buffering to a smaller frame size yields an output with a faster frame rate than the input, as illustrated below for scalar output.
The block coordinates the output frame size and frame rate of nonoverlapping buffers such that the sample period of the signal is the same at both the input and output: Tso = Tsi.
This block supports triggered subsystems when the block's input and output rates are the same.
Sample-based full-dimension matrix inputs are not accepted.
Sample-based inputs are interpreted by the Buffer block as independent channels of data. Therefore, a sample-based length-N vector input is interpreted as N independent samples.
In sample-based operation, the Buffer block creates frame-based outputs from sample-based inputs. A sequence of sample-based length-N vector inputs is buffered into an Mo-by-N matrix, where Mo is specified by the Output buffer size parameter (Mo>1). That is, each input vector becomes a row in the N-channel frame-based output matrix. When Mo=1, the input is simply passed through to the output, and retains the same dimension.
The Buffer overlap parameter, L,
specifies the number of samples (rows) from the current output to
repeat in the next output, where
. For
,
the number of new input samples that the block
acquires before propagating the buffered data to the output is the
difference between the Output buffer size and Buffer
overlap, or
.
The output frame period is
, which is equal to the input sequence sample period, Tsi,
when the Buffer overlap is
. For
, the block simply
discards L input samples after the buffer fills,
and outputs the buffer with period
, which is longer than the zero-overlap case.
In the model below, the block buffers a four-channel sample-based input using a Output buffer size of three and a Buffer overlap of one.
Notice that the input vectors do not begin appearing at the output until the second row of the second matrix. This is due to the block's latency. The first output matrix (all zeros in this example) reflects the block's Initial conditions setting, while the first row of zeros in the second output is a result of the one-sample overlap between consecutive output frames.
You can use the rebuffer_delay function with a frame size of 1 to precisely compute the delay (in samples) for sample-based signals. For the previous example,
d = rebuffer_delay(1,3,1)
d =
4This agrees with the four samples of delay (zeros) per channel shown in the previous figure.
In frame-based operation, the Buffer block redistributes the samples in the input frame to an output frame with a new size and rate. A sequence of Mi-by-N matrix inputs is buffered into a sequence of Mo-by-N frame-based matrix outputs, where Mo is the output frame size specified by the Output buffer size parameter. The output buffer size is the number of consecutive samples from the input frame that are buffered into the output frame. Mo can be greater or less than the input frame size, Mi. Each of the N input channels is buffered independently.
The Buffer overlap parameter, L,
specifies the number of samples (rows) from the current output to
repeat in the next output, where
. For
,
the number of new input samples the block acquires
before propagating the buffered data to the output is the difference
between the Output buffer size and Buffer
overlap,
.
The input frame period is
, where Tsi is
the sample period. The output frame period is
, which is equal
to the sequence sample period when the Buffer overlap is
. The output sample
period is therefore related to the input sample period by
Negative Buffer overlap values are not permitted.
In the model below, the block buffers a two-channel frame-based input using a Output buffer size of three and a Buffer overlap of one.
Notice that the sequence is delayed by eight samples, which is the latency of the block in the Simulink multitasking mode for the parameter settings of this example. The first eight output samples therefore adopt the value specified for the Initial conditions, which is assumed here to be zero. Use the rebuffer_delay function to determine the block's latency for any combination of frame size and overlap.
Zero-tasking latency means that the first input sample, received at t = 0, appears as the first output sample. In the Simulink single-tasking mode, the Buffer block has zero-tasking latency for the following special cases:
Scalar input and output (
) with zero or
negative Buffer overlap (
)
Input frame size is an integer multiple of the output frame size
where k is an
integer with zero Buffer overlap (
); notable cases
of this include
Any input frame size Mi with
scalar output (
)
and zero Buffer overlap (
)
Equal input and output frame sizes (
) with zero Buffer
overlap (
)
For all cases of sample-based single-tasking operation other than those listed above, the Buffer block's buffer is initialized to the value(s) specified by the Initial conditions parameter, and the block reads from this buffer to generate the first D output samples, where
The dimensions of the Initial conditions parameter depend on the Buffer overlap, L, and whether the input is single-channel or multichannel:
When
,
the Initial conditions parameter must be a scalar.
When
,
the Initial conditions parameter can be a scalar,
or it can be a vector with the following constraints:
For single-channel inputs, the Initial conditions parameter can be a vector of length Mo if Mi is 1, or a vector of length Mi if Mo is 1.
For multichannel inputs, the Initial conditions parameter can be a vector of length Mo * N if Mi is 1, or a vector of length Mi * N if Mo is 1.
For frame-based single-tasking operation and all multitasking operation, use the rebuffer_delay function to compute the exact delay, in samples, that the Buffer block introduces for a given combination of buffer size and buffer overlap.
For general buffering between arbitrary frame sizes, the Initial conditions parameter must be a scalar value, which is then repeated across all elements of the initial output(s). However, in the special case where the input is 1-by-N, and the block's output is therefore an Mo-by-N matrix, Initial conditions can be
An Mo-by-N matrix
A length-Mo vector to be repeated across all columns of the initial output(s)
A scalar to be repeated across all elements of the initial output(s)
In the special case where the output is 1-by-N , which is the result of unbuffering an Mi-by-N frame-based matrix, Initial conditions can be
A vector containing Mi samples to output sequentially for each channel during the first Mi sample times
A scalar to be repeated across all elements of the initial output(s)
Note For more information on latency and the Simulink tasking modes, see Excess Algorithmic Delay (Tasking Latency) and Scheduling Considerations in the Real-Time Workshop User's Guide. |
The Buffer block cannot be used in an enabled subsystem under the following conditions:
In a multirate multitasking environment
When the Buffer overlap parameter is set to a negative value
The Buffer block has an internal reservoir that temporarily stores data. When the Buffer block is used in an enabled subsystem, there is the possibility that the reservoir can overrun or underrun. The block implements safeguards against these occurrences.
Overrun occurs when more data enters into the buffer than it can hold. For example, consider buffering a sample-based input to a frame of size three with a buffer that accepts input every second and outputs every three seconds. If you place this buffer inside an enabled subsystem that is disabled every three seconds at t = 3s, t = 6s, and so on, the buffer accumulates data in its internal reservoir without being able to empty it. This condition results in overrun.
Underrun occurs when the buffer runs out of data to output. For example, again consider buffering a sample-based input to a frame size of three with a buffer that accepts input every second and outputs every three seconds. If you place this buffer inside an enabled subsystem that is disabled at t = 10s, t = 11s, t = 13s, t = 14s, t = 16s, and t = 17s, its internal reservoir becomes drained, and there is no data to output at t = 18s. This condition results in underrun.
To protect from overrun and underrun, the Buffer block keeps a record of the amount of data in its internal reservoir. When the Buffer block reads data, the amount of data in its reservoir goes up. When data is output from the Buffer block, the amount of data in its reservoir goes down. To protect from overrun, the oldest samples in the reservoir are discarded whenever amount of data in the reservoir is larger than the actual buffer size. To protect from underrun, the most recent samples are repeated whenever an output is due and there is no data in the reservoir.
See Frame Rebuffering Blocks and Converting Frame Status in the Signal Processing Blockset User's Guide.
Specify the number of consecutive samples, Mo, from each channel to buffer into the output frame.
Specify the number of samples, L, by which consecutive output frames overlap.
Specify the value of the block's initial output for cases of nonzero latency; a scalar, vector, or matrix.
Port | Supported Data Types |
|---|---|
Input |
|
Output |
|
| Delay Line | Signal Processing Blockset |
| Unbuffer | Signal Processing Blockset |
| rebuffer_delay | Signal Processing Blockset |
See Converting Sample and Frame Rates and Converting Frame Status for more information.
 | Block LMS Filter | Burg AR Estimator |  |
Learn more about Simulink through this collection of videos, articles, technical literature and the Getting Started with Simulink Guide.
| © 1984-2009- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |
