| |
|
 |
Ответов
(1 - 71)
|
|
 May 1 2008, 03:18
|
Частый гость
Группа: Свой
Сообщений: 100
Регистрация: 4-01-05
Пользователь №: 1 799
|
Цитата(Doka @ Apr 30 2008, 15:01)  думаю что и по стоимости (разработка + итоговый bom) и по ТТХ (потреблению и габаритам), будет намного разумнее искать готовые решения..
другое дело ,что простому смертному разработчику они практически недоступны (TI, Marvell, etc).. но это уже другая история.. посмотрите на Xilinx web site. Там они раздают ref.design, сделаный на sysgen. По моему до 6 каналов UP and DOWN. Может больше. Pretty impressive.
|
|
|
|
|
|
|
|
May 2 2008, 13:22
|
Участник
Группа: Новичок
Сообщений: 32
Регистрация: 1-07-05
Пользователь №: 6 454
|
Цитата(Andakad @ Apr 29 2008, 10:01) Приветствую всех!
Кто-нибудь знает WiMAX решения на ПЛИС или DSP? "Краем глаза" читал про платы на чипах Fujitsu, Wavecom... Может есть другие решения? Программы прошивки ПЛИС или для DSP?
Считаем поставленной задачу после процесса АЦП и до выдачи информационного сигнала и наборот до процесса ЦАП. Почти каждый производитель FPGA/DSP имеет в своем разпоряжении более или менее законченное решение для Wimax TI: C64 DSP + TataElxsi MAC/PHY software stack Freescale: DSP + network processor + sw PicoChip: оригинальное решение Intel Все они в основном заточены под большых производителей операторского оборудования.
|
|
|
|
|
|
|
|
May 5 2008, 07:52
|
Участник
Группа: Участник
Сообщений: 44
Регистрация: 31-03-08
Пользователь №: 36 361
|
Спасибо всем за ответы. Буду разбираться. Как показала практика - готовое решение не всегда готовое на 100%. Вот и хочется получить ПЛИС/DSP в которой бы сидел этот самый WiMAX на все полосы от 0,75МГц до 28МГц и все скорости. Как стационарный, так и мобильный. А то каждая фирма предлагает свой частный случай...
|
|
|
|
|
|
|
|
May 7 2008, 11:31
|
Группа: Новичок
Сообщений: 5
Регистрация: 11-04-05
Пользователь №: 4 021
|
Делали подобное решение - PHY уровень на ПЛИС, MAC и Management уровень на ARMе. А что Вас конкретно интересует?
|
|
|
|
|
|
|
|
May 14 2008, 11:08
|
Участник
Группа: Новичок
Сообщений: 32
Регистрация: 1-07-05
Пользователь №: 6 454
|
Цитата(Andakad @ May 5 2008, 10:52) Вот и хочется получить ПЛИС/DSP в которой бы сидел этот самый WiMAX на все полосы от 0,75МГц до 28МГц и все скорости. Как стационарный, так и мобильный. А то каждая фирма предлагает свой частный случай... Такое маловероятно, по маркетинговым причинам. WiMAX форум выбрал честь из того, что описано в 802.16 (+e) и это назвал Wimax. Так что все пытаются слелать, то что утвердил WiMAX форум (что можно продать). А там помойму не все возможные полосы и не все скорости. Так же пока обычно идет разделение на мобильный и стационарный (там нет полосы 28МГц) Цитата(deolan @ May 7 2008, 14:31) Делали подобное решение - PHY уровень на ПЛИС, MAC и Management уровень на ARMе. А что Вас конкретно интересует? Вы не могли бы посоветовать хороше описание MAC уровня (кроме стандарта самого по себе), с прицелом на имелементацию? Может есть какие-то opensource исходники Wimax MAC? Я нашел две книжки, но там как мне кажется описаны не все нюансы Loutfi Nuaymi WiMAX Technology for Broadband Wireless Access и Fundamentals-of-wimax-understanding-broadband-wireless-networking
|
|
|
|
|
|
|
|
May 16 2008, 14:57
|
Группа: Новичок
Сообщений: 5
Регистрация: 11-04-05
Пользователь №: 4 021
|
Цитата(vzn @ May 14 2008, 15:08) Вы не могли бы посоветовать хороше описание MAC уровня (кроме стандарта самого по себе), с прицелом на имелементацию? Может есть какие-то opensource исходники Wimax MAC?
Я нашел две книжки, но там как мне кажется описаны не все нюансы
Loutfi Nuaymi WiMAX Technology for Broadband Wireless Access и
Fundamentals-of-wimax-understanding-broadband-wireless-networking А какие нюансы? На каждый CID существует своя очередь, в которую приходящие из сети пакеты попадают согласно классификаторам CIDа. Раз на фрейм вызывается функция планировщика, которая "набивает" фрейм целыми либо кусками этих пакетов, согласно параметрам QoS и свойствам очереди (пакетированная и/или фрагментированная). Похоже на задачу укладки предметов в рюкзак, только сложнее, поскольку надо учитывать физические параметры burst-ов и множество разных ограничений. Также необходимо анализировать приходящие запросы на передачу данных от АС. Еще существует ряд управляющих MAC сообщений, которые предназначены для процедуры вхождения в сеть, переодического апдейта физических параметров и организации сервисных потоков и криптографических ассоциаций. Они тоже кладутся в очереди по Basic или Primary Management CID для планировщика. Вырабатываются они по графам состояний, описанным в стандарте. Еще есть более-менее внятные книги WiMAX Handbook Frank Ohrtman WiMAX Applications Syed Ahson Mohammad Ilyas WiMAX/MobileFI Yang Xiao WiMAX Standards and Security Syed Ahson Mohammad Ilyas WiMAX Technologies Performance Analysis and QoS Syed Ahson Mohammad Ilyas Mobile WiMAX - Toward Broadband Wireless Metropolitan Area Networks Yan Zhang Hsiao-Hwa Chen Правда, вопросами реализации нигде не уделяется много внимания...
|
|
|
|
|
|
|
|
Feb 4 2009, 10:39
|
фанат Linux'а
Группа: Свой
Сообщений: 1 353
Регистрация: 23-10-05
Из: SPB.RU
Пользователь №: 10 008
|
Цитата(deolan @ May 16 2008, 17:57) Еще есть более-менее внятные книги
WiMAX Handbook Frank Ohrtman
WiMAX Applications Syed Ahson Mohammad Ilyas
WiMAX/MobileFI Yang Xiao
WiMAX Standards and Security Syed Ahson Mohammad Ilyas
WiMAX Technologies Performance Analysis and QoS Syed Ahson Mohammad Ilyas
Mobile WiMAX - Toward Broadband Wireless Metropolitan Area Networks Yan Zhang Hsiao-Hwa Chen Где бы эти книги как бы ну это самое?  Вдруг там есть то что мне надо... Цитата Правда, вопросами реализации нигде не уделяется много внимания... А есть такие книги, где описывается, как программно реализовать физический уровень mobile wimax? Я такую только одну встречал, но она оказалась пустышкой... Ведь те кто разрабатывает чипы для 802.16e не роботы и не могут опираться на один лишь только стандарт... По крайней мере я в это не верю, что они по стандарту что-то смогли сделать, это бред...
--------------------
|
|
|
|
|
|
|
|
Feb 4 2009, 11:05
|
фанат Linux'а
Группа: Свой
Сообщений: 1 353
Регистрация: 23-10-05
Из: SPB.RU
Пользователь №: 10 008
|
Цитата(blackfin @ Feb 4 2009, 13:56) То есть как это - "программно реализовать физический уровень"???Что, программой уже можно заменить Transceiver? Пожалуйста, не надо так реагировать  Я понял что Вас смутило, но могу обрадовать, что физический уровень WiMax из одного только радиотракта не состоит и все-таки после АЦП там что-то есть О чем, кстати, стандарт и повествует, уделяя лишь немного внимания тому что идет между антенной и АЦП/ЦАП. Сам мобильный ваймакс предполагает программную реализацию обработки физического уровня на этапе установления соединения... И вот более подробно хотелось бы это изучить, потому как без программной обработки к аппаратной реализации перейти не могу...
--------------------
|
|
|
|
|
|
|
|
Feb 4 2009, 15:10
|
Частый гость
Группа: Свой
Сообщений: 161
Регистрация: 19-01-08
Из: Питер
Пользователь №: 34 234
|
Цитата(petrov @ Feb 4 2009, 15:06) Существует секретная книга - подробное пошаговое руководство как сделать wimax, чтобы её получить надо стать членом тайного общества.  Кто разрабатывает чипы они стандарт и пишут, это разработки очень высокого уровня с соответствующими исследованиями. Смешно, конечно, но по видимому так и есть. По крайней мере я уже не одну неделю пытаюсь сделать математическую модель коррелятора для преамбулы WiMax. Определенные результаты уже получил, но реализация их в ПЛИС будет занимать до хрена ресурсов. Я не верю, что разработчики стандарта исходили из того алгоритма, что придумал я, так как сделать дешевое устройство с такой большой плиской не реально. А стандарты ведь создаются с учетом того, чтобы технология пошла в массы. Вот, например, Mobile Wimax определяет 114 преамбул. И они явно сформированы не случайным образом, однако никакого описания того, как их формировали, в общем доступе нет. А ведь наверняка, используя это свойство, можно построить коррелятор в разы оптимальней чем мой... Поэтому склоняюсь к тому, что они там собрались на WiMax форуме и написали филькину граммоту, и назвали её 802.16, а сами пользуются тайным знанием....
Сообщение отредактировал DMax - Feb 4 2009, 15:11
|
|
|
|
|
|
|
|
Feb 4 2009, 22:04
|
Участник
Группа: Новичок
Сообщений: 32
Регистрация: 1-07-05
Пользователь №: 6 454
|
Цитата(DMax @ Feb 4 2009, 17:10) Поэтому склоняюсь к тому, что они там собрались на WiMax форуме и написали филькину граммоту, и назвали её 802.16, а сами пользуются тайным знанием.... Нет тут никакой черной магии и белой тоже нет. Wimax forum не писал 802.16, а писал его IEEE комитет. Форум только брал оттуда куски и составлял "профайлы" о том, что называть wimax и как это пользовать. Насколько я знаю (а мой опыт восновном больше по MAC уровню) все делают в лоб по стандарту. Волшебной книги с рекомендациями как делать правильно не существует в природе. Причина ее отсутствия в том, что стандарт существенно меняется и написаная книга тут же устаревает. Хотя может, когда все всё сделают, поделят рынок и будут переходить на новый стандарт, то появится такая книга с исчерпывающим описанием великого прошлого. Теория OFDM(A) связи разработана в 50-х годах прошлого века. PHY Wimax-а ничего вобщем-то не изобретает а делает как по учебнику отличаясь нюансами. Вот на MAC уровне есть простарнство для фантазии, чем они и пользуются Стандарт пишут пару сотен разных инжинеров различной кваливикации и потом за это все голосуют. Так что при таком подходе ожидать ясности мысли в документе не приходится. Теоретически форум должен когда-то написать рекомендации по приминению стандарта, но так как это работа во многом скучная, никто там ей особо не занимаеться. Все просто делают а потом собираются на plugfest и проверяют как друг с другом работает. Иногда что-то проскакивает в преписках на форуме. Народ задает вопросы а потом кто-то добрый отвечает. Но тако бывает не часто а PHY еще реже. Основное для разработки PHY (ИМХО) иметь модель и оборудование для тестирования. В частности Agilent делает много для Wimax (ADS2008 и генераторы сигналов). И в их тулзах часто можно почерпнуть нужную информации. Однако полезней стандарта ничего не найти.
|
|
|
|
|
|
|
|
Feb 5 2009, 15:04
|
фанат Linux'а
Группа: Свой
Сообщений: 1 353
Регистрация: 23-10-05
Из: SPB.RU
Пользователь №: 10 008
|
Цитата(DMax @ Feb 4 2009, 18:10) Смешно, конечно, но по видимому так и есть. По крайней мере я уже не одну неделю пытаюсь сделать математическую модель коррелятора для преамбулы WiMax. Определенные результаты уже получил, но реализация их в ПЛИС будет занимать до хрена ресурсов. Я не верю, что разработчики стандарта исходили из того алгоритма, что придумал я, так как сделать дешевое устройство с такой большой плиской не реально. А стандарты ведь создаются с учетом того, чтобы технология пошла в массы. Основная идея стандарта заключается в том, что оборудование будет реализовано не на ПЛИС, а на специализированных микросхемах. А на ПЛИС дешево - не реально. Коррелятор там не так много занимает, просто надо знать как его делать За подробностями в личку Цитата Вот, например, Mobile Wimax определяет 114 преамбул. И они явно сформированы не случайным образом, однако никакого описания того, как их формировали, в общем доступе нет. А ведь наверняка, используя это свойство, можно построить коррелятор в разы оптимальней чем мой... Их формировали от балды, главное что в один момент времени - работает один "вид" преамбул... Они нужны чтобы определить сегмент и прочие параметры, чтобы преамбулы от разных баз не путались... Правильнее сделать загрузку эталонных отсчетов для каждого из видов преамбул, а коррелятор он все тот же... Цитата Поэтому склоняюсь к тому, что они там собрались на WiMax форуме и написали филькину граммоту, и назвали её 802.16, а сами пользуются тайным знанием.... Меня никогда не покидала мысль о том, что в случае wimax это... ТАК, Привет, единомышленник То же самое могу сказать и про 802.11b... Это чистое надругательство над мозгом. Типа, Intel и прочие богатенькие между собой договорятся и реализуют по быстрому совместимое оборудование, а другим и не положено знать =( Преамбула это еще цветочки, вот с мобильным ваймаксом его физическим уровнем запросто можно до суицида с массовыми жертвами дойти... Нет нигде справедливости! =(
--------------------
|
|
|
|
|
|
|
|
Feb 6 2009, 16:27
|
Частый гость
Группа: Свой
Сообщений: 161
Регистрация: 19-01-08
Из: Питер
Пользователь №: 34 234
|
Цитата(AVR @ Feb 5 2009, 18:04) Коррелятор там не так много занимает, просто надо знать как его делать За подробностями в личку Написал тебе в личку Цитата(AVR @ Feb 5 2009, 18:04) Их формировали от балды, главное что в один момент времени - работает один "вид" преамбул... Они нужны чтобы определить сегмент и прочие параметры, чтобы преамбулы от разных баз не путались... Правильнее сделать загрузку эталонных отсчетов для каждого из видов преамбул, а коррелятор он все тот же... Ммм... а как handover тогда делатся? Как определить какие базовые станции в округе? По очереди проверить все преамбулы, перезагружая коррелятор? Цитата(AVR @ Feb 5 2009, 18:04) Меня никогда не покидала мысль о том, что в случае wimax это... ТАК, Привет, единомышленник Привет Цитата(AVR @ Feb 5 2009, 18:04) То же самое могу сказать и про 802.11b... Это чистое надругательство над мозгом. Типа, Intel и прочие богатенькие между собой договорятся и реализуют по быстрому совместимое оборудование, а другим и не положено знать =( Ммм... странно с 802.11b у меня никакого геморра не было. А в чем у тебя проблема? Цитата(AVR @ Feb 5 2009, 18:04) Преамбула это еще цветочки, вот с мобильным ваймаксом его физическим уровнем запросто можно до суицида с массовыми жертвами дойти... Нет нигде справедливости! =( Да уж, постарались они там. Извращенцы
|
|
|
|
|
|
|
|
Mar 24 2016, 13:45
|
Частый гость
Группа: Участник
Сообщений: 100
Регистрация: 4-04-07
Пользователь №: 26 768
|
Всем привет! Решил потягаться с TPC стандарта IEEE 802.16. Практически сразу уперся рогом в стену непонимания.. В спутниковых модемах TPC по этому стандарту имеет кодовые скорости: 5/16, 21/44, 0.495, 3/4, 0.793, 7/8 и 0.95. Нашел в сети документ на ядро декодера TPC этого же стандарта.. там кодовые скорости какие угодно, но только не эти... единственное совпадение по 0.793. Каким образом они умудрились получить 21/44 или 0.495? Перебрал все возможные пары.. рядом есть.. но чтобы так точно ни в одно значение не попал...
Эскизы прикрепленных изображений
|
|
|
|
|
|
|
|
Mar 25 2016, 06:50
|
я только учусь...
Группа: Модераторы
Сообщений: 3 447
Регистрация: 29-01-07
Из: Украина
Пользователь №: 24 839
|
Цитата(Neznaika @ Mar 24 2016, 15:45) Всем привет!
Решил потягаться с TPC стандарта IEEE 802.16.
Практически сразу уперся рогом в стену непонимания..
В спутниковых модемах TPC по этому стандарту имеет кодовые скорости: 5/16, 21/44, 0.495, 3/4, 0.793, 7/8 и 0.95.
Нашел в сети документ на ядро декодера TPC этого же стандарта.. там кодовые скорости какие угодно, но только не эти... единственное совпадение по 0.793.
Каким образом они умудрились получить 21/44 или 0.495? Перебрал все возможные пары.. рядом есть.. но чтобы так точно ни в одно значение не попал... Определились с алгоритмом декодирования? 
--------------------
If it doesn't work in simulation, it won't work on the board.
"Ты живешь в своих поступках, а не в теле. Ты — это твои действия, и нет другого тебя" Антуан де Сент-Экзюпери повесть "Маленький принц"
|
|
|
|
|
|
|
|
Mar 25 2016, 14:09
|
Частый гость
Группа: Участник
Сообщений: 100
Регистрация: 4-04-07
Пользователь №: 26 768
|
Вы меня совсем запутали) Ранее делал TPC по стандарту DVB-RCS (не S2 - я ошибся). TPC делал на основе max-log-MAP. Потом делал LDPC по стандарту DVB-S2, вот там был алгоритм min-sum. Сейчас взялся за стандарт IEEE 802.16. Видел описание аналогичное DVB-RCS, потому и решил не заморачиваться и сделать на его базе, если его можно на min-sum как то сделать, то рассмотрю этот вариант.
Сейчас больше беспокоят исходные данные с коэффициентами кодирования.
Удалось выцарапать из вражеского модема информацию о том, что кадр BPSK, 5/16 имеет преамбулу в 32 бита и длину блока в 3840 бит. Поковырялся с коэффициентами и вроде как 5/16 можно попробовать сделать на 2-х размерном коде (16,11) на (16,11) и коэффициентом 2/3.. набрасывая еще метку получаем 5/16. А вот c 21/44 такой номер не прошел... почему то не удается засинхронизироваться по метке... она вроде такая же, но больше первого случая. Сейчас прервусь на отпуск в 9 дней и снова в бой)
|
|
|
|
|
|
|
|
Mar 30 2016, 12:31
|
я только учусь...
Группа: Модераторы
Сообщений: 3 447
Регистрация: 29-01-07
Из: Украина
Пользователь №: 24 839
|
Цитата(Serg76 @ Mar 25 2016, 17:40) Вы не подскажите, что обозначают в TPC коды (128,127)x(128,126) или (64,63)x(64,62). Как с ними работать? Для чего нужны? PS Таблицы взяты из описания ИМС aha4540Спасибо...
Эскизы прикрепленных изображений
--------------------
If it doesn't work in simulation, it won't work on the board.
"Ты живешь в своих поступках, а не в теле. Ты — это твои действия, и нет другого тебя" Антуан де Сент-Экзюпери повесть "Маленький принц"
|
|
|
|
|
|
|
|
Mar 30 2016, 17:55
|
я только учусь...
Группа: Модераторы
Сообщений: 3 447
Регистрация: 29-01-07
Из: Украина
Пользователь №: 24 839
|
Цитата(Serg76 @ Mar 30 2016, 20:46) Это двумерные коды с проверкой на четность, усиленные по Y оси еще одной дополнительной проверкой (hyper axis), как формируется уже не припомню, давненько было Это я уже понял, но все так поверхностно написано, хотелось бы каких то подробностей - по декодированию и кодированию таких кодов Может материалы остались или ссылки? можно в личку...
--------------------
If it doesn't work in simulation, it won't work on the board.
"Ты живешь в своих поступках, а не в теле. Ты — это твои действия, и нет другого тебя" Антуан де Сент-Экзюпери повесть "Маленький принц"
|
|
|
|
|
|
|
|
Apr 8 2016, 09:00
|
Частый гость
Группа: Участник
Сообщений: 100
Регистрация: 4-04-07
Пользователь №: 26 768
|
Пока особо не вникал в кодирование. Хочу разобраться в исходных параметрах для начала. Действительно в DVB-S2 описан сверточный турбо-код (ТСС), а в стандарте WiMax и сверточный (TCC) и блочный (TPC). В одной из статей написано, что для TCC нужна лицензия France Telecom и приведена пара недостатков по сравнению с TPC. Для TPC как я понимаю, лицензия не требуется.
Так вот во многих модемах для формирования TPC-кода используется микросхема AHA4501. У нее есть ограниченный набор кодов Хемминга с параметрами (4,3), (8,7), (16,15), (8,4), (16,11), (32,26) и (64,57). Вроде как есть незначительное отличие от WiMax в наборе.
Чтобы получить кодовую скорость для BPSK в 5/16 не хватает предоставленных вариантов. А формирования укороченных кодов микросхемой я не увидел. Кроме того, добавляется синхрометка, которая корректирует кодовую скорость.
В данном случае кодовый блок имеет размер 3872 бита, из которых 32 бита синхрометка. Как они умудрились тогда получить 5/16? Сама синхрометка вставляется в кодовое слово, затирая данные или все же идет дополнительное сжатие данных?
Т.е.:
5/16=(Kx2/Kx1)*(Ky2/Ky1)*(Kz2/Kz1)*(3840/3872) - с учетом коррекции кодовой скорости синхрометкой
5/16=(Kx2/Kx1)*(Ky2/Ky1)*(Kz2/Kz1) - без учета.
Пробовал посчитать коэффициенты и для 2D-кода, и для 3D-кода, и с учетом синхрометки и без учета - не получается ни в каких случаях.
Может они после микросхемы как то укорачивают код? В блок-схеме одного из модемов стоит отдельно AHA4501 и за ней блок вставки синхрометки. Упоминания про укороченный код нету(
Вот такая печалька...
Сообщение отредактировал Neznaika - Apr 8 2016, 09:05
|
|
|
|
|
|
|
|
Apr 12 2016, 17:40
|
Группа: Новичок
Сообщений: 4
Регистрация: 15-01-16
Пользователь №: 90 050
|
Цитата(Neznaika @ Apr 12 2016, 11:40) Удалось похоже разобраться с кодовой скоростью 5/16.
Ее можно получить с помощью укороченного 3D-кода с коэффициентами (15,10), (16,11), (16,11).
Учитывая длину блока в 3840 бит и длину преамбулы в 32 бита имеем:
(10/15)*(11/16)*(11/16)*(3840/3872)=0.3125=5/16
Ура! Ура! Ура!))
Теперь повозимся с кодовой скоростью 21/44...
Повозился..
Учитывая длину блока в 25088 бит и длину преамбулы в 80 бит имеем:
(11/16)*(26/32)*(42/49)*(25088/25168)=21/44 подскажите а где 21/44 с такими параметрами используется? когда я занимался турбиками, по-моему параметры у 21/44 были немного другие = (28,22)*(32,26)*(4,3)*7
|
|
|
|
|
|
|
|
Apr 12 2016, 18:30
|
я только учусь...
Группа: Модераторы
Сообщений: 3 447
Регистрация: 29-01-07
Из: Украина
Пользователь №: 24 839
|
Цитата(id85 @ Apr 12 2016, 20:40) подскажите а где 21/44 с такими параметрами используется?
когда я занимался турбиками, по-моему параметры у 21/44 были немного другие = (28,22)*(32,26)*(4,3)*7 вопрос как Вы использовали (4,3) при декодировании? + вопрос
--------------------
If it doesn't work in simulation, it won't work on the board.
"Ты живешь в своих поступках, а не в теле. Ты — это твои действия, и нет другого тебя" Антуан де Сент-Экзюпери повесть "Маленький принц"
|
|
|
|
|
|
|
|
Apr 12 2016, 20:20
|
Группа: Новичок
Сообщений: 4
Регистрация: 15-01-16
Пользователь №: 90 050
|
Цитата(Maverick @ Apr 12 2016, 18:30) вопрос как Вы использовали (4,3) при декодировании? + вопросдо нужного BER "вытягивали" коды по осям X и Y. по оси Z четность использовал как вспомогательный код, который "помогал" иксу и игреку. четность не сошлась - все метрики минус "один", сошлась - наоборот. а Вы как? Цитата(id85 @ Apr 12 2016, 20:10) до нужного BER "вытягивали" коды по осям X и Y. по оси Z четность использовал как вспомогательный код, который "помогал" иксу и игреку. четность не сошлась - все метрики минус "один", сошлась - наоборот.
а Вы как? на домашнем компьютере документы по этим кодам ((128,127)x(128,126) или (64,63)x(64,62)) - утеряны. если найду - то в дам знать
|
|
|
|
|
|
|
|
Apr 13 2016, 06:08
|
я только учусь...
Группа: Модераторы
Сообщений: 3 447
Регистрация: 29-01-07
Из: Украина
Пользователь №: 24 839
|
Цитата(id85 @ Apr 12 2016, 23:20) до нужного BER "вытягивали" коды по осям X и Y. по оси Z четность использовал как вспомогательный код, который "помогал" иксу и игреку. четность не сошлась - все метрики минус "один", сошлась - наоборот.
а Вы как?
на домашнем компьютере документы по этим кодам ((128,127)x(128,126) или (64,63)x(64,62)) - утеряны. если найду - то в дам знать спасибо Разбираюсь пока нет понимания...
--------------------
If it doesn't work in simulation, it won't work on the board.
"Ты живешь в своих поступках, а не в теле. Ты — это твои действия, и нет другого тебя" Антуан де Сент-Экзюпери повесть "Маленький принц"
|
|
|
|
|
|
|
|
Apr 13 2016, 07:10
|
Частый гость
Группа: Участник
Сообщений: 100
Регистрация: 4-04-07
Пользователь №: 26 768
|
Цитата(id85 @ Apr 12 2016, 20:40) подскажите а где 21/44 с такими параметрами используется?
когда я занимался турбиками, по-моему параметры у 21/44 были немного другие = (28,22)*(32,26)*(4,3)*7 21/44 - это кодовая скорость спутникового модема при модуляции BPSK или QPSK. Модемы как импортные, например CDM-600L, так и отечественные, например ЭТРА-МД4L. В обоих модемах используется микросхема AHA4501. Чуть выше я предложил свой вариант получения этой скорости, основываясь на параметрах этой микросхемы и зная длину кодового слова и длину преамбулы. Очень возможно, что на самом деле использованы немного другие параметры кода, но у меня получилось с теми, что я привел.
|
|
|
|
|
|
|
|
Apr 14 2016, 13:34
|
Частый гость
Группа: Участник
Сообщений: 100
Регистрация: 4-04-07
Пользователь №: 26 768
|
А как в-принципе формируется 3D-кодовое слово? Данные в куб записываются в какой очередности? Они как то по очереди пишутся в лицевую грань слева направо, а потом в следующий слой по оси Z? Чтобы получить кодовое слово нужно 3 кодера, работающих параллельно и формирующие одновременно грани по осям X,Y,Z или как? Или может нужна какая то опорная частота, превышающая скорость данных в разы и с помощью одного кодера происходит заполнение куба? Я уже голову сломал, в ИНЕТе очень скудно информации... Самый полезный документ для меня пока вот этот: http://www.ieee802.org/16/tg1/phy/contrib/802161pc-00_35.pdf
|
|
|
|
|
|
|
|
Apr 15 2016, 07:03
|
я только учусь...
Группа: Модераторы
Сообщений: 3 447
Регистрация: 29-01-07
Из: Украина
Пользователь №: 24 839
|
Цитата(Neznaika @ Apr 14 2016, 16:34) А как в-принципе формируется 3D-кодовое слово? Данные в куб записываются в какой очередности? Они как то по очереди пишутся в лицевую грань слева направо, а потом в следующий слой по оси Z? Чтобы получить кодовое слово нужно 3 кодера, работающих параллельно и формирующие одновременно грани по осям X,Y,Z или как? Или может нужна какая то опорная частота, превышающая скорость данных в разы и с помощью одного кодера происходит заполнение куба? Я уже голову сломал, в ИНЕТе очень скудно информации... Самый полезный документ для меня пока вот этот: http://www.ieee802.org/16/tg1/phy/contrib/802161pc-00_35.pdfДля 2D данные записываются по строчно (как я понял). Например для (64,57)x(46,39) записываются строками по 64 элемента. Всего строк будет 46. Третье измерение например (4,3) или (64,63) как я понял из интернета/форума - это проверка на четность, но как ее делать/использовать мне не понятно. Просьба если разбиретесь с третьим измерением или с ”enhanced” Turbo Product Codes (eTPCs)" прошу поделиться информацией.
--------------------
If it doesn't work in simulation, it won't work on the board.
"Ты живешь в своих поступках, а не в теле. Ты — это твои действия, и нет другого тебя" Антуан де Сент-Экзюпери повесть "Маленький принц"
|
|
|
|
|
|
|
|
Apr 15 2016, 19:07
|
Группа: Новичок
Сообщений: 4
Регистрация: 15-01-16
Пользователь №: 90 050
|
Цитата(Maverick @ Apr 15 2016, 07:03) Для 2D данные записываются по строчно (как я понял).
Например для (64,57)x(46,39) записываются строками по 64 элемента. Всего строк будет 46.
Третье измерение например (4,3) или (64,63) как я понял из интернета/форума - это проверка на четность, но как ее делать/использовать мне не понятно.
Просьба если разбиретесь с третьим измерением или с ”enhanced” Turbo Product Codes (eTPCs)" прошу поделиться информацией. могу выслать программу для формирования кодов tpc. для пробного декодирования. есть поддержка 2д и 3д. еслу нужно - дайте знать
|
|
|
|
|
|
|
|
Apr 18 2016, 07:17
|
Частый гость
Группа: Участник
Сообщений: 100
Регистрация: 4-04-07
Пользователь №: 26 768
|
И мне) И мне)) На andrusha_grig-v@mail.ru) Спасибо) По поводу реализации кодера... В Инете есть описание ядра кодера фирмы Xilinx: http://www.xilinx.com/support/documentatio...coder_ds211.pdfТак вот... там прописано, что для кода (8,4)*(8,4) задержка составляет 13 тактов. Вообще TPC-кодер для этого стандарта не имеет задержки. Походу эти 13 тактов тратятся на сохранение данных в ячейках памяти, таким образом, чтобы при формировании проверочной информации не использовались одновременно ячейки в которые нужно записывать и считывать. Формирование проверочной информации на мой взгляд должно происходить параллельно двумя кодерами после 13 такта, тогда мы уложимся в нужное число тактов кодового слова. Задержка 13 тактов также позволит уже иметь входные данные для 2-го кодера, работающего по оси Y. Что касается 3D-кодов, то там видимо нужно заполнить минимальное количество куба данных, чтобы возможна была работа одновременно 3 кодеров. Пока не ясна проблема организации памяти, будем еще подуматЪ)
Сообщение отредактировал Neznaika - Apr 18 2016, 07:28
|
|
|
|
|
|
|
|
Sep 5 2016, 07:36
|
Частый гость
Группа: Участник
Сообщений: 100
Регистрация: 4-04-07
Пользователь №: 26 768
|
Всем привет! Вот и пришло время связать меня крепкими узами любви с BTC-декодером стандарта WiMAX. Покопался в ИНЕТе, информации очень мало и она скудна. Лишь только в одной статье наших китайских друзей удалось найти более-менее разжеванную версию декодера. Но и в ней не очень много ясности. Исходя из просмотренной литературы многие склоняются к использованию алгоритма Чейза в этом типе декодера. Как я понимаю на данный момент, процесс декодирования заключается в поиске среди мягких решений полученного кадра 2 или 3 значений с минимальными вероятностями. Какое количество брать и в связи с чем не очень понятно. Видел пример с 3. Это нам дает возможность сформировать 2^3=8 тестовых последовательностей. Далее проводим декодирование жестких решений 8 тестовых последовательностей, где на позициях с малой вероятностью располагаются все возможные биты, какие там могут быть, т.е. с целью перебора всех возможных вариантов. После декодирования БЧХ-декодером, получаем 8 возможных исправленных вариантов. Далее сравниваем их с кадром из мягких решений, смотрим какое максимально приближено, то и выбираем. Как получить далее новые мягкие решения мне пока не понятно, но пока еще рано. В чем собственно вопрос?) В статье нашего китайского друга приведены несколько другие этапы декодирования. И в начале они делают жесткие решения, по ним проводят БЧХ-декодирование и получают синдром. Далее ищут позиции с самыми низкими вероятностями и выполняют какие то магические манипуляции с полученными данными. Вообще полученный синдром нам уже дает позицию с ошибкой (декодер Хемминга как я понимаю способен исправить только 1 ошибку), в том случае, если она одна.. если больше, то позиции 2-х и более ошибок не определить. Статью и блок-схему прикрепил к сообщению. Кто-нибудь из гуру блочных турбокодов может прокомментировать сложившуюся ситуацию?
Эскизы прикрепленных изображений
Прикрепленные файлы
168101.pdf ( 1.03 мегабайт )
Кол-во скачиваний: 37
|
|
|
|
|
|
|
|
Sep 5 2016, 09:53
|
я только учусь...
Группа: Модераторы
Сообщений: 3 447
Регистрация: 29-01-07
Из: Украина
Пользователь №: 24 839
|
Цитата(Neznaika @ Sep 5 2016, 10:36) Всем привет! Вот и пришло время связать меня крепкими узами любви с BTC-декодером стандарта WiMAX. Покопался в ИНЕТе, информации очень мало и она скудна. Лишь только в одной статье наших китайских друзей удалось найти более-менее разжеванную версию декодера. Но и в ней не очень много ясности. Исходя из просмотренной литературы многие склоняются к использованию алгоритма Чейза в этом типе декодера.
Как я понимаю на данный момент, процесс декодирования заключается в поиске среди мягких решений полученного кадра 2 или 3 значений с минимальными вероятностями. Какое количество брать и в связи с чем не очень понятно. Видел пример с 3. Это нам дает возможность сформировать 2^3=8 тестовых последовательностей. Далее проводим декодирование жестких решений 8 тестовых последовательностей, где на позициях с малой вероятностью располагаются все возможные биты, какие там могут быть, т.е. с целью перебора всех возможных вариантов. После декодирования БЧХ-декодером, получаем 8 возможных исправленных вариантов. Далее сравниваем их с кадром из мягких решений, смотрим какое максимально приближено, то и выбираем. Как получить далее новые мягкие решения мне пока не понятно, но пока еще рано.
В чем собственно вопрос?) В статье нашего китайского друга приведены несколько другие этапы декодирования. И в начале они делают жесткие решения, по ним проводят БЧХ-декодирование и получают синдром. Далее ищут позиции с самыми низкими вероятностями и выполняют какие то магические манипуляции с полученными данными.
Вообще полученный синдром нам уже дает позицию с ошибкой (декодер Хемминга как я понимаю способен исправить только 1 ошибку), в том случае, если она одна.. если больше, то позиции 2-х и более ошибок не определить.
Статью и блок-схему прикрепил к сообщению. Кто-нибудь из гуру блочных турбокодов может прокомментировать сложившуюся ситуацию? очень сильно напоминает алгоритм Чейзапроблема в том, что чейз не дает на выходе мягкие данные для следующих итераций (второй и более итераций). есть доработанный алгоритм - вложение
--------------------
If it doesn't work in simulation, it won't work on the board.
"Ты живешь в своих поступках, а не в теле. Ты — это твои действия, и нет другого тебя" Антуан де Сент-Экзюпери повесть "Маленький принц"
|
|
|
|
|
|
|
|
Sep 6 2016, 07:21
|
Частый гость
Группа: Участник
Сообщений: 100
Регистрация: 4-04-07
Пользователь №: 26 768
|
Спасибо, Алексей, за ответ) По первой ссылке я был и даже удалось пообщаться с автором статьи по некоторым непонятным вопросам. На базе этого примера алгоритма Чейза действительно не определить мягкие решения. Глянул вашу вторую статью, с ходу разобраться сложно, но наверно можно. В инете нарыл немного другую статейку с живым примером (прикрепил к сообщению), но и там увы не все понятно. Пока у меня в голове получаются следующие этапы: 1. Находим позиции с меньшими вероятностями. 2. Заменяем их всеми возможными значениями 1 и 0, формируя тестовые последовательности. 3. Принимаем жесткие решения по остальным битам. 4. Декодируем полученные тестовые вектора БЧХ-декодером. 5. Далее модулируем их при образуя в вектора со значениями (1,-1). 6. Исходя из примера моей статьи проводим столько этапов, сколько у нас векторов. 7. Вычисляем вероятность L=1/2(S_плюс-S_минус). Я на верном пути или где то глубоко заблуждаюсь? В статье откуда то берутся значения p(c_i).. откуда они?
Эскизы прикрепленных изображений
|
|
|
|
|
|
|
|
Apr 20 2017, 13:25
|
Частый гость
Группа: Участник
Сообщений: 100
Регистрация: 4-04-07
Пользователь №: 26 768
|
Всем привет! На днях закончил реализацию BTC-декодера (16,11,4)x (16,11,4)x (16,11,4). Получил BER(6дБ)=10^-5 и BER(8дБ)=10^-7. Использовал алгоритм Chase-Pyndiah. Хотелось бы попробовать чего-нибудь по мощнее. Нашел статью, прикрепленную к сообщению, там вроде как алгоритм посерьезнее описан, но к сожалению указана вспомогательная статья к которой не имею доступа. Может есть у кого? S.K. Shin, S.I. Lee, and S.P. Lee, “Evaluation of Block Turbo Code Performance with the Reduced Search Trellis Decoding Method,” IEE Proc. Communications, vol. 148, no. 3, June 2001 Буду признателен за помощь)
|
|
|
|
|
|
|
|
Apr 20 2017, 13:56
|
Профессионал
Группа: Участник
Сообщений: 1 050
Регистрация: 4-04-07
Пользователь №: 26 775
|
Цитата(Neznaika @ Apr 20 2017, 16:25) Всем привет! На днях закончил реализацию BTC-декодера (16,11,4)x (16,11,4)x (16,11,4). Получил BER(6дБ)=10^-5 и BER(8дБ)=10^-7. Использовал алгоритм Chase-Pyndiah. 6 и 8 дБ соответствуют Eb/No? Если так, то, очевидно, что у Вас просто ужасная реализация декодера. К примеру, AHA для вашей конфигурации кода дает следующие результаты: BER(Eb/No= 1,7дБ)=10^-5 и BER(Eb/No= 2дБ)=10^-7. Даже декодер с жестким решением даст больший ЭВК, нежели получился у Вас(((.
|
|
|
|
|
|
|
|
Apr 20 2017, 18:47
|
я только учусь...
Группа: Модераторы
Сообщений: 3 447
Регистрация: 29-01-07
Из: Украина
Пользователь №: 24 839
|
Цитата(Neznaika @ Apr 20 2017, 16:25) Всем привет! На днях закончил реализацию BTC-декодера (16,11,4)x (16,11,4)x (16,11,4). Получил BER(6дБ)=10^-5 и BER(8дБ)=10^-7. Использовал алгоритм Chase-Pyndiah. Хотелось бы попробовать чего-нибудь по мощнее. Нашел статью, прикрепленную к сообщению, там вроде как алгоритм посерьезнее описан, но к сожалению указана вспомогательная статья к которой не имею доступа.
Может есть у кого?
S.K. Shin, S.I. Lee, and S.P. Lee, “Evaluation of Block Turbo
Code Performance with the Reduced Search Trellis Decoding
Method,” IEE Proc. Communications, vol. 148, no. 3, June 2001
Буду признателен за помощь) Ответил в почту
--------------------
If it doesn't work in simulation, it won't work on the board.
"Ты живешь в своих поступках, а не в теле. Ты — это твои действия, и нет другого тебя" Антуан де Сент-Экзюпери повесть "Маленький принц"
|
|
|
|
|
|
|
|
Apr 21 2017, 07:13
|
Частый гость
Группа: Участник
Сообщений: 100
Регистрация: 4-04-07
Пользователь №: 26 768
|
По поводу результата... АНА - это АНА, они всю жизнь занимаются помехоустойчивым кодированием и продвинулись в этой области очень далеко. Я ориентировался на результаты статей, которые нашел в ИНЕТе. Искал непосредственно реализацию 3D-кода, а именно (16,11,4)^3. Перебрав кучу статей у меня сложилось впечатление, что наиболее популярный метод декодирования Сhase-Pyndiah не так уж безгрешен. Обычно приводят результаты его работы на низком отношении сигнал/шум до 2.5дБ. Именно в этой области BER получается максимально приближено к границе Шеннона, а вот что происходит на больших отношениях сигнал/шум показывают редко. Все что удалось найти по этому вопросу прикрепил к посту.
Эскизы прикрепленных изображений
|
|
|
|
|
|
|
|
Apr 21 2017, 08:11
|
Профессионал
Группа: Участник
Сообщений: 1 050
Регистрация: 4-04-07
Пользователь №: 26 775
|
Цитата(Neznaika @ Apr 21 2017, 10:13) По поводу результата... АНА - это АНА, они всю жизнь занимаются помехоустойчивым кодированием и продвинулись в этой области очень далеко. Я ориентировался на результаты статей, которые нашел в ИНЕТе. Искал непосредственно реализацию 3D-кода, а именно (16,11,4)^3. Перебрав кучу статей у меня сложилось впечатление, что наиболее популярный метод декодирования Сhase-Pyndiah не так уж безгрешен. Обычно приводят результаты его работы на низком отношении сигнал/шум до 2.5дБ. Именно в этой области BER получается максимально приближено к границе Шеннона, а вот что происходит на больших отношениях сигнал/шум показывают редко. Все что удалось найти по этому вопросу прикрепил к посту. АНА - это АНА, согласен, но приблизиться к их результатам, используя Чейза, вполне реально. Я привел результаты AHA к тому, чтобы продемонстрировать, что Вы не совсем полностью реализовали корректирующую способность алгоритма Чейза, а уже собрались переходить к другому алгоритму. В прикрепленной Вами последней статье как раз приведен результат для Вашей конфигурации кода - (16,11)^3. ЭВК составляет 8,5 дБ для Pb=10^-6, судя по Вашим результатм - это "космос". Кстати, может Вы не совсем верно сняли характеристики своего декодера?
|
|
|
|
|
|
|
|
Apr 21 2017, 09:23
|
Профессионал
Группа: Участник
Сообщений: 1 050
Регистрация: 4-04-07
Пользователь №: 26 775
|
Цитата(Neznaika @ Apr 21 2017, 12:07) Почему космос то? Я изначально указывал что при 8дБ Еb/No у меня BER=10^-7, мне видится это немного лучше, чем в третьей статье.. Измерения проводил с живым шумом и с BPSK сигналом. Выигрывать 1-2 дБ за счёт оптимизации архитектуры пока не вижу смысла, а приближения алгоритма к результатам АНА не видел ни в одной статье. Однако есть патент АНА на SISO блочного турбо декодера, там описан как раз алгоритм, напоминающий Чейза. Но патент 2006 года, а кодеки они делают гораздо раньше. К сожалению в патенте не приводится BER и зачем он им мне пока не понятно. Попробую с ним пока покопаться.. Может они там не алгоритм, а какую то идею в этом алгоритме запатентовали.. Ну а как по-другому? Если у вас BER=10^-7 достигается при 8дБ Еb/No, а в AHA эта же вероятность достигается при Eb/No=2дБ, т.е разница в реализациях 6 дБ !!!!!, куда же это годиться?. Да и 1-2 дБ энергетического проигрыша - это тоже непозволительная роскошь, это примерно разница между жестким и мягким декодированием. Кроме того, в статье приведено значение Coding Gain, т.е. ЭВК - разница между кодированной и некодированной передачей, а не абсолютного значения Еb/No. Разберитесь, что и как Вы измеряли, может оказаться, что не все так плохо с декодером.
|
|
|
|
|
|
|
|
Apr 21 2017, 11:30
|
Частый гость
Группа: Участник
Сообщений: 100
Регистрация: 4-04-07
Пользователь №: 26 768
|
В модели я контролирую количество ошибок на входе и на каждой полуитерации. При входном BER в 4*10^-2, декодер выдает чистые нули после 1.5 итераций. Такой входной BER характерен Eb/No около 2дБ.
В железе ошибки появляются на 8 дБ и сам характер работы декодера напоминает работу одной итерации. Что вторая итерация, что 4-ая... особой разницы не видел +-1дБ по BER. Первая итерация раз в 10 дает результат хуже, чем остальные.
К демодулятору также вопросов не имею, так как LDPC-декодер нормально работает с ним на 2.5дБ.
Убивает то, что по одинаковым входным значениям модель и железо работают одинаково) Либо я в модели не те тесты подаю или есть какая то серьезная ошибка в архитектуре, либо пора обращаться к экстрасенсам...
Архитектура без оптимизации, в канальной памяти хранятся данные из канала, они подаются на SISO, который выдает мягкие решения. Записываем их в RAM внешней информации. После, эти же значения складываем со значениями из канальной памяти и снова подаем на SISO и т.д. Первоначально обрабатываются строки по Х, потом колонки по Y и колонки по оси Z. Далее следует новая итерация, но уже на 2-ой итерации имеем внешнюю информацию от Z. В оптимизационных архитектурах видел, что внешняя информация двух осей складывается для вычисления мягких решений по третьей. Но в данном случае не верится, что это сильно поможет делу.
Сообщение отредактировал Neznaika - Apr 21 2017, 11:32
|
|
|
|
|
|
|
|
Apr 21 2017, 12:11
|
Профессионал
Группа: Участник
Сообщений: 1 050
Регистрация: 4-04-07
Пользователь №: 26 775
|
Цитата(Neznaika @ Apr 21 2017, 14:30) В модели я контролирую количество ошибок на входе и на каждой полуитерации. При входном BER в 4*10^-2, декодер выдает чистые нули после 1.5 итераций. Такой входной BER характерен Eb/No около 2дБ. При Eb/No около 2дБ на входе, - 0 ошибок на выходе - это нормально, так и должно быть, хотя картина неполная, желательно промерять во всем рабочем диапазоне. Цитата(Neznaika @ Apr 21 2017, 14:30) В железе ошибки появляются на 8 дБ и сам характер работы декодера напоминает работу одной итерации. Что вторая итерация, что 4-ая... особой разницы не видел +-1дБ по BER. Эти 8 дБ - это SNR или Eb/No и в какой точке приемного тракта измерены и при какой модуляции? у меня сложилось такое мнение, что у Вас с методикой измерения не все в порядке. Цитата(Neznaika @ Apr 21 2017, 14:30) К демодулятору также вопросов не имею, так как LDPC-декодер нормально работает с ним на 2.5дБ. эта фраза вообще ни о чем не говорит, LDPC и демодуляторы бывают разные. Цитата(Neznaika @ Apr 21 2017, 14:30) Убивает то, что по одинаковым входным значениям модель и железо работают одинаково) Либо я в модели не те тесты подаю или есть какая то серьезная ошибка в архитектуре, либо пора обращаться к экстрасенсам... как же одинаково, если такие разные результаты получаются по децибеллам, значит неправильно измерения проводите.
|
|
|
|
|
|
|
|
Apr 24 2017, 06:59
|
Частый гость
Группа: Участник
Сообщений: 100
Регистрация: 4-04-07
Пользователь №: 26 768
|
На первом рисунке привел диалоговое окно модели. Длина кадра 3840 бит. Видно как исправляются ошибки от оси к оси. Если брать меньшее отношение сигнал/шум, то после первой уже полуитерации по оси Х ошибок почти нет. Что касается демодулятора, то на втором рисунке приведена BER работы LDPC-декодера по стандарту DVB-S2 с длиной блока 16200 бит. Видно, что при BPSK модуляции и кодовой скоростью 11/15 на 2.5 дБ результат его работы неплохой. О чем я заключаю, что демодулятор в полном порядке. А измерения проводил по разному. Первоначально оценивал BER на входе BTC-декодера и видел, что при входном BER 10^-2 (около 4 дБ некодированных данных) после декодера появляются ошибки. Так же проводил контрольные измерения Eb/No c помощью вражеского модема CDM-600 на тех же настройках, не меняя параметров генератора шума. И он подтверждал мои оценки Eb/No. Вот только на 5-8 дБ он давал нули, а мой декодер на 8дБ выдавал BER=10^-7. Сергей, спасибо, за ваши ответы) Вы меня неплохо подзарядили. Очень надеюсь, что ошибка будет найдена в скором времени... Обычно всегда находилась)
Эскизы прикрепленных изображений
|
|
|
|
|
|
|
|
Apr 24 2017, 07:47
|
Профессионал
Группа: Участник
Сообщений: 1 050
Регистрация: 4-04-07
Пользователь №: 26 775
|
Да не за что, в принципе. Да, видно, что Ваш декодер не дотягивает до фирменного, вопрос только в том, насколько? Давайте так, хоть это и не совсем корректно: Вы можете сказать, при каком соотношении Eb/No на фирменном модеме "практически" будут отсутствовать ошибки? По характеристикам кода это должно наступить где-то в районе Eb/No > 2...2,5 dB с учетом потерь демодулятора в BPSK/QPSK режимах. Если это наступит при более высоких значениях Eb/No, то тогда к ошибкам реализации декодера добавятся еще и ошибки методики измерений.
|
|
|
|
|
|
|
|
Apr 24 2017, 11:38
|
Профессионал
Группа: Участник
Сообщений: 1 050
Регистрация: 4-04-07
Пользователь №: 26 775
|
Цитата(Neznaika @ Apr 24 2017, 12:56) CDM-600 работает до Eb/No=5дБ с BER=0 на BPSK 5/16. Далее у него идёт срыв синхронизации. Фактически это уже 0 дБ, Вы ничего не путаете, как промышленный модем в такой мощной конфигурации BPSK + FEC 1/3 работает при Eb/No>5 dB. Он без проблем должен работать при более низкой энергетике, для Eb/No>2 dB он должен выдавать практически нулевой BER. Как измеряете Eb/No? Цитата(Serg76 @ Apr 24 2017, 14:04) Вы ничего не путаете, как промышленный модем в такой мощной конфигурации BPSK + FEC 1/3 работает при Eb/No>5 dB. Он без проблем должен работать при более низкой энергетике, для Eb/No>2 dB он должен выдавать практически нулевой BER. Как измеряете Eb/No? Так и есть, модем CDM-625, режим BPSK + FEC 5/16 дает BER 1e-6 при Eb/No = 2,5 dB, полдецибела на потери реализации.
|
|
|
|
|
|
|
|
Jun 28 2017, 08:51
|
Частый гость
Группа: Участник
Сообщений: 100
Регистрация: 4-04-07
Пользователь №: 26 768
|
Всем привет! Решил снова обратиться к гуру кодирования) 5/16 удалось временно победить, устранил пару ошибок в железе при работе с памятью и декодер на BPSK стал работать без ошибок до срыва синхронизации демодулятора при 5дБ, аналогично работе CDM-600. Стал копаться со скоростью 21/44 на BPSK. Длина кадра 25088 бит. Из-за того, что CDM-600 использует микросхему AHA, а в ней максимальный блок данных может быть около 4 кбит, то наши "партнеры" из Америки, решили выкрутиться и разбили 25088 бит на 7 блоков. Каждый блок состоит из 3 страниц полезной информации и 1 страницы, сформированной из предыдущих 3 путем операции XOR. Все 4 страницы кодируются 2D-кодером.
Вопрос встал, что делать с данными 4-ой страницы?..
Первоначально декодирую все 4 страницы по оси Х и Y декодером Чейза. Аналогично 3D-декодеру, по оси Z беру слова, состоящие из данных 4-х страниц: 3 бита полезной информации и 1 бит проверочный, полученный через XOR из предыдущих бит. Для параллельности процесса беру сразу несколько 4-к... В одном случае 5, в другом 6 (из-за укороченного кода по оси Y)... Провожу декодирование аналогичное декодированию по алгоритму Чейза... Нахожу позиции полезных бит с минимальными вероятностями, формирую тестовые вектора, а затем просто пересчитываю 4-ые биты. Далее вычисляю метрики и аналогично алгоритму Чейза вычисляю мягкие решения.
В результате, получаю, что декодирование по оси Z ухудшает кодовое усиление декодера. Результат декодирования только по осям X и Y заметно лучше, но BER=10^-6 на Eb/No=5дБ. Наверняка сидит что-то серьезное... но.. Что делать с осью Z?... Очевидно, что мой способ декодирования по Z дает ошибку.. Может кто знает или подскажет как использовать данные 4-ой страницы?
|
|
|
|
|
|
|
 |
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|
WiMAX
