Форум РадиоКот

[uquote="ARV",url="/forum/viewtopic.php?p=3159731#p3159731"]

roman.com писал(а):Тут, на выходе 10 разрядного АЦП получаем 8 разрядов данных (или 9 разрядов). Понятно, что разрешающая способность АЦП меньше, но зато последний разряд не шумит))

чтобы получать 8 разрядов с нешумящими (хотя это самообман) разрядами, специально придуман режим "выравнивания влево" (бит ADLAR) - включите его и пользуйтесь ADCH в качестве результата - к чему какие-то загадочные вычисления, гистерезисы и т.п.?

но повторяю еще раз: это самообман. кто вам мешает в 10-битном результате всегда тупо давить младший бит в 0? и не будет он шуметь...[/uquote]
я недавно столкнулся с проблемой. Фильтрую показания магнетометра из MPU9250 ибо шумят очень сильно. И проблема такова, что при использовании скользящего среднего или просто среднего или фильтра Кальмана в направлении близком к нулю градусов измеряемый результат начинает колебаться в пределах от -175 градусов до 5 градусов. И фильтрация ничего не дает, то есть дает, но результат совершенно неверный. И вот я подумал, что тут бы и применить этот метод, а именно "занулять" два или три разряда. Все никак руки не дойдут опробовать это дело

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

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

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

ozonn писал(а):И чем вам это не нравится?

Чем мне не нравится? )) Временем обработки прерывания... Важные прерывания.. не важные прерывания... А если у меня есть важные прерывания, например аварийный датчик отключения системы на INT0...

Ну хорошо... МК чёто делает... сработало прерывание по завершению преобразованию АЦП... уходим в обработчик прерывания по завершению преобразования АЦП... Сидим в обработчике и чёто там считаем... примерно так:

a=ADCW; // первая выборка АЦП... записали данные из АЦП в переменную "a" (тип int)...
повторный запуск...
...
a=a+ADCW; // вторая выборка АЦП... прибавили данные из АЦП в переменную "a" (тип int)...
повторный запуск...
...
a=a+ADCW; // третья выборка АЦП... прибавили данные из АЦП в переменную "a" (тип int)...
сброс...
повторный запуск...
...
a=a/3; // нашли среднее значение по трём выборкам АЦП...
повторный запуск...
...

А пока мы сидели в обработчике прерывания по завершению преобразования АЦП... в это время самое время сработал Запрос на внешнее прерывание 0 ... Нужно НЕМЕДЛЕННО обработать это прерывание и отключить систему!!! Получили отложенное прерывание... И что? МК сначала закончит обработку прерывания по завершению преобразования АЦП... Затем выйдет из обработчика... Выполнит ещё одну инструкцию.. и только потом перейдёт в обработчик по вектору INT0... На всё это уйдёт грубо до 10...20 микросекунд (зависит от длины кода обработчика и тактовой частоты МК)... Только после этого сработает аварийное отключение системы. Вот только через 10...20 микросекунд отключать будет уже нечего.. потому что за это время всё нафиг уже сгорело)))

Поэтому, оставляем только аварийное прерывание по вектору INT0. В случае Запрос на внешнее прерывание 0, МК немедленно перейдёт в обработчик по вектору INT0. При этом время на отключение системы потребуется меньше 1 микросекунды (зависит от длины кода обработчика и тактовой частоты МК). За это время ничего сгореть не успеет (а может и испеет... всё зависит от системы).
А всякие там АЦП и прочее, не важное, можно обработать и в главном цикле..

Это просто пример... что может быть важно, а что не очень важно... ))

ozonn писал(а):сначала делим результат измерения на 2, потом, независимо от того, больше ли это частное чем предыдущее частное плюс один или оно меньше, чем предыдущее частное минус один, выполняем одно и то же действие, а именно, еще раз делим результат на два. Т.е. получаем результат в четыре раза меньше измеренного. В чем тут фокус?

char u; // u - выход данные АЦП
int ub; // ub - буфер АЦП

a=ADCW/2; // это просто делим на 2. Було 10 разрядов, стало 9 разрядов)) Это не важно))

А фокус тут:
if (a>ub+1) {u=a/2; ub=a;};
if (a<ub-1) {u=a/2; ub=a;};

// Если новые данные (АЦП) отличаются больше чем на один от ранее записанных (в буфер АЦП), то новые данные (АЦП) вступают в силу (u - выход данные АЦП). И одновременно сохраняем новые данные (в буфер АЦП).
// Если новые данные (АЦП) не отличаются/или отличаются не больше чем на один от ранее записанных (в буфере АЦП), то это просто ШУМ (АЦП). В этом случае новые данные (АЦП) игнорируются.

Так полностью избавляемся от шума..)) Там лучше смотреть на графике АЦП...

[uquote="ARV",url="/forum/viewtopic.php?p=3159740#p3159740"]видите ли, в чем дело... когда вы отбрасываете биты, то просто загрубляете измерения,[/uquote]
да, я это отчетливо понимаю. Просто пока не вижу иного способа отфильтровать такого рода шум. Может придумать какой-либо алгоритм, чтобы отбрасывать отрицательные значения при условии, что их фильтруемом диапазоне выборок меньше чем положительных... Пока не знаю, что тут делать

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

