реклама на сайте
подробности

 
 
16 страниц V  < 1 2 3 4 5 > »   
Reply to this topicStart new topic
> Вопросы по итеративному декодированию, Реализация CTC/BTC/LDPC кодов
Serg76
сообщение Dec 30 2014, 00:33
Сообщение #31


Профессионал
*****

Группа: Участник
Сообщений: 1 029
Регистрация: 4-04-07
Пользователь №: 26 775



Цитата(Maverick @ Dec 30 2014, 01:40) *
вопрос как?

количество метрик для (128*120) очень большое получается - как обойти этот момент?

Скорее всего это заблуждение, либо видел где-то упоминание об этом, либо подкупила высокая помехоустойчивость AHA декодеров. Сейчас склоняюсь к мысли, что такую скорость можно получить мажоритарным декодером, у него сложность реализации линейная

Порядка 10 Мбит/с у меня получалось на персоналке для TPC 3/4 при 5-ти итерациях, применял Чейза.
Go to the top of the page
 
+Quote Post
des00
сообщение Dec 30 2014, 03:42
Сообщение #32


Вечный ламер
******

Группа: Модераторы
Сообщений: 7 222
Регистрация: 18-03-05
Из: Томск
Пользователь №: 3 453



Цитата(Maverick @ Dec 30 2014, 06:25) *
знаю, прежде чем попросить проверил ...

То что вы спрашивали помню, а вот то что отсылал нет sm.gif
Цитата
чтобы достичь таких высоких скоростей обработки и повторить такое...

Не совсем понимаю в чем проблема, там же 4 декодера работают параллельно. Обрабатывается сразу по 4 строки и 4 столбца, при этом как я понимаю работают не побитно, а пословно. Пока совершенно не ориентируюсь в 2D TPC кодах, но если скорость кодирования высокая, то думаю что это может очень быстро работать.

судя по доке на 150МГц они дают 45 мегабит на декодер, итого 3 такта на бит. 4 декодера с запасом.


--------------------
Go to the top of the page
 
+Quote Post
Maverick
сообщение Dec 30 2014, 09:50
Сообщение #33


я только учусь...
******

Группа: Модераторы
Сообщений: 3 366
Регистрация: 29-01-07
Из: Украина
Пользователь №: 24 839



Цитата(des00 @ Dec 30 2014, 05:42) *
То что вы спрашивали помню, а вот то что отсылал нет sm.gif

Не совсем понимаю в чем проблема, там же 4 декодера работают параллельно. Обрабатывается сразу по 4 строки и 4 столбца, при этом как я понимаю работают не побитно, а пословно. Пока совершенно не ориентируюсь в 2D TPC кодах, но если скорость кодирования высокая, то думаю что это может очень быстро работать.

судя по доке на 150МГц они дают 45 мегабит на декодер, итого 3 такта на бит. 4 декодера с запасом.

спасибо...
не отсылали, я Вам тогда не ответил, решил сам покопать... sm.gif


--------------------
If it doesn't work in simulation, it won't work on the board.

"Ты живешь в своих поступках, а не в теле. Ты — это твои действия, и нет другого тебя" Антуан де Сент-Экзюпери повесть "Маленький принц"
Go to the top of the page
 
+Quote Post
des00
сообщение Jan 19 2015, 10:09
Сообщение #34


Вечный ламер
******

Группа: Модераторы
Сообщений: 7 222
Регистрация: 18-03-05
Из: Томск
Пользователь №: 3 453



Глупый вопрос. Почему в RSС кодах не учитывается extrinsic информация о проверочных битах. Понятно что между декодерами передавать LLR проверочных битов не имеет смысла, но в пределах одного декодера между итерациями почему не воспользоваться выходными LLR метриками проверочных бит. В качестве примера вот код из CML
Код
for it = 1:max_iterations
    inx1 = X + inner_extr;
    [outx1, outz1]=DuobinaryCRSCDecode( inx1, inz1, poly, decoder_type);
    
    llrx1 = outx1 - inner_extr;
    inx2(1:3*N) = llrx1( code_interleaver_GF4);
    [outx2, outz2, out_info]=DuobinaryCRSCDecode( inx2, inz2, poly, decoder_type);
    detected_data(code_interleaver.info_intl) = (out_info>0)+0;
    errors(it)= sum( sum(abs(detected_data - data)));
    if (errors(it) == 0)
        break;
    else
        inner_extr(code_interleaver_GF4) = outx2 - inx2;
    end
end

