des00

Да, такая техника есть, но учтите, что порог синхронизации демодулятора основного потока, намного выше, чем этого специального канала. Т.е. на пальцах, порог синхронизации демодулятора основного канала -90дбм, CIR демодулятора -120дбм(он стоит ниже основного на 30дб). То при сигнале в антене -100дбм, основной поток вы вообще не сможете демодулировать, а CIR демодулятору уже будет без разницы произвели ли вы вычитание помехи или нет. Демодулятор все равно не сможет захватится. Т.е. похожие схемы используются при иерархической модуляции, но там есть проблема задержки (нужно демодулировать, декодировать, замодулировать, с остаточными ошибками декодирования и т.д.), но в данном конкретном месте, применять эту технику нет смысла. освежил память https://www.etsi.org/deliver/etsi_ts/103100_103199/103129/01.01.02_60/ts_103129v010102p.pdf там кстати есть энергетические рассчеты по основному потоку. Помимо базы, там есть еще выигрыш по полосе и возможно интегрирование уже после снятия шпс. Рискну предположить что фраза означает что вы можете идентифировать несущую, даже если ее уровень на уровне шумов. А под идентифицировать они понимают принять DVB CID Global Unique Identifier а не восстановить несущую и тем более сигнал основного канала. А это действительно возможно, из-за выигрыша по полосе, базе и возможном накоплении) ЗЩ. Цифры в примере от балды, просто что бы показать о чем идет речь)

Да, но у хилых 36К блок делится на два полноценных 18к, которые могут быть спокойно стоять в True Dual Port режиме, без каких либо ограничений

Добрый день! Наконец то появилось время подтянуть себя в вопросах реализации кодов с вероятностным декодированием. Первая задача реализация DVB-RCS/WiMAX CTC кодера на ПЛИС, часть проекта будет выложен в опенсорс. Решил создать отдельную тему для обсуждения вопросов по реализации После штудирования литературы и примеров сорцов в сети возникла часть вопросов, на которые не хватает ума/настойчивости найти ответы: 1. Для DVB-RCS оговорены выкалывания под скорости кодирования 1/3, 2/5, 1/2, 2/3, 3/4, 4/5, 6/7. Почему не определены скорости 5/6 (удивляет "дырка" между скоростями 4/5 и 6/7) и 7/8? При этому матрица выкалывания под эти скорости возможна. 2. Полиномы RCS для Wimax и DVB одинаковые, но перемежители разные. Это сделано по политическим причинам или это результат "улучшения" характеристик декодера в процессе разработки стандарта? 3. В сверточных бинарных кодах, свойство tail-bitting используется при декодировании: В одной доке нашел что дополняют принятую последовательность вначале и в конце, затем декодируют по витерби и выкусывают нужное. В примере матлаба вообще составляют два фрейма, декодируют один за другим, потом из двух декодированных собирают один результат. Никакого намека на похожие операции в доках на турбокоды не нашел. Почему в алгоритмах SOVA/MAP/... для турбокодов это не делается? 4. По tail-bitting нашел в доках только то, что особым образом инициализируются рекурсия прямой и обратной метрики на первой итерации, а на всех остальных значения между итерациями сохраняются. Но в сорцах от 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 Т.е. видно что последовательные вызовы функции DuobinaryCRSCDecode между собой не обмениваются этой информацией. А в самих функциях // initialization for CRSC code for (i =0; i< max_states; i++) { alpha[i][0] = 0; beta[i][len] = 0; } Т.е. не используется даже свойство одинакового начального состояния. Более того, в алгоритмах с оконным расчетом обратной рекурсии тоже забивают на свойство tail-bitting. Так насколько это важно и почему во всех доках настойчиво пишут кодировать данные 2 раза для определения состояния инициализации? 5. В алгоритмах, наследованных от Log-MAP метрика ветки считается как сумма корреляций метрик приемных битов с выходными битами решетки : gamma(Sk-1, S) = Lapri + (ys0*xs0 + ys1*xs1 + yp0*xp0 + yp1*xp1). При этом предполагается что y - надежность принятого символа , x = -1/1 выходной(переданный) бит. В сорцах от CML это место выглядит так : int m_input = 2; // 2 input bits, int max_states = 8; // total state numbers int M_input = 1<<m_input; int i, j, max_trellis = M_input * max_states; ....... for (j = 0; j< max_trellis; j++) { temp_input = j%M_input; temp_output = trellis_out[j]; gamma[j] = ( temp_input ==0)? 0: inx[ (temp_input -1)+ i*llr_height ]; //llr for systematic symbol gamma[j] += ( temp_output ==0)? 0: inz[ (temp_output -1)+ i*llr_height ]; //llr for parity symbol } Насколько я понимаю Си gamma[j] = ( temp_input ==0)? 0: inx[ (temp_input -1)+ i*llr_height ] - берет надежности символов кроме нулевого. Диапазон изменения temp_input = 0..3 или в битах 00/01/10/11. Вот этот момент мне совсем не понятен. Пока всё :) Прошу помощи тех кто в теме.

