Quantcast

Documentation Center

  • Trial Software
  • Product Updates

Communications System Toolbox Release Notes

R2014a

New Features, Bug Fixes, Compatibility Considerations

OFDM modulator and demodulator System objects and blocks

This release adds OFDM modulation and demodulation capability by the addition of System objects and blocks. For more information, see the comm.OFDMModulator and comm.OFDMDemodulator System object Help pages.

DC blocker System object and block

The release adds a new DC blocker System object and block. For more information, see the dsp.DCBlocker Help page.

Direct and nondirect modes for HDL-optimized CRC generator and detector

This release allows the selection of either the direct or non-direct algorithm for CRC checksum calculations for the HDL-optimized CRC generator and detector System objects and blocks. For more information, see the comm.HDLCRCDetector and the comm.HDLCRCGenerator System object Help pages.

Additional featured examples such as 802.11 OFDM synchronization and HDL Optimized QAM Transmitter and Receiver

Additional featured examples:

  • 802.11 sychronization

  • HDL Optimized QAM Transmitter and Receiver

    Generate HDL code from hardware-optimized 64-QAM transmitter and receiver. This example addresses real-world communications issues and generates HDL code for FPGA implementation (HDL Coder™ license required).

  • HDL Optimized QPSK Transmitter

    This example shows how Simulink® blocks that support HDL code generation can be used to implement the baseband processing of a digital communications transmitter (HDL Coder license required).

APP Decoder System object parameter change

Beginning in release R2012a, the Algorithm property replaced the MetricMethod property for the APP Decoder System object™. At this time, an error will occur in legacy code that uses the MetricMethod property.

Compatibility Considerations

If you have any existing System object code that uses the MetricMethod property, you must change the property to Algorithm.

GPU System Object Support in System Block

GPU System objects are now supported in the System Block. The following System objects are supported in the current release:

  • comm.gpu.AWGNChannel

  • comm.gpu.BlockDeinterleaver

  • comm.gpu.BlockInterleaver

  • comm.gpu.ConvolutionalDeinterleaver

  • comm.gpu.ConvolutionalEncoder

  • comm.gpu.ConvolutionalInterleaver

  • comm.gpu.PSKDemodulator

  • comm.gpu.PSKModulator

  • comm.gpu.TurboDecoder

  • comm.gpu.ViterbiDecoder

System object templates

The MATLAB New > System object menu now has three new class-definition file templates. The Basic template sets up a simple System object. The Advanced template includes additional features of System objects. The Simulink Extension template provides additional customization of the System object for use in the MATLAB System block.

System objects infer number of inputs and outputs from stepImpl method

When you create a new kind of System object that has a fixed number of inputs or outputs specified in the stepImpl method, you no longer need to include getNumInputsImpl or getNumOutputsImpl in your class definition file. The correct number of inputs and outputs are inferred from the stepImpl inputs and outputs, respectively.

System objects setupImpl method enhancement

When you create a new kind of System object and include the setupImpl method, you do not have to match the setupImpl method inputs to the stepImpl method inputs. If your setupImpl method does not use any input characteristics, such as, data type or size), you can include only the System object as the input argument.

System objects base class renamed to matlab.System

The System object base class, matlab.system.System has been rename to matlab.System. If you use matlab.system.System when defining a new System object, a error message results.

Compatibility Considerations

Change all instances of matlab.system.System in your System objects code to matlab.System.

System objects Propagates mixin methods

Four new methods have been added to the Propagates mixin class. You use this mixin when creating a new kind of System object for use in the MATLAB System block in Simulink. You use these methods to query the input and specify the output of a System object.

  • propagatedInputComplexity

  • propagatedInputDataType

  • propagatedInputFixedSize

  • propagatedInputSize

System objects infoImpl method allows variable inputs

When you create a new kind of System object, you can use the info method to provide information specific to that object. The infoImpl method, which you include in your class-definition file, now allows varargin as an input argument.

Support Package for RTL-SDR Radio (v 14.1.0)

Design and prototype software-defined radio (SDR) systems using MATLAB® and Simulink with the Communications System Toolbox™ Support Package for RTL-SDR Radio.

For full access to features and documentation, download the support package from the Hardware Support page. To get help for the RTL-SDR Radio support package after you install it, enter help sdrr at the MATLAB command line.

Key Features

  • RTL-SDR radio as an I/O peripheral to receive streaming RF signals

  • Configurable center frequency and sample rate

  • NooElec™ NESDR Mini USB Stick (R820T) and NooElec NESDR Nano USB Stick (R820T) SDR devices with frequency range 30MHz – 1.8GHz

  • Compatible with other RTL-SDR USB radios (for example, Terratec T-Stick E4000).

  • Several application examples for getting started

Blocks and System Objects

RTL-SDR Examples

  • Spectrum Analysis with RTL-SDR Radio for MATLAB and Simulink

  • Frequency Offset Calibration with RTL-SDR Radio for MATLAB and Simulink

  • FM Monophonic Receiver with RTL-SDR Radio for MATLAB and Simulink

  • FM Stereo Receiver with RTL-SDR Radio for MATLAB and Simulink

  • FRS/GMRS Walkie-Talkie Receiver with RTL-SDR Radio for MATLAB and Simulink

Enter sdrexamples at the MATLAB command prompt for a full index of SDR support package examples.

Hardware and Software Requirements

For both MathWorks® and third-party software and hardware requirements, see RTL-SDR Support from Communications System Toolbox.

Support Package for Xilinx FPGA-Based Radio updates (v 14.1.0)

Intermediate frequency tuning

This features supports a second stage tuning for both transmit and receive data paths. Then tuner is configurable at run-time (tunable). It has a finer resolution compared to the primary tuner on RF card, and the ability to remove unwanted interference from the pass band of interest.

  • Transmitter and Receiver blocks: Set the Intermediate Frequency parameter in the block mask.

    The intermediate frequency (IF) tuner allows you to account for the error in tuning between target frequency and actual frequency.

  • Transmitter and Receiver System objects: Set the IntermediateFrequency property for the System object. For example:

    so = comm.SDRADIFMCOMMSTransmitter;
    so.IntermediateFrequency = txIFValue
    

    See the reference pages for comm.SDRADIFMCOMMSReceiver, comm.SDRADIFMCOMMSTransmitter, or comm.SDREpiqBitsharkReceiver.

  • With the HDL Coder workflow advisor (for Simulink only): Choose to include or not include the Intermediate Frequency tuner in the FPGA when using the targeting workflow.

    At step 4.1, Set SDR Options:

    • For transmit, select Include transmitter intermediate frequency tuner.

    • For receiver, select Include receiver intermediate frequency tuner.

DC blocking filter

Choose to bypass the DC bias removal filter. Use this feature when the filter is also blocking some signal and you need to use a different DC bias compensation scheme. By default, this option is not selected, which means to include the automatic DC blocking filter.

QPSK targeting examples

  • Targeting HDL Optimized QPSK Receiver with SDR Platform: Learn how to model an HDL-optimized QPSK receiver and prototype it on the SDR hardware using the HDL Coder workflow advisor.

  • Targeting HDL Optimized QPSK Transmitter with SDR Platform: Learn how to model an HDL-optimized QPSK transmitter and prototype it on the SDR hardware using the HDL Coder workflow advisor.

R2013b

New Features, Bug Fixes, Compatibility Considerations

Simulink blocks for MIMO channel, sphere decoder, and constellation diagram

This release includes a new MIMO Channel, sphere decoder, and constellation diagram blocks.

The MIMO Channel block filters an input signal using a multiple-input multiple-output (MIMO) multipath fading channel. For more information, see MIMO Channel.

The Sphere Decoder block offers MIMO receiver processing for communications systems using spatial multiplexing with high data rates, such as 802.11n, LTE, and WiMAX. This implementation offers maximum likelihood performance with reduced complexity. For more information, see Sphere Decoder.

The Constellation Diagram block plots constellation diagrams and provides the ability to perform EVM and MER measurements. The Constellation Diagram block replaces the Discrete-Time Scatter Plot block. For more information, see Constellation Diagram.

Compatibility Considerations

The Constellation Diagram block display enforces a 1:1 aspect ratio. The Discrete-Time Scatter Plot block, which the Constellation Diagram block replaces, does not enforce a 1:1 aspect ratio. For a non-unity display aspect ratio, you can use the Simulink XY Graph block.

Code generation for all MIMO channel Doppler spectra

The comm.MIMOChannel System object now generates C code for the following Doppler spectra:

  • Rounded

  • Bell

  • Asymmetric Jakes

  • Restricted Jakes

  • Gaussian

  • BiGaussian

  • Flat

  • Jakes

Open-loop PSK and QAM carrier synchronizers in MATLAB

This release provides new open-loop carrier synchronizer System objects, which allow you to estimate and compensate for carrier offset due to transceiver impairments. For more information, see:

HDL-Optimized QPSK Receiver with Captured Data

The example HDL Optimized QPSK Receiver with Captured Data shows how to optimize an QPSK receiver for HDL code generation and hardware implementation. The HDL-optimized model shows a QPSK receiver that addresses real-world communications issues like carrier frequency, phase offset, and timing recovery for the hardware implementation.

Raised cosine transmit and receive filter System objects

This release provides new raised cosine transmit and receive filter System objects. For more information, see:

Rayleigh and Rician fading channel System objects

This release provides new fading channel System objects. For more information, see:

System objects matlab.system.System warnings

The System object base class, matlab.system.System, has been replaced by matlab.System. If you use matlab.system.System when defining a new System object, a warning message results.

Compatibility Considerations

Change all instances of matlab.system.System in your System objects code to matlab.System.

Restrictions on modifying properties in System object Impl methods

When defining a new System object, certain restrictions affect your ability to modify a property.

You cannot use any of the following methods to modify the properties of an object:

  • cloneImpl

  • getDiscreteStateImpl

  • getDiscreteStateSpecificationImpl

  • getNumInputsImpl

  • getNumOutputsImpl

  • getOutputDataTypeImpl

  • getOutputSizeImpl

  • isInputDirectFeedthroughImpl

  • isOutputComplexImpl

  • isOutputFixedSizeImpl

  • validateInputsImpl

  • validatePropertiesImpl

This restriction is required by code generation, which assumes that these methods do not change any property values. These methods are validation and querying methods that are expected to be constant and should not impact the algorithm behavior.

Also, if either of the following conditions exist:

  • You plan to generate code for the object

  • The object will be used in the MATLAB System block

you cannot modify tunable properties for any of the following runtime methods:

  • outputImpl

  • processTunedPropertiesImpl

  • resetImpl

  • setupImpl

  • stepImpl

  • updateImpl

This restriction prevents tunable parameter updates within the object from interfering with updates from outside the generated code. Tunable parameters can only be changed from outside the generated code.

Compatibility Considerations

If any of your class definition files contain code that changes a property in one of the above Impl methods, move that property code into an allowable Impl method. Refer to the System object Impl method reference pages for more information.

Block parameter prompt changes for raised cosine filter blocks

In this release, several block parameter prompts on the Raised Cosine Transmit Filter block and the Raised Cosine Receive Filter block have changed.

 How to map old block property names to new block property names

Compatibility Considerations

The updated Raised Cosine Transmit Filter and Raised Cosine Receive Filter blocks design a unit energy filter and then apply the linear amplitude filter gain to the filter coefficients. If you open a model that was saved in a prior version of the software, the software updates the block parameters. The blocks set the Filter span in symbols as twice the value of the Group delay (number of symbols) parameter. Similarly, the blocks set the linear amplitude filter gain to use the same filter coefficients as the old model. If you define a parameter value using a variable, you should confirm that the variable propagates correctly after you open the model.

Each time you open a model that was created using a prior release, Simulink automatically sets the block parameter values to obtain the same filter coefficients. If you save the model, the updates become permanent. As a best practice, you should confirm that the parameter values of the filter blocks are valid before saving the updated models.

NumTransmitAntennas and NumReceiveAntennas properties added back to MIMOChannel System object.

In the previous release, the NumTransmitAntennas and NumReceiveAntennas properties were removed from the MIMO Channel System object. This release, the properties were added back to the object. For more information, see comm.MIMOChannel

Functionality Being Changed or Removed

Effective this release, you should not use the following block or functions when simulating digital communications systems.

FunctionalityWhat Happens When You Use This Functionality?Use This InsteadCompatibility Considerations
Discrete-Time Scatter Plot blockStill runsConstellation DiagramReplace all instances of Discrete-Time Scatter Plot block with Constellation Diagram
Gaussian Filter blockStill runsgaussdesign function and Discrete FIR Filter, FIR Interpolation, or FIR Decimation blockReplace all instances of Gaussian Filter block withDiscrete FIR Filter, FIR Interpolation, or FIR Decimation blocks. Use gaussdesign to generate filter coefficients for these blocks.
rcosfirStill runsrcosdesignReplace all instances of rcosfir with rcosdesign.
rcosfltStill runsrcosdesign function and either filter or upfirdn functionsReplace all instances of rcosflt with rcosdesign and either filter or upfirdn.
rcosiirStill runsrcosdesign function for FIR raised cosine filtersReplace all instances of rcosiir with rcosdesign.
rcosineStill runsrcosdesignReplace all instances of rcosine with rcosdesign.

Migrate Code from firrcos and rcosfir to rcosdesign

This section helps you update your legacy code using firrcos and rcosfir to use the recommended rcosdesign.

 firrcos to rcosdesign

 rcosfir to rcosdesign

Support Package for Xilinx FPGA-Based Radio

Design SDR applications for use with FPGA-based radio. Supports both fixed bitstream (Support Package for Xilinx® FPGA-Based Radio software provides all logic) and custom bitstream (user-provided logic) workflows (SDR Targeting). This support package includes Simulink receiver and transmitter blocks for use with Simulink and receiver and transmitter System objects for use with MATLAB. These blocks and System objects enable communication with an FPGA-based radio, allowing for development work in software-defined radio applications.

Main Features

Supported Hardware and Software

  • Hardware support

    FPGA Development BoardRF BoardFixed Bitstream SupportSDR Targeting Support
    Virtex-6 ML605Epiq Bitshark™ RevBYesYes
    Virtex-6 ML605Epiq Bitshark RevCYesYes
    Xilinx ML605ADI FMCOMMS1 RevBYesYes

  • Software requirements

    • SDR fixed bitstream and SDR targeting are tested with Xilinx ISE 13.4.

    • For fixed bitstream, Xilinx iMPACT is required.

R2013a

New Features, Bug Fixes, Compatibility Considerations

Sphere Decoder System object for MIMO receiver processing

The Sphere Decoder System object offers MIMO receiver processing for communications systems using spatial multiplexing with high data rates, such as 802.11n, LTE, and WiMAX. This implementation offers maximum likelihood performance with reduced complexity.

For more information, see the comm.SphereDecoder Help page.

Constellation Diagram System object with measurements

The constellation diagram System object plots constellation diagrams and provides the ability to perform EVM and MER measurements. For more information, see the comm.ConstellationDiagram System object Help page.

LTE space-frequency block coding and LTE GPU-accelerated turbo coding examples

This release includes new LTE examples illustrating space-frequency block coding and GPU-accelerated turbo coding.

The LTE Downlink PDSCH with Transmit Diversity example highlights LTE Downlink PDSCH processing with transmit diversity, including two transmit antenna and four transmit antenna configurations.

The LTE Downlink Shared Channel Processing with GPU Acceleration example shows how you can use GPUs to accelerate bit error rate simulations.

In addition, the existing LTE PHY Downlink with Spatial Multiplexing example includes two new MATLAB-based implementations.

HDL code generation for CRC Generator, CRC Detector, RS Encoder, and RS Decoder System objects

Effective this release, the following System objects provide HDL code generation:

To generate HDL code, you must have an HDL Coder license.

Variable-size support for AWGN, MIMO, and LTE MIMO Channel System objects

This release includes variable-size support for the AWGN, MIMO Channel, and LTE MIMO Channel System objects. This support enables you to:

  • Vary the number of transmit and receive antennas, which is necessary for LTE modeling

  • Vary the number of samples per channel, which is helpful for LTE and WiMAX modeling

For more information see:

IEEE 802.11 WLAN - HDL optimized beacon frame receiver example with captured data

This example shows a hardware friendly model that receives beacon frames in an 802.11 wireless local area network (WLAN).

Automatic gain controller block and System object

This release includes a new automatic gain controller (AGC) block and System object. The AGC adaptively adjusts its gain to achieve a constant signal level at the output.

For more information see the AGC block and comm.AGC System object Help pages.

Additional CRC algorithm implementation

Effective this release, the CRC blocks and System objects support the direct algorithm, input byte reflection, checksum reflection, and final XOR operation. These features enable more straightforward Ethernet CRC generation and detection. For more information see:

ATSC digital television example

The ATSC Digital Television example shows the vestigial sideband modulation with 8 discrete amplitude levels (8-VSB) transmission subsystem of the Advanced Television Systems Committee (ATSC) digital television standard.

Disable second output port on APP Decoder

Beginning in this release, you can disable the second output port, containing coded bit log-likelihood ratios, on the APP Decoder System object and block.

For the System object, disable the CodedBitLLROutputPort property.

For the block, select the Disable L(c) output port check box.

Behavior change of locked System objects for loading, saving, and cloning

In the previous release, saving, loading, and cloning a locked System object would result in an unlocked System object. This System object had the same property values as the one from which it was cloned, but not the same internal state.

In this release, it does not matter whether you save a locked System object into a MAT file and load it later or clone a locked System object using the clone method. In either case, the result is a locked System object with the same property values and the same internal states.

Dynamic memory allocation based on size

By default, dynamic memory allocation is now enabled for variable-size arrays whose size exceeds a configurable threshold. This behavior allows for finer control over stack memory usage. Also, you can generate code automatically for more MATLAB algorithms without modifying the original MATLAB code. The following System objects support dynamic memory allocation for C code generation:

Compatibility Considerations

If you use scripts to generate code and you do not want to use dynamic memory allocation, you must disable it. For more information, see Controlling Dynamic Memory Allocation.

Naming convention change for LTE examples

Effective this release, there is a new naming convention for LTE examples. See the following table for more information.

Example TitleOld New File NameNew File Name
Downlink Transport Channel (DL-SCH) ProcessingcommlteDLSCHLTEDLSCHExample
LTE PHY Downlink with Spatial MultiplexingcommlteDownlinkLTEDownlinkExample

Compatibility Considerations

Typing the old file names at the MATLAB command line no longer opens example models. To open the example models, you must type the new file names.

APP Decoder System Object parameter change

Beginning in release R2012a, the Algorithm property replaced the MetricMethod property for the APP Decoder System object. At this time, any legacy code that uses the MetricMethod property generates a warning.

Compatibility Considerations

If you have any existing System object code that uses the MetricMethod property, you must use the sysobjupdate function to update your code. For more information, type help sysobjupdate at the MATLAB command line.

Functions to remain in the product

The following functions, which were previously announced for removal, will remain in the product.

Communications System Toolbox Functionality Being Changed or Removed

The following function will be removed in a future release.

FunctionalityWhat Happens When You Use This Functionality? Use This Instead Compatibility Considerations
mimochanWarnscomm.MIMOChannelReplace all instances of mimochan with comm.MIMOChannel.

Update Legacy Code to use System object

For help updating your legacy code so that it uses the comm.MIMOChannel System object, see the following table.

 Map mimochan Properties and Methods to comm.MIMOChannel

R2012b

New Features, Compatibility Considerations

Support for C code generation for all System objects in Communications Systems Toolbox

Effective this release, the following System objects provide C code generation:

All CPU-based System objects in the Communications System Toolbox product generate C code. The GPU-based System objects do not generate C code.

Support for HDL code generation for Reed-Solomon encoder, decoder, and CRC detector blocks

Effective this release, the following blocks provide HDL code generation:

  • General CRC Syndrome Detector HDL Optimized

  • Integer-Input RS Encoder HDL Optimized

  • Integer-Output RS Decoder HDL Optimized

To generate HDL code, you must have an HDL Coder license.

Support for HDL code generation for Rectangular QAM and PSK Demodulator System objects

Effective this release, the following System objects provide HDL code generation:

To generate HDL code, you must have an HDL Coder license.

LTE Zadoff-Chu sequence generator function

Communications System Toolbox includes a Zadoff-Chu sequence generator function. This function is useful when modeling 3GPP LTE physical layer characteristics, downlink primary synchronization signals, or the uplink reference signals and random access preamble sequences. For more information, see the lteZadoffChuSeq Help page.

LTE downlink shared channel example

This example shows the Downlink Shared Channel (eNodeB to UE) processing of the Long Term Evolution (LTE) physical layer (PHY) specifications developed by the Third Generation Partnership Project (3GPP). LTE-Advanced is one of the candidates for fourth generation (4G) communications systems, approved by the International Telecommunication Union (ITU), with expected downlink peak data rates in excess of 1Gbps (for Release 10 and beyond). Using the Release 10 specifications, this example highlights the multi-antenna transmission scheme that enables such high data rates.

Phase Noise block and System object, specifying phase noise spectrum with a vector of frequencies

The Phase Noise block and System object now have more flexibility for specifying spectral noise characteristics. You can specify a vector of phase noise levels, at more than one frequency value. Previously, the software allowed the specification of a single-phase noise level point. The new implementation enables more realistic noise modeling in your communications models, and allows you to visualize the phase noise spectrum that the block or System object generates.

IEEE 802.11 beacon with captured data example

This example shows reception of beacon frames in an 802.11 wireless local area network (WLAN). You can select one of several captured signals and view the data the beacon frame carries.

P25 spectrum sensing example

This example shows how to use cyclostationary feature detection to distinguish signals with different modulation schemes, including P25 signals. It defines four cases of signals: noise only, C4FM, CQPSK, and one arbitrary type. The example applies the detection algorithm to signals with different SNR values and determines when the signals can be classified as one of the four types.

MATLAB-based QPSK transceiver example

The QPSK Transmitter and Receiver example now includes a MATLAB implementation that uses System objects. This example models a digital communications system to simulate the QPSK transmitter - receiver chain. In particular, this example illustrates a method for tackling real-world wireless communication issues, such as: carrier frequency/phase offset, timing recovery, and frame synchronization.

Design Iteration Workflow

This example illustrates a design workflow and the typical iterations involved in designing a wireless communications system with the Communications System Toolbox. Because Communications System Toolbox supports both MATLAB and Simulink, this examples showcases separate design iterations using MATLAB functions or Simulink models.

The workflow starts with a simple QPSK modulator system that transmits a signal through an AWGN channel and calculates the bit error rate. To make the system more realistic and improve system performance, the example gradually introduces Viterbi decoding, turbo coding, multipath fading channels, OFDM-based transmission and equalization, and multiple-antenna techniques.

Constellation method for modulator and demodulator System objects

Effective this release, modulator and demodulator System object have a constellation method. This method calculates or plots the ideal signal constellation, depending on object settings. The following System objects have the constellation method:

Specify initial states of Gold Sequence Generator and PN Sequence Generator System objects

You can specify the initial states for the PN Sequence Generator and Gold Sequence Generator System objects as inputs to the step method. You can use these System objects as scrambling sequence generators. For packet-based systems, including WiMAX and LTE, the initial conditions are a function of time. Therefore, for simulation purposes, you must specify the initial states as an input.

System object tunable parameter support in code generation

You can change tunable properties in user-defined System objects at any time, regardless of whether the object is locked. For System objects predefined in the software, the object must be locked. In previous releases, you could tune System object properties only for a limited number of predefined System objects in generated code.

save and load for System objects

You can use the save method to save System objects to a MAT file. If the object is locked, its state information is saved, also. You can recall and use those saved objects with the load method.

You can also create your own save and load methods for a System object you create. To do so, use the saveObjectImpl and loadObjectImpl, respectively, in your class definition file.

Save and restore SimState not supported for System objects

The Save and Restore Simulation State as SimState option is no longer supported for any System object in a MATLAB Function block. This option was removed because it prevented parameter tunability for System objects, which is important in code generation.

Compatibility Considerations

If you need to save and restore simulation states, you may be able to use a corresponding Simulink block, instead of a System object.

Communications System Toolbox Functionality Being Changed or Removed

The following function, which was previously announced for removal and warned at run time, has been removed from the product.

  • seqgen.pn

The following functions will be removed in a future release.

FunctionalityWhat Happens When You Use This Functionality? Use This Instead Compatibility Considerations
commmeasure.ACPRWarnscomm.ACPRReplace all instances of commmeasure.ACPR with comm.ACPR.
commmeasure.EVMWarnscomm.EVMReplace all instances of commmeasure.EVM with comm.EVM.
commmeasure.MERWarnscomm.MERReplace all instances of commmeasure.MER with comm.MER.
fec.bchdecWarnscomm.BCHDecoderReplace all instances of fec.bchdec with comm.BCHDecoder.
fec.bchencWarnscomm.BCHEncoderReplace all instances of fec.bchenc with comm.BCHEncoder.
fec.ldpcdecWarnscomm.LDPCDecoderReplace all instances of fec.ldpcdec with comm.LDPCDecoder.
fec.ldpcencWarnscomm.LDPCEncoderReplace all instances of fec.ldpcenc with comm.LDPCEncoder.
fec.rsdecWarnscomm.RSDecoderReplace all instances of fec.rsdec with comm.RSDecoder.
fec.rsencWarnscomm.RSEncoderReplace all instances of fec.rsenc with comm.RSEncoder.

Update Legacy Code to use System objects