видно что в качестве inz1/inz2 всегда используются канальные LLR, хотя outz1/outz2 - метрики с учетом влияния решетки.
или код с http://the-art-of-ecc.com/8_Iterative/index.html
Код
   for (int c=0;c<ITERATIONS;c++)
   {
    // k from 0 to N-1 instead of 1 to N
    for (int k=0;k<size;k++)
       {
       // calculate the gamma(s',s);
       for (int input=0;input<2;input++)
        {
        double uk = (input == 0) ? -1.0 : 1.0;

              for (int s=0;s<numstates;s++)
             {
             double xk = (output[input][s] == 0) ? -1.0 : 1.0;

         gammaE[0][input][k][s]=exp(0.5*Lc*parity1[k]*xk);
         gamma[0][input][k][s]
                      = exp(0.5*uk*(L[1][k]+Lc*mesg[k]))*gammaE[0][input][k][s];
             }
          }
       }
.....
       // calculate the gamma(s',s);
       for (int input=0;input<2;input++)
        {
        double uk = (input == 0) ? -1.0 : 1.0;

              for (int s=0;s<numstates;s++)
                {
                double xk = (output[input][s] == 0) ? -1.0 : 1.0;

            gammaE[1][input][k][s] = exp(0.5*Lc*parity2[k]*xk);
            gamma[1][input][k][s] = exp(0.5*uk*(L[0][k]+Lc*mesg[k]))
                                                     * gammaE[1][input][k][s];
                }
             }
       }

также parity1/parity2 используются всегда как есть


--------------------
Go to the top of the page
 
+Quote Post
andyp
сообщение Jan 19 2015, 12:14
Сообщение #35


Местный
***

Группа: Участник
Сообщений: 423
Регистрация: 23-07-08
Пользователь №: 39 163



Цитата(des00 @ Jan 19 2015, 13:09) *
Глупый вопрос. Почему в RSС кодах не учитывается extrinsic информация о проверочных битах. Понятно что между декодерами передавать LLR проверочных битов не имеет смысла, но в пределах одного декодера между итерациями почему не воспользоваться выходными LLR метриками проверочных бит.


Апостериорные вероятности проверочных бит не добавляют полезной информации. Вся инфа, выцепленная из структуры кода, уже учтена в экстринсиках систематических бит. Они определяют вероятности состояний решетки и, соответственно переходов по ней, из которых рассчитываются апостериорные вероятности того или иного проверочного бита.
Go to the top of the page
 
+Quote Post
des00
сообщение Jan 19 2015, 13:25
Сообщение #36


Вечный ламер
******

Группа: Модераторы
Сообщений: 7 222
Регистрация: 18-03-05
Из: Томск
Пользователь №: 3 453



Цитата(andyp @ Jan 19 2015, 20:14) *
Апостериорные вероятности проверочных бит не добавляют полезной информации. Вся инфа, выцепленная из структуры кода, уже учтена в экстринсиках систематических бит. Они определяют вероятности состояний решетки и, соответственно переходов по ней, из которых рассчитываются апостериорные вероятности того или иного проверочного бита.

Понял, как самому в голову не пришло sm.gif Тогда вопросы - следствие:
1. Тогда зачем в некоторых примерах рассчитывают LLR проверочных бит и принимают решение о проверочных битах? Только ради того что бы посчитать BER методом обратного кодирования?
2. В таком случае можно же сократить количество вычислений при итерациях, вычислив gammaE[0][input][k][s]=exp(0.5*Lc*parity1[k]*xk); один раз при первом проходе?


--------------------
Go to the top of the page
 
+Quote Post
andyp
сообщение Jan 19 2015, 15:23
Сообщение #37


Местный
***

Группа: Участник
Сообщений: 423
Регистрация: 23-07-08
Пользователь №: 39 163



Цитата(des00 @ Jan 19 2015, 16:25) *
Понял, как самому в голову не пришло sm.gif Тогда вопросы - следствие:
1. Тогда зачем в некоторых примерах рассчитывают LLR проверочных бит и принимают решение о проверочных битах? Только ради того что бы посчитать BER методом обратного кодирования?


Не знаю.

Цитата
2. В таком случае можно же сократить количество вычислений при итерациях, вычислив gammaE[0][input][k][s]=exp(0.5*Lc*parity1[k]*xk); один раз при первом проходе?


Давай рассмотрим BCJR без логарифмов. В этом случае gamma - вероятность перехода из состояния s_in в состояние s_out решетки. Пусть переходу соответствует информационный бит in (их может быть не один) и проверочный бит , coded (их тоже может быть не один)

gamma(s_in, s_out) = P_appriory(in) * P_extrinsic(in) * P_appriory(coded).

