|
|
|
| R2012a Documentation → Communications System Toolbox | |
Learn more about Communications System Toolbox |
|
| Contents | Index |
This table summarizes what's new in V 5.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:
'Internal rule' System Object Property Values Changed to 'Full precision'
System Objects Input and Property Warnings Changed to Errors
The Communications System Toolbox product replaces two pre-existing products: Communications Blockset and Communications Toolbox. You can access archived documentation for both products on the MathWorks Web site.
This release adds new comm.LDPCEncoder and comm.LDPCDecoder System objects. These new System objects provide simulation of low-density, parity-check codes.
This release adds a new comm.gpu.LDPCDecoder System object, which uses a graphics processing unit (GPU) to decode low-density, parity-check codes. This new System object procures simulation results more quickly than a CPU.
The following blocks now support variable-size input signals:
M-PSK Modulator Baseband
QPSK Modulator Baseband
BPSK Modulator Baseband
M-PAM Modulator Baseband
Rectangular QAM Modulator Baseband
General QAM Modulator Baseband
M-PSK Demodulator Baseband
QPSK Demodulator Baseband
BPSK Demodulator Baseband
M-PAM Demodulator Baseband
Rectangular QAM Demodulator Baseband
General QAM Demodulator Baseband
Bit to Integer Converter
Integer to Bit Converter
Convolutional Encoder
Viterbi Decoder
The following source blocks can now output variable-size signals:
Gold Sequence Generator
Kasami Sequence Generator
PN Sequence Generator
The following System objects now support variable-size input signals:
comm.PSKModulator
comm.QPSKModulator
comm.BPSKModulator
comm.PAMModulator
comm.RectangularQAMModulator
comm.GeneralQAMModulator
comm.PSKDemodulator
comm.QPSKDemodulator
comm.BPSKDemodulator
comm.PAMDemodulator
comm.RectangularQAMDemodulator
comm.GeneralQAMDemodulator
comm.IntegerToBit
comm.BitToInteger
The following System objects now output variable-size signals:
comm.GoldSequence
comm.KasamiSequence
comm.PNSequence
This release introduces a new encoding algorithm for all blocks in the CRC sublibrary residing in the Error Detection and Correction library. In this new implementation, the block processes multiple input bits in one step, resulting in faster processing times. The previous implementation always processed one input bit at each step.
The Communications 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:
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 following System objects support code generation:
comm.PSKTCMMoldulator
comm.RectangularQAMTCMModulator
comm.GeneralQAMTCMModulator
comm.EarlyLateGateTimingSynchronizer
comm.GardnerTimingSynchronizer
comm.GMSKTimingSynchronize
comm.MSKTimingSynchronizer
comm.MuellerMullerTimingSynchronizer
comm.KasamiSequence
Communications System Toolbox software uses a new implementation of the LDPC Decoder block. If you open a previously existing model that contains the LDPC block, the model generates a warning at the MATLAB command line. Simply resave the model to prevent any subsequent warnings.
In previous releases, when the frequency offset input signal to the Phase/Frequency Offset block or comm.PhaseFrequencyOffset System object was constant, or time-invariant, the block and System object generated the correct output. However, the block and System object produced incorrect results for a time-varying frequency offset input signal. The new implementation generates the correct output for a time-varying frequency offset input signal.
The Derepeat block now contains the Input processing and Rate options parameters. See Frame-Based Processing for more information.
All the obsolete block libraries associated with Communications Blockset version 2 Release 12, version 2.5 Release 13, and version 3.0 Release 14 have been removed from this product. The removal includes the following libraries:
commanabbnd2
commcontsrc2
commdigpbndam2
commdigpbndcpm2
commdigpbndfm2
commdigpbndpm2
comminteg2
commanapbnd2
commchan2
commdigbbndam2
commdigbbndpm2
Communications System Toolbox software does not support any of the blocks from Release 12 and Release 13. The Communications System Toolbox block libraries provide some of the same functionality in the form of upgraded blocks.
When a System object is locked (for example, 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.
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. Communications 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 transition to the new paradigm of frame-based processing, many blocks have received new parameters. The following sections provide more detailed information about the specific Communications 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 R2010b 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 the Input processing parameter, the parameter will be set to Inherited (this choice will be removed - see release notes) when you load your model. 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 R2010b frame-based processing changes, see the following Compatibility Considerations sections.
Some Communications 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 received a new Input processing parameter. You can select 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 Summary for Communications System Toolbox 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, expand the following list.
Blocks with New Input Processing Parameter
Compatibility Considerations. When you load an existing model R2010b, 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 R2010b, 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 for the Gaussian Filter or Windowed Integrator, 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.
The AWGN Channel block uses the new method of Frame-Based Processing. In previous releases, the frame status of the input signal determined how the AWGN Channel block processed the signal. In R2010b, the default behavior of the AWGN Channel block is to always perform frame-based processing.
Unless you specify otherwise, the block now treats each column of the input signal as an individual channel, regardless of its frame status. To enable the behavior change in the AWGN Channel block while still allowing for backward compatibility, an Input processing parameter has been added. This parameter will be removed in a future release, at which point the block will always perform frame-based processing.
Compatibility Considerations. The Input processing parameter will be removed in a future release. At that point in time, the AWGN Channel block will always perform frame-based processing.
You can use the slupdate function to upgrade your existing models that contain an AWGN Channel block. The function detects all AWGN Channel blocks in your model and, if you allow it to, performs the following actions:
If the input to the block is an M-by-1 or unoriented sample-based signal, the slupdate function performs three actions. First, a Transpose block is placed in front of the AWGN Channel 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. The slupdate function also sets the Input processing parameter to Columns as channels (frame based). This setting ensures that your model will continue to produce the same results when the Input processing parameter is removed in a future release. The slupdate function also adds a Transpose block after the AWGN channel block in your model for an M-by-1 sample-based input and a Reshape block for unoriented inputs. By converting the row vector output of the AWGN channel to the input dimension, the model continues to behave as in prior releases.
If the input to the block is not an M-by-1 or unoriented sample-based signal, the slupdate function sets the Input processing parameter to Columns as channels (frame based). 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 Input processing parameter is removed in a future release.
In R2010a and earlier releases, many Communications System Toolbox blocks that supported multirate processing had a Framing parameter. This parameter allowed you to specify whether the block should Maintain input frame size or Maintain input frame rate when processing the input signal. Beginning in R2010b, a new Rate options parameter replaced the Framing parameter. The Rate options parameter allows you to specify whether the block should Enforce single-rate processing or Allow multirate processing.
Some blocks that supported multirate processing in R2010a and earlier releases did not have a Framing parameter. These blocks used the frame status of the input signal to determine whether they performed single-rate or multirate processing. Because of the upcoming frame-based processing changes, signals will no longer carry their frame status. Thus, multirate blocks can no longer rely on the frame status of the input signal to determine whether they perform single-rate or multirate processing. You must now specify a value for the Rate options parameter on the block dialog box.
To see a full list of blocks that have a new Rate options parameter, expand the following section.
Multirate Blocks with a New Rate Options Parameter
The following blocks do not process sample-based row vectors:
Compatibility Considerations. Using existing models that contain these blocks to process sample-based row vectors generates an error message.
The CMA Equalizer block now handles input signals like the other equalizer blocks in the Communications Blockset library. Therefore, the block no longer accepts scalar input signals in symbol-spaced mode.
The Differential Encoder block supports scalar-valued and column vector input signals. It does not support frame-based or sample-based row vectors.
The Correlation window length parameter specifies the number of samples the block uses to calculate the cross-correlation of two signals. You must specify a window lengths of at least 2 for the cross-correlation calculations. If you set the Correlation window length parameter to 1, the block generates an error message. The following blocks contain the Correlation window length parameter:
This release contains the following new demos:
 | Version 5.1 (R2011b) Communications System Toolbox | Compatibility Summary for Communications System Toolbox |  |
Learn how to apply early verification to your development process through these technical resources.
How much time do you spend on testing to ensure implementation meets system-level requirements?
| © 1984-2012- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |
