Моргалка на Arduino. Этюды для начинающих.

[11vetal]

еще, в качестве примера http://we.easyelectronics.ru/Theory/chestno-prostoy-cifrovoy-filtr.html

[Alex_Soroka]

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

причем сложных помех: "прямоугольные" импульсы(фронты и "ступеньки") раскладываются в ряд Фурье еще в кучи разных частот и гармоник 

[UriBas]

Круто конечно, только я не пойму смысла - зачем эта программа лишний раз нагружающая слабенький МК если она легко заменяется всего двумя детальками - резистором и конденсатором (RC фильтр), которые даже лучший результат дают, без всяких ступенек. 

Программным способом мы имеем возможность в ходе работы гибко менять алгоритм.. исходя из состояния АКБ и цели.  К примеру, если надо как раз отлавливать пики, или провалы (при анализе спада или подъема скорости - для обнаружения слабых банок)  то  RC фильтр будет мешать, правда это уже для сугубо узких каких-то задач.

[Яков93]

К примеру, если надо как раз отлавливать пики, или провалы (при анализе спада или подъема скорости - для обнаружения слабых банок)  то  RC фильтр будет мешать, правда это уже для сугубо узких каких-то задач.

Явно не для этой "моргалки на Ардуино" задача.
Отлавливать пики и спады можно и с RC фильтром, просто выглядеть они будут не настолько "прямоугольно" как может быть на самом деле.

К вопросу об эффективности "моего" скетча.
Вот для интереса сейчас снял показания которые получает моя "ардуина" с датчика тока - 3 цикла замера по 32 замеров в каждом

1: 570 569 569 569 568 656 633 593 580 578 577 574 573 573 572 572 573 571 571 571 569 573 569 570 570 569 569 570 572 571 571 573
2: 570 569 569 568 570 569 570 569 569 591 655 601 585 578 581 577 577 577 576 574 588 577 572 573 573 572 573 572 572 575 573 570
3: 577 574 575 575 574 574 579 576 576 575 576 572 572 572 571 572 574 573 578 573 572 572 566 572 567 568 569 567 566 574 567 566

Как видно скачут цифры достаточно сильно, хотя ток идет постоянный. И это еще после двух последовательных RC фильтров  Не пойму пока в чем может быть помеха, ну да ладно, не об этом.

Чтобы выкинуть излишне высокие или излишне низкие значения, они сортируются по возрастанию, получается вот такая штука
1: 568 569 569 569 569 569 569 569 570 570 570 570 571 571 571 571 571 572 572 572 573 573 573 573 573 574 577 578 580 593 633 656
2: 568 569 569 569 569 569 570 570 570 570 572 572 572 572 573 573 573 573 574 575 576 577 577 577 577 578 581 585 588 591 601 655
3: 566 566 566 567 567 567 568 569 571 572 572 572 572 572 572 572 573 573 574 574 574 574 574 575 575 575 576 576 576 577 578 579

Видно что в два первых цикла попали совершенно выбивающиеся высокие показатели, которые если просто их усреднить вместе со всеми остальными дадут неправильное среднее. Поэтому берем те показания что в середине и ищем среднее только из них
1: 569 570 570 570 570 571 571 571 571 571 572 572 572 573 573 573
2: 570 570 570 572 572 572 572 573 573 573 573 574 575 576 577 577
3: 569 571 572 572 572 572 572 572 572 573 573 574 574 574 574 574

В итоге получаются такие значения:
1: 571
2: 573
3: 572

При этом если бы искали просто тупое арифметическое из 32 значений получилось бы такое :
1: 576
2: 577
3: 572
и увеличение выборки до 500+ значений помогает слабо, зато круто тормозит программу.

[Alex_N]

Я не заметил, что бы 500 измерений сильно тормозили мою программу. Это же не управление самолётом. В АКБ процессы идут очень медленно, поэтому в данном случае это вполне приемлемо.
Я не отрицаю применение фильтров. Всё хорошо в меру. Но более менее сглаживающие фильтры работают с вещественными числами, а это память.
Тут чуть-чуть,  там.., так и вся закончилась. В данном случае лучше пожертвовать быстродействием. Хотя, в каждом конкретном случае всё по разному.
У меня теперь ардуина будет работать, как составная часть системы, включающая ноутбук. Вот там и можно будет с математикой наиграться. Сейчас собираю девайс, потом прога.

[bones]

А вот осциллограф видит и показания в МК, и следующие расчеты также идут с учетом этих ступенек.