P_appriory(in) * P_appriory(coded) можно посчитать заранее, это не меняется между итерациями. P_extrinsic(in) - меняется.
Go to the top of the page
 
+Quote Post
andyp
сообщение Jan 21 2015, 08:37
Сообщение #38


Местный
***

Группа: Участник
Сообщений: 423
Регистрация: 23-07-08
Пользователь №: 39 163



Подумал на счет пункта 1 - LLR проверочных бит могут потребоваться для итеративной демодуляции-выравнивания.
Go to the top of the page
 
+Quote Post
smoke_111
сообщение Jan 21 2015, 09:42
Сообщение #39


Участник
*

Группа: Участник
Сообщений: 40
Регистрация: 9-09-10
Из: москва
Пользователь №: 59 392



или для демодуляции и декодировании в многоуровневых сигнально-кодовых конструкциях.
Go to the top of the page
 
+Quote Post
des00
сообщение Jan 22 2015, 09:06
Сообщение #40


Вечный ламер
******

Группа: Модераторы
Сообщений: 7 222
Регистрация: 18-03-05
Из: Томск
Пользователь №: 3 453



Цитата(andyp @ Jan 19 2015, 22:23) *
P_appriory(in) * P_appriory(coded) можно посчитать заранее, это не меняется между итерациями. P_extrinsic(in) - меняется.

Это и имел в виду, похоже что в сети полно декодеров, назову их "каноническими", которые показывают работу алгоритма и не заботятся о производительности. Все остальное "пилите шура, пилите" (с) sm.gif

Цитата(andyp @ Jan 21 2015, 15:37) *
Подумал на счет пункта 1 - LLR проверочных бит могут потребоваться для итеративной демодуляции-выравнивания.

Вполне возможно, видел много статей про турбоэквалайзирование, но для моих скоростей оно пока не применимо.

Цитата(smoke_111 @ Jan 21 2015, 16:42) *
или для демодуляции и декодировании в многоуровневых сигнально-кодовых конструкциях.

Вы имеете в виду что-то вроде иерархической модуляции, для классических созвездий этого делать не нужно, там просто демаппер корректный надо сделать.


--------------------
Go to the top of the page
 
+Quote Post
smoke_111
сообщение Jan 23 2015, 08:08
Сообщение #41


Участник
*

Группа: Участник
Сообщений: 40
Регистрация: 9-09-10
Из: москва
Пользователь №: 59 392



я имею в виду схемы наподобии trellis-coded modulation на основе разбиения Ангербёка(Ungerboek), где для демодуляции бит следующего уровня нужны все данные с предыдущего.
Go to the top of the page
 
+Quote Post
andyp
сообщение Jan 23 2015, 08:49
Сообщение #42


Местный
***

Группа: Участник
Сообщений: 423
Регистрация: 23-07-08
Пользователь №: 39 163



Цитата(smoke_111 @ Jan 23 2015, 11:08) *
я имею в виду схемы наподобии trellis-coded modulation на основе разбиения Ангербёка(Ungerboek), где для демодуляции бит следующего уровня нужны все данные с предыдущего.


Ну да, для BCM (BICM) мягкий выход проверочных бит нужен.
Go to the top of the page
 
+Quote Post
smoke_111
сообщение Jan 23 2015, 13:09
Сообщение #43


Участник
*

Группа: Участник
Сообщений: 40
Регистрация: 9-09-10
Из: москва
Пользователь №: 59 392



точно, спасибо, забыл как это называется.
Go to the top of the page
 
+Quote Post
des00
сообщение Jan 26 2015, 06:45
Сообщение #44


Вечный ламер
******

Группа: Модераторы
Сообщений: 7 222
Регистрация: 18-03-05
Из: Томск
Пользователь №: 3 453



Перевожу модель в фиксед поинт. Есть глупый вопрос: в документе ETSI TR 101 790 V1.4.1 указаны рекомендации
Цитата
It has been found in one implementation, using Sub-MAP and at Packet Error Ratio (PER) in the region of 10е-5, that a 3-bit quantization entails a penalty of 0,2 dB compared to a 4-bit quantization. It can be further shown, by simulation, that increasing from 4 bits to 5 bits results in no more than 0,1 dB additional coding gain.

