|
|
|
| R2012a Documentation → DSP System Toolbox | |
Learn more about DSP System Toolbox |
|
| Contents | Index |
This table summarizes what's new in V8.0 (R2011a):
| New Features and Changes | Version Compatibility Considerations | Fixed Bugs and Known Problems |
|---|---|---|
| Yes Details below | Yes—Details labeled as Compatibility Considerations, below. See also Summary. | Bug
Reports Includes fixes |
New features and changes introduced in this version are:
New Function for Changing the System Object Package Name from signalblks to dsp
Improved Display Updates for the Time Scope Block and System Object
New Implementation Options Added to Blocks in the Filter Designs Library
New dsp.DigitalDownConverter and dsp.DigitalUpConverter System Objects
Improved Performance of FFT Implementation with FFTW library
'Internal rule' System Object Property Value Changed to 'Full precision'
Downsample Block No Longer Has Frame-Based Processing Latency for a Frame Size of One
FrameBasedProcessing Property Removed from the dsp.DelayLine and dsp.Normalizer System Objects
The DSP System Toolbox product replaces the Signal Processing Blockset™ and Filter Design Toolbox™ products in R2011a.
You can access archived documentation for the Signal Processing Blockset and Filter Design Toolbox products on the MathWorks Web site.
In signal processing applications, you often need to process sequential samples of data at once as a group, rather than one sample at a time. DSP System Toolbox documentation refers to the former as frame-based processing and the latter as sample-based processing. A frame is a collection of samples of data, sequential in time.
Historically, Simulink-family products that can perform frame-based processing propagate frame-based signals throughout a model. The frame status is an attribute of the signals in a model, just as data type and dimensions are attributes of a signal. The Simulink engine propagates the frame attribute of a signal by means of a frame bit, which can either be on or off. When the frame bit is on, Simulink interprets the signal as frame based and displays it as a double line, rather than the single line sample-based signal.
Beginning in R2010b, MathWorks started to significantly change the handling of frame-based processing. In the future, frame status will no longer be a signal attribute. Instead, individual blocks will control whether they treat inputs as frames of data or as samples of data. To learn how a particular block handles its input, you can refer to the block reference page.
To make the transition to the new paradigm of frame-based processing, many blocks have received new parameters. You can view an example of how to use these parameters to control sample- and frame-based processing in R2011a and future releases. To open the model, type ex_inputprocessing at the MATLAB command line. This model demonstrates how a block can process a signal as sample based or frame based, depending on the setting of that block's Input processing parameter.
Notice that when the Discrete FIR Filter and Time Scope blocks are configured to perform frame-based processing, they interpret columns as channels and treat the 2-by-2 input signal as two independent channels. Conversely, when the blocks are configured to perform sample-based processing, they interpret elements as channels and treat the 2-by-2 input signal as four independent channels. For further information about sample- and frame-based processing, see Sample- and Frame-Based Concepts.
The following sections provide more detailed information about the specific R2011a DSP System Toolbox software changes that are helping to enable the transition to the new way of frame-based processing:
Compatibility Considerations. During this transition to the new way of handling frame-based processing, both the old way (frame status as an attribute of a signal) and the new way (each block controls whether to treat inputs as samples or as frames) will coexist for a few releases. For now, the frame bit will still flow throughout a model, and you will still see double signal lines in your existing models that perform frame-based processing.
Backward Compatibility — By default, when you load an existing model in R2011a any new parameters related to the frame-based processing change will be set to their backward-compatible option. For example, if any blocks in your existing models received a new Input processing parameter this release, that parameter will be set to Inherited (this choice will be removed - see release notes) when you load your model in R2011a. This setting enables your existing models to continue working as expected until you upgrade them. Because the inherited option will be removed in a future release, you should upgrade your existing models as soon as possible.
slupdate Function — To upgrade your existing models to the new way of handling frame-based processing, you can use the slupdate function. Your model must be compilable in order to run the slupdate function. The function detects all blocks in your model that are in need of updating, and asks you whether you would like to upgrade each block. If you select yes, the slupdate function updates your blocks accordingly.
Timely Update to Avoid Unexpected Results — It is important to update your existing models as soon as possible because the frame bit will be removed in a future release. At that time, any blocks that have not yet been upgraded to work with the new paradigm of frame-based processing will automatically transition to perform their library default behavior. The library default behavior of the block might not produce the results you expected, thus causing undesired results in your models. Once the frame bit is removed, you will no longer be able to upgrade your models using the slupdate function. Therefore, you should upgrade your existing modes using slupdate as soon as possible.
For more detailed information about the specific compatibility considerations related to the R2011a frame-based processing changes, see the following Compatibility Considerations sections.
Some DSP System Toolbox blocks are able to process both sample- and frame-based signals. After the transition to the new way of handling frame-based processing, signals will no longer carry information about their frame status. Blocks that can perform both sample- and frame-based processing will require a new parameter that allows you to specify the appropriate processing behavior. To prepare for this change, many blocks are receiving a new Input processing parameter. You can set this parameter to Columns as channels (frame based) or Elements as channels (sample based), depending upon the type of processing you want. The third choice, Inherited (this choice will be removed - see release notes), is a temporary selection. This additional option will help you to migrate your existing models from the old paradigm of frame-based processing to the new paradigm. Refer to the Compatibility Considerations section for more information about migrating your existing models to the new paradigm of frame-based processing.
For a list of blocks that received a new Input processing parameter in R2011a, expand the following list.
Blocks with the New Input Processing Parameter
For a list of blocks that received an Input processing parameter in R2010b, see the R2010b Signal Processing Blockset Release Notes.
Compatibility Considerations. When you load an existing model R2011a, any block with the new Input processing parameter will show a setting of Inherited (this choice will be removed - see release notes). This setting enables your existing models to continue to work as expected until you upgrade them. Although your old models will still work when you open and run them in R2011a, you should upgrade them as soon as possible.
You can upgrade your existing models, using the slupdate function. The function detects all blocks that have Inherited (this choice will be removed - see release notes) selected for the Input processing parameter, and asks you whether you would like to upgrade each block. If you select yes, the function detects the status of the frame bit on the input port of the block. If the frame bit is 1 (frames), the function sets the Input processing parameter to Columns as channels (frame based). If the bit is 0 (samples), the function sets the parameter to Elements as channels (sample based).
In a future release, the frame bit and the Inherited (this choice will be removed - see release notes) option will be removed. At that time, the Input processing parameter in models that have not been upgraded will automatically be set to either Columns as channels (frame based) or Elements as channels (sample based), depending on the library default setting for each block. If the library default setting does not match the parameter setting in your model, your model will produce unexpected results. Additionally, after the frame bit is removed, you will no longer be able to upgrade your models using the slupdate function. Therefore, you should upgrade your existing modes using slupdate as soon as possible.
R2011a updates the Overlap-Add FFT Filter, Overlap-Save FFT Filter, and Short-Time FFT blocks to the use new way of frame-based processing. In previous releases, the frame status of the input signal determined how these blocks processed the input. In R2011a, the default behavior of these blocks is to always perform frame-based processing.
Unless you specify otherwise, these blocks now treat each column of the input signal as an individual channel, regardless of its frame status. You can now enable the behavior change in these blocks while still allowing for backward compatibility. This release adds a Treat Mx1 and unoriented sample-based signals as parameter for this purpose. This parameter will be removed in a future release, at which point the blocks will always perform frame-based processing.
Compatibility Considerations. The Treat Mx1 and unoriented sample-based signals as parameter will be removed in a future release. From that point, the Overlap-Add FFT Filter, Overlap-Save FFT Filter, and Short-Time FFT blocks will always perform frame-based processing.
You can use the slupdate function to upgrade your existing models that contain one of these blocks. The function detects all Overlap-Add FFT Filter, Overlap-Save FFT Filter, and Short-Time FFT blocks in your model. Then, if you allow it to, slupdate performs the following actions:
If the input to the block is an M-by-1 or unoriented sample-based signal, the slupdate function:
Places a Transpose block in front of the affected block in your model. This block transposes the M-by-1 or unoriented sample-based input into a 1-by-M row vector. By converting the input to a row vector, the block continues to produce the same results as in previous releases (an Mo-by-Mi output).
Sets the Treat Mx1 and unoriented sample-based signals as parameter to One channel. This setting ensures that your model will continue to produce the same results when the Treat Mx1 and unoriented sample-based signals as parameter is removed in a future release.
If the input to the block is not an M-by-1 or unoriented sample-based signal, the slupdate function sets the Treat Mx1 and unoriented sample-based signals as parameter to One channel. This setting does not affect the behavior of your current model. However, the change does ensure that your model will continue to produce the same results when the Treat Mx1 and unoriented sample-based signals as parameter is removed in a future release.
R2011a adds a new Running difference parameter to the Difference block.
Compatibility Considerations. In a future release, the following option for the Running difference parameter will be removed: Inherit from input (this choice will be removed — see release notes). From this time forward, you must specify whether or not the block computes a running difference; the block will no longer make that choice based on the status of the frame bit.
You can use the slupdate function to upgrade your existing models that contain a Difference block. The function detects whether your models contain any Difference blocks with the Running difference parameter set to Inherit from input (this choice will be removed — see release notes). If you do, the function detects the status of the frame bit, and sets the Running difference parameter accordingly.
R2011a updates the Signal To Workspace block. The block now allows you to choose an output format using the Save format parameter. You can choose to save your data as an Array, Structure, or Structure with time.
Additionally, the old Frames parameter has been replaced by a new Save 2-D signals as parameter. This parameter allows you to specify whether the block saves 2-D signals as a 2-D array, or as a 3-D array. To provide for backward compatibility, the Save 2-D signals as parameter also has an option Inherit from input (this choice will be removed — see release notes). When you select this option, the block saves sample-based data as a 3-D array and frame-based data as a 2-D array.
Compatibility Considerations. In a future release, the following option will be removed: Inherit from input (this choice will be removed — see release notes). From this time forward, you must specify whether the block saves signals as a 2-D or 3-D array. The block will no longer make that choice based on the status of the frame bit.
You can use the slupdate function to upgrade your existing models that contain a Signal To Workspace block. The function detects whether your models contain any Signal To Workspace blocks with the Save 2-D signals as parameter set to Inherit from input (this choice will be removed — see release notes). If you do, the function detects the status of the frame bit and sets the Save 2-D signals as parameter accordingly.
If the input signal is frame based, the function sets the Save 2-D signals as parameter to 2-D array (concatenate along first dimension).
If the input signal is sample based, the function sets the Save 2-D signals as parameter to 3-D array (concatenate along third dimension).
R2011a updates the Spectrum Scope block to use the new way of frame-based processing. To enable this change, the block received a new Treat Mx1 and unoriented sample-based signals as parameter. This new parameter is available only when you select the Buffer input check box. By default, the new parameter is set to One channel. In this mode, the block treats M-by-1 and unoriented sample-based input as a single column vector and buffers the input along that column.
In previous releases, some DSP System Toolbox blocks handled sample-based row vector inputs in a special way. Of the blocks that can treat sample-based row vector inputs differently, there are two categories:
Some blocks have a Treat sample-based row input as a column check box which allows you to explicitly specify how the block should treat sample-based row vector inputs. Expand the following section for a full list of these blocks.
Other blocks automatically treat a sample-based row vector input as a single channel (column vector). Expand the following section for a full list of these blocks.
Blocks That Implicitly Treat Sample-Based Row Vectors as a
Single Channel
The special treatment of sample-based row vector inputs will be removed in a future release. See the compatibility considerations for more information about how this change will affect your models.
Compatibility Considerations. The blocks listed will continue to work as expected in R2011a. However, in a future release these blocks will produce a warning when you provide them with a sample-based row vector input, and eventually, their behavior will change.
You can prepare your models for the upcoming change by running the slupdate function. If the function detects any blocks that have a Treat sample-based row input as a column check box, it performs the following actions:
If the input to the block is a sample-based row vector, and the Treat sample-based row input as a column check box is selected, the slupdate function places a Transpose block in front of the affected block. The Transpose block transposes the sample-based row vector into a column vector, which is then input into the affected block. Transposing the input signal ensures that your model will produce the same results in future releases.
If the Treat sample-based row input as a column check box is not selected, or if the input to the block is not a sample-based row vector, the slupdate function takes no action. Your model will continue to work as expected in future releases.
If the slupdate function detects any blocks that automatically treat sample-based row vectors as a column, it performs the following actions:
If the input to the block is a sample-based row vector, the slupdate function places a Transpose block in front of the affected block. The Transpose block transposes the sample-based row vector into a column vector, which is then input into the affected block. Transposing the input signal ensures that your model will produce the same results in future releases.
If the input to the block is not a sample-based row vector, the slupdate function takes no action. Your model will continue to work as expected in future releases.
In R2010b, the package name of Signal Processing Blockset™ System objects changed from signalblks to dsp. In R2011a, a new function is available to help you update your code. You can use the sysobjupdate function to recursively search a folder and its subfolders for MATLAB files that contain System object packages, classes, and properties that have been renamed.
If you have any existing System object code that uses a package name of signalblks, you should use the sysobjupdate function to update your code. For more information, type help sysobjupdate at the MATLAB command line.
R2011a adds a new Discrete FIR Filter block to the DSP System Toolbox Filtering/Filter Implementations library. The block is an implementation of the Simulink Discrete FIR Filter block.
You can now print the data you see in the Time Scope block. To send the data to your printer, select File > Print ... from the scope menu. To print the data to a MATLAB figure, select File > Print to Figure.
R2011a introduces the capability to improve the performance of the Time Scope block and dsp.TimeScope System object by reducing the frequency with which the display updates. You can now choose between this new enhanced performance mode and the old behavior by selecting Reduce Updates to Improve Performance from the Simulation menu of the block, or the Playback menu of the System object. By default, both the block and System object operate in the new enhanced performance mode.
This release provides filter customization options for blocks in the Filtering/Filter Designs library. You can access these options in the Filter implementation section of the block dialog box:
Implement designed filters as Simulink basic elements or as a digital filter.
Customize filters built using Simulink basic elements using the Optimizations parameters.
Blocks in the Filtering/Filter Designs library also support Input processing and Rate options parameters in R2011a. For more information, see Blocks with a New Input Processing Parameter.
Frame-based processing and filters with algebraic loops — For filters that contain sample-by-sample feedback, using a lumped-element implementation instead of Simulink basic elements can eliminate algebraic loops. For supported blocks, use the slupdate function on older models with designed filters to convert the designed filters into lumped filters. You can enable this feature manually by clearing the Use basic elements for filter customization check box.
For filters with algebraic loops that do not have this option, specify sample-based processing by setting the Input processing parameter to Elements as channels (sample based).
Rate Options parameter — Filters that allow multirate processing, such as FIR decimators and interpolaters, perform single-rate processing by default. For more information, see the block reference pages.
This release adds new dsp.DigitalDownConverter and dsp.DigitalUpConverter System objects. The digital up converter (DUC) and digital down converter (DDC) System objects provide tools to design interpolation/decimation filters and simplify the steps required to implement the up/down conversion process.
The FFT, IFFT blocks include the use of the FFTW library.
The following System objects support inputs that change their size at runtime.
For the dsp.UDPSender and dsp.UDPReceiver System objects only, you should update your code to stop sending or receiving any data length settings. Support for variable-size data makes the data length settings redundant. For example,
% Change these lines to remove explicit lengths:
step(hudps, dataSent, dataLength);
[dataReceived len] = step(hudpr);
bytesReceived = bytesReceived + ...
length(dataReceived) len;
% Code lines with lengths removed:
step(hudps,datasent);
[dataReceived] = step(hudpr);
bytesReceived = bytesReceived + ...
length(dataReceived);
A FullPrecisionOverride property has been added to the System objects listed below. This property is a convenient way to control whether the object uses full precision to process fixed-point input.
When you set this property to true, which is the default, it eliminates the need to set many fixed-point properties individually. It also hides the display of these properties (such as RoundingMode, OverflowAction, etc.) because they are no longer applicable individually.
To set individual fixed-point properties, you must first set FullPrecisionOverride to false.
The following System objects are affected:
All of these System objects have their new FullPrecisionOverride property set to the default, true. If you had set any fixed-point properties to non-default values for these objects, those values are ignored. As a result, you may see different numerical answers from those answers in a previous release. To use your nondefault fixed-point settings, you must first change FullPrecisionOverride to false.
To clarify the value of many DataType properties, the 'Internal rule' option has been changed to 'Full precision'.
The objects allow you to enter either 'Internal rule' or 'Full precision'. If you enter 'Internal rule', that option is stored as 'Full precision'.
The DSP System Toolbox supports the MATLAB Compiler for most System objects. With this capability, you can use the MATLAB Compiler to take MATLAB files, which can include System objects, as input and generate standalone applications.
The following System objects are not supported by the MATLAB Compiler software:
The MATLAB Variable Editor now displays System objects properties in the same order as they display at the command line. Note that the Variable Editor provides a read-only view for System objects.
When a System object is locked (e.g., after the step method has been called), the following situations now produce an error. This change prevents the loss of state information.
Changing the input data type
Changing the number of input dimensions
Changing the input complexity from real to complex
Changing the data type, dimension, or complexity of tunable property
Changing the value of a nontunable property
Previously, the object issued a warning for these situations. The object then unlocked, reset its state information, relocked, and continued processing. To update existing code so that it does not produce an error, use the release method before changing any of the items listed above.
R2011a adds the following new demos:
Digital Up and Down Conversion for Family Radio Service — Shows you how to use the new dsp.DigitalDownConverter and dsp.DigitalUpConverter System objects to design a Family Radio Service (FRS) transmitter and receiver.
Design and Analysis of a Digital Down Converter — Shows you how to use the dsp.DigitalDownConverter System object to simplify the steps required to emulate the TI Graychip 4016 digital down converter.
Using System Objects with MATLAB Compiler — Shows you how to use MATLAB Compiler to create a standalone application from MATLAB System objects.
Additionally, the Simulink-based demo, GSM Digital Down Converter, has been enhanced to use the Fixed-Point Toolbox™ cordicrotate function. The demo now allows you to compare an NCO-based mixer to a CORDIC-based mixer.
In previous releases, the example models used throughout the Signal Processing Blockset™ documentation were named with a prefix of doc_. In R2011a, this prefix has changed to ex_. For example, in R2010b, you could launch an example model using the Time Scope block by typing doc_timescope_tut at the MATLAB command line. To launch the same model in R2011a, you must type ex_timescope_tut at the command line.
You can no longer launch DSP System Toolbox documentation example models using the doc_ name. To open these models in R2011a, you must replace the doc_ prefix in the model name with ex_.
As of R2011a, the Downsample block no longer exhibits frame-based processing latency when the input frame size is one.
Existing models that use the Downsample block in frame-based processing mode may produce different results in R2011a. Specifically, the Downsample block no longer has one-frame of latency when the input frame size is one. If your model uses a Downsample block in frame-based processing mode and the input frame size is one, you will see different results when you run your model in R2011a. If you need to restore the one-frame latency, you can use a Delay block to delay the output of the Downsample block by one frame.
The SignalReader System object now accepts column inputs only.
Update any code with row input to the SignalReader object to convert the input to column form before passing it to the object. (Note that this change occurred in R2010b.)
In R2010b, the FrameBasedProcessing property was removed from the dsp.DelayLine and dsp.Normalizer System objects. Both objects now treat each column of the input as a separate channel (frame-based processing).
As of R2010b, MATLAB issues a warning when you set the FrameBasedProcessing property of the dsp.DelayLine or dsp.Normalizer System objects.
If you saved a System object to a MAT file in R2010a and load that file in R2011a, MATLAB may display a warning that the constructor must preserve the class of the returned object. This occurs because an aspect of the class definition changed for that object in R2011a. The object's saved property settings may not restore correctly.
MAT files containing a System object saved in R2010a may not load correctly in R2011a. You should recreate the object with the desired property values and save the MAT file.
 | Version 8.1 (R2011b) DSP System Toolbox | Compatibility Summary for DSP System Toolbox |  |
Includes the most popular MATLAB recorded presentations with Q&A sessions led by MATLAB experts.
| © 1984-2012- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |
