SA - работа с модулем OFDM. Примеры.

SA - работа с модулем OFDM. Примеры.

Несколько практических примеров.

После выхода версии 6.1.0.5 и статьи SA модуль OFDM. Созведия в каналах, мы получили довольно много писем, по вопросам практического использования возможностей модуля OFDM.

Статья SA модуль OFDM. Созведия в каналах. как оказалось, оставляет несколько мрачное впечатление, получается, что с неизвестным OFDM сигналом вообще мало чего можно сделать. Конечно это не так, и "напугать" кого либо цели не ставилось, напротив, я считаю, что пользователь должен знать узкие моменты и быть готовым к тому, что не всегда, все будет гладко и легко. В любом случае, даже с учетом тех трудностей которые были описаны ранее, модуль OFDM входящий в SA представляет весьма мощный инструмент, работу с которым рассмотрим чуть более плотно в этой статье.

Возьмем сигнал DAB , этот сигнал интересен тем, что количество каналов у него чрезвычайно велико, и попытки "зарядить" SA на поиски корреляционного треугольника с нижним порогом MinBr=20, без каких либо измерений вообще, чреваты очень длительными расчетами, вплоть до нескольких суток, в чем уже кое-кто убедился :)

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



ACF, а в данном случае она очень яркая, дает верхнюю границу Baud Rate на уровне ~1000 Гц, выше она не может быть даже теоретически. Уже можно приблизительно задать границы как MaxBr = 1000 и MinBr = 500. Почему нижнюю границу выбрали как MaxBr/2 ? Во первых это всего лишь пример, во вторых, и он, очень грубый. Дело вот в чем, ACF, когда она явная и не вызывает сомнений, дает примерный частотный разнос сетки каналов, скорость манипуляции может быть только ниже этого разноса, но, скорость в двое меньше разноса означает, что каналы имеют полное разделение на спектре, с этим сигналом это не так, и нижняя граница безусловно сильно избыточна. У OFDM с CP, относительно легко различимы каналы и при соотношении разноса частот и скорости манипуляции Shift/Br равном 1.5-1.3 раза. Сказать, что в этом сигнале частоты легко различимы сложно, следовательно, нижнюю границу можно установить на уровне 750 Гц. Уже при таких параметрах, если их задать в модуле OFDM, поиски корреляционного треугольника займут примерно 2-3 часа, существенное сокращение против 24 часов и более, не правда ли?

Можно, и нужно взять максимум из классического анализа продолжая уточнение границ ожидаемой скорости манипуляции. Метод описанный в статье Классический анализ OFDM сигналов. дает примерное значение тактовой частоты 801-802 Герца. Хотя все и написано, тем не менее ниже показано как это сделать, шаг за шагом.



Что бы гарантированно не промахнуться, берем интервал MaxBr = 804 и MinBr = 800. На расчеты в модуле OFDM с такими начальными установками, уйдет примерно... 2-4 минуты максимум. :)



На самом деле, для задания границ поиска, нужна именно скорость манипуляции, пример с ACF приведен лишь для того, что если тактовую частоту получить достоверно не удается, то можно как вариант, использовать и данные полученые только с ACF, но с более грубым результатом разумеется.



Манипуляция в каналах, предположительно(!), помним статью SA модуль OFDM. Созведия в каналах , pi/4 DQPSK или PSK-4(QPSK), более точно пока сказать невозможно.

В общем случае, количество каналов не играет особой роли, на скорость расчетов влияет исключителльно отношение частоты дискретизации к скорости манипуляции исследуемого сигнала Fd/Br, при значениях этой величины за, примерно 1000-1500, время расчетов очень резко и нелинейно возрастает до очень существенных величин. Поэтому выбор оптимальной, по возможности низкой, частоты дискретизации, при поиске корреляционного треугольника весьма важный фактор.

Следующий, очень интересный сигнал с ресурса DIG_intro.htm это OFDM-59 .

С определением параметров у этого сигнала, особых сложностей не возникает, но исходная частота дискретизации 11025 Герц, явно не верная, ее следует понизить до 8000 Герц.



Редкий, но тем не менее реальный случай, когда относительное созвездие достаточно достоверно говорит о том, что режим манипуляции в каналах - QAM-16. Посимвольное перемещение по сигналу позволяет обнаружить еще одну особенность, каждый пятый символ служебный, во всех каналах амплитуда одинаковая, скорее всего эти служебные символы предназначены для быстрой настройки/подстройки эквалайзера демодулятора, так как QAM модуляция весьма чувствительна к амплитудно-фазовым искажениям и требуется их постоянная коррекция.

Следующий сигнал WinDrm

