serjj1333

Прикольно. Немного смущают требования - восстановленная несущая + ограничение на многолучёвость, т.е. в реальности метод будет работать только после carrier recovery и эквалайзера. И ещё в схеме я бы делал оценку смещения по времени после оценки смещения по фазе, повернув выход коррелятора, чтобы привести к случаю когда фаза = 0. То, что они работают по одной квадратуре при смещении в 45 градусов даёт в шумах дополнительную ошибку эстиматора (половина энергии не используется), что и видно из графика (просаживается относительно CRB).

Ну дык. Надо всё в меру. Если генератор free-run, то сбрасывать его только в самом начале, если он используется для генерации длинных преамбул, то сбрасывать его нужно перед каждой посылкой (per frame).

Не мешайте в кучу гигабитные транссиверы и радио-модем. Это вообще не по теме. Почитайте Nezami "RF Architectures & Digital Signal Processing Aspects of Digital Wireless Transceivers", глава 4. Основная идея такова, что так же как и подстройку по несущей, восстановление символьной можно делать "вслепую", т.е. по данным или по пилотам. Подстройка по данным будет зависить от модуляции данных. Подстройку по пилотам можно делать универсальной, т.к. пилот сигнал формируете вы и он вам а приори известен. Главное не нужно придумывать велосипед, посмотрите уже существующие методы и всё будет ок. Ничего добавлять или выкидывать из потока не надо.

А почему бы не сделать фильтр, который пропускает только те частоты, на которых есть интересующие вас поднесущие? А фильтрующие свойства самого Фурье преобразования вас не устроят? (вы хотите получить динамику большую чем 10*log10(N_fft/2)?)

Если они не циклические.

+1. В bare metal читаю по прямому адресу и всё норм. Даже если мосты не инициализированы, зависания нет, ибо его там и не должно быть. Распространённое заблуждение. В случае HPS qsys необходим для генерации preloader'a. Настройки, которые вы делаете в hps компоненте через папочку handoff попадают в конфиги preloader'a с помощью утилиты generate bsp-editor'a. А загружена ли прошивка FPGA, собранная с данным qsys, или нет - без разницы, на HPS это не влияет, т.к. модули, которые вы конфигурите хардверные. Простой пример. Вы хотите читать/писать NAND память с помощью встроенного ONFI контроллера. По-умолчанию проц вам этого не даст, однако, если вы подсунете ему preloader, собранный из qsys, где на NAND был разведён клок и выведены соотвествующие ноги, то всё заработает. FPGA при этом можно вообще не трогать.

Ну так не надо какую попало. Туда загружется то, что туда загружают. Особых сбоев тут быть не должно. Но если этот момент принципиален, могу предложить два пути решения: а) копать в линухе, потому что зависания ненормальны, в bare metal, если fpga не загружена, то просто с регистров 0 читаются; б) попробовать как вариант поиграться с h2f_gp (general purpose signals, включаются в hps компоненте qsys), может быть получится передавать сигнатуру через этот интерфейс.

А в чём разница? Это будет тоже самое обращение к периферии, которое также вероятно приведёт к зависанию линуха. Почитайте про такой модуль как FPGA manager и про работу с ним. Он входит в состав HPS и отвечает за конфигурирование FPGA из под проца и мониторинг состояния FPGA. В hwlib для него написан драйвер, из под линуха тоже должно быть что-то. А заоодно почитайте вот эту тему. В ней вы узнаете о ещё одной проблеме, которая может возникнуть, когда FPGA грузится позже проца.

Читайте внимательнее. До 6 каналов, а не полос подавления. Микросхема обеспечивает раздельную фильтрацию до 6 каналов. Т.е. в каждом канале все частоты, которые не входят в данный канал, подавляются. Не очень понятно, зачем вам такая конструкция. Обычно требования предъявляются наоборот. Нужно обеспечить пропускание в таких-то полосах в таком-то количестве каналов, всё остальное просто подавляется. Задача режекторной фильтрации это, как правило, обеспечить большое подавление в узкой полосе, при этом соседние частоты не должны быть задавлены, т.к. режекторный фильтр применяется для вырезания узкополосной помехи из рабочего диапазона частот.

Перенос шаблонов С на verilog/VHDL приводит к неприятным ошибкам. Практика показывает, что вендорский код далёк от идеального. Я сейчас говорю не о конкретно этом примере (странно, что вопрос об инициализации вызвал такое обсуждение), а вообще. Кривые конструкции встречаются как в rtl так и в C исходниках. Sad but true.

Есть ли у вас какая нибудь статья по этой теме? Спасибо.

