Serg76 0 30 декабря, 2014 Опубликовано 30 декабря, 2014 · Жалоба вопрос как? количество метрик для (128*120) очень большое получается - как обойти этот момент? Скорее всего это заблуждение, либо видел где-то упоминание об этом, либо подкупила высокая помехоустойчивость AHA декодеров. Сейчас склоняюсь к мысли, что такую скорость можно получить мажоритарным декодером, у него сложность реализации линейная Порядка 10 Мбит/с у меня получалось на персоналке для TPC 3/4 при 5-ти итерациях, применял Чейза. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
des00 25 30 декабря, 2014 Опубликовано 30 декабря, 2014 · Жалоба знаю, прежде чем попросить проверил ... То что вы спрашивали помню, а вот то что отсылал нет :) чтобы достичь таких высоких скоростей обработки и повторить такое... Не совсем понимаю в чем проблема, там же 4 декодера работают параллельно. Обрабатывается сразу по 4 строки и 4 столбца, при этом как я понимаю работают не побитно, а пословно. Пока совершенно не ориентируюсь в 2D TPC кодах, но если скорость кодирования высокая, то думаю что это может очень быстро работать. судя по доке на 150МГц они дают 45 мегабит на декодер, итого 3 такта на бит. 4 декодера с запасом. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Maverick_ 15 30 декабря, 2014 Опубликовано 30 декабря, 2014 · Жалоба То что вы спрашивали помню, а вот то что отсылал нет :) Не совсем понимаю в чем проблема, там же 4 декодера работают параллельно. Обрабатывается сразу по 4 строки и 4 столбца, при этом как я понимаю работают не побитно, а пословно. Пока совершенно не ориентируюсь в 2D TPC кодах, но если скорость кодирования высокая, то думаю что это может очень быстро работать. судя по доке на 150МГц они дают 45 мегабит на декодер, итого 3 такта на бит. 4 декодера с запасом. спасибо... не отсылали, я Вам тогда не ответил, решил сам покопать... :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
des00 25 19 января, 2015 Опубликовано 19 января, 2015 · Жалоба Глупый вопрос. Почему в 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 используются всегда как есть Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
andyp 10 19 января, 2015 Опубликовано 19 января, 2015 · Жалоба Глупый вопрос. Почему в RSС кодах не учитывается extrinsic информация о проверочных битах. Понятно что между декодерами передавать LLR проверочных битов не имеет смысла, но в пределах одного декодера между итерациями почему не воспользоваться выходными LLR метриками проверочных бит. Апостериорные вероятности проверочных бит не добавляют полезной информации. Вся инфа, выцепленная из структуры кода, уже учтена в экстринсиках систематических бит. Они определяют вероятности состояний решетки и, соответственно переходов по ней, из которых рассчитываются апостериорные вероятности того или иного проверочного бита. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
des00 25 19 января, 2015 Опубликовано 19 января, 2015 · Жалоба Апостериорные вероятности проверочных бит не добавляют полезной информации. Вся инфа, выцепленная из структуры кода, уже учтена в экстринсиках систематических бит. Они определяют вероятности состояний решетки и, соответственно переходов по ней, из которых рассчитываются апостериорные вероятности того или иного проверочного бита. Понял, как самому в голову не пришло :) Тогда вопросы - следствие: 1. Тогда зачем в некоторых примерах рассчитывают LLR проверочных бит и принимают решение о проверочных битах? Только ради того что бы посчитать BER методом обратного кодирования? 2. В таком случае можно же сократить количество вычислений при итерациях, вычислив gammaE[0][input][k]=exp(0.5*Lc*parity1[k]*xk); один раз при первом проходе? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
andyp 10 19 января, 2015 Опубликовано 19 января, 2015 · Жалоба Понял, как самому в голову не пришло :) Тогда вопросы - следствие: 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) - меняется. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
andyp 10 21 января, 2015 Опубликовано 21 января, 2015 · Жалоба Подумал на счет пункта 1 - LLR проверочных бит могут потребоваться для итеративной демодуляции-выравнивания. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
smoke_111 0 21 января, 2015 Опубликовано 21 января, 2015 · Жалоба или для демодуляции и декодировании в многоуровневых сигнально-кодовых конструкциях. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
des00 25 22 января, 2015 Опубликовано 22 января, 2015 · Жалоба P_appriory(in) * P_appriory(coded) можно посчитать заранее, это не меняется между итерациями. P_extrinsic(in) - меняется. Это и имел в виду, похоже что в сети полно декодеров, назову их "каноническими", которые показывают работу алгоритма и не заботятся о производительности. Все остальное "пилите шура, пилите" (с) :) Подумал на счет пункта 1 - LLR проверочных бит могут потребоваться для итеративной демодуляции-выравнивания. Вполне возможно, видел много статей про турбоэквалайзирование, но для моих скоростей оно пока не применимо. или для демодуляции и декодировании в многоуровневых сигнально-кодовых конструкциях. Вы имеете в виду что-то вроде иерархической модуляции, для классических созвездий этого делать не нужно, там просто демаппер корректный надо сделать. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
smoke_111 0 23 января, 2015 Опубликовано 23 января, 2015 · Жалоба я имею в виду схемы наподобии trellis-coded modulation на основе разбиения Ангербёка(Ungerboek), где для демодуляции бит следующего уровня нужны все данные с предыдущего. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
andyp 10 23 января, 2015 Опубликовано 23 января, 2015 · Жалоба я имею в виду схемы наподобии trellis-coded modulation на основе разбиения Ангербёка(Ungerboek), где для демодуляции бит следующего уровня нужны все данные с предыдущего. Ну да, для BCM (BICM) мягкий выход проверочных бит нужен. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
smoke_111 0 23 января, 2015 Опубликовано 23 января, 2015 · Жалоба точно, спасибо, забыл как это называется. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
des00 25 26 января, 2015 Опубликовано 26 января, 2015 · Жалоба Перевожу модель в фиксед поинт. Есть глупый вопрос: в документе 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, они ставят созвездие почти в насыщение квантователя. В чем тайный смысл сего действа ? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
andyp 10 26 января, 2015 Опубликовано 26 января, 2015 · Жалоба Первый вопрос почему не нормируют созвездие, ведь ару это умножение на константу, сигнал умножается вместе с шумом? Давай сначала - что такое канальные 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. Видимо, провели моделирование какое-то, чтобы подтвердить результаты. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться