[petrov 0]

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

 

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

[Oldring 0]

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

 

 

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

[petrov 0]

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

 

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

[des00 0]

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

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 0]

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

[voloda 0]

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

matlab 2009b

qam_fb_gardner_costac.rar

[petrov 0]

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

matlab 2009b

 

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

 

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

[voloda 0]

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

 

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

 

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

 

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

 

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

 

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

[petrov 0]

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

 

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

[voloda 0]

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

 

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

[petrov 0]

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

 

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

 

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

 

 

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

[voloda 0]

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

[petrov 0]

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 0]

pi/4 dqpsk coherent demodulation

 

simulink matlab R2010a

 

pi4_qpsk_2010_05_07.rar