Перейти к содержанию
    

Вопросы по итеративному декодированию

вопрос как?

 

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

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

 

Порядка 10 Мбит/с у меня получалось на персоналке для TPC 3/4 при 5-ти итерациях, применял Чейза.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

знаю, прежде чем попросить проверил ...

То что вы спрашивали помню, а вот то что отсылал нет :)

чтобы достичь таких высоких скоростей обработки и повторить такое...

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

То что вы спрашивали помню, а вот то что отсылал нет :)

 

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

 

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

спасибо...

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Глупый вопрос. Почему в 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 используются всегда как есть

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Глупый вопрос. Почему в RSС кодах не учитывается extrinsic информация о проверочных битах. Понятно что между декодерами передавать LLR проверочных битов не имеет смысла, но в пределах одного декодера между итерациями почему не воспользоваться выходными LLR метриками проверочных бит.

 

Апостериорные вероятности проверочных бит не добавляют полезной информации. Вся инфа, выцепленная из структуры кода, уже учтена в экстринсиках систематических бит. Они определяют вероятности состояний решетки и, соответственно переходов по ней, из которых рассчитываются апостериорные вероятности того или иного проверочного бита.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Апостериорные вероятности проверочных бит не добавляют полезной информации. Вся инфа, выцепленная из структуры кода, уже учтена в экстринсиках систематических бит. Они определяют вероятности состояний решетки и, соответственно переходов по ней, из которых рассчитываются апостериорные вероятности того или иного проверочного бита.

Понял, как самому в голову не пришло :) Тогда вопросы - следствие:

1. Тогда зачем в некоторых примерах рассчитывают LLR проверочных бит и принимают решение о проверочных битах? Только ради того что бы посчитать BER методом обратного кодирования?

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Понял, как самому в голову не пришло :) Тогда вопросы - следствие:

1. Тогда зачем в некоторых примерах рассчитывают LLR проверочных бит и принимают решение о проверочных битах? Только ради того что бы посчитать BER методом обратного кодирования?

 

Не знаю.

 

2. В таком случае можно же сократить количество вычислений при итерациях, вычислив gammaE[0][input][k]=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) - меняется.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Подумал на счет пункта 1 - LLR проверочных бит могут потребоваться для итеративной демодуляции-выравнивания.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

или для демодуляции и декодировании в многоуровневых сигнально-кодовых конструкциях.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

P_appriory(in) * P_appriory(coded) можно посчитать заранее, это не меняется между итерациями. P_extrinsic(in) - меняется.

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

 

Подумал на счет пункта 1 - LLR проверочных бит могут потребоваться для итеративной демодуляции-выравнивания.

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

 

или для демодуляции и декодировании в многоуровневых сигнально-кодовых конструкциях.

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

я имею в виду схемы наподобии trellis-coded modulation на основе разбиения Ангербёка(Ungerboek), где для демодуляции бит следующего уровня нужны все данные с предыдущего.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

я имею в виду схемы наподобии trellis-coded modulation на основе разбиения Ангербёка(Ungerboek), где для демодуляции бит следующего уровня нужны все данные с предыдущего.

 

Ну да, для BCM (BICM) мягкий выход проверочных бит нужен.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Перевожу модель в фиксед поинт. Есть глупый вопрос: в документе 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, они ставят созвездие почти в насыщение квантователя. В чем тайный смысл сего действа ?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Первый вопрос почему не нормируют созвездие, ведь ару это умножение на константу, сигнал умножается вместе с шумом?

 

Давай сначала - что такое канальные 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. Видимо, провели моделирование какое-то, чтобы подтвердить результаты.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...