Подниму старую тему. Таки дошел до ситуации, когда хочу научится считать проверочные матрицы регулярных LDPC кодов, основанных на сдвинутых единичных матрицах. Хочу насчитать матрицы как в Wimax, но на более широкий диапазон скоростей кодирования. Интересуют 1/2, 2/3, 3/4, 4/5, 5/6, 6/7, 7/8, 8/9, 9/10. Накачал статьей с сети, но .... "говорила мне мама, учи математику сынок..." много не понятно. Может кому попадалась хорошая литература или есть подборка литератуы по этому вопросу ? Можете поделится? Спасибо. ЗЫ. Сам давал ссылку на статьи П.Трифонова, они у меня есть, но см. причину выше)))

эммм, ну в вашей фразе не указано же, что вычитается сигнал, как вы говорите хоста. Там просто указано что можно вытащить его из под шумов. ЕМНИП там база порядка 8к, что теоретически дает выйгрыш по энергетике 39дб. Сам этот сигнал ставится под основной на уровне -30, такое отношение сигнал-шум достаточно для работы с FEC. Не вижу противоречий с вашей фразой. А вот про возможность:если мне снова не изменяет память, излучается основной сигнал и CID на одной стороне. летят они вместе, как его можно самого из себя вычесть...... Это же не спектр в спектре, когда из приемного вычитается передающий, априори известный. Ну либо я чего то не понимаю.

а это вообще, без демодуляции и повторной модуляции основного сигнала возможно?

чорт возьми, вы абсолютно правы. им не хватило тяму реализовать хилый режим разбиения большого блока на два независимых и полноценных, меньшего размера. Не ожидал, что там на аппартном уровне полный ноль. Моя неправда)

сделал отдельную тему для проекта с началом здесь сообщения из кросс тем переместил. продолжаем пиарить красоту SV. итак новый релиз проекта БЧХ : 1. переписана работа с математикой в полях галуа. Теперь ква собирает декодер много быстрее, почти не задумываясь и не требует кучу памяти %) 2. переписан статически конфигурируемый БЧХ кодер/декодер, удалены лишние модули, ясность выше код чище 3. добавлен статический конфигурируемый RS кодер/декодер, стиль унифицирован с БЧХ кодером. Внимание : в сорцах есть реализация BM алгоритма, требующая на декодирование всего check тактов (!!! именно тактов а не шагов). 4. модифицированы random constraints тестбенчи, ясность выше, код чище. 5. Все как и прежде, не требует каких либо генераторов, скриптов и т.д. Вычисляется и синтезируется по месту. Расчет генераторного полинома БЧХ по прежнему не сделан %( Динамически конфигурируемые кодеры/декодеры выкладывать не буду, это уж как нить сами ;) UPD. Естественно осталась возможность использовать несколько инстансов кодеров с разными параметрами в одном проекте %) bch_rs_release_19062011.zip

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

Действительно, чой то я не то сказал Тогда странно, 1/6 у них даёт 1е-6 где-то на 0.75дб, у меня где то 0.375дб, а в документе от ccsds 0.125дб. Вот и подумал что алгоритмы разные)

спасибо за ссылку, вот у них как раз близкие к моим характеристикам) но и метод декодирования у них заявлен другой BCJR, а не max log map. Надо поизучать, может быть он позволит поднять скорость работы сверточного турбодекодера

эммм, в смысле как скомпилировать технологические библиотеки примитивов? дык это в хендбуке на софт есть) скомплировать, прописать в modelsim.ini и все. а другой поддержки и нет по сути, движок моделирования то один

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

