Hi Harald,

> Why the code differs, I don't know. Maybe it was
> never completed in conv_gen?

It seems, I found the answer. If you look closer at
gsm0503_coding.c/gsm0503_pdtch_encode(), you will see:

// Around line 1300, CS-2 encoding
// ...

osmo_pbit2ubit_ext(conv, 3, l2_data, 0, 271, 1);
usf = l2_data[0] & 0x7;

osmo_crc16gen_set_bits(&gsm0503_cs234_crc16, conv + 3,
    271, conv + 3 + 271);

memcpy(conv, gsm0503_usf2six[usf], 6);

osmo_conv_encode(&gsm0503_cs2, conv, cB);

//
for (i = 0, j = 0; i < 588; i++)
    if (!gsm0503_puncture_cs2[i])
        cB[j++] = cB[i];

hl_hn = gsm0503_pdtch_hl_hn_ubit[1];

// ...

So, as I understand, this code applies puncture itself.
But in our case, the osmo_conv_encode() applies puncture
too, from the gsm0503_cs2 convolutional code definition.
The same things happens in the gsm0503_pdtch_decode().

There are two possible ways to go in my mind:

1) The simplest way is to merely remove puncture from
   both gsm0503_cs2 and gsm0503_cs3 definitions, but
   it may break some code, which already uses current
   variant.
2) Change exactly the gsm0503_coding.c to use puncture
   from shared convolutional code definitions. For me,
   this way is prefered, but I don't know how to change
   the code yet.

Any opinions?
Does any project use the convolutional code definitions
from 'utils/conv_gen.py'?