Grizzly 0 8 марта, 2019 Опубликовано 8 марта, 2019 · Жалоба Разбираюсь с тем, как производятся данные процедуры. Кто-нибудь реализовывал декодирование LTE? Возник вопрос по соотношению между разными параметрами. В особенности, когда несколько TB передаются в паре RB. Нашёл проекты на GitHub и описание в сети. Не могу понять, как получено значение (https://github.com/ttsou/openphy/blob/master/README.md#run) Rate match length D=284 С K=280 все понятно, это A = 256 + 24 бита CRC. Откуда взялись ещё 4 бита? Кроме того, длины 284 в отличие от 280 нет в диапазоне от 40 до 6144 битов (размер кодового блока). Вот тут есть объяснение процедура согласования скоростей: https://ltebasics.wordpress.com/2013/12/24/rate-matching-in-pdsch/amp/ Я бы ещё понял, если бы значение D было кратно 32. Есть ли в сети исходники какой-нибудь эталонной реализации, чтобы разобраться? UPD. Как только написал, сразу пришел в голову ответ ;) Это хвостовые 4 бита для выведения решетки в исходное состояние. Тем не менее вопрос о какой-нибудь верной реализации в Matlab/Octave/C/C++ остаётся открытым. Вдруг уже кто-то работал и проверял. По приведенной выше ссылке и в OpenLTE с виду существенно отличаются. Наверное, в OpenLTE наиболее правильно. UPD2.: Вот тут вроде бы похоже на истину :) По крайней мере, значения параметров не вызывают сомнений. Код рабочий. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Grizzly 0 8 марта, 2019 Опубликовано 8 марта, 2019 · Жалоба Всё-таки нашлись ошибки. Для блоков с данными, превышающих 6144 бита, что-то сделано неверно при их разбиении на подблоки. Ошибки в размерностях массива. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
coding4dsp 0 11 марта, 2019 Опубликовано 11 марта, 2019 · Жалоба В 08.03.2019 в 23:08, Grizzly сказал: Всё-таки нашлись ошибки. Для блоков с данными, превышающих 6144 бита, что-то сделано неверно при их разбиении на подблоки. Ошибки в размерностях массива. В доках 3GPP TS 36.212 длина кодового слова в табличном перемежении (Table 5.1.3-3: Turbo code internal interleaver parameters) не превышает 6144 бит. Может в этом дело? Мне казалось, что для полиномов с кодовым ограничением 4 нужно 3 терминационных бита, а не 4. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Grizzly 0 11 марта, 2019 Опубликовано 11 марта, 2019 · Жалоба 5 минут назад, coding4dsp сказал: кодовым ограничением 4 нужно 3 терминационных бита, а не 4. 4. После кодирования со скоростью 1/3 будет 12 бит. Это в стандарте написано. В принципе разобрался, где найти исходники в приведенной мною ссылке на OpenPHY все выглядит сделанным по стандарту. Надо было сразу внимательнее код читать. Он очень хорошо и понятно написан. В учебнике полно ошибок в коде :( Пошел процесс. Только не все кодовые блоки удаётся декодировать, разбираться ещё много. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
coding4dsp 0 11 марта, 2019 Опубликовано 11 марта, 2019 (изменено) · Жалоба 10 минут назад, Grizzly сказал: 4. После кодирования со скоростью 1/3 будет 12 бит. Это в стандарте написано. 3 на систематические биты, 3 на проверочные биты 1-го RSC, 3 на проверочные биты 2 RSC и еще 3 на систематические биты 2-го RSC. Изменено 11 марта, 2019 пользователем coding4dsp Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Grizzly 0 11 марта, 2019 Опубликовано 11 марта, 2019 · Жалоба 4 часа назад, coding4dsp сказал: 3 на систематические биты, 3 на проверочные биты 1-го RSC, 3 на проверочные биты 2 RSC и еще 3 на систематические биты 2-го RSC. Спасибо, что поправили. Неверно написал. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Grizzly 0 12 марта, 2019 Опубликовано 12 марта, 2019 · Жалоба Интересно, а можно ли как-то идентифицировать на приемной стороне скорость кода после rate matcher, не используя данные служебных каналов, в которых передается данная информация в косвенном виде? Надо подумать. Понятно, что примерно можно, турбокод выправит ошибки. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
des00 25 13 марта, 2019 Опубликовано 13 марта, 2019 · Жалоба On 3/11/2019 at 10:04 PM, coding4dsp said: 3 на систематические биты, 3 на проверочные биты 1-го RSC, 3 на проверочные биты 2 RSC и еще 3 на систематические биты 2-го RSC. Занятно, а ссылок на сравнение Wimax/DVB RSC с этим турбокодом у вас нет? Просто странно почему они не сделали замыкание решетки как в DVB для упрощения декодирования, а ввели терминирование. Или на декодере с однобитным входом это не работает? ЗЫ. я бы понял терминирование на полиномах без обратной связи, это упрощает декодирование. Но терминирование с обратной свзяью, разве что выкинуть ошибки на последних символах. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
coding4dsp 0 13 марта, 2019 Опубликовано 13 марта, 2019 · Жалоба 5 часов назад, des00 сказал: Занятно, Я делал турбо-кодек только под LTE. Посмотрел DVB - там duo-binary турбо-код с tail-biting, я с таким не сталкивался. Вы же про tail-biting говорите? В рекурсивном сверточном коде последнее состояние от всех данных зависит, а не от k-последних. Однако, если в wimax/dvb используется duo-binary с tail-biting, то, значит, я не до конца разобрался. 5 часов назад, des00 сказал: ЗЫ. я бы понял терминирование на полиномах без обратной связи, это упрощает декодирование. Но терминирование с обратной свзяью, разве что выкинуть ошибки на последних символах. На приеме с увеличением кол-ва итераций надежность оценки терминационных символов расти, конечно, не будет, так как для них нет Extrinsic'ов. После обратного прохода, эти биты, конечно, отбросят, но декодер ведь шел из известного конечного состояния, а это главное. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
des00 25 13 марта, 2019 Опубликовано 13 марта, 2019 · Жалоба 10 minutes ago, coding4dsp said: Я делал турбо-кодек только под LTE. Посмотрел DVB - там duo-binary турбо-код с tail-biting, я с таким не сталкивался. Вы же про tail-biting говорите? В рекурсивном сверточном коде последнее состояние от всех данных зависит, а не от k-последних. Однако, если в wimax/dvb используется duo-binary с tail-biting, то, значит, я не до конца разобрался. На приеме с увеличением кол-ва итераций надежность оценки терминационных символов расти, конечно, не будет, так как для них нет Extrinsic'ов. После обратного прохода, эти биты, конечно, отбросят, но декодер ведь шел из известного конечного состояния, а это главное. Да про него, правда в стандарте эта операция называется "Circulation of Initial State" и проводится без дополнительных бит данных. Методом двойного кодирования. В этом случае начальное и конечное состояние одинаково. Это используется при декодировании. А вот с дополнением нулями, в рекурсивном кодере мне не понятно как они добиваются известного конечного состояния. Оно же каждый раз будет разное и зависеть от всех данных. Если бы был нерекурсивный кодер, тогда проблем нет) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
coding4dsp 0 13 марта, 2019 Опубликовано 13 марта, 2019 (изменено) · Жалоба 9 минут назад, des00 сказал: А вот с дополнением нулями, в рекурсивном кодере мне не понятно как они добиваются известного конечного состояния. Оно же каждый раз будет разное и зависеть от всех данных. Если бы был нерекурсивный кодер, тогда проблем нет) Когда приходит пора терминации, то активен ключ В. Изменено 13 марта, 2019 пользователем coding4dsp Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
des00 25 13 марта, 2019 Опубликовано 13 марта, 2019 · Жалоба 15 minutes ago, coding4dsp said: Когда приходит пора терминации, то активен ключ В. Спасибо, теперь понятно. не увидел сразу) Прикольно. Надо запомнить на будущее Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Grizzly 0 13 марта, 2019 Опубликовано 13 марта, 2019 · Жалоба @coding4dsp а вы реализовывали только кодер/декодер или всю процедуру работы с битами? Не до конца понял стандарт. Если у нас TB больше максимально допустимого кодового слова, происходит деление на блоки. Длина блоков и длина E после rate matcher одинакова должна быть для всех блоков или может быть различной? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
coding4dsp 0 13 марта, 2019 Опубликовано 13 марта, 2019 · Жалоба 1 час назад, Grizzly сказал: @coding4dsp а вы реализовывали только кодер/декодер или всю процедуру работы с битами? Не до конца понял стандарт. Если у нас TB больше максимально допустимого кодового слова, происходит деление на блоки. Длина блоков и длина E после rate matcher одинакова должна быть для всех блоков или может быть различной? Только кодер/декодер, по этому с ходу на ваш вопрос не отвечу(( Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Grizzly 0 13 марта, 2019 Опубликовано 13 марта, 2019 · Жалоба 1 час назад, coding4dsp сказал: Только кодер/декодер У меня на самом деле LTE-like, поэтому вопросов много. Вслепую приходится вытягивать информацию. Непонятно, где ошибаюсь, поскольку настоящего LTE для отработки нет :( Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