В данном частном случае можно сделать инициализацию под дефайном, т.е. если код для синтеза, то инициализацию не делать, если для симулятора - то делать. В верилоге это что-то вроде `ifndef SYNTHESIS, при этом дефайн SYNTHESIS глобальный, что позволяет легко переключать весь проект между синтезируемым и симулируемым. Как в VHDL такое делается, я не помню, но думаю, что подобным же образом. Кроме инициализаций под `ifndef SYNTHESIS можно поместить ещё много полезного, с чем будет работать только симулятор. Впрочем это моё ИМХО.

А какая, простите, ещё бывает инициализация? ;) Если из-за такого сигнала происходит "размножение" Х-ов, то очевидно, что ресет на него завести следует. Это например счётчики и аккумуляторы. А если это регистр, который хранит результат умножения или сложения двух других сигналов к примеру, то сбрасывать его не нужно, а на Х-ы в самом начале симуляции можно не обращать внимание. С другой стороны в таких вот случаях Х-ы это даже хорошо. Потому что они позволяют а) оценить когда схема "пошла", т.е. когда результат можно анализировать, до этого её выход считаем хламом и б) отследить регистры накопители, на которые забыли добавить сброс. Кстати ещё один момент. При симуляции шин с множественным доступом по адресу бывает очень полезным выставлять в данные Х-ы, когда нет сигнала валидности, т.к. это позволяет отследить ошибки работы с шиной. Если в целевом модуле ни с того ни с сего появились Х-ы, значит модуль неверно отрабатывает операции на шине. Х-ы в данном случае являются аналогами мусора, который валит по загруженным шинам вроде Авалона или AXI в отсутствии валидности данных.

Сигнал сброса симулируется элементарно из тест-бенча. Если вы завели сброс и в ходе симуляции у вас полезли Х-ы, то очевидно, что у каких-то триггеров, которые требуют сброс, он описан неверно или не описан вовсе. В моём понимание это ошибка. Нет никакой необходимости сбрасывать каждый регистр, но при разработке дизайна надо определить какие регистры сбросить надо и описать этот сброс (синхронный или асинхронный, в зависимости от задачи/убеждений/пожеланий). Инициализацию переменных при объявлении стараюсь делать только в тест-бенчах.

У вас же FSK, какие уровни? 4 палки в спектре, каждая соответствует своей паре бит. Либо набор согласованных фильтров с определением максимума энергии на выходе, либо fft и определяете на каком частотном бине максимум энергии. FSK модуляция угловая по своей сути, т.е. в амплитуде информации нет. Зачем тут АРУ?

У вас какая полоса обработки и сколько каналов вы хотите через этот фильтр пропустить? И должен ли проц ещё какую либо векторную математику делать кроме этой фильтрации? Подумайте, если ваши запросы будут не очень велики, может stm32f3 с FPU на борту решит вашу проблему? Для отладки банальнейшая плата Discovery, встроенный jtag-based отладчик + матлаб позволят вам досконально изучить и отладить фильтр. Для сравнения этот малыш относительно легко пережёвывает весьма нагруженный чистый floating point фильтр Маджвика (много векторных вычислений), но у меня там полоса всего 100 Гц. Возможно для банального FIR фильтра можно разогнаться до десятков кГц, в ветке про STM в соседнем форуме вам могут подсказать подробнее.

Смею предположить, что для функции arm_sin_q31 0 рад = 0, pi рад = 2^30, 2*pi = 2^31. Входной диапазон соответственно [0:2*pi) или [0 : 2^31-1)

Простота - это FSK, помехозащищенность - это FH-FSK (frequency hopping FSK). OFDM - это скорость + работа в канале с частотно-селективными замираниями. OFDM на звук как белый шум. Это уже сделано до вас: wifi, bluetooth. Что будет, если в комнате будут посторонние источники шума? Как уходить от такой интерференции? Подумайте о разнесённом приёме. Если у вас будут спектральные нули в АЧХ канала (а это очень вероятно), никакое кодирование не поможет. А при разнесённом приёме канал хорошо сглаживается. Использовать демодулятор с мягкими решениями можно и при плохом восстановлении сигнала, это никак не связано, не надо всё в кучу валить.

А вы сможете по SPI перегружать частоту NCO 100 млн. раз в секунду или быстрее? :rolleyes: Или вы имеете в виду сформировать полосовой сигнал на baseband и переносить его на несущую в ЦАП?