Нет, ступенька там - это 1 LSB, они есть всегда, когда речь идет об оцифровке сигнала.
Для реализации этого фильтра требуется 1 умножение и пара сложений (все можно сделать в целых числах), не думаю что на фоне заполнения буфера, сортировки массива и вычисления среднего это даст заметную нагрузку на МК.

1: 570 569 569 569 568 656 633 593 580 578 577 574 573 573 572 572 573 571 571 571 569 573 569 570 570 569 569 570 572 571 571 573

Вот пример примитивного цифрового фильтра для данного ряда:


Конечно, применять или нет, целиком зависит от задачи, ресурсов мк, желания и прочих факторов.

[Яков93]

Нет, ступенька там - это 1 LSB, они есть всегда, когда речь идет об оцифровке сигнала.

Не спорю, есть всегда. Только при аналоговом RC фильтре этих ступенек практически не видно, хотя там идет точно такая же оцифровка сигнала.

Для реализации этого фильтра требуется 1 умножение и пара сложений (все можно сделать в целых числах), не думаю что на фоне заполнения буфера, сортировки массива и вычисления среднего это даст заметную нагрузку на МК.

Суть "моего" скетча не в замене RC фильтра из двух копеечных деталек. А в отлавливании явных помех, которые через такой фильтр проскакивают. У меня помехи к сожалению проскакивают через два последовательных RC фильтра с разными номиналами деталей, приходится заморачиваться и отлавливать их программно.

Вот пример примитивного цифрового фильтра для данного ряда:

Спойлер

Конечно, применять или нет, целиком зависит от задачи, ресурсов мк, желания и прочих факторов.

Графики вижу, а цифрового фильтра не вижу, пусть даже самого примитивного. Ардуина графики не понимает 
Вы наверное сами видите большой недостаток этого фильтра даже на графике. Шли-шли ровненькие синие точки, красные шли на той же высоте что и синие. Потом появляется явная помеха в виде огромного пика и красные точки вместо того чтобы ее просто исключить из расчета начинают под нее подстраиваться и усредняться. В результате становятся выше чем нормальный ряд синих точек. В чем смысл подобного хитрого фильтра если то же самое сделает тупое среднее арифметическое из 32 значений?

[11vetal]

Для примера -упрощенный фильтр Калмана
U_k = (U_x + (K*U_k-1))/(K+1)
Играясь коэффициентом К можно подобрать характеристику фильтра.
Реально работает и ресурсов много не требует. Поиграйся в Excel

[Яков93]

Для примера -упрощенный фильтр Калмана
U_k = (U_x + (K*U_k))/(K+1)
Играясь коэффициентом К можно подобрать характеристику фильтра.
Реально работает и ресурсов много не требует. Поиграйся в Excel

Насколько я понимаю и умножение и особенно деление весьма затратные операции для МК. Если я правильно понимаю алогоритм этого фильтра тут требуется проводить и умножение и деление над каждым полученным значением? Получаем мы 32 значения - будьте добры 32 раза делите и 32 раза умножайте. По мне так странно при этом говорить - "ресурсов много не требует". Все относительно.

Например в похожем по результату поиске среднего арифметического есть только много сложений и одно единственное деление, которое можно сделать сдвигом регистра, что менее затратно.
В "моем" скетче основная затратная часть это массив из 32 2-х байтовых значений (int). Каюсь не знаю сколько времени занимают циклы "for" но мне представляется что не очень-то много, там никакой затратной арифметики, просто перестановка чисел местами. И в конце такой же поиск среднего арифметического только из нужного диапазона - несколько сложений и один сдвиг регистра. Не вижу чтобы это было что-то сильно затратное 

[bones]

при аналоговом RC фильтре этих ступенек практически не видно

Мы с вами друг друга не понимаем, 1LSB для 10 бит это 1/1024 от Vref вне зависимости от того, какой фильтр на входе, высота ступеньки всегда одинакова, просто автор использовал 8 бит для простоты и наглядности.
Насчет самого примитивного фильтра:
y = y0*15/16 + x*1/16;
где:
y - выход
y0 - предыдущее значение выходного сигнала
x - вход

после небольшой оптимизации получаем
y = y0 - y0/16 + x;

тогда точность будет заметно выше, при 10 бит АЦП получим виртуальный 14-разрядный выход, можно его сдвинуть, можно изменить коэффициент для пересчета в амперы/вольты.

В чем смысл подобного хитрого фильтра

На мой взгляд он существенно отличается:
1. от среднего тем, что не нужно делать Х измерений для получения результата, здесь он зависит только от текущего входного и предыдущего выходного значения.
2. от "медианы" тем, что не нужен буфер и сортировка.

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

[Яков93]

Мы с вами друг друга не понимаем, 1LSB для 10 бит это 1/1024 от Vref вне зависимости от того, какой фильтр на входе, высота ступеньки всегда одинакова, просто автор использовал 8 бит для простоты и наглядности.

Он и при аналоговом фильтре использовал 8 бит, тем не менее там график сигнала гораздо плавнее. Возможно Вы ошибаетесь насчет всего-лишь 1 LSB потерянных с применением цифрового фильтра. Не удивлюсь если быстродействие системы из-за постоянных подсчетов на цифровом фильтре не позволяло быстро делать делать замеры и рисовать плавный изгиб.

Насчет самого примитивного фильтра:
y = y0*15/16 + x*1/16;
где:
y - выход
y0 - предыдущее значение выходного сигнала
x - вход

после небольшой оптимизации получаем
y = y0 - y0/16 + x;

тогда точность будет заметно выше, при 10 бит АЦП получим виртуальный 14-разрядный выход, можно его сдвинуть, можно изменить коэффициент для пересчета в амперы/вольты.

Я не спорю, для интереса надо будет попробовать где-нть применить. Хотя я как-то больше доверяю железному резистору с конденсатором, они и без МК сигнал сгладят.

На мой взгляд он существенно отличается:
1. от среднего тем, что не нужно делать Х измерений для получения результата, здесь он зависит только от текущего входного и предыдущего выходного значения.
2. от "медианы" тем, что не нужен буфер и сортировка.

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

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

[11vetal]

эта формула работает быстрее чем поиск среднего значения и в памяти хранится только предыдущее отфильтрованное значение.

[bones]

этот "простейший фильтр" больше на быстродействие будет влиять

Вынужден с вами не согласиться,
y = y0 - y0/16 + x;
можно выразить как
y = y0 - y0>>4 + x;
в том случае если вы работаете с stm32 и у вас нормальный компилятор, то вся эта конструкция преобразуется к 1 команде на ассемблере



которая выполняется 1 такт процессора, согласно таблице.
Еще 1 такт придется потратить на получение -y0, итого 2.

Получаем вычислительную сложность алгоритма = 2 тактам процессора.

[Alex_N]

Как говорил старина Винер - "Кто в здравом уме и твердой памяти будет программировать на ассемблере ?". Вы бы ещё в машинных кодах пример привели.
Это всё уже прошлый век. Я сам раньше страдал. А теперь - ни ни. Надо рассматривать только языки высокого уровня Pascal, C, Modula и т.д.
Собственно говоря ардуина и привлекает народ дружелюбным интерфейсом. Как в своё время IBM PC/AT, после языка JCL казались просто прорывом.

[Serg]

"Кто в здравом уме и твердой памяти будет программировать на ассемблере ?"

Речь про С.
"если вы работаете с stm32 и у вас [b-b]нормальный компилятор[/b-b]" (с языка С).
Обычно компиляторы для МК очень нормальные.

[ИС-Х]

"Кто в здравом уме и твердой памяти будет программировать на ассемблере ?"

"Ну, я инвалид!" 
Для таких мелких задач, да на мелком камне мне проще на асме.

[bones]

Я не пишу на ассемблере, скриншот привел только для демонстрации сложности расчетов.
Желательно иметь представление о целевой платформе, поэтому иногда просматриваю по диагонали набор инструкций.

К примеру, на stm32, мы можем получать данные АЦП с частотой 1МГц.
1. Простейший цифровой фильтр нам позволит получать данные с частотой 1МГц
2. "среднее" из 32 даст нам данные (примерно такие же) с частотой ~30 кГц
3. "медиана" - думаю не больше 1кГц, (мы не можем предсказать время сортировки массива, поэтому придется брать максимальное).

Полагаю что на atmega будет похожая картина.

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

Исходим всегда от задачи.

[Кass]

Надо рассматривать только языки высокого уровня Pascal, C, Modula и т.д.

Эти языки не очень хорошо адаптированы под АСУ реалтайм. Ну некоторые версии С еще есть, к примеру С шарп. Вместо Паскаля есть ST, но чаще используют FBD. В FBD зачастую ФБ написан на С или ST, и его можно редактировать. На ассемблере очень долго писать. Когда были ограничения по скорости и памяти, то местами имело смысл. Сейчас такие необходимости отпали.