petrov 7 28 июня, 2009 Опубликовано 28 июня, 2009 · Жалоба BTW ради любопытства я запустил эту модель и отвлекся. Через некоторое время эквалайзер развалился... Да может разваливаться, в этом и проблема эквалайзеров и совместной синхронизации, от любого чиха разваливаются или уходят в паразитное устойчивое состояние, тут в общем просто демонстрация алгоритма адаптации более быстрого чем обычный LMS, здесь нет решения всех проблем которые возникают. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Oldring 0 28 июня, 2009 Опубликовано 28 июня, 2009 · Жалоба Да может разваливаться, в этом и проблема эквалайзеров и совместной синхронизации, от любого чиха разваливаются или уходят в паразитное устойчивое состояние, тут в общем просто демонстрация алгоритма адаптации более быстрого чем обычный LMS, здесь нет решения всех проблем которые возникают. Меня тоже удивило что не упоминается в литературе взаимодействие эквалайзера с синхронизатором и AGC. Хотя то что неприятности неизбежны, после прочтения базовой теории, изложенной в Хайкине, становится очевидным. Вы не встречали статей по этой теме? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
petrov 7 28 июня, 2009 Опубликовано 28 июня, 2009 · Жалоба Меня тоже удивило что не упоминается в литературе взаимодействие эквалайзера с синхронизатором и AGC. Хотя то что неприятности неизбежны, после прочтения базовой теории, изложенной в Хайкине, становится очевидным. Вы не встречали статей по этой теме? В том то и дело что не встречалось. Всяких супер алгоритмов адаптации полно, синхронизаторы отдельно рассматривают, а вот совместных робастных схем что-то не видно. Ну и видимо не случайно кругом OFDM. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
des00 25 29 июня, 2009 Опубликовано 29 июня, 2009 · Жалоба Да может разваливаться, в этом и проблема эквалайзеров и совместной синхронизации, от любого чиха разваливаются или уходят в паразитное устойчивое состояние, тут в общем просто демонстрация алгоритма адаптации более быстрого чем обычный 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 7 29 июня, 2009 Опубликовано 29 июня, 2009 · Жалоба 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 7 19 августа, 2009 Опубликовано 19 августа, 2009 · Жалоба 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 10 апреля, 2010 Опубликовано 10 апреля, 2010 · Жалоба Добавил в модель petrov-а петлю костаса для qam16. matlab 2009b qam_fb_gardner_costac.rar Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
petrov 7 15 апреля, 2010 Опубликовано 15 апреля, 2010 · Жалоба Добавил в модель petrov-а петлю костаса для qam16. matlab 2009b Уже обсуждалось, к статье Костаса это отношения не имеет. Непонятно зачем использовать плохой вариант управления решениями, если можно использовать управление решениями? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
voloda 0 23 апреля, 2010 Опубликовано 23 апреля, 2010 · Жалоба К статье Костаса это отношения не имеет. Собирал по книжке Незами ст. 110 рис. 3-20. Уже обсуждалось Если уже обсуждалось - укажите, пожалуйста, где именно. Видел только вариант для BPSK. Непонятно зачем использовать плохой вариант управления решениями, если можно использовать управление решениями? Опять же, ссылку на модель/статью/на словах обьясните, как сделать правильное управление решениями. Я не волшебник, я только учусь:)) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
petrov 7 23 апреля, 2010 Опубликовано 23 апреля, 2010 · Жалоба Все ответы есть в "Цифровая Связь" - Прокис. Управление решениями есть во всех моделях с синхронизацией с обратной связью, которые в этой ветке выложены. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
voloda 0 24 апреля, 2010 Опубликовано 24 апреля, 2010 · Жалоба Впринципе, конечно, управление решениями, выложенное во всех моделях этой ветки - точнее. Но вычисление фазы комплексного сигнала процесс не быстрый. Может быть, модель, в которой используются только умножатели - пошустрее будет? Если тема уже обсуждалась, дайте ссылку. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
petrov 7 24 апреля, 2010 Опубликовано 24 апреля, 2010 · Жалоба Впринципе, конечно, управление решениями, выложенное во всех моделях этой ветки - точнее. Но вычисление фазы комплексного сигнала процесс не быстрый. Может быть, модель, в которой используются только умножатели - пошустрее будет? Если тема уже обсуждалась, дайте ссылку. В моделях вычисление аргумента так сделано для очевидности того что является ошибкой - угол поворота принимаемого созвездия относительно решений, можно и без вычисления аргумента это делать - Im(conj(soft)*decision), только надо учитывать что коэффициент передачи такого такого детектора зависит от амплитуды сигнала. Так и сделано в том детекторе для QPSK с управлением решениями который все почему-то неправильно называют Костасом. Так почему бы сразу не использовать управление решениями для 16QAM не извращаясь с детектором для QPSK? http://electronix.ru/forum/index.php?showtopic=71563 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
voloda 0 27 апреля, 2010 Опубликовано 27 апреля, 2010 · Жалоба В моделях вычисление аргумента так сделано для очевидности того что является ошибкой - угол поворота принимаемого созвездия относительно решений, можно и без вычисления аргумента это делать - 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 7 27 апреля, 2010 Опубликовано 27 апреля, 2010 · Жалоба 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 7 7 мая, 2010 Опубликовано 7 мая, 2010 · Жалоба pi/4 dqpsk coherent demodulation simulink matlab R2010a pi4_qpsk_2010_05_07.rar Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться