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'? With best regards, Vadim Yanitskiy. 2016-09-29 21:40 GMT+07:00 Harald Welte <laforge@gnumonks.org>:
From my memory:
* CS1 is rate 1/2 conv code with no puncturing. * CS2+3 apply different puncturing amounts on that conv code * CS4 has no error correction (=100% puncturing)
Why the code differs, I don't know. Maybe it was never completed in conv_gen?
-- Sent from a mobile device. Please excuse my brevity.