I would like to be able to compute the so-called "free distance" for a TCM with a rate 2/3 convolutional code (two inputs, three outputs) inside that I plan to use for 8PSK. My previous assumption was that I could simply compute distance between the "null sequence" and the next closest sequence because the code is linear. But that does not seem to work because this computation gives me a squared free distance of supposedly 5.17157 for an 8-state code that actually performs worse in AWGN channel simulations than the 8-state recursive Ungerboeck code for which I compute the squared free distance to be 4.58579 (which is correct in this case).

Any pointers on how to compute the free distance for TCM would be greatly appreciated.

The TCM for which my free distance calculation seems to fail is this one:

in1 ----------*---------------*-- out2
              |               |
              |               V
in0 -*--------|--------*---->(+)- out1      (+) is a binary plus (xor)
     |        |        |
     V        V        V                    [D] is a delay element/flip-flop
    (+)->[D]-(+)->[D]-(+)->[D]-*- out0
     A                 A       |            V and A are supposed to be
     |                 |       |            arrow heads

symbol mapping:
binary "out2 out1 out0" -> exp(2i*pi*out/8)
where out_k is the k-th bit of out counting from zero as the LSB
  • $\begingroup$ Good question; I edited the tags for you. $\endgroup$
    – Jason R
    Nov 22, 2013 at 14:11

1 Answer 1


The free distance of a Trellis Coded Modulation system implemented either on BPSK or QPSK is a straightforward calculation. You'd have to compute the free distance $d_{free}$ of the convolutional code which is known as the Minimum Squared Euclidean Distance (MSED). Now, if the code has set-partitioned labeling to achieve coding gains over conventional labeling, then the minimum distance is given as $$\text{min}(d_{free},d_{ic})$$ where $d_{ic}$ is the minimum squared Intra-coset distance which can be calculated from the mapping. Having said this, the MSED of the convolutional code can be computed the same way its $d_f$ (the hamming free distance) is computed. You need to do a trellis search and replace hamming weights with squared euclidean minimum distances with the all zero-sequence mapping (this is valid because any convolutional code is linear and if the mapping is BPSK or QPSK, every symbol has a decoding Voronoi region that has the same area and the same shape as every other sequence). I believe you've implemented your trellis search perfectly. Having said this, the Ungerboeck code cannot be performing better than a code which has a higher Euclidean $d_{min}$. Suggestions:
1. Either you're computing one of the distances wrongly
2. Are you sure about the minimum distance of the Ungerboeck code?

  • $\begingroup$ Thanks for taking the time to respond. I'm not convinced that "linear code" is enough to guarantee equally sized and shaped Voronoi regions. I think I missed some other constraint that I violated by adding the upper right XOR and that I ran into a situation where the Vornoi region around the zero sequence was larger (hence the larger free distance estimate) but it performed worse in terms of BER because there were also other smaller regions. $\endgroup$
    – sellibitze
    Dec 10, 2013 at 14:23
  • $\begingroup$ Anyways, I learned that a low BER is not only about large free distances but also the Voronoi shapes. It's a good idea to do some simulations with different codes to find more sphere-like shaped Voronoi regions. Free distance isn't everything, apparently. $\endgroup$
    – sellibitze
    Dec 10, 2013 at 14:24
  • $\begingroup$ The way I tried to compute the free distance was by decoding the all-zero-sequence while forcing the decoder to avoid the zero-state in the middle by artificially increasing the transition costs to that trellis node to infinity. I think this is legit to compute the distance of the next closest valid sequence. But it does not give me the "free distance" in case the Voronoi regions have different shapes and sizes, obviously. And I think that's just what happened because otherwise the decoder worked as intended. $\endgroup$
    – sellibitze
    Dec 10, 2013 at 14:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.