LabVIEW Portal

Что то много всего навалилось в начале 2014.
Из-за изменения условий одного эксперимента "отказал"
стандартный пик детектор, пришлось придумывать свой, "военный"
измерения "засорились" механической вибрацией и далее всегда будет так.
Фильтрование снижает точность определения величин максимумов и минимумов
Подумал вдруг, а ведь это довольно интересная задачка-конкурс
ну для начинающих это уж точно.
Вдруг кто то заинтересуется и захочет принять участие. Может в теории
пик или впадина это точка где первая производная равна нулю, но на практике
требуется совсем другое а именно максимумы и минимумы некой "волны",
обрезанные пороговыми значениями, смотрите пример, совместимость
проверил до 2012 версии.
В примере применен собственный виндоподобный интерфейс, решающий проблемы
из этой темы, так для разнообразия, или народу понравиться?
http://www.labviewportal.org/viewtopic.php?f=35&t=6651
К пик-детектору это отношения не имеет.

Jakob Brontfeyn писал(а):Из-за изменения условий одного эксперимента "отказал"
стандартный пик детектор, пришлось придумывать свой, "военный"
измерения "засорились" механической вибрацией и далее всегда будет так.

Яков, Вы как всегда оригинальны в своих решениях.
Но не совсем понятно, чем не устраивает стандартный детектор, может Вы его "неправильно готовите".
Данный вопрос уже неоднократно возникал и обсуждался на форуме, главное верно определить критерий и ограничения.
То что реализовано у Вас ближе к функции Threshold Detector, только детектируется не начало пика, а его центр.

Если Вы хотите поставить задачу, то исходными данными должны быть:
1. Сигнал (запись или имитатор).
2. Условия (критерий и ограничения) детектирования пиков.

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

------------

Философствовать можно долго.
Для примера, я убрал фактор случайности и изменил Ваши настройки "по умолчанию", судите сами .

IvanLis писал(а):Философствовать можно долго.
Для примера, я убрал фактор случайности и изменил Ваши настройки "по умолчанию", судите сами

Да не ожидал, что так быстро будет найдено "слабое место", то бишь конец массива,
когда Threshold превышен, но значение, назад ниже порога не возвращается, кончился массив
как тогда определить где максимум не просто, но "пик". Правда в реальном
эксперименте массив всегда заканчивается значениями ниже порогового.
Задачи к сожалению ставлю не я, а сама жизнь.
Для лучшего понимания можно заглянуть сюда тут показано в картинках,
http://labviewportal.org/viewtopic.php? ... 293#p53293
пока сигнал на вернем осцилографе был относительно чистый,
справлялся стандартный пик-детектор, PD-Wide установил 7
важно, чтобы был зафиксирован только один "максимум" и только один "минимум" на
период а таких треугольных периодов 5 для каждой температуры. Один сбой,
больше или меньше пиков обнаружено, и никакой автоматической работы дальше не будет.
Иван, Вы натолкнули меня на интересную мысль, а что если задать PD-Wide, для пик-
детектора, как переменную (большое значение), а точнее равное длине куска массива выше
(для впадин ниже) чем Threshold и найти пик именно в этом куске стандартным детектором.
Буду пробовать, как он работает при больших PD-Wide, может введу
стандартный пик детектор в мой суб-ви, запускаться будет только в конце массива.

PS. наверное требуется еще маленькое пояснение,
то что для стандартного пик-детектора садается, как PD-Wide, для моего суб-ви
обозначает совсем другое, а именно количество точек подряд превысивших
порог для поиска максимума или пренизивших для поиска минимума,
так как при пересечении порогов наблюдается "дребезг"

Jakob Brontfeyn писал(а):Вы натолкнули меня на интересную мысль, а что если задать PD-Wide, для пик-
детектора, как переменную (большое значение), а точнее равное длине куска массива выше
(для впадин ниже) чем Threshold и найти пик именно в этом куске стандартным детектором.

только наверное более правильно будет 1+N/2
но это нужно экспериментально смотреть

Тема получила развитие, при механических испытаниях деталей автомобилей и других машин и механизмов
Образец нагружается стандартным "линейным треугольником".
Но на него накладывается "вибрация", синус скажем 12 Герц амплитудой не более 10% от основной нагрузки. Используется буферизированная система сбора данных с частотой 1000 измерений/сек размер буфера 1000 измерений или по времени 1 секунда.
Эксперимент длится несколько дней. Писать все в файл немыслимо, это будут десятки гигабайт. требуется выделить только макс-мин амплитуды 12 герц и только их реально измеренные значения писать в файл и больше никаких лишних точек не писать.
Сигналы реальные и довольно зашумленные. Реальных амплитуд и формы кривой основной нагрузки никто заранее не знает.
Единственный параметр известный более менее точно это частота наложенной синусоиды.
Реальные эксперименты уже идут. Вот слепил совершенно убийственную демонстрашку после запуска нажмите "TRIANGL START"

Jakob Brontfeyn писал(а): Фильтрование снижает точность определения величин максимумов и минимумов
Подумал вдруг, а ведь это довольно интересная задачка-конкурс
ну для начинающих это уж точно.
Вдруг кто то заинтересуется и захочет принять участие.

Как конкурс - честно говоря не очень, потому что условия задачи и критерии победы должны быть абсолютно чёткие. А тут всё довольно расплывчато?
Наверное пойдёт задачка типа такой:
Продавец компании NI получил три десятка комплектов демо-версии LabVIEW и список из тридцати городов, с адресами тех, кому он должен втюхать этот продукт. Вооружившись программой Google Maps, дотошный инженер вычислил время перемещения между каждым городом и заполнил табличку. Вопрос - как ему найти оптимальный маршрут, чтобы посетить каждый город ровно один раз? Время на работу программы ограничим, скажем десятью минутами. Не уложившиеся в десять минут работы решения дисквалифицируются. На вход программы прилетает двумерный массив с временем перемещения между городами, а на выходе - одномерный массив с порядком перемещения (индексами городов). Побеждает программа, составившая самый короткий маршрут. Если две программы находят одинаковый маршрут, то побеждает та, у которой время вычисления меньше. Как-то так.

Могу совсем просто обьяснить
Требуется on-line из потока полного измерения смотри файл all_1000_HZ.тхт
получать только реально измеренные макс-мин высокочастотной
составляющей и ни каких лишних точек больше, смотри файл maх_min_sinusa.tхt
Известна точно только частота наложенной составляющей, здесь она 12,5 Герц.
Сигнал реальный зашумленный, стандартный пик детектор правильно работать не будет.

Отчего не пройтись по сигналу медианным фильтром, который уберёт весь шум?

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

Jakob Brontfeyn писал(а):Сигналы реальные и довольно зашумленные. Реальных амплитуд и формы кривой основной нагрузки никто заранее не знает.
Единственный параметр известный более менее точно это частота наложенной синусоиды.
Реальные эксперименты уже идут. Вот слепил совершенно убийственную демонстрашку.....

Яков, Ваш сигнал прекрасен как Венера Милосская. Никаких шумов не наблюдается, разве только компенсировать плавание постоянной составляющей, но именно ее Вам наверное и нужно вычислить в конце-концов. Иного смысла наложения несущей я не вижу.

Интересно послушать рассуждения с точки зрения радиотехника.
Видимо требуется обьяснить кое что дополнительно.
1. по словом пик понимаем максимум или минимум
в пределах полупериода наложенного сигнала (12,5 Герц в данном случае),
максимум для первого, а минимум для второго полупериода
2. так называемое Вами "плаванье постоянной составляющей" это
стандартное управление деформацией образца линейным треугольным сигналом
с периодом порядка 8 секунд. Измеряем мы силу и она получается не совсем линейной,
поскольку мы выходим немного за пределы упругой деформации чтобы через несколько
тысяч или десятков тысяч циклов образцу пришел капут.
3. записать в файл для его дальнейшей обработки требуется именно только
пики. Дальнейшая обработка это уже не мое дело, а других специалистов в области
механики материалов (HCF-LCF fatigure) можете посмотреть в гугле что это такое,
но я не советую, зароетесь в сопромат с головой и к теме это не имеет отношения.
Скажу только от себя, что наложенная вибрация наиболее опасна как раз не в области
упругой деформации а ближе к вершинам "треугольника"
4. сигнал идет в потоке on-line побуферно 1000 каждую секунду, это я просто передал
весь массив за 17 секунд.

А, теперь понятно. А рельный-то сигнал как выглядит?

AndreyDmitriev писал(а):А, теперь понятно. А рельный-то сигнал как выглядит?

tak

Эксперимент длится несколько дней. Писать все в файл немыслимо, это будут десятки гигабайт.

у вас два сигнала. Итого 4х2 = 8 байт на замер. 8000 байт/с *86400 с/сут = 660Мб /сутки. Абсолютно нормальный размер архива.

Jakob Brontfeyn писал(а):

AndreyDmitriev писал(а):А, теперь понятно. А рельный-то сигнал как выглядит?

tak

Там же почти идеальная синусоида - шума нет практически, ну я не вижу по крайней мере. Даже стандартный пик детектор при правильно выбранном окне должен нормально отрабатывать. В чём, собственно проблема?

Borjomy_1 писал(а):

Эксперимент длится несколько дней. Писать все в файл немыслимо, это будут десятки гигабайт.

у вас два сигнала. Итого 4х2 = 8 байт на замер. 8000 байт/с *86400 с/сут = 660Мб /сутки. Абсолютно нормальный размер архива.

kN µm °C sek

-8.160 -145.215 450.216 36000.000

посчитайте лучше, так выглядит после 10 часов работы,
но даже 660 мб/сутки это уже очень много