[uquote="roman.com",url="/forum/viewtopic.php?p=3159742#p3159742"]Чем мне не нравится? )) Временем обработки прерывания... Важные прерывания.. не важные прерывания... А если у меня есть важные прерывания, например аварийный датчик отключения системы на INT0...[/uquote]
причем тут время обработки? Время обработки какого либо события не зависит от того выполняется ли оно в прерывании или в другом месте. Если у вас самое важно событие происходит по прерыванию на INT0, то, разумеется, другие прерывания должны быть запрещены. К сожалению у атмег одноуровневая система. Но, таких событий задержка обработки которых смерти подобна, не так уж и много

[uquote="ARV",url="/forum/viewtopic.php?p=3159731#p3159731"]чтобы получать 8 разрядов с нешумящими (хотя это самообман) разрядами, специально придуман режим "выравнивания влево" (бит ADLAR)[/uquote]
я вкурсе)) ADMUX=0b00100000; // где 1- ADLAR - Выравнивание результата
[uquote="ARV",url="/forum/viewtopic.php?p=3159731#p3159731"]к чему какие-то загадочные вычисления, гистерезисы и т.п.?
но повторяю еще раз: это самообман. кто вам мешает в 10-битном результате всегда тупо давить младший бит в 0? и не будет он шуметь...[/uquote]
в том то всё и дело... сколько бы мы последних бит не выбрасывали, младший бит будет шуметь.

Ivanoff-iv писал(а):про гистерезис — это люфт, создаём диапазон и если измерение из него вышло обновляем переменную (и диапазон вслед за ней) точность снизится, но для диспл5в нормально — меньше цифры мельтешат.

вот вы меня поняли с первого раза..)) Да, часто бывает так, что лучше загрубить АЦП, главное чтобы циферки на экране не мельтешили.. (уж очень это раздражает) .. )) С гистерезисом (он же люфт, кому как больше нравится.. который напоминает мне Триггер Шмитта с "плавающим" начальным смещением... и т.д.) циферки на экране не мельтешат))

Конечно, есть и другие способы, типа перевести МК в режим непрерывного преобразования... выставить нужную частоту выборок АЦП с помощью тактового генератора и предделителя, как минимум в десятки (сотни) раз больше максимальной частоты шума на входе АЦП... Затем найти максимальное и минимальное значение... на ходу найти среднее значение...
Только это уже будет не МК, а сигнальный процессор))

ozonn писал(а):Время обработки какого либо события не зависит от того выполняется ли оно в прерывании или в другом месте.

я вкурсе))

ozonn писал(а):другие прерывания должны быть запрещены.

Запрос на внешнее прерывание по INT0 может произойти в любой момент.. непредсказуемо)) Значит, другие прерывания должны быть запрещены ВСЕГДА.

ozonn писал(а):обработки которых смерти подобна, не так уж и много

Да, их мало. Но аварийные прерывания настолько важные, что всё остальное уже не важно...

[uquote="roman.com",url="/forum/viewtopic.php?p=3159758#p3159758"]Запрос на внешнее прерывание по INT0 может произойти в любой момент.. непредсказуемо)) Значит, другие прерывания должны быть запрещены ВСЕГДА. [/uquote]
вот именно: другие прерывания должны быть запрещены всегда. А вот нужное прерывание должно быть разрешено. О чем я, собственно, и веду речь. Прерывания весьма полезная вещь и их надо применять везде, где это допустимо

Добавлено after 1 minute 14 seconds:
[uquote="roman.com",url="/forum/viewtopic.php?p=3159758#p3159758"]в том то всё и дело... сколько бы мы последних бит не выбрасывали, младший бит будет шуметь.[/uquote]
с каких это делов он будет шуметь?

есть средство (правда тоже не лишено...) разрешать прерывания внутри некритичных прерываний или после выполнения критичного кода.

ozonn писал(а):К сожалению у атмег одноуровневая система.

Вот и я об этом...

Ivanoff-iv писал(а):разрешать прерывания внутри некритичных прерываний

Типа вложенное прерывание в меги... не помню... кажись чтото пробовал... Вы имеете ввиду типа Регистр статуса SREG ?

Цитата:
"Бит I сбрасывается в 0 аппаратно после генерации запроса на прерывание, а после выполнения инструкции возврата из прерывания RETI снова устанавливается к 1 для выполнения последующих прерываний. Бит I может также сбрасываться и устанавливаться программно"...

ozonn писал(а):с каких это делов он будет шуметь?

особенность работы АЦП... Сначала всё переводим в цифровой код, а затем выравниваем (аппаратно или программно).

Ну допустим подключили ИОН к VCC и подали половину напряжения питания на вход АЦП...
Получили код - 10 бит - (512) или 10 0000 0000.

Даже если выкинуть 9 бит и оставим один старший бит (он же последний),
10 0000 0000 >> 9 = 1. (10 0000 0000)

