BER depends on TotalFrame count in QPSK Transmitter and Receiver example

Hi,

I'm trying to adapt the QPSK Transmitter and Receiver example of the communication toolbox, s.t., I can call it on arbitrary input messages, instead of having it generate the message bits. However, I see an interesting behavior when changing the TotalFrame parameter which configures how many frames should be sent. When using values different than the default 1000, i.e., 10, 100 and 10000, I observer similar amounts of bit errors (varying slightly in independent runs), such that the BER changes with the amount of frames sent.

I don't understand this, as the transmissions should be independent (in the example the frame counter influences each frame's delay, but when I modify the example to use no delay and phase offset, just AWGN, the same behavior can be observed). Also I find it interesting that the difference in BER corresponds to the difference in transmissions: a factor of 100.

What could explain this behavior?

Answer 1

[Kaashyap Pappu]

The variability is due to timing synchronization and carrier frequency offset (CFO). Timing synchronization becomes much difficult in presence of CFO. When you run the simulation for 10000 frames with CFO set to zero, you can see in the constellation that as timing offset varies, received constellation continuously oscillates between ideal to noisy and vice versa in a cycle. This in presence of CFO is much worse. With-in 10 frames, it still will be in noisy or non-ideal state in which BER could be higher than expected. As there is no error correction in the chain, the variance is also very high. Hence, running for 10 frames or 100 frames does not give a good result. Whereas when you run for 1000 frames or 10000 frames, the result starts to converge.

Hope this helps!

[Max Schettler]

I also assumed that the time, phase, and frequency offsets of the channel influence this, but with a modified channel that has just the AWGN component I observe the same behavior.

Regarding the variance, that was also my suspission, but multiple runs show that the behavior is consistent, albeit varying.

I modified the example code, such that each iteration prints the BER values, which gives me the output seen in output.txt. This also is consistent across runs, the specific output I posted has a large number of errors, however, often times, there is only a single line of zeroes in the beginning, followed by a few errors that stay constant for the remainder of the iterations.

This kind of output explains the behavior I'm seeing, since all errors occur in the first few frames, however I'm not sure whether this reflects how such a QPSK system would behave in the real world.

[Markandeya Janaswamy]

Hi Max,

What you observed happens in the real world too! Symbol synchronization of a time domain waveform (such as the QPSK Transmitter and Receiver example of the communication toolbox) is accomplished by using a phase locked loop (PLL) and it takes some time for the PLL to get locked. Communications toolbox has got comm.SymbolSynchronizer which does exactly that - timing/phase recovery for a time domain waveform!

The initial errors that you have shown in output.txt is because the PLL is not locked yet and the constellation is still bad. Once, it is locked, there are no errors! In real scenario too the same thing applies. Hence, results converge only after a large number of bits are processed as pointed out by Kaashyap.

Cheers,

Markandeya