|
|
|
модель 8PSK модема |
|
|
|
Jun 29 2009, 05:23
|
Вечный ламер
Группа: Модераторы
Сообщений: 7 248
Регистрация: 18-03-05
Из: Томск
Пользователь №: 3 453
|
Цитата(petrov @ Jun 28 2009, 05:22) Да может разваливаться, в этом и проблема эквалайзеров и совместной синхронизации, от любого чиха разваливаются или уходят в паразитное устойчивое состояние, тут в общем просто демонстрация алгоритма адаптации более быстрого чем обычный LMS, здесь нет решения всех проблем которые возникают. спасибо за модель, но есть несколько вопросов. Сначала по методу : 1. Почему вы нормируете дельту не на мощность сигнала, а на амплитуду? 2. Почему у вас при нормировке есть дополнительная задержка на следующий такт? ИМХО из за этого слетает алгоритм обновления. Тот же Diniz пишет следующее (см. атач) я заменил в FSE плече амплитуду на мощность с бесконечной памятью канала эквалайзер стал вести себя более спокойно. Теперь по структуре: Я отключил DF звено ( выход на терминатор, на вход сумматора 0). И эквалайзер вообще не может найти решение, странно по идее оно должно быть, пусть и с более плохим качеством. Почему так происходит? И вопрос всем по реализации. По идее мощность это квадрат сигнала, но вот как поступают при переносе вычислений в форматы с фиксированной запятой. Например есть созвездие 0.5+i0.5, в этом случае мощность составит 0.5, при нормировке это даст 1, но если рассмотреть реальное железо, пусть это будут 8ми битные точки 128 +128i, тогда мощность составит 32768 и нужно вводить скалирующие коэффициенты, что бы привести это к общему знаменателю. В принципе для созвездия 0.5+i0.5 это просто, но как быть когда созвездие например такое [0.5+i0.5 1.5+i0.5 0.5+i1.5 1.5+i1.5] ведь в этом случае так просто отскалировать не получиться? Я вижу решение в нормировке созвездия к единице, т.е. привести его к виду [0.25+i0.25 0.75+i0.25 0.25+i0.75 0.75+i0.75] и дальше идти обычному пути. Делать надо так или я изобретаю велосипед? Спасибо. Цитата(Oldring @ Jun 28 2009, 06:53) Меня тоже удивило что не упоминается в литературе взаимодействие эквалайзера с синхронизатором и AGC. Хотя то что неприятности неизбежны, после прочтения базовой теории, изложенной в Хайкине, становится очевидным. Вы не встречали статей по этой теме? в книге The Theory and Practice of Modem Design, John A.C. Bingham, (с) 1988 John Wiley & Sons, Inc есть главы 7.5 Timing Recovery for Symbol-Rate Adaptive Equalizers и 7.6 Timing Recovery for Fractionally Rate Adaptive Equalizers
Эскизы прикрепленных изображений
--------------------
|
|
|
|
|
Jun 29 2009, 09:47
|
Гуру
Группа: Свой
Сообщений: 2 220
Регистрация: 21-10-04
Из: Balakhna
Пользователь №: 937
|
Цитата(des00 @ Jun 29 2009, 09:23) 1. Почему вы нормируете дельту не на мощность сигнала, а на амплитуду? С мощностью мне показался вариант слишком быстрым, в целом модем получается менее устойчивым, например эквалайзер начинает конкурировать с петлёй символьной синхронизации, центральный коэффициент улетает на край и затем развал. Смотрите как лучше для вашего случая, для не сильно искажённых каналов достаточно просто АРУ перед эквалайзером, нормировку в эквалалайзере можно выкинуть. Цитата(des00 @ Jun 29 2009, 09:23) 2. Почему у вас при нормировке есть дополнительная задержка на следующий такт? Просто перетащил фильтр из другой модели, конечно можно задержку убрать, но в самом фильтре есть задержка, тем больше чем меньше альфа. Цитата(des00 @ Jun 29 2009, 09:23) Я отключил DF звено ( выход на терминатор, на вход сумматора 0). И эквалайзер вообще не может найти решение, странно по идее оно должно быть, пусть и с более плохим качеством. Почему так происходит? С таким каналом с гуляющими спектральными нулями линейный эквалайзер не справится, уменьшайте амплитуду задержанного луча относительно главного и скорость измененния канала наверное тоже, также возможно нужно увеличение количества коэффициентов. Цитата(des00 @ Jun 29 2009, 09:23) По идее мощность это квадрат сигнала, но вот как поступают при переносе вычислений в форматы с фиксированной запятой. Например есть созвездие 0.5+i0.5, в этом случае мощность составит 0.5, при нормировке это даст 1, но если рассмотреть реальное железо, пусть это будут 8ми битные точки 128 +128i, тогда мощность составит 32768 и нужно вводить скалирующие коэффициенты, что бы привести это к общему знаменателю. В принципе для созвездия 0.5+i0.5 это просто, но как быть когда созвездие например такое [0.5+i0.5 1.5+i0.5 0.5+i1.5 1.5+i1.5] ведь в этом случае так просто отскалировать не получиться?
Я вижу решение в нормировке созвездия к единице, т.е. привести его к виду [0.25+i0.25 0.75+i0.25 0.25+i0.75 0.75+i0.75] и дальше идти обычному пути. Делать надо так или я изобретаю велосипед? В общем тут без комментариев, сам всегда мучаюсь с такими вопросами, [0.5+i0.5 1.5+i0.5 0.5+i1.5 1.5+i1.5] и [0.25+i0.25 0.75+i0.25 0.25+i0.75 0.75+i0.75] - по сути это одно и то же, ведь нет же никакой запятой в 8-ми битной шине, она у нас в голове.
|
|
|
|
|
Apr 10 2010, 14:29
|
Частый гость
Группа: Свой
Сообщений: 106
Регистрация: 4-12-09
Из: Н. Новгород
Пользователь №: 54 053
|
Добавил в модель petrov-а петлю костаса для qam16. matlab 2009b
|
|
|
|
|
Apr 23 2010, 16:20
|
Частый гость
Группа: Свой
Сообщений: 106
Регистрация: 4-12-09
Из: Н. Новгород
Пользователь №: 54 053
|
Цитата(petrov @ Apr 15 2010, 15:08) К статье Костаса это отношения не имеет. Собирал по книжке Незами ст. 110 рис. 3-20. Цитата(petrov @ Apr 15 2010, 15:08) Уже обсуждалось Если уже обсуждалось - укажите, пожалуйста, где именно. Видел только вариант для BPSK. Цитата(petrov @ Apr 15 2010, 15:08) Непонятно зачем использовать плохой вариант управления решениями, если можно использовать управление решениями? Опять же, ссылку на модель/статью/на словах обьясните, как сделать правильное управление решениями. Я не волшебник, я только учусь )
|
|
|
|
|
Apr 24 2010, 16:33
|
Гуру
Группа: Свой
Сообщений: 2 220
Регистрация: 21-10-04
Из: Balakhna
Пользователь №: 937
|
Цитата(voloda @ Apr 24 2010, 19:58) Впринципе, конечно, управление решениями, выложенное во всех моделях этой ветки - точнее. Но вычисление фазы комплексного сигнала процесс не быстрый. Может быть, модель, в которой используются только умножатели - пошустрее будет?
Если тема уже обсуждалась, дайте ссылку. В моделях вычисление аргумента так сделано для очевидности того что является ошибкой - угол поворота принимаемого созвездия относительно решений, можно и без вычисления аргумента это делать - Im(conj(soft)*decision), только надо учитывать что коэффициент передачи такого такого детектора зависит от амплитуды сигнала. Так и сделано в том детекторе для QPSK с управлением решениями который все почему-то неправильно называют Костасом. Так почему бы сразу не использовать управление решениями для 16QAM не извращаясь с детектором для QPSK? http://electronix.ru/forum/index.php?showtopic=71563
|
|
|
|
|
Apr 27 2010, 13:08
|
Частый гость
Группа: Свой
Сообщений: 106
Регистрация: 4-12-09
Из: Н. Новгород
Пользователь №: 54 053
|
Цитата(petrov @ Apr 24 2010, 20:33) В моделях вычисление аргумента так сделано для очевидности того что является ошибкой - угол поворота принимаемого созвездия относительно решений, можно и без вычисления аргумента это делать - Im(conj(soft)*decision), только надо учитывать что коэффициент передачи такого такого детектора зависит от амплитуды сигнала. Так и сделано в том детекторе для QPSK с управлением решениями который все почему-то неправильно называют Костасом. Так почему бы сразу не использовать управление решениями для 16QAM не извращаясь с детектором для QPSK? http://electronix.ru/forum/index.php?showtopic=715631) Пока что не совсем понял, откуда можно вывести Im(conj(soft)*decision) - из управления решениями или из той модели, которую по ошибке называют Костасом? Или все три решения - одинаковы и два других можно вывести из третьего? 2) В созвездии 16QAM можно взять точки, не лежащие на QPSK. Но неоднозначность фазы там будет 2pi/8, а не 2pi/4 , как для под-QPSK созвездий. Возможна ситуация, когда по точкам под-QPSK будет выдаваться ошибка одного знака, а по не под-QPSK - другого. Тоесть они будут вращать частоту в разные стороны. При расстройке частоты 0.03 0.04, модель, которая работает только по под-QPSK созвездиям ищет решение быстрее. 3) Добавил управление по решению Im(conj(soft)*decision). Впринципе находит решение и без учета зависимости коэффициента передачи от амплитуды сигнала. 4) Спасибо за ссылку. Интересно.
|
|
|
|
|
Apr 27 2010, 14:14
|
Гуру
Группа: Свой
Сообщений: 2 220
Регистрация: 21-10-04
Из: Balakhna
Пользователь №: 937
|
Цитата(voloda @ Apr 27 2010, 17:08) 1) Пока что не совсем понял, откуда можно вывести Im(conj(soft)*decision) Это же очевидно чему это выражение пропорционально, синусу разности фаз между решением и принимаемым вектором. Цитата(voloda @ Apr 27 2010, 17:08) 2) В созвездии 16QAM можно взять точки, не лежащие на QPSK. Но неоднозначность фазы там будет 2pi/8, а не 2pi/4 , как для под-QPSK созвездий. Возможна ситуация, когда по точкам под-QPSK будет выдаваться ошибка одного знака, а по не под-QPSK - другого. Тоесть они будут вращать частоту в разные стороны. При расстройке частоты 0.03 0.04, модель, которая работает только по под-QPSK созвездиям ищет решение быстрее. Для сопровождения характеристики этого детектора будут хуже, а для большей полосы захвата и более быстрой настройки на начальном этапе лучше использовать непосредственно BPSK, QPSK. Цитата(voloda @ Apr 27 2010, 17:08) 3) Добавил управление по решению Im(conj(soft)*decision). Впринципе находит решение и без учета зависимости коэффициента передачи от амплитуды сигнала. Имелось ввиду что коэффициент передачи детектора нужно учитывать при анализе ФАПЧ.
|
|
|
|
|
|
5 чел. читают эту тему (гостей: 5, скрытых пользователей: 0)
Пользователей: 0
|
|
|