Насколько я понимаю речь идет о квантовании LLR метрик битов. Изучение других материалов показало, что 1 бит под дробную часть не эффективно, минимально рекомендуемое 2 бита. Делаю вывод, что в случае 4-х бит речь идет о формате представления чисел s2.2. Т.е. знаковое число, 2 бита под целую часть и 2 бита под дробную. В таком случае диапазон LLR метрик битов -4.00 ... +3.75 (вероятность нуля 0.98... вероятность единицы 0.97). Эти значения как раз совпадают со значением LLR битов нормированного QPSK созвездия -+1 -+1i, при попадании точно в точку. Тут все понятно. Нормируем созвездие на эквалайзере/ару, считаем евклидовы метрики, делаем ограничение на уровень -4...3.75.

Чуть ниже в этом же документе написано
Цитата
Measurements, using samples from a real demodulator with Automatic Gain Control, have put into evidence that the position of the "sample clouds" within the quantizer range could be optimized for Turbo decoding. One implementation uses the following rule-of-thumb: "multiply the analogue samples of the demodulator by a constant so that after 4-bit quantization, the average of the unsigned values is equal to Rate × 8, Rate being the Turbo code rate (6/7, 4/5, 3/4, etc.)

И тут у меня взрывается мозг. Судя по доке, рекомендуемые уровни для кодирования [1/3 1/2 2/3 3/4 4/5 6/7] = [2.6 4.0 5.3 6.0 6.4 6.8]. Первый вопрос почему не нормируют созвездие, ведь ару это умножение на константу, сигнал умножается вместе с шумом? Второй вопрос, судя по всему предполагается квантование сигнала в формате s3.0, но в таком случае диапазон чисел -8...+7, т.е. при кодировании 6/7, они ставят созвездие почти в насыщение квантователя. В чем тайный смысл сего действа ?


--------------------
Go to the top of the page
 
+Quote Post
andyp
сообщение Jan 26 2015, 16:54
Сообщение #45


Местный
***

Группа: Участник
Сообщений: 423
Регистрация: 23-07-08
Пользователь №: 39 163



Цитата(des00 @ Jan 26 2015, 09:45) *
Первый вопрос почему не нормируют созвездие, ведь ару это умножение на константу, сигнал умножается вместе с шумом?


Давай сначала - что такое канальные LLR (случай BPSK,AWGN)

LLR = log(p(x=1|r)/p(x = 0|r)) = log(exp(-(r-a)^2/sigma^2)/exp(-(r+a)^2/sigma^2)) =
=4*a/sigma^2*r;

r - сигнал на входе демаппера;
sigma^2 - дисперсия шума
a - точка, соответствующая чистому сигналу на входе приемника (фактически, это мат. ожидание абс. величины сигнала на выходе приемника).

АРУ на входе демаппера увеличит в К_agc раз sigma^2 и a, поэтому формула для LLR не изменится. Т.е. это математически это все равно - скалить сигнал на входе или созвездие в демаппере.

Цитата
Второй вопрос, судя по всему предполагается квантование сигнала в формате s3.0, но в таком случае диапазон чисел -8...+7, т.е. при кодировании 6/7, они ставят созвездие почти в насыщение квантователя. В чем тайный смысл сего действа ?


На счет 3.0 vs 2.1 - если рассмотреть алгоритм MAXLOG-MAP, то он не чувствителен к постоянному множителю в канальных LLR, т.е. суть вопроса от меня ускользает - можно отскалить вход как это будет удобно. Именно поэтому при реализации смело плюют на a/sigma^2 в знаменателе канальных LLR, если диспресия шума постоянна на кодовом блоке.

Давай теперь перейдем к квантованию. Сначала проще ограничение на входе рассмотреть. Мой опыт говорит, что ограничение на входе декодера полезно даже без квантования. Фактически оно приводит к тому, что в декодер попадает меньше шума, экстремальные всплески которого просто срезаются ограничителем. Я обычно выбираю уровень ограничения, равный a+(1.5...2)*sigma. a/sigma - худший рабочий SNR декодера. Авторы рекомендаций используют мало уровней квантования, так что им нужно сбалансировать шум квантования и шум от ограничения динамического диапазона входа ограничителем. Для больших скоростей они посчитали, что дисперсия шума на входе будет меньше (рабочая точка декодера смещается вправо по шкале SNR) и потому решили сузить динамический диапазон относительно +/- a и уменьшить шум квантования малых LLR. Видимо, провели моделирование какое-то, чтобы подтвердить результаты.
Go to the top of the page
 
+Quote Post

16 страниц V  < 1 2 3 4 5 > » 
Reply to this topicStart new topic
2 чел. читают эту тему (гостей: 2, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 23rd September 2017 - 16:24
Рейтинг@Mail.ru


Страница сгенерированна за 0.0149 секунд с 7
ELECTRONIX ©2004-2016