Jump to content

    

модель 8PSK модема

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

 

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

Share this post


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

 

 

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

Share this post


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

 

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

Share this post


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

post-3453-1246251914_thumb.jpg

Share this post


Link to post
Share on other sites
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-ми битной шине, она у нас в голове.

Share this post


Link to post
Share on other sites
Добавил в модель petrov-а петлю костаса для qam16.

matlab 2009b

 

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

 

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

Share this post


Link to post
Share on other sites
К статье Костаса это отношения не имеет.

 

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

 

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

 

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

 

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

 

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


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

 

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

 

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

 

 

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

Share this post


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

Share this post


Link to post
Share on other sites
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). Впринципе находит решение и без учета зависимости коэффициента передачи от амплитуды сигнала.

 

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this