то под действием шума на входе АЦП, этот последний бит будет шуметь... а показания будут прыгать около среднего значения, т.е. между значением (512) или 10 0000 0000 и значением (511) или 01 1111 1111... ))

или так:
(512) 10 0000 0000 >> 9 = 1. (10 0000 0000)
(511) 01 1111 1111 >> 9 = 0. (01 1111 1111)


последний бит... шумит зараза..))

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

Добавлено after 2 minutes 34 seconds:
но были предприняты меры против "сингулярности"

[uquote="roman.com",url="/forum/viewtopic.php?p=3159789#p3159789"]

ozonn писал(а):с каких это делов он будет шуметь?

особенность работы АЦП... Сначала всё переводим в цифровой код, а затем выравниваем (аппаратно или программно).

Ну допустим подключили ИОН к VCC и подали половину напряжения питания на вход АЦП...
Получили код - 10 бит - (512) или 10 0000 0000.

Даже если выкинуть 9 бит и оставим один старший бит (он же последний),
10 0000 0000 >> 9 = 1. (10 0000 0000)

то под действием шума на входе АЦП, этот последний бит будет шуметь... а показания будут прыгать около среднего значения, т.е. между значением (512) или 10 0000 0000 и значением (511) или 01 1111 1111... ))

или так:
(512) 10 0000 0000 >> 9 = 1. (10 0000 0000)
(511) 01 1111 1111 >> 9 = 0. (01 1111 1111)


последний бит... шумит зараза..)) [/uquote]
честно говоря, даже и не понял, что вы тут написали. Допустим, вы выровняли результат по левому края и читаете только ADCH, т.е. имеете 8 разрядный результат. Допустим, два младших, из этих восьми шумят, остальные нет. Далее делаем следующее:

result = result & 0b11111100;

получаем только шесть старших бит, ни один из которых не шумит. И АЦП тут не причем

это означает - что если величина трётся около круглого значения, то, чтобы избавиться от шума отрезать придётся слишком много
а гистерезис решит такую проблему: допустим напряжение надо с точностью 0.1в, на экране 12.5в, когда поднимется до 12.6 - запишем 12.6, а когда обратно пойдет, то только при 12.5 запишем 12.5в, а при 12.54 - на экране может быть и 12.5 и 12.6в (в зависимости от того, что было раньше).

Ivanoff-iv писал(а):если величина трётся около круглого значения, то, чтобы избавиться от шума отрезать придётся слишком много
а гистерезис решит такую проблему

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

не понятно, к чему этот цирк, если фильтрация решает все проблемы по-настоящему?

[uquote="ARV",url="/forum/viewtopic.php?p=3160100#p3160100"]

Ivanoff-iv писал(а):если величина трётся около круглого значения, то, чтобы избавиться от шума отрезать придётся слишком много
а гистерезис решит такую проблему

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

не понятно, к чему этот цирк, если фильтрация решает все проблемы по-настоящему?[/uquote]
та да, как бы непонятно, если величина "трётся", то тут сам бог велел фильтровать. Даже простое усреднения даст неплохой результат

конечно при выборе метода фильтрации очень важно, для чего фильтруем

ozonn писал(а):Даже простое усреднения даст неплохой результат

неплохой результат меня не устраивает... мне нужен абсолютный результат))

ARV писал(а):к чему этот цирк, если фильтрация решает все проблемы по-настоящему?

какая фильтрация даёт абсолютный результат ?

ozonn писал(а):делаем следующее:result = result & 0b11111100; получаем только шесть старших бит, ни один из которых не шумит. И АЦП тут не причем

Да, получаем только шесть старших бит, из которых все шесть старших бит шумят:

0b11111100 <> 0b11111011 - шум
0b11111000 <> 0b11110111 - шум
...
...
... и т.д. )))

[uquote="roman.com",url="/forum/viewtopic.php?p=3160170#p3160170"]

ozonn писал(а):Даже простое усреднения даст неплохой результат

неплохой результат меня не устраивает... мне нужен абсолютный результат))[/uquote]
тогда вам нужно идти в церковь. Только там вам помогут

Добавлено after 2 minutes 35 seconds:
[uquote="roman.com",url="/forum/viewtopic.php?p=3160170#p3160170"]

ozonn писал(а):делаем следующее:result = result & 0b11111100; получаем только шесть старших бит, ни один из которых не шумит. И АЦП тут не причем

Да, получаем только шесть старших бит, из которых все шесть старших бит шумят:

0b11111100 <> 0b11111011 - шум
0b11111000 <> 0b11110111 - шум
...
...
... и т.д. )))[/uquote]
и каким же образом они "шумят"? Вы смысл термина "шум" понимаете?

ozonn писал(а):Вы смысл термина "шум" понимаете?

объясните..))

объясняю:
шум, это непредсказуемые(хаотичное) изменения какой либо величины, в нашем случае - измеряемого напряжения. Если у вас к примеру, измеряемое напряжение представляется однобайтовым числом, в котором шумит, т.е. непредсказыемо меняется младший разряд, то выполнив операцию "и" измеренного значения с маской 0b11111110, вы получите число, которое не будет меняться хаотично.