Отрабатывая технику анализа нам удалось вычислить его параметры практически точно, что позволяет получить убедительные абсолютные созвездия в любом канале. Как нетрудно заметить используется QAM-64 с различным сервисным "обрамлением", которое предназначено для различных систем авторегулирования, позиционирования созвездий точно по осям, и т.д.



И последний сигнал, который мы рассмотрим так же плотно как и первый, это Q15X25 .

Для этого есть несколько причин, во первых, манипуляция в каналах ошибочно определена(не нами) как относительная, на самом деле там абсолютная PSK-4(QPSK), во вторых, для поиска корреляционного треугольника нужно немного постараться, и в третьих, сама запись обладает особенностями, которые мы попытаемся обьяснить.

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



Программа останавливается на параметрах "LS=97, LG=33, Br=82.47, Sh=125" и продолжает "находить" следующие. В этом нет вообще-то ничего удивительного, но в итоге программа не находит убедительного треугольника. Одной из причин этого может быть, и как правило бывает, недостаточное количество материала для анализа, в данном случае у нас в расчетах участвует всего 17 символов.

Тут есть тонкий момент, если скорость манипуляции низкая, то символ достаточно длинный, и может хватить и 10 символов для надежного расчета, в случае если скорость манипуляции высокая(относительно конечно) то может не хватить и 30, так как сам символ короткий. Манипулируя параметром MinBr, за счет его увеличения, мы можем, на коротких сигналах получить больше символов для расчета, чем и нужно воспользоваться. Так как, если бы, скорость манипуляции была бы действительно в районе 20-30 Герц, то и 17 символов вполне хватило бы. Поднимем границу MinBr до такой величины, пока символов не станет в пределах 40. И снова запустим расчет.



Теперь программа безошибочно находит требуемое, так как материала вполне достаточно для расчетов. Это не трюк, просто это нужно знать и понимать, что по умолчанию параметры в модуле OFDM устанавливаются совсем не оптимально, и что даже если ни чего не найдено, то это не означает, что программа плохо искала, возможно ей "плохо обьяснили" где нужно искать. :)

Самое интересное, если вы попытаетесь сейчас, пройтись посимвольно по фрагменту записи и получить созвездие, вряд ли у вас получится сделать более 5 шагов, и соответственно нормальные созвездия отобразить будет не возможно. Сейчас проблема в следующем, слайдер Symbols установлен на уровне 40 символов, это значит, что пространство в записи длинной в 40 символов всегда резервируется для корректного расчета треугольника, так как он всегда отображается. И если вы перемещаетесь на один символ посимвольно, то вместе с этим перемещается и "основной состав" из 40 символов, который всегда впереди. И как только этот "поезд" упрется в конец фрагмента, дальше вы не пройдете, хотя могли бы сделать еще 40 шагов как минимум.

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

Теперь без проблем вы получите в любом канале, достаточно убедительные созвездия PSK-4(QPSK).



Теперь об особенностях этой записи/сигнала. Внимательный аналитик не может пройти мимо того факта, что корреляционный треугольник найденый программой, на самом деле, на треугольник похож чрезвычайно слабо. Более того, если мы попробуем вершину этого "треугольника" совместить с маркером, тем самым, как вы помните из статьи SA модуль OFDM. Созвездия в каналах выбрав лучший LU, самый последний, самый надежный, мы вообще не получим вразумительного созвездия. У этого сигнала, приемлимые по качеству LU, почему-то занимают относительно маленькую часть левого склона треугольника, при том, что параметры записи точно соответствуют "родным", это ли не загадка для аналитика? Как же так, в статье SA модуль OFDM. Созвездия в каналах так красиво и убедительно рассказано о нюансах OFDM, а тут, вот он сигнал, который отказывается вести себя нормально? В чем проблема, и почему так происходит?

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

Известно, что на стыках символов OFDM происходит резкая смена параметров каналов, меняется фаза и/или амплитуда. Это естественно приводит к появлению внеполосных выбросов, подавление этих выбросов, если это очень необходимо, достаточно сложная задача, попытки решить эту задачу примитивными методами и приводят к таким результатам как этот сигнал. Грубая, прямая жесткая фильтрация, просто напросто "выкусывает" выброс вместе с прилегающими отсчетами, затрагивая как конец одного символа так и начало следующего. Наглядное представление, условное конечно, но вполне правильное:



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

Сигнал может и будет выглядеть красиво, но он ущербный по определению. Если уж очень хочется отфильтровать OFDM сигнал, то как минимум это нужно делать на расстоянии не ближе чем (2-3)*Br Герц от крайних каналов, а лучше вообще этого не делать, или решать задачу другими, не такими примитивными методами.

Удачи. getQuotation();






Рекомендуемый контент




Copyright © 2010-2017 housea.ru. Контакты: info@housea.ru При использовании материалов веб-сайта Домашнее Радио, гиперссылка на источник обязательна.