For help updating your legacy code so that it uses the new System objects, refer to the following sections.

 Map commmeasure.ACPR Properties and Methods to comm.ACPR

 Map commmeasure.EVM Properties and Methods to comm.EVM

 Map commmeasure.MER Properties and Methods to comm.MER

 Map fec.bchenc Properties to comm.BCHEncoder

 Map fec.bcdec Properties to comm.BCHDecoder

 Map fec.ldpcenc Properties to comm.LDPCEncoder

 Map fec.ldpcdec Properties to comm.LDPCDecoder

 Map fec.rsenc Properties to comm.RSEncoder

 Map fec.rsdec Properties to comm.RSDecoder

Frame-Based Processing

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. For more information, see Frame-Based Processing.

R2012a

New Features, Compatibility Considerations

MIMO Multipath Fading Channel System Objects

The Communications System Toolbox product now includes a Multiple Input Multiple Output (MIMO) Multipath Fading Channel System object, comm.MIMOChannel. Multipath MIMO fading channels allow for design of communication systems with multiple antenna elements at the transmitter and receiver. For more information, see the comm.MIMOChannel Help page.

The product also includes an LTE MIMO Multipath Fading Channel System object, comm.LTEMIMOChannel. This object allows for design of communication systems with multiple antenna elements at the transmitter and receiver using the 3GPP Long Term Evolution (LTE) standard. For more information, see the comm.LTEMIMOChannel Help page.

Multi-H Support for CPM Modulator and Demodulator Simulink Blocks and MATLAB System Objects

The CPM Modulator Baseband and CPM Demodulator Baseband blocks and System objects now support Multi-H CPM modulation. These enhancements allow you to perform research and development work for communication systems designed with the ARTM, JTRS, or MIL-STD-188–181C communications standards. For more information, see:

GPU System Objects

This release adds new GPU System objects, which use a graphics processing unit (GPU) to procure simulation results more quickly than a CPU. These new objects include:

MATLAB Compiler Support for GPU System Objects

In Release 2012a, you can use the MATLAB Compiler™ product with GPU System objects. With this capability, MATLAB Compiler software can generate standalone applications from MATLAB files, including files that contain GPU System objects.

Code Generation Support

The following System objects now support C code generation:

The following function now supports C code generation:

HDL Support For HDL CRC Generator Block

Release R2012a provides HDL code generation support for the new HDL CRC Generator block.

Enhancements for System Objects Defined by Users

This release contains enhancements for System objects defined by users.

Code Generation for System Objects

System objects defined by users now support C code generation. To generate code, you must have the MATLAB Coder™ product.

New System Object Option on File Menu

The File menu on the MATLAB desktop now includes a New > System object menu item. This option opens a System object class template, which you can use to define a System object class.

Variable-Size Input Support for System Objects

System objects that you define now support inputs that change size at runtime.

Data Type Support for System Objects

System objects that you define now support all MATLAB data types as inputs and outputs.

New Property Attribute to Define States

R2012a adds the new DiscreteState attribute for properties in your System object class definition file. Discrete states are values calculated during one step of an object's algorithm that are needed during future steps.

New Methods to Validate Properties and Get States from System Objects

The following methods have been added:

  • validateProperties – Checks that the System object is in a valid configuration. This applies only to objects that have a defined validatePropertiesImpl method

  • getDiscreteState – Returns a struct containing a System object's properties that have the DiscreteState attribute

matlab.system.System changed to matlab.System

The base System object class name has changed from matlab.system.System to matlab.System.

Compatibility Considerations

Compatibility Considerations

The previous matlab.system.System class will remain valid for existing System objects. When you define new System objects, your class file should inherit from the matlab.System class.

New and Enhanced Demos

The following demos are new or enhanced for this release:

Functionality Being Changed or Removed

The following functions will be removed in a future release.

FunctionalityWhat Happens When You Use This Functionality? Use This Instead Compatibility Considerations
rsdecofWarnscomm.RSDecoderReplace all instances of rsdecof with comm.RSDecoder.
rsencofWarnscomm.RSEncoderReplace all instances of rsencof with comm.RSEncoder.

The following functions, which were previously announced for removal in a future release, now warn at run time. You should not use these functions.

FunctionalityWhat Happens When You Use This Functionality? Use This Instead Compatibility Considerations
rcosfltWarnsfdesign.pulseshaping
rcosiirWarnsN/ADo not use.
rcosineWarnsfdesignpulseshaping
bchdecWarnscomm.BCHDecoder 
bchencWarnscomm.BCHEncoder 
rsdecWarnscomm.RSDecoder 
rsencWarnscomm.RSEncoder 
randintWarnsrandiUse randi to generate matrix of uniformly distributed random integers

Several functions, which were previously announced for removal in a future release and warned at run time, have been removed from the Communications System Toolbox product. To see the full list of these removed functions, expand the following section.

 Removed Functions

The following function, which was previously announced for removal in a future release, will remain in the Communications System Toolbox product.

Frame-Based Processing

Beginning in R2010b, MathWorks started to significantly change the handling of frame-based processing. In the future, frame sta tus 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. For more information, see Frame-Based Processing.

Inherited Option of the Input Processing Parameter Now Warns

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 have 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 in previous releases. 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 that is available to help you migrate your existing models from the old paradigm of frame-based processing to the new paradigm.

