Note: This page has been translated by MathWorks. Please click here

To view all translated materals including this page, select Japan from the country navigator on the bottom of this page.

To view all translated materals including this page, select Japan from the country navigator on the bottom of this page.

Some models require you to know how long it takes for data in one portion of a model to influence a signal in another portion of a model. For example, when configuring an error rate calculator, you must indicate the delay between the transmitter and the receiver. If you miscalculate the delay, the error rate calculator processes mismatched pairs of data and consequently returns a meaningless result.

This section illustrates the computation of delays in multirate models and in models where the total delay in a sequence of blocks comprises multiple delays from individual blocks. This section also indicates how to use the Find Delay and Align Signals blocks to help deal with delays in a model.

Other parts of this documentation set also discuss delays. For information about dealing with delays or about delays in specific types of blocks, see

Find Delay block reference page

Align Signals block reference page

Viterbi Decoder block reference page

Derepeat block reference page

For discussions of delays in simpler examples than the ones in this section, see

While some blocks can determine their current output value using only the current input value, other blocks need input values from multiple time steps to compute the current output value. In the latter situation, the block incurs a delay. An example of this case is when the Derepeat block must average five samples from a scalar signal. The block must delay computing the average until it has received all five samples.

In general, delays in your model might come from various sources:

Digital demodulators

Convolutional interleavers or deinterleavers

Equalizers

Viterbi Decoder block

Buffering, downsampling, derepeating, and similar signal operations

Explicit delay blocks, such as Delay and Variable Integer Delay

Filters

The following discussions include some of these sources of delay.

This section examines the 256 Channel
asymmetric digital subscriber line (ADSL) example model and
aims to compute the correct **Receive delay** parameter
value in one of the Error Rate Calculation blocks in the model. The
model includes delays from convolutional interleaving and an explicit
delay block. To open the ADSL example model, enter `commadsl`

in the MATLAB
Command Window.

In the ADSL example, data follows one of two parallel paths,
one with a nonzero delay and the other with a delay of zero. One path
includes a convolutional interleaver and deinterleaver, while the
other does not. Near the end of each path is an Error Rate Calculation
block, whose **Receive delay** parameter must reflect
the delay of the given path. The rest of the discussion makes an observation
about frame
periods in the model and then considers the path for interleaved data.

Before searching for individual delays, first observe that most
signal lines throughout the model share the same frame period. To
see this, select **Display** > **Sample
Time**. This option colors blocks and signals according
to their frame periods (or sample periods, in the case of sample-based
signals). All signal lines at the top level of the model are the same
color, which means that they share the same frame period. As a consequence,
frames are a convenient unit for measuring delays in the blocks that
process these signals. In the computation of the cumulative delay
along a path, the weighted average (of numbers of frames, weighted
by each frame's period) reduces to a sum.

In the transmitter portion of the model, the interleaved path
is the lower branch, shown in yellow below. Similarly, the interleaved
path in the receiver portion of the model is the lower branch. Near
the end of the interleaved path is an Error Rate Calculation block
that computes the value labeled `Interleaved BER`

.

The following table summarizes the delays in the path for noninterleaved data. Subsequent paragraphs explain the delays in more detail and explain why the total delay relative to the Error Rate Calculation block is one frame, or 776 samples.

Block | Delay, in Output Samples from Individual Block | Delay, in Frames | Delay, in Input Samples to Error Rate Calculation Block |
---|---|---|---|

Convolutional Interleaver and Convolutional Deinterleaver pair | 40 | 1 (combined) | 776 (combined) |

Delay | 800 | ||

Total | N/A | 1 | 776 |

**Interleaving. **Unlike the noninterleaved path, the interleaved path contains
a Convolutional Interleaver block in the transmitter and a Convolutional
Deinterleaver block in the receiver. The delay of the interleaver/deinterleaver
pair is the product of the **Rows of shift registers** parameter,
the **Register length step** parameter, and one less
than the **Rows of shift registers** parameter. In
this case, the delay of the interleaver/deinterleaver pair turns out
to be 5*2*4 = 40 samples.

**Delay Block. **The receiver portion of the interleaved path also contains a
Delay block. This block explicitly causes a delay of 800 samples having
the same sample time as the 40 samples of delay from the interleaver/deinterleaver
pair. Therefore, the total delay from interleaving, deinterleaving,
and the explicit delay is 840 samples. These 840 samples make up one
frame of data leaving the Delay block.

**Summing the Delays. **No other blocks in the interleaved path of the example cause
any delays. Adding the delays from the interleaver/deinterleaver pair
and the Delay block indicates that the total delay in the interleaved
path is one frame.

**Total Delay Relative to Error Rate Calculation Block. **The Error Rate Calculation block that computes the value labeled ```
Interleaved
BER
```

requires a **Receive delay** parameter
value that is equivalent to one frame. The **Receive delay** parameter
is measured in samples and each input frame to the Error Rate Calculation
block contains 776 samples. Also, the frame rate at the outports of
all delay-causing blocks in the interleaved path equals the frame
rate at the input of the Error Rate Calculation block. Therefore,
the correct value for the **Receive delay** parameter
is `776`

samples.

This section discusses a punctured coding model that includes
delays from decoding, downsampling, and filtering. Two Error Rate
Calculation blocks in the model work correctly if and only if their **Receive
delay** parameters accurately reflect the delays in the model.
To open the model, enter `doc_punct`

in
the MATLAB Command Window.

Before searching for individual delays, select **Display**>**Sample
Time**>**All**. Only the rightmost
portion of the model differs in color from the rest of the model.
This means that all signals and blocks in the model except those in
the rightmost edge share the same frame period. Consequently, frames
at this predominant frame rate are a convenient unit for measuring
delays in the blocks that process these signals. In the computation
of the cumulative delay along a path, the weighted average (of numbers
of frames, weighted by each frame's period) reduces to a sum.

The yellow blocks represent multirate systems, while the AWGN Channel block runs at a higher frame rate than all the other blocks in the model.

The block labeled Inner Error Rate, located near the center
of the model, is a copy of the Error Rate Calculation block from the
Comm Sinks library. It computes the bit error rate for the portion
of the model that excludes the punctured convolutional code. In the
portion of the model between this block's two input signals, delays
come from the Tx Filter and the Rx Filter. This section explains why
the Inner Error Rate block’s **Receive delay** parameter
is the total delay value
of `16`

.

**Tx Filter Block. **The block labeled Tx Filter is a copy of the Raised Cosine Transmit
Filter block. It interpolates the input signal by a factor of `8`

and
applies a square-root raised cosine filter. The value of the block’s **Filter
span in symbols** parameter is 6, which means its group delay
is 3 symbols. Since this block’s sample rate increases from
input port to output port, it must output an initial frame of zeros
at the beginning of the simulation. Since its input frame size is
2, the block’s total delay is 2 + 3 = 5 symbols. This corresponds
to 5 samples at the block’s input port.

**Rx Filter Block. **The block labeled Rx Filter is a copy of the Raised Cosine Receive
Filter block. It decimates its input signal by a factor of 8 and applies
another square-root raised cosine filter. The value of this block’s **Filter
span in symbols** parameter is 6, which means its group delay
is 3 symbols. At the block’s output, the 3 symbols correspond
to 3 samples.

**QPSK Demodulator Block. **The block labeled QPSK Demodulator Baseband receives complex
QPSK signals and outputs 2 bits for each complex input. This conversion
to output bits doubles the cumulative delay at the input of the block.

**Summing the Delays. **No other blocks in the portion of the model between the Inner
Error Rate block's two input signals cause any delays. The total delay
is then `(2 + 3 + 3) * 2 = 16`

samples. This value
can be used as the **Receive Delay** parameter in
the Inner Error Rate block.

The block labeled Outer Error Rate, located at the left of the
model, is a copy of the Error Rate Calculation block from the Comm
Sinks library. It computes the bit error rate for the entire model,
including the punctured convolutional code. Delays come from the Tx
Filter, Rx Filter, and Viterbi Decoder blocks. This section explains
why the Outer Error Rate block's **Receive delay** parameter
is the total delay value
of `108`

.

**Filter and Downsample Blocks. **The Tx Filter, Rx Filter, and Downsample blocks have a combined
delay of 16 samples. For details, see Inner Error Rate Block.

**Viterbi Decoder Block. ** Because the Viterbi Decoder block decodes a rate `3/4`

punctured
code, it actually reduces the delay seen at its input. This reduction
is given as `16 * 3/4 = 12`

samples.

The Viterbi Decoder block decodes the convolutional code, and
the algorithm’s use of a traceback path causes a delay. The
block processes a frame-based signal and has **Operation mode** set
to `Continuous`

. Therefore, the delay, measured
in output samples, is equal to the **Traceback depth** parameter
value of `96`

. (The delay amount is stated on the
reference page for the Viterbi Decoder block.)
Because the output of the Viterbi Decoder block is precisely one of
the inputs to the Outer Error Rate block, it is easier to consider
the delay to be 96 samples rather than to convert it to an equivalent
number of frames.

**Total Delay Relative to Outer Error Rate Block. **The Outer Error Rate block requires a **Receive delay** parameter
value that is the sum of all delays in the system. This total delay
is `12 + 96 = 108`

samples.

The preceding discussions explained why certain Error Rate Calculation
blocks in the models had specific **Receive delay** parameter
values. You could have arrived at those numbers independently by using
the Find Delay block, or you could have avoided needing to know those
numbers by using the Align Signals block. This section explains both
techniques using the ADSL example model, `commadsl`

,
as an example. Applying the techniques to the punctured convolutional
coding example, discussed in Punctured Coding Model, would
be similar.

Recall from Path for Interleaved Data that the delay in the path for interleaved data is 776 samples. To have the Find Delay block compute that value for you, use this procedure:

Insert a Find Delay block and a Display block in the model near the Error Rate Calculation block that computes the value labeled

`Interleaved BER`

.Connect the blocks as shown below.

Set the Find Delay block's

**Correlation window length**parameter to a value substantially larger than 776, such as 2000.### Note

You must use a sufficiently large correlation window length or else the values produced by the Find Delay block do not stabilize at a correct value.

Run the simulation.

The new Display block now shows the value 776, as expected.

To use the Error Rate Calculation block to compute the value
labeled `Interleaved BER`

*without* having
to set the **Receive delay** parameter to a nonzero
value, you can use the Align Signals block to automatically align
the transmitted and received signals before the Error Rate Calculation
block performs its computations. Use this procedure:

Insert an Align Signals block and a Display block in the model near the Error Rate Calculation block that computes the value labeled

`Interleaved BER`

.Connect the blocks as shown below.

Set the Align Signals block's

**Correlation window length**parameter to a value substantially larger than 776, such as 2000.### Note

You must use a sufficiently large correlation window length or else the Align Signals block cannot find the correct amount by which to delay one of the signals. If the

`delay`

output from the Align Signals block does not stabilize at a constant value, the correlation window length is probably too small.Set the Error Rate Calculation block's

**Receive delay**parameter to`0`

. You might also want to set the block's**Computation delay**parameter to a nonzero value to account for the possibility that the Align Signals block takes a nonzero amount of time to stabilize on the correct amount by which to delay one of the signals.Run the simulation.

The new Display block now shows the value 776. Also, the Align
Signals block delays one signal relative to the other so that the
signals are aligned. The Error Rate Calculation block therefore processes
two signals that are properly aligned with each other and does not
need to use a nonzero **Receive delay** parameter
to attempt any further alignment.

Examining the delay output signal from the Align Signals block,
using the Display block as in the figure above, is important because
if the delay output signal does not stabilize at a constant value,
the signals are not truly aligned and the error rate is not reliable.
In this case, the Align Signals block's **Correlation window
length** parameter is probably too small.

**Delays and Alignment Problems. **Some models require you not only to compute delays but to manipulate
them. For example, if a model incurs a delay between a block encoder
and its corresponding decoder, the decoder might misinterpret the
boundaries between the codewords that it receives and, consequently,
return meaningless results. More generally, such a situation can arise
when the path between paired components of a block-oriented operation
(such as interleaving, block coding, or bit-to-integer conversions)
includes a delay-causing operation (such as those listed in Sources of Delays).

To avoid this problem, you can insert an additional delay of an appropriate amount between the encoder and decoder. If the model also computes an error rate, then the additional delay affects that process, as described in Delays. This section uses examples to illustrate the purpose, methods, and implications of manipulating delays in a variety of circumstances.

This section illustrates the sensitivity of block-oriented operations
to delays, using a small model that aims to capture the essence of
the problem in a simple form. Open the model by entering `doc_alignment`

in
the MATLAB^{®} Command Window. Then run the simulation so that the
Display blocks show relevant values.

In this model, two coding blocks create and decode a block code. Two copies of the Delay block create a delay between the encoder and decoder. The two Delay blocks have different purposes in this illustrative model:

The Inherent Delay block represents any delay-causing blocks that might occur in a model between the encoder and decoder. See Sources of Delays for a list of possibilities that might occur in a more realistic model.

The Added Delay block is an explicit delay that you insert to produce an appropriate amount of total delay between the encoder and decoder. For example, the

`commadsl`

model contains a Delay block that serves this purpose.

By default, the **Delay** parameters in the
Inherent Delay and Added Delay blocks are set to `1`

and `0`

,
respectively. This represents the situation in which some operation
causes a one-bit delay between the encoder and decoder, but you have
not yet tried to compensate for it. The total delay between the encoder
and decoder is one bit. You can see from the blocks labeled Word and
Delayed Word that the codeword that leaves the encoder is shifted
downward by one bit by the time it enters the decoder. The decoder
receives a signal in which the boundary of the codeword is at the
second bit in the frame, instead of coinciding with the beginning
of the frame. That is, the codewords and the frames that hold them
are not aligned with each other.

This nonalignment is problematic because the Hamming Decoder block assumes that each frame begins a new codeword. As a result, it tries to decode a word that consists of the last bit of one output frame from the encoder followed by the first six bits of the next output frame from the encoder. You can see from the Error Rate Display block that the error rate from this decoding operation is close to 1/2. That is, the decoder rarely recovers the original message correctly.

To use an analogy, suppose someone corrupts a paragraph of prose by moving each period symbol from the end of the sentence to the end of the first word of the next sentence. If you try to read such a paragraph while assuming that a new sentence begins after a period, you misunderstand the start and end of each sentence. As a result, you might fail to understand the meaning of the paragraph.

To see how delays of different amounts affect the decoder's
performance, vary the values of the **Delay** parameter
in the Added Delay block and the **Receive delay** parameter
in the Error Rate Calculation block and then run the simulation again.
Many combinations of parameter values produce error rates that are
close to 1/2. Furthermore, if you examine the transmitted and received
data by entering

[tx rx]

in the MATLAB Command Window, you might not detect any correlation between the transmitted and received data.

Some combinations of parameter values produce error rates of zero because the delays are appropriate for the system. For example:

In the Added Delay block, set

**Delay**to`6`

.In the Error Rate Calculation block, set

**Receive delay**to`4`

.Run the simulation.

Enter

`[tx rx]`

in the MATLAB Command Window.

The top number in the Error Rate Display block shows that the
error rate is zero. The decoder recovered each transmitted message
correctly. However, the Word and Displayed Word blocks do not show
matching values. It is not immediately clear how the encoder's output
and the decoder's input are related to each other. To clarify the
matter, examine the output in the MATLAB Command Window. The sequence
along the first column (`tx`

) appears in the second
column (`rx`

) four rows later. To confirm this, enter

isequal(tx(1:end-4),rx(5:end))

in the MATLAB Command Window and observe that the result is `1`

(true).
This last command tests whether the first column matches a shifted
version of the second column. Shifting the MATLAB vector `rx`

by
four rows corresponds to the Error Rate Calculation block's behavior
when its **Receive delay** parameter is set to `4`

.

To summarize, these special values of the **Delay** and **Receive
delay** parameters work for these reasons:

Combined, the Inherent Delay and Added Delay blocks delay the encoded signal by a full codeword rather than by a partial codeword. Thus the decoder is correct in its assumption that a codeword boundary falls at the beginning of an input frame and decodes the words correctly. However, the delay in the encoded signal causes each recovered message to appear one word later, that is, four bits later.

The Error Rate Calculation block compensates for the one-word delay in the system by comparing each word of the transmitted signal with the data four bits later in the received signal. In this way, it correctly concludes that the decoder's error rate is zero.

### Note

These are not the only parameter values that produce error rates of zero. Because the code in this model is a (7, 4) block code and the inherent delay value is 1, you can set the

**Delay**and**Receive delay**parameters to 7k-1 and 4k, respectively, for any positive integer k. It is important that the sum of the inherent delay (1) and the added delay (7k-1) is a multiple of the codeword length (7).

**Aligning Words of a Block Code. **The ADSL example, discussed in ADSL Example Model, illustrates the
need to manipulate the delay in a model so that each frame of data
that enters a block decoder has a codeword boundary at the beginning
of the frame. The need arises because the path between a block encoder
and block decoder includes a delay-causing convolutional interleaving
operation. This section explains why the model uses a Delay block
to manipulate the delay between the convolutional deinterleaver and
the block decoder, and why the Delay block is configured as it is.
To open the ADSL example model, enter `commadsl`

in
the MATLAB Command Window.

In the ADSL example, the Convolutional Interleaver and Convolutional Deinterleaver blocks appear after the Scrambler & FEC subsystems but before the Descrambler & FEC subsystems. These two subsystems contain blocks that perform Reed-Solomon coding, and the coding blocks expect each frame of input data to start on a new word rather than in the middle of a word.

As discussed in Path for Interleaved Data,
the delay of the interleaver/deinterleaver pair is 40 samples. However,
the input to the Descrambler & FEC subsystem is a frame of size
840, and 40 is not a multiple of 840. Consequently, the signal that
exits the Convolutional Deinterleaver block is a frame whose first
entry does *not* represent the beginning of a new
codeword. As described in Observing the Problem, this
misalignment, between codewords and the frames that contain them,
prevents the decoder from decoding correctly.

The ADSL example solves the problem by moving the word boundary from the 41st sample of the 840-sample frame to the first sample of a successive frame. Moving the word boundary is equivalent to delaying the signal. To this end, the example contains a Delay block between the Convolutional Deinterleaver block and the Descrambler & FEC subsystem.

The **Delay** parameter in the Delay block
is `800`

because that is the minimum number of samples
required to shift the 41st sample of one 840-sample frame to the first
sample of the next 840-sample frame. In other words, the sum of the
inherent 40-sample delay (from the interleaving/deinterleaving process)
and the artificial 800-sample delay is a full frame of data, not a
partial frame.

This 800-sample delay has implications for other parts of the
model, specifically, the **Receive delay** parameter
in one of the Error Rate Calculation blocks. For details about how
the delay influences the value of that parameter, see Path for Interleaved Data.

The preceding discussion explained why an 800-sample delay is necessary to correct the misalignment between codewords and the frames that contain them. Knowing that the Descrambler & FEC subsystem requires frame boundaries to occur on word boundaries, you could have arrived at the number 800 independently by using the Find Delay block. Use this procedure:

Insert a Find Delay block and a Display block in the model.

Create a branch line that connects the input of the Convolutional Interleaver block to the

`sRef`

input of the Find Delay block.Create another branch line that connects the output of the Convolutional Deinterleaver block to the

`sDel`

input of the Find Delay block.Connect the

`delay`

output of the Find Delay block to the new Display block. The modified part of the model now looks like the following image (which also shows drop shadows on key blocks to emphasize the modifications).Show the dimensions of each signal in the model by selecting enabling

**Display**>**Signals & Ports**>**Signal Dimensions**.Run the simulation.

The new Display block now shows the value 40. Also, the display of signal dimensions shows that the output from the Convolutional Deinterleaver block is a frame of length 840. These results indicate that the sequence of blocks between the Convolutional Interleaver and Convolutional Deinterleaver, inclusive, delays an 840-sample frame by 40 samples. An additional delay of 800 samples brings the total delay to 840. Because the total delay is now a multiple of the frame length, the delayed deinterleaved data can be decoded.

**Aligning Words for Interleaving. **This section describes an example that manipulates the delay
before a deinterleaver, because the path between the interleaver and
deinterleaver includes a delay from demodulation. To open the model,
enter `doc_gmskint`

in
the MATLAB Command Window.

The model includes block coding, helical interleaving, and GMSK modulation. The table below summarizes the individual block delays in the model.

Block | Delay, in Output Samples from Individual Block | Reference |
---|---|---|

GMSK Demodulator Baseband | 16 | Delays in Digital Modulation |

Helical Deinterleaver | 42 | Delays of Convolutional Interleavers |

Delay | 5 | Delay reference page |

The demodulation process in this model causes a delay between the interleaver and deinterleaver. Because the deinterleaver expects each frame of input data to start on a new word, it is important to ensure that the total delay between the interleaver and deinterleaver includes one or more full frames but no partial frames.

The delay of the demodulator is 16 output samples. However,
the input to the Helical Deinterleaver block is a frame of size 21,
and 16 is not a multiple of 21. Consequently, the signal that exits
the GMSK Demodulator Baseband block is a frame whose first entry does *not* represent
the beginning of a new word. As described in Observing the Problem, this
misalignment between words and the frames that contain them hinders
the deinterleaver.

The model moves the word boundary from the 17th sample of the
21-sample frame to the first sample of the next frame. Moving the
word boundary is equivalent to delaying the signal by five samples.
The Delay block between the GMSK Demodulator Baseband block and the
Helical Deinterleaver block accomplishes such a delay. The Delay block
has its **Delay** parameter set to `5`

.

Combining the effects of the demodulator and the Delay block, the total delay between the interleaver and deinterleaver is a full 21-sample frame of data, not a partial frame.

The interleaver and deinterleaver cause a combined delay of 42 samples measured at the output from the Helical Deinterleaver block. Because the delayed output from the deinterleaver goes next to a Reed-Solomon decoder, and because the decoder expects each frame of input data to start on a new word, it is important to ensure that the total delay between the encoder and decoder includes one or more full frames but no partial frames.

In this case, the 42-sample delay is exactly two frames. Therefore, it is not necessary to insert a Delay block between the Helical Deinterleaver block and the Binary-Output RS Decoder block.

The model contains two Error Rate Calculation blocks, labeled
Channel Error Rate and System Error Rate. Each of these blocks has
a **Receive delay** parameter that must reflect the
delay of the path between the block's `Tx`

and `Rx`

signals.
The following table explains the **Receive delay** values
in the two blocks.

Block | Receive Delay Value | Reason |
---|---|---|

Channel Error Rate | `16` | Delay of GMSK Demodulator Baseband block, in samples |

System Error Rate | `15*3` | Three fifteen-sample frames: one frame from the GMSK Demodulator Baseband and Delay blocks, and two frames from the interleaver/deinterleaver pair |

**Aligning Words of a Concatenated Code. **This section describes an example that manipulates the delay
between the two portions of a concatenated code decoder, because the
first portion includes a delay from Viterbi decoding while the second
portion expects frame boundaries to coincide with word boundaries.
To open the model, enter `doc_concat`

in
the MATLAB Command Window. It uses the block and convolutional codes
from the `commdvbt`

example,
but simplifies the overall design a great deal.

The model includes a shortened block code and a punctured convolutional code. All signals and blocks in the model share the same frame period. The following table summarizes the individual block delays in the model.

Block | Delay, in Output Samples from Individual Block |
---|---|

Viterbi Decoder | 136 |

Delay | 1496 (that is, 1632 - 136) |

The Viterbi decoding process in this model causes a delay between the Integer to Bit Converter block and the Bit to Integer Converter block. Because the latter block expects each frame of input data to start on a new 8-bit word, it is important to ensure that the total delay between the two converter blocks includes one or more full frames but no partial frames.

The delay of the Viterbi Decoder block is 136 output samples.
However, the input to the Bit to Integer Converter block is a frame
of size 1632. Consequently, the signal that exits the Viterbi Decoder
block is a frame whose first entry does *not* represent
the beginning of a new word. As described in Observing the Problem, this
misalignment between words and the frames that contain them hinders
the converter block.

The outer decoder in this model (Integer-Output RS Decoder) also expects each frame of input data to start on a new codeword. Therefore, the misalignment issue in this model affects many concatenated code designs, not just those that convert between binary-valued and integer-valued signals.

The model moves the word boundary from the 137th sample of the
1632-sample frame to the first sample of the next frame. Moving the
word boundary is equivalent to delaying the signal by 1632-136 samples.
The Delay block between the Viterbi Decoder block and the Bit to Integer
Converter block accomplishes such a delay. The Delay block has its **Delay** parameter
set to `1496`

.

Combining the effects of the Viterbi Decoder block and the Delay block, the total delay between the interleaver and deinterleaver is a full 1632-sample frame of data, not a partial frame.

The model contains two Error Rate Calculation blocks, labeled
Inner Error Rate and Outer Error Rate. Each of these blocks has a **Receive
delay** parameter that must reflect the delay of the path
between the block's `Tx`

and `Rx`

signals.
The table below explains the **Receive delay** values
in the two blocks.

Block | Receive Delay Value | Reason |
---|---|---|

Inner Error Rate | `136` | Delay of Viterbi Decoder block, in samples |

Outer Error Rate | `1504 (188*8 bits)` | One 188-sample frame, from the combination of the inherent delay of the Viterbi Decoder block and the added delay of the Delay block |

**Aligning Words for
Nonlinear Digital Demodulation. **This example manipulates delay in order obtain the correct symbol
synchronization of a signal so that symbol boundaries correctly align
before demodulation occurs.

To open this
model, type `doc_nonlinear_digital_demod`

at
the MATLAB command line.

This model includes a CPFSK modulation scheme and pulse shaping filter. For the demodulation to work properly, the input signal to the CPFSK demodulator block must have the correct alignment. Various blocks in this model introduce processing delays. Because of these delays, the input signal to the CPFSK demodulator block is not in the correct alignment.

Both the Raised Cosine Transmit and Receive Filter blocks introduce a delay. The delay is defined as: $$GroupDelay\cdot Ts$$

where *Ts* represents the input sample time
of the Raised Cosine Transmit Filter block.

The input sample time of the Raised Cosine Transmit Filter block equals the output sample time of the Raised Cosine Receive Filter block. Therefore, the total delay at the output of the Raised Cosine Receive Filter is:

$$2\cdot GroupDelay\cdot Ts$$

or $$8\cdot Ts$$

as GroupDelay = 4

The CPFSK demodulator block receives this delayed signal, and
then it processes each collection of 8 samples per symbol to compute
1 output symbol. You must ensure that the CPFSK demodulator receives
input samples in the correct collection of samples. For binary CPFSK
with a **Modulation index** of 1/2, the demodulator
input must align along even numbers of symbols. Note that this requirement
applies only to binary CPFSK with a modulation index of 1/2. Other
CPM schemes with different M-ary values and modulation indexes have
different requirements.

To ensure that the CPFSK demodulator in this model receives the correct collection of input samples with the correct alignment, introduce a delay of 8 samples (in this example, $$8\cdot Ts$$). The total delay at the input of the CPFSK demodulator is $$16\cdot Ts$$, which equates to two symbol delays (2.T, where T is the symbol period).

In sample-based mode, the CPFSK demodulator introduces a delay
of **Traceback length** + 1 samples at its output.
In this example, **Traceback length** equals 16.
Therefore, the total **Receiver delay** in the Error
rate calculation block equals 17+2 or 19. For more information, see Delays in Digital Modulation in
the Communications
System Toolbox™ *User's Guide*.

Was this topic helpful?