Здравствуйте.
Отправили меня тут в дебри стат. радиотехники.
Итак, некий девайс выделяет из входящего аналогового сигнала огибающую - прямоугольный видеоимпульс.
По поставленному условию, входящий сигнал можно считать нормальным случайным процессом.
Далее огибающая проходит через логарифмический детектор и потом на АПЦ. То есть, на АПЦ поступает напряжение, пропорциональное логарифму огибающей.
Сама задача состоит в том, чтобы на ПЛИС производить обнаружение сигнала с АЦП. Основная проблема, которую я вижу - обнаружение требуется производить за 1-2 такта.
Я впервые сталкиваюсь с решением подобных задач и засел за двухтомник Б. Р. Левина.
Как я понял, обнаружение обычно выполняется при помощи корреляционных устройств. Но у меня ничего неизвестно о сигнале, кроме того, что это прямоугольный видеоимпульс, да и в требование про 1-2 такта коррелятор как-то не вписывается.
То есть, как я понимаю, надо статистическим путем установить порог по некому критерию и сравнивать с этим порогом каждый входной отсчет, и по результатам сравнения принимать решение - на входе смесь сигнала с шумом или только шум.
Перед стартом работы устройства у меня есть время на некую предварительную обработку. То есть, условно говоря, в это время на ПЛИС идет исключительно шум, который также проходит через лог. детектор. Вроде как из этого можно собрать какую-то информацию для статистики.
В первом приближении, время на такую обработку - неограничено (на самом деле ограничено, просто оно очень большое по сравнению со всей остальной обработкой).
В любом учебнике по мат. статистике есть методы, как по накопленной выборке восстановить фактически любые параметры распределения. С другой стороны, критерии проверки стат. гипотез, описанные в книге Левина, используют при вычислении порога обнаружения всякие сложные интегралы, отношения каких-то сложных выражений (так называемое отношение правдоподобия) и тд. Неужели это всё придется реализовывать в ПЛИС и нет более простых путей? Ведь это же как-то реализовывали на гораздо менее продвинутой элементной базе десятилетия до этого момента времени. Те же согласованные фильтры - пороги для них же тоже расчитываются по этим формулам. Не совсем понимаю.
Прошу ориентира - куда вообще копать-то.
seniorandre
Aug 2 2017, 15:05
Честно говоря мешанина какая-то, не хватает инфы...
1. Говорить про стат обработку и корреляционный анализ после лог детектора как то неправильно, уже часть инфы потеряна, т.к. в лог детекторе как минимум стоит LPF.
2. Один-два такта чего? сигнала и или ПЛИС?
3. Сигнал кодированный или просто ON|OFF прямоугольника?
4. Сделали девайс без математической базы под сигнал что ли?
Dr.Alex
Aug 2 2017, 15:06
Цитата(el.d @ Aug 2 2017, 17:39)
Сама задача состоит в том, чтобы на ПЛИС производить обнаружение сигнала с АЦП. Основная проблема, которую я вижу - обнаружение требуется производить за 1-2 такта.
Вам должен быть задан
критерий "обнаружения" сигнала.
Без критерия это просто ничего не значащее слово.
Цитата(seniorandre @ Aug 2 2017, 16:05)
Честно говоря мешанина какая-то, не хватает инфы...
1. Говорить про стат обработку и корреляционный анализ после лог детектора как то неправильно, уже часть инфы потеряна, т.к. в лог детекторе как минимум стоит LPF.
2. Один-два такта чего? сигнала и или ПЛИС?
3. Сигнал кодированный или просто ON|OFF прямоугольника?
4. Сделали девайс без математической базы под сигнал что ли?
2. ПЛИС.
3. Просто прямоугольный.
4. Похоже, что так и есть. Уже и саму плату произвели, и все элементы разместили, а потом ко мне приходят и говорят - роди алгоритм.
Цитата(Dr.Alex @ Aug 2 2017, 16:06)
Вам должен быть задан критерий "обнаружения" сигнала.
Без критерия это просто ничего не значащее слово.
Минимизация пропуска цели, т.е. критерий Неймана-Пирсона, как я понимаю.
seniorandre
Aug 2 2017, 15:19
Цитата(el.d @ Aug 2 2017, 18:14)
4. Похоже, что так и есть. Уже и саму плату произвели, и все элементы разместили, а потом ко мне приходят и говорят - роди алгоритм.
С таким подходом только выход за порог лог детектора можно определять и достаточно любого контроллера.
После лог детектора есть огибающая видеоимпульса и она же огибающая шума, отделить шум от видеоимпульса уже нельзя, бред какой-то.
Дайте хоть блок схему девайса и пример сигнала.
_Anatoliy
Aug 3 2017, 03:13
Цитата(el.d @ Aug 2 2017, 18:14)
Минимизация пропуска цели, т.е. критерий Неймана-Пирсона, как я понимаю.
На мой взгляд ещё должен быть критерий минимизации ложных срабатываний - шум не принять за сигнал.
Цитата(_Anatoliy @ Aug 3 2017, 04:13)
На мой взгляд ещё должен быть критерий минимизации ложных срабатываний - шум не принять за сигнал.
При работе по критерию Неймана-Пирсона вероятность ложность тревоги - фиксированная величина и на данный момент принципиальной роли не играет.
_Anatoliy
Aug 4 2017, 03:54
Цитата(el.d @ Aug 3 2017, 09:12)
При работе по критерию Неймана-Пирсона вероятность ложность тревоги - фиксированная величина и на данный момент принципиальной роли не играет.
А если тупо поставить пиковый детектор на логарифм шума,сколько он натикает - такой порог и выбрать? Без интегралов. Если порог будет меньше найденного - нахватаем ложников, если больше - потеряем чувство. Чисто практический подход.
ИМХО не конкретно по теме, но по подходу - я бы сел за Матлаб/Симулинк и построил там модель входного каскада и там же попытался нарисовать алгоритм обработки, подавая на вход нужный сигнал, шум и прочие. Когда получится, можно подумать о переносе в ПЛИС. Так вы сможете на ранних этапах убедиться, будет работать такой алгоритм или нет без того, чтобы проверять все на практике.
Цитата(syoma @ Aug 6 2017, 11:06)
ИМХО не конкретно по теме, но по подходу - я бы сел за Матлаб/Симулинк и построил там модель входного каскада и там же попытался нарисовать алгоритм обработки, подавая на вход нужный сигнал, шум и прочие. Когда получится, можно подумать о переносе в ПЛИС. Так вы сможете на ранних этапах убедиться, будет работать такой алгоритм или нет без того, чтобы проверять все на практике.
Да, я так всегда делаю.
Баскакова я конечно читал (в первый раз - еще в институте), однако в стартовом посте вроде указано, что обнаружение должно производится за 1-2 такта ПЛИС. Очевидно, что при таком условии СФ или коррелятор - не подходят. Не говоря уже о том, что всё, что известно априори о сигнале - прямоугольный видеоимпульс; длительность не менее 200 нс.
Цитата(el.d @ Aug 8 2017, 01:37)
Баскакова я конечно читал (в первый раз - еще в институте), однако в стартовом посте вроде указано, что обнаружение должно производится за 1-2 такта ПЛИС. Очевидно, что при таком условии СФ или коррелятор - не подходят. Не говоря уже о том, что всё, что известно априори о сигнале - прямоугольный видеоимпульс; длительность не менее 200 нс.
Насчёт 200 нс понятно, про 1-2 такта тоже понятно, не очень понятно как они соотносятся друг с другом.
У Вас что, тактовая 10 МГц что-ли?
Цитата(SSerge @ Aug 7 2017, 19:56)
Насчёт 200 нс понятно, про 1-2 такта тоже понятно, не очень понятно как они соотносятся друг с другом.
У Вас что, тактовая 10 МГц что-ли?
Не совсем 10, но близко и того же порядка.
stealth-coder
Aug 8 2017, 17:00
1. За 1 такт ПЛИС у вас накапливается несколько отсчётов сигнала? Я не плисовод, но что-то когда-то где-то читал об однотактных реализациях умножений/сложений за счёт распараллеливания, быстрого переноса и т.п. Подозреваю, что таким образом можно реализовать коррелятор с временем вычисления 1-2 такта.
2. Частота дискретизации не выше тактовой ПЛИС, а ожидаемая форма импульса прямоугольная? В таком случае вопрос можно свести к интегрированию (суммированию) отсчётов на заданном промежутке, по приходу очередного отсчёта из суммы вычитаете самый первый отсчёт в линии задержки, прибавляете вновь полученный отсчёт.
3. Задержка при вычислениях важна? Если нет, то можно сделать коррелятор в виде конвейера, результат будет вычисляться за один такт, только с задержкой в N тактов.
Для просмотра полной версии этой страницы, пожалуйста,
пройдите по ссылке.