In this release your model will warn when the following conditions are all met for any block in your model:

  • The Input processing parameter is set to Inherited (this choice will be removed - see release notes)

  • The input signal is sample-based

  • The input signal is a vector, matrix, or N-dimensional array

To see a list of Communications System Toolbox blocks that contain the Input processing parameter, expand the following section.

 Blocks with Input Processing Parameter

Compatibility Considerations

Compatibility Considerations

To eliminate this warning, you must 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. It then 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). The option set will depend 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.

Inherited Option of the Rate Options Parameter Now Warns

Some Communications System Toolbox blocks support single-rate or multirate processing. After the transition to the new paradigm for handling frame-based processing, signals will no longer carry information about their frame status. Blocks that can perform both single-rate and multirate processing have a new parameter that allows you to specify the appropriate processing behavior. To prepare for this change, many blocks received a new Rate options parameter in previous releases. You can set this parameter to Enforce single-rate processing or Allow multirate processing. The third choice, Inherit from input (this choice will be removed - see release notes), is a temporary selection that is available to help you migrate your existing models from the old paradigm of frame-based processing to the new paradigm.

In this release your model will warn when the following conditions are met for any block in your model:

  • The Rate options parameter set to Inherit from input (this choice will be removed - see release notes)

  • The input signal is sample-based

  • The input signal is a scalar

To see a full list of Communications System Toolbox blocks that have a new Rate options parameter, expand the following section.

 Blocks with Rate Options Parameter

Compatibility Considerations

Compatibility Considerations

To eliminate this warning, you must upgrade your existing models using the slupdate function. The function detects all blocks that have Inherit from input (this choice will be removed - see release notes) selected for the Rate options parameter. It then 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 Rate options parameter to Enforce single-rate processing. If the bit is 0 (samples), the function sets the parameter to Allow multirate processing.

In a future release, the frame bit and the Inherit from input (this choice will be removed - see release notes) option will be removed. At that time, the Rate options parameter in models that have not been upgraded will automatically be set to either Enforce single-rate processing or Allow multirate processing. The option set will depend 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.

R2011b

New Features, Bug Fixes, Compatibility Considerations

New Demos

Turbo Codes

Communications System Toolbox now supports turbo codes. These error correction codes approach the Shannon limit, resulting in low error rates for transmission schemes with low signal-to-noise ratios. You can implement turbo codes using either MATLAB System objects or Simulink blocks:

USRP2 Migration

Support for the UDP-based USRP2 Transmitter and USRP2 Receiver blocks is being removed in release R2011b. New USRPTM blocks and System objects that work with USRPTM radios using the Universal Hardware DriverTM from Ettus ResearchTM are now available. These new blocks and objects support buffers with arbitrary frame size. If you have Communications System Toolbox, you can download and use these new blocks and System objects.

GPU System Objects

This release adds new GPU System objects, which use a graphics processing unit (GPU) to procure simulation results more quickly than a CPU. These new objects include:

  • comm.gpu.AWGNChannel

  • comm.gpu.BlockDeinterleaver

  • comm.gpu.BlockInterleaver

  • comm.gpu.PSKModulator

  • comm.gpu.ViterbiDecoder

Custom System Objects

You can now create custom System objects in MATLAB. This capability allows you to define your own System objects for time-based and data-driven algorithms, I/O, and visualizations. The System object API provides a set of implementation and service methods that you incorporate into your code to implement your algorithm. See Define New System Objects in the DSP System Toolbox™ documentation for more information.

Variable-Size Support

The following blocks now support variable-size input and/or output signals:

  • APP Decoder

  • AWGN Channel (Enter commvarsize at the MATLAB command line to access the library containing this implementation of the block)

  • CRC-N Generator

  • CRC-N Syndrome Detector

  • Error Rate Calculation

  • General CRC Generator

  • General CRC Syndrome Detector

  • OSTBC Combiner

  • OSTBC Encoder

  • Turbo Decoder (Enter commvarsize at the MATLAB command line to access the library containing this implementation of the block)

  • Turbo Encoder (Enter commvarsize at the MATLAB command line to access the library containing this implementation of the block)

The following blocks now support puncturing with variable-size signals:

  • Convolutional Encoder

  • Viterbi Decoder

The following System objects now support variable-size input and/or output signals:

  • comm.APPDecoder

  • comm.ConvolutionalEncoder

  • comm.CRCDetector

  • comm.CRCGenerator

  • comm.ErrorRate

  • comm.OSTBCCombiner

  • comm.OSTBCEncoder

  • comm.TurboDecoder

  • comm.TurboEncoder

  • comm.ViterbiDecoder

System Object Code Generation Support

The following System objects support code generation:

  • comm.BarkerCode

  • comm.DifferentialDecoder

  • comm.DifferentialEncoder

  • comm.DiscreteTimeVCO

  • comm.HadamardCode

  • comm.OVSFCode

  • comm.TurboEncoder

  • comm.TurboDecoder

  • comm.WalshCode

Delayed Reset for Viterbi Decoder

The Viterbi Decoder block and Viterbi Decoder System object now have a delayed reset option. The delay in the reset action allows the block to support HDL code generation. To generate HDL code, you must have an HDL Coder license.

For the Viterbi Decoder block:

  • Select Enable reset input port

  • Select Delay reset action to next time step. This parameter only appears when you set the Operation mode parameter to Continuous.

The Viterbi Decoder block resets its internal state after decoding the incoming data.

For the comm.ViterbiDecoder System object

  • Set ResetInputPort to true

  • Set DelayedResetAction to true. This property only appears when you set the ResetInputPort property to true.

  • Set TerminationMethod to Continuous

The Viterbi Decoder System object resets its internal state after decoding the incoming data.

System Objects FullPrecisionOverride Property Added

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 inputs.

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.

    Note:   The CoefficientDataType property is not controlled by FullPrecisionOverride

This change affects the following System objects:

Compatibility Considerations

Compatibility Consideration

All these System objects have their new FullPrecisionOverride property set to the default, true. If you had set any fixed-point properties to nondefault 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.

APP Decoder System Object Parameter Change

For the APP Decoder System object, the Algorithm property replaces the MetricMethod property. At this time, existing customer code continues to work; however, a warning prompts you to update the code.

Compatibility Considerations

Compatibility Consideration

If you have any existing System object code that uses the MetricMethod property, you should use the sysobjupdate function to update your code. For more information, type help sysobjupdate at the MATLAB command line.

System Object DataType and CustomDataType Properties Changes

When you set a System object, fixed-point <xxx>DataType property to ‘Custom', it activates a dependent Custom<xxx>DataType property. If you set that dependent Custom<xxx>DataType property before setting its <xxx>DataType property, a warning message displays. <xxx> differs for each object.

Compatibility Considerations

Compatibility Considerations

Previously, setting the dependent Custom<xxx>DataType property would automatically change its <xxx>DataType property to ‘Custom'. If you have code that sets the dependent property first, avoid warnings by updating your code. Set the <xxx>DataType property to ‘Custom' before setting its Custom<xxx>DataType property.

    Note:   If you have a Custom<xxx>DataType in your code, but do not explicitly update your code to change <xxx>DataType to ‘Custom', you may see different numerical output.

Conversion of System Object Error and Warning Message Identifiers

For R2011b, error and warning message identifiers for System objects have changed in Communications System Toolbox software.

Compatibility Considerations

Compatibility Considerations

If you have scripts or functions that use message identifiers that changed, you must update the code to use the new identifiers. Typically, message identifiers are used to turn off specific warning messages. You can also use them in code that uses a try/catch statement and performs an action based on a specific error identifier.

For example, the MATLAB:system:System:inputSpecsChangedWarning identifier has changed to MATLAB:system:inputSpecsChangedWarning . If your code checks for MATLAB:system:System:inputSpecsChangedWarning, you must update it to check for MATLAB:system:inputSpecsChangedWarning instead.

To determine the identifier for a warning, run the following command just after you see the warning:

[MSG,MSGID] = lastwarn;

This command saves the message identifier to the variable MSGID.

To determine the identifier for an error, run the following command just after you see the error:

exception = MException.last;
MSGID = exception.identifier;

Warning messages indicate a potential issue with your code. While you can turn off a warning, a suggested alternative is to change your code so it runs without warnings.

Frame-Based Processing

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. For more information, see Frame-Based Processing.

R2011a

New Features, Bug Fixes, Compatibility Considerations

Product Restructuring

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.

LDPC Encoder and Decoder System Objects

This release adds new comm.LDPCEncoder and comm.LDPCDecoder System objects. These new System objects provide simulation of low-density, parity-check codes.

LDPC GPU Decoder System Object

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.

Variable-Size Support

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

Algorithm Improvements for CRC Blocks

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.

MATLAB Compiler Support for System Objects

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:

'Internal rule' System Object Property Values Changed to 'Full precision'

To clarify the value of many DataType properties, the 'Internal rule' option has been changed to 'Full precision'.

Compatibility Considerations

Compatibility Consideration

The objects allow you to enter either 'Internal rule' or 'Full precision'. If you enter 'Internal rule', that option is stored as 'Full precision'.

System Object Code Generation Support

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

LDPC Decoder Block Warnings

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.

Phase/Frequency Offset Block and System Object Change

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.

Derepeat Block Changes

The Derepeat block now contains the Input processing and Rate options parameters. See Frame-Based Processing for more information.

Version 2, 2.5, and 3.0 Obsolete Blocks Removed

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

Compatibility Considerations

Compatibility Considerations

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.

System Objects Input and Property Warnings Changed to Errors

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

Compatibility Considerations

Compatibility Consideration

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.

Frame-Based Processing

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.

General Product-Wide Changes

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

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.

Blocks with a New Input Processing Parameter

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.

For a list of blocks that received a new Input processing parameter, expand the following list.

 Blocks with New Input Processing Parameter

Compatibility Considerations

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.

AWGN Channel Block Changes

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

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.

Multirate Processing Parameter Changes

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

Sample-Based Row Vector Processing Changes

The following blocks do not process sample-based row vectors:

Compatibility Considerations

Compatibility Considerations

Using existing models that contain these blocks to process sample-based row vectors generates an error message.

CMA Equalizer Changes

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.

Differential Encoder Changes

The Differential Encoder block supports scalar-valued and column vector input signals. It does not support frame-based or sample-based row vectors.

Find Delay and Align Signal Block Changes

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:

Compatibility Summary

Was this topic helpful?