в общем ответ на ваш вопрос Итог: именно поэтому я хотел бы знать как в уже неоднократно перечисленных мною выше программах осуществляется конкретизация той или иной конфигурации ПЛИС. никак. современные ПЛИС не промоделировать в этих программах. Слишком сложная внутренняя архитектура, слишком много всего учитывать и нужно это единицам,с проектами класса мигания светодиодом, без паяльника. А логические симуляторы лучше делают те, кто на этом собаку сьел и может легко подтянуть технологические библиотеки моделирования от вендоров ПЛИС. Поэтому вам все же в квартус, исе,виваду, моделсим, альдек и учиться писать верификационное окружение. Ну либо не лезть в эту бесперспективную, с точки зрения времени, тему.

я думал вы про ПЛИС, а вы всё про примитивные устройства, которые, как уже указали выше, просто набор ключей и расписывались руками.

рад бы помочь, но в OFDM я как свинья в апельсинах, не было задачи... Сделал доработки, характеристики стали лучше, но характеристик в документе не дотягивает. Не указан режим снятия кривых, ставил 8 бит метрику, 50 итераций, табличную функцию MMAX*, все равно хуже где то на 0.25дб и водопадный регион более крутой. Надо подумать ccsds_turbo_release08112019.zip

а можете ткнуть носом где именно? У меня плохой английский, но мне кажется, что в этой фразе и на этом рисунке http://digsys.upc.es/csd/P02/P2_T/Behav/RTL_behavioural.jpg подразумевается классический квартус, а вот тут подразумевается обычный софт от фпга вендора, о чем даже есть упоминание в файле тестбенча -- VHDL Test Bench Created by ISE for module: HEX_7SEG_DECODER

тогда вам к марсоходианам, там на пальцах разъясняется что и куда https://marsohod.org/

вы бы для начала с модуляцией определились, потом канал свой описали и посмотрели структуру ошибок в нем, и только потом уже к кодированию подошли бы

да там не особо много вариантов. если есть shared mode в ячейках, то софт сделает на них, если нет, то на дереве. Тем более, в ТЗ у ТС нет регистрово, поэтому без разницы как оно будет сделано. С регистрами да, возможны варианты: дерево или цепь, с разными видами латентности.

вы уже передергиваете) когда мне, в первое знакомство с ква, пришлось создать проект с пинами, то я ввел два пина в редакторе, сохранил проект, и пробежался по файлам которые ква сделал. В итоге, все свелось к правке qsf файла (quartus settings file), где хранится вообще все, а дальше set_instance_assignment -name IO_STANDARD LVDS -to blablabla set_location_assignment PIN_E3 -to blablabla set_location_assignment PIN_E4 -to "blablabla(n)" все тоже самое что и в UCF файле. Это без чтения документации и прочего. Просто на уровне интуциии, с нулевым опытом. А про Xilinx, вы констрейны под ISE если писали, вот его концепция временных спецификаций, мозг сломаешь пока вьедешь)

у него же автоматически выполняется пакетное задание на проверку всего, при этом это не откючается) давно уже все пишут руками напрямую в qsf файле или подключают к qsf файл тикловский с описанием портов. подозреваю что дело в железке, там скорее всего ftdi кривая или в системе у вас с ними проблемы (да, на фтдиай там все сделано) чип эдитор, технолоджи маппер, ртл вьвер, по модулю и правой кнопке мыши, (вивадовский просмотр ресурса после имплементации, вообще без открытия проекта недоступен). констрейны в любом файле и подключить к проекту. Ну а редактор, а зачем вообще из него работать, писать отдельно, проверка синтаксиса тамже, вызовом компиляци симулятора, с перенаправлением потока))

у меня после ISE с вивадой такое было, после квартуса))) В соседней теме. По сабжу, полагаю что софт рабочий, не без костылей, но сейчас время такое, все косячат. ЗЫ. По описанию архитектуры, похожа на М1 от миландра) Первые, довольно жирные, ласточки)

то что нужно, спасибо) Нашел пару ошибок в базовой модели, и не пару в RTL коде) ошибки ламерские)))). Код работает, но не дает то что должен

Статически конфигурируемый CCSDS 131.0-B-3 турбокодек для сыклона 5, скорость кодирования 1/3, 1784 бита. кодер : 130ALM, 153 Reg, 2M10K, 180MHz -> ~= 60Mbps декодер : 2411ALM, 4077Reg, 48M10, 140MHz -> ~= 10Mbps (10 итераций) ccsds_turbo_beh_release02112019.zip