adnega

Тогда как вы корректно делаете из 1000 Гц семплирования, при помощи фильтрации, 1 Гц отображения?

Зафиксировали тезис. Я попробую доказать, что вы мало смыслите в ЦОС. По-вашему, можно безнаказанно выкидывать отчеты из выборки? (это следствие неравенства частоты сэмплирования и частоты отображения).

А как наличие или отсутствие фильтрации влияет на сэмплирование?

А как наличие или отсутствие фильтрации влияет на сэмплирование. Что такое "сэмплирование" по-вашему? По-моему, это получение отсчета в конкретный момент времени. Как правило, отсчеты получают с частотой дискретизации. В ЦОС применяют дискретные квантованные отсчеты.

Т.е. вы собираете 1000 отсчетов, фильтруете (например, усредняете), получаете 1 результирующий отчет с частотой 1 Гц и его отображаете? Все так?

И что из этого следует? К чему это замечание? Допустим, они сильно разные: семплируем с частотой 1000 Гц, а выводим с частотой 1 Гц. Т.е. 999 отсчетов отбрасываем, а используем один. Или в другую сторону: 1000 раз в секунду отправляем целые показания температуры воздуха, которые меняются на 1С за час. Как архитектор архитектору - в этих случаях система спроектирована не оптимально. Пределом оптимума будет получение данных с частотой близкой к частоте обновления показаний. Но если на цифры смотрит человек, то иногда нужно принудительно не обновлять показания (хоть до 10 секунд), чтоб не было болтанки, и это никак не связано с частотой сэмплирования и частотой отображения.

Например, для индикатора температуры воздуха в виде светового табло какая нужна точность? Если сделать высокую, то будут телепания +27C<>+28C. При этом может быть значительный градиент температуры. Например, у меня на лоджии было +18 у потолка и -2 на полу (пока не сделал отопление). Какая температура на лоджии? Это зависит где установить датчик! Если загрубить показания на +- 1C зоной нечувствительности, то никакой потери точности не будет, а показания станут не такими дергаными.

Чем вам реальная задача с температурой не нравиться? Я описывал реальную модель измеряемой величины - как минимум истинное значение + систематическая ошибка + аддитивный белый гауссовский шум. У меня диплом учитывал еще аддитивный белый фазовый шум, но это к обсуждаемым сигналам не относится. Вы знаете модель реального сигнала какую-то другую? Предложите - обсудим. Мне приходилось пару раз сталкиваться с Заказчиками с требованиями померить температуру так, чтобы получалось +28C, но это для копилки анекдотов, мы же понимаем.

Да меньшее. В аналоговом виде это не различимо, но в цифре совсем иначе. Если от 10.0 отнять хоть мельчайшую песчинку, то будет уже 9.99... Есть такое 9.99.... , что если к нему добавить мельчайшую песчинку, то будет 10.0. На этом все и строиться. Тот же парадокс кучи, только теперь на границе значений будет мерцающая красная подсветка.

Предлагаю всем желающим ознакомиться с парадоксом кучи.

Я же показал, что с каждым новым отсчетом. Если у вас частота сэмплирования 100 Гц - значит с частотой 100 Гц. Я же показал, что от размера окна это не зависит. Это не форум красивых картинок, напомню. Вы похожи на человека с трусовой резинкой, на которой нанесены сантиметры, и который при измерениях натягиевает ее так, чтобы получались "красивые" показания. Разве нет? Реальнее некуда. Я привел пример ранее - меееедленное (на 1C в час) изменение температуры. Будет 10 эпизодов в час, когда показания на цифровом индикаторе будут телепаться при любом виде сглаживаний.

Нет. Вот вам последовательность 9.9, 10.1, 9.9, 10.1 и т.д. Сделайте окно любой длины и увидите, что это не поможет. После каждого нового отсчета целая часть будет телепаться 9<>10. (9.9 + 10.1) / 2 = 10.0 (9.9 + 10.1 + 9.99) / 3 = 9.9(6) (9.9 + 10.1 + 9.99 + 10.1) / 4 = 10.0 (9.9 + 10.1 + 9.99 + 10.1 + 9.9) / 5 = 9.98 Можно показать, что четные равны 10.0, а нечетные стремятся к 10.0 слева, т.е. всегда будут 9 с чем-то. На экране пользователь будет видеть 10.0<>9.99 с частотой сэмплирования.

В лидеры чего? Я вижу тут он несколько раз пересек горизонтальную линию. Это неприемлемо, т.к. на цифровом индикаторе будет мерцающие 9.99<>10.0 В некоторых задачах не важна точность, а важно удобство представления информации. Любая физическая величина измеряется с ошибкой. Кроме шума там будет еще и систематическая ошибка. За счет нее истинное значение сместится. За счет АБГ-шума величина должна превратиться в колокольчик с гауссовским распределением. Для него можно принять доверительный интервал с некой вероятностью. Исходя из этого, получится не единственное значение, а некий диапазон. Чем выше вероятность, тем шире диапазон. Если диапазон нулевой, то и вероятность истинного значения нулевая;) Я предлагаю, если предыдущее значение находилось внутри текущего диапазона (для заданной вероятности), то показания не менять. Если выпало за диапазон, то смещать показания как можно ближе к центру нового диапазона. Да, статистическую динамику будет видно хуже, но если мы говорим про измерение, то вероятность истинного значения не меняется. Или я невнимательно слушал на первом курсе.

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

А если не превысили, то что отображаем на экране? Предыдущее защелкнутое значение?

Нет. Если у него разрешение выше точности настолько, что нечувствительность в 1..2 lsb точность не ухудшает. Например, добавится еще один разряд в индикации.

Делал лабу по оптике на третьем курсе. Оформлял в экселе. Установил точность 6 знаков после запятой для данных - чисто для красоты. Препод был дотошный, и лабу принимать отказался, т.к. 6 знаков после запятой - это бред, а не красота. Я с ним полностью согласен! Устанавливать ровно 5.00 вместо 4.99 и 5.01 из той же оперы. Это погрешность 0.2%, что во много раз отличается от реальной погрешности (1%, 5%, 10%).

Если юзер задает переменную кнопками - не обсуждаем, т.к. в этом случае телепание переменной отсутствует. Если аналоговой крутилкой, то можно либо отказаться от зоны нечувствительности, либо модифицировать код: - если было управление (дельта более 2 lsb), то на 5 секунд отключить зону нечувствительности. - если не было событий в виде "дельта более 2 lsb" в течение более 5 секунд, то включить зону нечувствительности.

Вот еще пример. На входе i, на выходе adc_press_value. Таймаут adc_press_to где-то увеличивается в мс. Итого: если переменная не изменилась больше чем на 2 lsb, то меняться будет раз в 10 секунд. Если изменилась более чем на 2 lcb, то обновиться мгновенно. Пользуюсь серийно - юзеры довольны. i = (i / 10) * 75006 / 1000000; if((myabs(adc_press_value - i) > 2) || (adc_press_to > 10000)) { adc_press_value = i; adc_press_to = 0; }

Только зону нечувствительности на несколько дискретных значений. Не понятно, что будет на экране при телепании переменной 9.94<>9.95. Телепание показаний 9.9<>10.0, судя по вашей табличке?

А зачем это может понадобиться? Есть разные виды соединений: - винтики/клепки; - пайка; - сварка. Для радиатора от БП разве клепками не обойтись?

Я для решения подобной задачи делал полноценный шлюз на ESP8266. На стороне WiFi эмулировал один протокол, на стороне UART - другой. В промежутке - как бы, полноценное устройство. По UART обмениваемся с устройством командами, и имеем полную копию статуса устройства. По WiFi получаем команды и отправляем ответы из копии полного статуса устройства. Вообще, запрос-ответ по WiFi для ESP8266 составляет в среднем порядка 20мс, но есть редкие события и по 500 мс.

Вот видео по теме.

Проверить распиновку разъема - я встречал два различных варианта. Как правило, пин RST в режиме STM32 не дергается - нужно дорабатывать программатор.

А TIM_GetTimeStamp_ms не переполняется?