Гармонический, ЛЧМ. Первый в случае частотного обнаружения окном с перекрытием. Второй - согласованным фильтром. ЛЧМ пожалуй предпочтительнее. У ЛЧМ относительно выраженный пик в АКФ + он устойчив к Допплеру (бинарные М-последовательности/Баркер, которые часто применяют вместе с OFDM, в акустическом канале будут приниматься плохо из-за высокого и быстро меняющегося Допплера). Нужно использовать не только преамбулу, но и постамбулу. Из-за широкополосной модели Допплера происходит ресемплинг сигнала в канале (растяжение/сжатие). Измеряя время между детектированием преамбулы/постамбулы, можно определить коэффициент времянного искажения и сделать обратный дробный ресемплинг. Либо второй вариант - использование в качестве преамбулы серии из одинаковых последовательностей, что также позволит оценить коэффициент искажения. Очень скоро вы поймёте, что преамбула - это самое малое, что нужно сделать, т.к. с акустическим OFDM очень много трудностей, вот например: Обычно для звука применяют OFDM с большой базой Фурье и модуляциями BPSK/QPSK/8PSK на каждой несущей кроме зарезервированных под служебные. Большая база нужна для эффективного раложения сильно частотно-селективного звукового канала на множество каналов с плоским замиранием. PSK модуляция каждой несущей нужна, очевидно, для скорости. Никому не нужен акустический OFDM, если он не даёт существенного выигрыша по скорости в сравнении с более протсым и робастным ШПС/FSK. Для OFDM вам потребуется механизм компенсации Допплера до Гц (очень затратные по ресурсу ML-алгоритмы). На каждом символе. А Допплер в акустике будет "плыть" от символа к символу потенциально больше чем на Гц. Возможна ситуация, когда АЧХ канала будет меняться от символа к символу. Метод адаптивной оценки канала должен как-то это учитывать. Нормальный OFDM модем для звука почти 100% должен быть многоканальным, (1)2х2 или (1)4х4 MISO/MIMO + MRC/STBC. На SISO в реальных условиях вы не получите выигрыша по скорости, который позволяет OFDM, там проще сразу уходить на ШПС/FSK, остальное просто не пролезет. Ну если у вас конечно приёмник и передатчик не напротив друг друга стоят. Есть проекты, где для высокоскоростной когерентной связи используют АФАР. И, если не секрет, в конечном счёте цель - вода? В какой среде планируете применять разработку? Если вы всерьёз заинтересованы OFDM для звука, начните с MIT'овских статей, например OFDM_capacity_considerations.pdf doppler.pdf design_considerations.pdf.pdf Успехов.

Частота ограничена только теоремой Котельникова, т.е. символьная частота >= 2*максимальная частота генерируемая. В предельном случае тактовая равна символьной (для высокочастотных NCO). Точность ограничена не тактовой, а алгоритмом. Никто не мешает получить доли Гц на 100 МГц тактовой, просто в этом случае ваша верхняя частота будет ограничена 50 МГц. В случае, описанном ТС, тактовая должна быть > 2*120, т.е. не менее 240 МГц. Но если позволит аналоговый фильтр (на отстройке 60 МГц обеспечит подавление, например, не менее 30-40 дБ) после ЦАП, то можно сформировать на тактовой/символьной 120 МГц сигнал в полосе 0...40 МГц, который даст во второй зоне Найквиста сигнал в полосе 80...120 МГц. Т.к. в АЧХ ЦАП тем более во 2й зоне есть неравномерность, обусловленная функцией sinc(x), то в формируемый сигнал можно ввести амплитудную модуляцию, которая определяется текущей частотой сигнала, но это уже частности.

Если камень совсем мёртвый, то ID не считается (FF...) скорее всего будет. Соответствующие ПО (типа программаторов флеш) на это сругуются. Если читаете своим софтом, то сругаться следует ему. Пойдёт для первичной проверки связи с камнем. Но если говорить о работоспособности, то вы должны проверить чтение/запись. Если что-то серьёзное на неё будет завязываться, то нужно все страницы пройти тестом, который все биты проверит, например 0xAA/0x55.

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

Генератор пилы (пишется за 10 минут) + NCO (взять готовый Альтеровский или сваять свой, например на Кордике или Тэйлоре), нет, не подойдёт? :rolleyes:

То, о чём вы говорите, называется по другому. Это соотношение сигнал-помеха, которое определяется по-мимо расстояния такими факторами как: (вам подсказывают) направленность антенн, полоса и центральная частота помехи, геометрическое положение помехи и пр. Для комплексной оценки применяют параметр SINR (signal-to-noise+interference-ratio) чтобы различать влияние шумов приёмника (полоса сигнала и расстояние АВ определяют SNR в таком случае) и влияние интерференции.