модель 8PSK модема Опции

[petrov]

BTW ради любопытства я запустил эту модель и отвлекся. Через некоторое время эквалайзер развалился...

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

[Oldring]

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

Меня тоже удивило что не упоминается в литературе взаимодействие эквалайзера с синхронизатором и AGC. Хотя то что неприятности неизбежны, после прочтения базовой теории, изложенной в Хайкине, становится очевидным. Вы не встречали статей по этой теме?

[petrov]

Меня тоже удивило что не упоминается в литературе взаимодействие эквалайзера с синхронизатором и AGC. Хотя то что неприятности неизбежны, после прочтения базовой теории, изложенной в Хайкине, становится очевидным. Вы не встречали статей по этой теме?

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

[des00]

Да может разваливаться, в этом и проблема эквалайзеров и совместной синхронизации, от любого чиха разваливаются или уходят в паразитное устойчивое состояние, тут в общем просто демонстрация алгоритма адаптации более быстрого чем обычный 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] и дальше идти обычному пути. Делать надо так или я изобретаю велосипед?

Спасибо.

Меня тоже удивило что не упоминается в литературе взаимодействие эквалайзера с синхронизатором и 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

Эскизы прикрепленных изображений

 

[petrov]

1. Почему вы нормируете дельту не на мощность сигнала, а на амплитуду?

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

2. Почему у вас при нормировке есть дополнительная задержка на следующий такт?

Просто перетащил фильтр из другой модели, конечно можно задержку убрать, но в самом фильтре есть задержка, тем больше чем меньше альфа.

Я отключил 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] и дальше идти обычному пути. Делать надо так или я изобретаю велосипед?

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

[petrov]

8PSK feed-back gardner symbol sync farrow interpolator decision directed phase sync gain control variable delay

simulink matlab 7.0.

 psk8_fb_symbol_sync_fb_phase_sync_agc_2009_08_19.rar ( 15.25 килобайт ) Кол-во скачиваний: 1467

[voloda]

Добавил в модель petrov-а петлю костаса для qam16.
matlab 2009b

Прикрепленные файлы

 qam_fb_gardner_costac.rar ( 19.35 килобайт ) Кол-во скачиваний: 643

 

[petrov]

Добавил в модель petrov-а петлю костаса для qam16.
matlab 2009b

Уже обсуждалось, к статье Костаса это отношения не имеет.

Непонятно зачем использовать плохой вариант управления решениями, если можно использовать управление решениями?

[voloda]

К статье Костаса это отношения не имеет.

Собирал по книжке Незами ст. 110 рис. 3-20.

Уже обсуждалось

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

Непонятно зачем использовать плохой вариант управления решениями, если можно использовать управление решениями?

Опять же, ссылку на модель/статью/на словах обьясните, как сделать правильное управление решениями. Я не волшебник, я только учусь)

[petrov]

Все ответы есть в "Цифровая Связь" - Прокис.

Управление решениями есть во всех моделях с синхронизацией с обратной связью, которые в этой ветке выложены.

[voloda]

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

Если тема уже обсуждалась, дайте ссылку.

[petrov]

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

Если тема уже обсуждалась, дайте ссылку.

В моделях вычисление аргумента так сделано для очевидности того что является ошибкой - угол поворота принимаемого созвездия относительно решений, можно и без вычисления аргумента это делать - Im(conj(soft)*decision), только надо учитывать что коэффициент передачи такого такого детектора зависит от амплитуды сигнала. Так и сделано в том детекторе для QPSK с управлением решениями который все почему-то неправильно называют Костасом. Так почему бы сразу не использовать управление решениями для 16QAM не извращаясь с детектором для QPSK?


http://electronix.ru/forum/index.php?showtopic=71563

[voloda]

В моделях вычисление аргумента так сделано для очевидности того что является ошибкой - угол поворота принимаемого созвездия относительно решений, можно и без вычисления аргумента это делать - Im(conj(soft)*decision), только надо учитывать что коэффициент передачи такого такого детектора зависит от амплитуды сигнала. Так и сделано в том детекторе для QPSK с управлением решениями который все почему-то неправильно называют Костасом. Так почему бы сразу не использовать управление решениями для 16QAM не извращаясь с детектором для QPSK?


http://electronix.ru/forum/index.php?showtopic=71563

1) Пока что не совсем понял, откуда можно вывести 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) Спасибо за ссылку. Интересно.

Прикрепленные файлы

 qam_fb_gardner_conj_soft_decision.rar ( 20.27 килобайт ) Кол-во скачиваний: 442

 

[petrov]

1) Пока что не совсем понял, откуда можно вывести Im(conj(soft)*decision)

Это же очевидно чему это выражение пропорционально, синусу разности фаз между решением и принимаемым вектором.

2) В созвездии 16QAM можно взять точки, не лежащие на QPSK. Но неоднозначность фазы там будет 2pi/8, а не 2pi/4 , как для под-QPSK созвездий. Возможна ситуация, когда по точкам под-QPSK будет выдаваться ошибка одного знака, а по не под-QPSK - другого. Тоесть они будут вращать частоту в разные стороны. При расстройке частоты 0.03 0.04, модель, которая работает только по под-QPSK созвездиям ищет решение быстрее.

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

3) Добавил управление по решению Im(conj(soft)*decision). Впринципе находит решение и без учета зависимости коэффициента передачи от амплитуды сигнала.

Имелось ввиду что коэффициент передачи детектора нужно учитывать при анализе ФАПЧ.

[petrov]

pi/4 dqpsk coherent demodulation

simulink matlab R2010a

 pi4_qpsk_2010_05_07.rar ( 24.97 килобайт ) Кол-во скачиваний: 1653