Experiences with Simulink’s Communications Toolbox

April 4th, 2008

Simulink is a companion to Matlab which purports to be a time-flow simulation package. This post is going to get quite technical, so if you’re not into either communications system design or Simulink in general, look away now.

I’ve used Simulink before, in my third year at York, but that was following a well-structured lab script where the lecturer had partially set up the models in advance. This time I’ve been doing a course (I’m obliged to do one of Leicester’s engineering MSc modules in my first year) simulating communications systems in Simulink, and the lab script is much vaguer. I’ve spent a lot of time banging my head against a brick wall in Simulink, and here are some important gotchas that might save other people going through the same level of auto-cranial damage.


Firstly, Simulink is not a pure time-flow simulator. It likes to pretend that it is, but it isn’t. You can’t just consider a Simulink model as a flow of bits through a system, because you come unstuck very quickly.

In theory, Simulink offers you a sample-based mode of operation, but a number of the blocks in the Comms Toolbox don’t support it. Instead, you have to operate in a frame-based mode, even if you set the frame size to 1. Remembering that Simulink is built on top of Matlab, a “frame” is a Matlab vector containing one or more samples in sequence. Blocks that would in real life have different data rates at their inputs and outputs instead operate by changing the frame size. This saves a lot of computational complexity, but puts the onus back on the user to sort out the frame structure and insert buffers wherever they’re needed. Any idea that building a system in Simulink is just a straightforward matter of dragging a few blocks and wiring them up quickly disappears!

To give an example, the Hamming Coder block implements by default a (7,4) Hamming code, which means it takes in four data bits and outputs a seven bit codeword. So if your data is coming from, say, a Bernouilli Binary Generator, one bit at a time, you need to insert a Buffer block before the Hamming Coder, with the buffer size set to four bits. The buffer takes in single bit frames and outputs a four bit frame at one quarter of the frame rate. So far, so good. So now at the output of your Hamming Coder you have a frame size of seven bits, at an even slower frame rate. And you’re going to feed these bits into, say, a 16QAM modulator. Now 16QAM has four bits per symbol, so you need to put four bits at a time into the Rectangular QAM Modulator block. So, you need to buffer again. But what frame size should you use? Simulink’s Buffer block isn’t very smart. If you set the output frame size to four bits, it just throws away the three bits it has over! Instead, you have to realise that the Rectangular QAM Modulator will accept a frame size that’s a multiple of four. Four times seven is 28, so you buffer up 28 samples and feed those into the Modulator, which then produces you an output frame of 7 samples, where each sample represents a modulated symbol. This caused me a lot of hassle, because it isn’t clear in the documentation that this is the way it has to be.

Delaying tactics

Okay, so having done this, you now feed your modulated samples through a digital filter that represents the channel. Marvellous. Except that the filter introduces a three sample delay. The Error Rate Calcuation block has to be told the end-to-end delay in order to calcuate the BER correctly (otherwise it isn’t comparing like with like and the BER tends to around 0.5!). But between your filter and the Error Rate Calculation you have to demodulate and decode the data. So, what happens? Well, you pass your seven sample frame through the 16QAM demodulator and produce a 28 sample frame. This 28 sample frame goes to the Hamming Decoder, and produces a four sample frame at the output. But what happens to the three sample delay? Well, three samples before the demodulator becomes twelve samples after the demodulator, because the demod produces four output bits for every input sample. But what happens at the Hamming Decoder? It produces four output bits for seven input bits. So our 12 sample delay becomes 12 * (4/7) = 6.86 samples. Oh dear. We have a non-integer delay! So we now have to think back a bit and introduce an extra delay block after the filter, such that the delay at the input to the Hamming Decoder is a multiple of four-sevenths! If we pad up with four extra samples after the filter, that brings us to seven samples of delay before the demod, making 28 samples delay at the input to the Hamming Decoder, which will in turn produce a sixteen sample delay at the output of the Hamming Decoder (16 = 28 * (4/7)) and that we can then put into the Error Rate Calculation and it all works.

As long as you remember that Simulink hates non-integer anything, you’ll be all right.

Modulation order in QAM

The Rectangular QAM Modulator block has rather unhelpful default options which wasted a considerable amount of time. If you drag one into your model, you’ll find that not only has it defaulted to binary coded rather than Gray coded (the latter performs much better, and I can’t think of a reason why you would ever want to use a binary coded constellation) but that the box called “Normalisation Method” is set to “Min distance between symbols”. This isn’t sensible. In this mode, you specify the distance (amplitude/phase) separating the constellation points. Which is ridiculous, because it means that when you increase the order of the modulation scheme, the modulated signal has a higher amplitude, which is equivalent to transmitting much more power.
Save yourself a lot of head scratching and strange results and click the box to “Peak power”, which gives a realistic behaviour, by ensuring that whatever the order of the modulation scheme you choose, the peak amplitude remains the same.

Ideal Rectangular Pulse Filter normalisation

Whilst I’m on the subject of normalisation, note that if you use an Ideal Rectangular Pulse Filter to upsample your signal (it just repeats samples) then remember to switch off the normalisation (which is on by default) as it mucks things up by reducing the signal amplitude by a factor corresponding to the upsampling factor.


Was the Communications Toolbox designed by someone with a background in communications? I don’t think so, as the default options on many blocks just don’t behave like the real subsystems they’re supposed to represent. You have been warned!

Leave a Reply