Перейти к содержанию
    

Цифровой интегратор. Реализация на микроконтроллере.

Уберите аналоговый интегратор, оцифруйте сигнал виброускорения.

...

 

Строго говоря, это не совсем корректный совет.

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

Кроме того, временные и частотные характеристики могут отличаться тоже вполне ощутимо. Особливо, если выяснится, что сигма-дельта не подходит.

В общем случае, надо делать оценочный баланс по шуму, временным и частотным характеристикам, а потом принимать решение.

 

Но что верно, то верно. Если в системе есть ресурсы, и задача позволяет, то лучше всё переводить в цифру.

Уровень гибкости и возможности цифровых и аналоговых решений просто несопоставимы.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

 

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

 

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

есть возможность - сделайте в аналоге 2 интегратора со сбросом и/или "разрядом"- не понравится - отключите второй (пустите сигнал в обход) и интегрируйте в цифре.

 

Диапазон частот устройства 0,5-320 Гц. Частоту дискретизации сделаем 820 Гц.

еще подумайте насколько круто ограничен диапазон за 320 Гц и корректно ли будет работать ваш сигма дельта при таких соотношениях частот дискретизации и сигнала.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Вставлю и я пять копеек. Закидывать значения АЦП в кольцевой буфер такого размера, чтобы получилось правильное время интеграции. Затем все складывать и делить на размер буфера. Если правильно выбрать тип данных, то насыщаться не будет. Т.к. точки, которые были раньше чем длина буфера больше не входят в сумму.

 

Это будет прямоугольное окно.

 

Если перед усреднением умножать на маску размера буфера, скажем гауссову, то будет гауссово окно.

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Вставлю и я пять копеек. Закидывать значения АЦП в кольцевой буфер такого размера, чтобы получилось правильное время интеграции. Затем все складывать и делить на размер буфера. Если правильно выбрать тип данных, то насыщаться не будет. Т.к. точки, которые были раньше чем длина буфера больше не входят в сумму.

 

Это будет прямоугольное окно.

 

Если перед усреднением умножать на маску размера буфера, скажем гауссову, то будет гауссово окно.

 

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

Изменено пользователем MSP430F

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Вот такой еще вопрос.

Пишут, что одним из оптимальных методом интегрирования является метод трапеций:

Yn+1 = Yn + 1/2(Xn+1 + Xn). Но в чем тут смысл ? В следующей итерации оставшаяся половина от Xn+1 также будет просуммирована.

Тогда в чем разница от метода прямоугольников, чтобы не написать просто Yn+1 = Yn + Xn+1 ?

 

Или все дело в частотах и метод трапеций начинает работать при частотах входного сигнала, сопоставимых с частотой Найквиста ?

Методы имеют одинаковый порядок ошибки:

Доказательство

Но 1/2 как правило выполняется с округлением или отбрасыванием последнего бита. Поэтому в методе трапеций ещё присутствует неявный нч фильтр.

 

 

 

Всем доброго времени суток!

 

С ходу задача кажется не сложной - надо просто оцифрованные значения на каждом шаге умножать на некий коэффициент и прибавлять к переменной - аккумулятору, а с него уже подавать на ЦАП. Но как избежать возможного насыщения цифрового интегратора ? Надо ли обязательно использовать float для вычислений или достаточно будет int (32 бит) ?

 

Буду признателен за любые подсказки.

Float тоже имеет насыщение. Причем сопоставимое с тем же int32. Если числа типа float при сложении имеют разный порядок, то они будут складываться с ошибками или во все не складываться.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Как же я сам не додумался! Я в своей задаче каждый раз заново считаю.

Изменено пользователем Scientificer

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Как же я сам не додумался! Я в своей задаче каждый раз заново считаю.

аа понял, дак это не интегратор получается, а что-то вроде CIC фильтра или скользящего среднего.

скорее всего так вы получите некий интеграл на промежутке времени, скорее всего для оценки скорости и перемещения не абсолютного это подойдет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

аа понял, дак это не интегратор получается, а что-то вроде CIC фильтра или скользящего среднего.

 

Ну мне именно скользящее среднее и предложили использовать в качестве интегратора... Я просто предложил экономичный алгоритм его расчета для целых чисел. Вы считаете, что скользящее среднее и интегратор сильно разные вещи ?

Изменено пользователем MSP430F

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

ага его всегда так и считают, в этом его плюс- малая вычислительная потребность.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Сначала решите простую задачу:

 

Вы сели в автомобиль и поехали. Из приборов у вас только спидометр и секундомер. Как определить пройденный путь по истечении времени ?T? В соответствии с курсом средней школы:

 

p><p>

 

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

 

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

 

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

 

У вас примерно та же ситуация, только в случае с акселерометром вместо спидометра будет 2 последоваетльных интегратора.

 

Ну мне именно скользящее среднее и предложили использовать в качестве интегратора... Я просто предложил экономичный алгоритм его расчета для целых чисел. Вы считаете, что скользящее среднее и интегратор сильно разные вещи ?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ну мне именно скользящее среднее и предложили использовать в качестве интегратора... Я просто предложил экономичный алгоритм его расчета для целых чисел. Вы считаете, что скользящее среднее и интегратор сильно разные вещи ?

 

 

Пф скользящего среднего:

 

?H(z) {=} \frac{1-z^{-N}}{1-z^{-1}}

 

Пф интегратора:

 

?H(z) {=} \frac{1}{1-z^{-1}}

 

Не очень одинаковые.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

ведь интегрируя мгновенное ускорение автор получит мгновенную скорость, (если средняя скорость нулевая!!!), интегрируем мгновенную скорость в течение некоего времени получим некое расстояние.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...