el.d 0 2 августа, 2017 Опубликовано 2 августа, 2017 · Жалоба Здравствуйте. Отправили меня тут в дебри стат. радиотехники. Итак, некий девайс выделяет из входящего аналогового сигнала огибающую - прямоугольный видеоимпульс. По поставленному условию, входящий сигнал можно считать нормальным случайным процессом. Далее огибающая проходит через логарифмический детектор и потом на АПЦ. То есть, на АПЦ поступает напряжение, пропорциональное логарифму огибающей. Сама задача состоит в том, чтобы на ПЛИС производить обнаружение сигнала с АЦП. Основная проблема, которую я вижу - обнаружение требуется производить за 1-2 такта. Я впервые сталкиваюсь с решением подобных задач и засел за двухтомник Б. Р. Левина. Как я понял, обнаружение обычно выполняется при помощи корреляционных устройств. Но у меня ничего неизвестно о сигнале, кроме того, что это прямоугольный видеоимпульс, да и в требование про 1-2 такта коррелятор как-то не вписывается. То есть, как я понимаю, надо статистическим путем установить порог по некому критерию и сравнивать с этим порогом каждый входной отсчет, и по результатам сравнения принимать решение - на входе смесь сигнала с шумом или только шум. Перед стартом работы устройства у меня есть время на некую предварительную обработку. То есть, условно говоря, в это время на ПЛИС идет исключительно шум, который также проходит через лог. детектор. Вроде как из этого можно собрать какую-то информацию для статистики. В первом приближении, время на такую обработку - неограничено (на самом деле ограничено, просто оно очень большое по сравнению со всей остальной обработкой). В любом учебнике по мат. статистике есть методы, как по накопленной выборке восстановить фактически любые параметры распределения. С другой стороны, критерии проверки стат. гипотез, описанные в книге Левина, используют при вычислении порога обнаружения всякие сложные интегралы, отношения каких-то сложных выражений (так называемое отношение правдоподобия) и тд. Неужели это всё придется реализовывать в ПЛИС и нет более простых путей? Ведь это же как-то реализовывали на гораздо менее продвинутой элементной базе десятилетия до этого момента времени. Те же согласованные фильтры - пороги для них же тоже расчитываются по этим формулам. Не совсем понимаю. Прошу ориентира - куда вообще копать-то. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
seniorandre 0 2 августа, 2017 Опубликовано 2 августа, 2017 (изменено) · Жалоба Честно говоря мешанина какая-то, не хватает инфы... 1. Говорить про стат обработку и корреляционный анализ после лог детектора как то неправильно, уже часть инфы потеряна, т.к. в лог детекторе как минимум стоит LPF. 2. Один-два такта чего? сигнала и или ПЛИС? 3. Сигнал кодированный или просто ON|OFF прямоугольника? 4. Сделали девайс без математической базы под сигнал что ли? Изменено 2 августа, 2017 пользователем seniorandre Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Dr.Alex 0 2 августа, 2017 Опубликовано 2 августа, 2017 · Жалоба Сама задача состоит в том, чтобы на ПЛИС производить обнаружение сигнала с АЦП. Основная проблема, которую я вижу - обнаружение требуется производить за 1-2 такта. Вам должен быть задан критерий "обнаружения" сигнала. Без критерия это просто ничего не значащее слово. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
el.d 0 2 августа, 2017 Опубликовано 2 августа, 2017 · Жалоба Честно говоря мешанина какая-то, не хватает инфы... 1. Говорить про стат обработку и корреляционный анализ после лог детектора как то неправильно, уже часть инфы потеряна, т.к. в лог детекторе как минимум стоит LPF. 2. Один-два такта чего? сигнала и или ПЛИС? 3. Сигнал кодированный или просто ON|OFF прямоугольника? 4. Сделали девайс без математической базы под сигнал что ли? 2. ПЛИС. 3. Просто прямоугольный. 4. Похоже, что так и есть. Уже и саму плату произвели, и все элементы разместили, а потом ко мне приходят и говорят - роди алгоритм. Вам должен быть задан критерий "обнаружения" сигнала. Без критерия это просто ничего не значащее слово. Минимизация пропуска цели, т.е. критерий Неймана-Пирсона, как я понимаю. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
seniorandre 0 2 августа, 2017 Опубликовано 2 августа, 2017 (изменено) · Жалоба 4. Похоже, что так и есть. Уже и саму плату произвели, и все элементы разместили, а потом ко мне приходят и говорят - роди алгоритм. С таким подходом только выход за порог лог детектора можно определять и достаточно любого контроллера. После лог детектора есть огибающая видеоимпульса и она же огибающая шума, отделить шум от видеоимпульса уже нельзя, бред какой-то. Дайте хоть блок схему девайса и пример сигнала. Изменено 2 августа, 2017 пользователем seniorandre Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_sda 0 3 августа, 2017 Опубликовано 3 августа, 2017 · Жалоба Минимизация пропуска цели, т.е. критерий Неймана-Пирсона, как я понимаю. На мой взгляд ещё должен быть критерий минимизации ложных срабатываний - шум не принять за сигнал. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
el.d 0 3 августа, 2017 Опубликовано 3 августа, 2017 · Жалоба На мой взгляд ещё должен быть критерий минимизации ложных срабатываний - шум не принять за сигнал. При работе по критерию Неймана-Пирсона вероятность ложность тревоги - фиксированная величина и на данный момент принципиальной роли не играет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_sda 0 4 августа, 2017 Опубликовано 4 августа, 2017 · Жалоба При работе по критерию Неймана-Пирсона вероятность ложность тревоги - фиксированная величина и на данный момент принципиальной роли не играет. А если тупо поставить пиковый детектор на логарифм шума,сколько он натикает - такой порог и выбрать? Без интегралов. Если порог будет меньше найденного - нахватаем ложников, если больше - потеряем чувство. Чисто практический подход. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
syoma 1 6 августа, 2017 Опубликовано 6 августа, 2017 · Жалоба ИМХО не конкретно по теме, но по подходу - я бы сел за Матлаб/Симулинк и построил там модель входного каскада и там же попытался нарисовать алгоритм обработки, подавая на вход нужный сигнал, шум и прочие. Когда получится, можно подумать о переносе в ПЛИС. Так вы сможете на ранних этапах убедиться, будет работать такой алгоритм или нет без того, чтобы проверять все на практике. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
el.d 0 7 августа, 2017 Опубликовано 7 августа, 2017 · Жалоба ИМХО не конкретно по теме, но по подходу - я бы сел за Матлаб/Симулинк и построил там модель входного каскада и там же попытался нарисовать алгоритм обработки, подавая на вход нужный сигнал, шум и прочие. Когда получится, можно подумать о переносе в ПЛИС. Так вы сможете на ранних этапах убедиться, будет работать такой алгоритм или нет без того, чтобы проверять все на практике. Да, я так всегда делаю. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SSerge 6 7 августа, 2017 Опубликовано 7 августа, 2017 · Жалоба А я обычно с учебников начинаю. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
el.d 0 7 августа, 2017 Опубликовано 7 августа, 2017 · Жалоба Баскакова я конечно читал (в первый раз - еще в институте), однако в стартовом посте вроде указано, что обнаружение должно производится за 1-2 такта ПЛИС. Очевидно, что при таком условии СФ или коррелятор - не подходят. Не говоря уже о том, что всё, что известно априори о сигнале - прямоугольный видеоимпульс; длительность не менее 200 нс. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SSerge 6 7 августа, 2017 Опубликовано 7 августа, 2017 · Жалоба Баскакова я конечно читал (в первый раз - еще в институте), однако в стартовом посте вроде указано, что обнаружение должно производится за 1-2 такта ПЛИС. Очевидно, что при таком условии СФ или коррелятор - не подходят. Не говоря уже о том, что всё, что известно априори о сигнале - прямоугольный видеоимпульс; длительность не менее 200 нс. Насчёт 200 нс понятно, про 1-2 такта тоже понятно, не очень понятно как они соотносятся друг с другом. У Вас что, тактовая 10 МГц что-ли? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
el.d 0 7 августа, 2017 Опубликовано 7 августа, 2017 (изменено) · Жалоба Насчёт 200 нс понятно, про 1-2 такта тоже понятно, не очень понятно как они соотносятся друг с другом. У Вас что, тактовая 10 МГц что-ли? Не совсем 10, но близко и того же порядка. Изменено 7 августа, 2017 пользователем el.d Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
stealth-coder 2 8 августа, 2017 Опубликовано 8 августа, 2017 (изменено) · Жалоба 1. За 1 такт ПЛИС у вас накапливается несколько отсчётов сигнала? Я не плисовод, но что-то когда-то где-то читал об однотактных реализациях умножений/сложений за счёт распараллеливания, быстрого переноса и т.п. Подозреваю, что таким образом можно реализовать коррелятор с временем вычисления 1-2 такта. 2. Частота дискретизации не выше тактовой ПЛИС, а ожидаемая форма импульса прямоугольная? В таком случае вопрос можно свести к интегрированию (суммированию) отсчётов на заданном промежутке, по приходу очередного отсчёта из суммы вычитаете самый первый отсчёт в линии задержки, прибавляете вновь полученный отсчёт. 3. Задержка при вычислениях важна? Если нет, то можно сделать коррелятор в виде конвейера, результат будет вычисляться за один такт, только с задержкой в N тактов. Изменено 9 августа, 2017 пользователем stealth-coder Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться