MSP430 и timestamps

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

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

В этом случае каждое измерение используется дважды, как «прежний отсчет» и как «новый отсчет».

Я почему об этом заговорил? Потому что ты выше показал код TI по расчету объема вот тут MSP430 и timestamps (комментарий) . Так вот они считают скорость до следующего измерения постоянной, поэтому считается площадь под ступенчатым графиком, как на картинке: https://ege-study.ru/wp-content/uploads/2016/03/3-пнрд.jpg. То есть они считают просто площади прямоугольников.

А как ты делаешь, и не сказано. Но, в общем-то, об этом речи и не заходило, поэтому я вскользь упомянул. Линейная аппроксимация будет такой: https://docs.scipy.org/doc/scipy-0.16.1/reference/_images/interpolate-3_00_00... и тогда, да, в расчете объема будет участвовать и предыдущий и текущий отсчет.

Да, всё так.

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

Как-то так:

https://imgur.com/a/0Mjnu8U

Но, опять же, хуже не будет, и, как я говорил, оверхед почти не добавляет.

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

http://www.machinelearning.ru/wiki/index.php?title=Методы_прямоугольников_и_т...

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

Если же сравнивать эти два метода между собой, то метод прямоугольников, который относится к методам Гаусса - Кристоффеля, является точнее метода трапеций, относящегося к методам Ньютона - Котеса. Но в то же время метод трапеций может применяться с произвольным шагом, в отличие от метода прямоугольников, который, как мы увидели, не применим, например, к функциям,заданным в конечном числе точек.

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

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

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

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

Если мы сравним суммы, то мы увидим, что в случае с прямоугольниками каждое слагаемое = v_i * t, а в случае с трапециями, мы имеем ... + (v_(i-1) + v_i) * t/2 + (v_i + v_(i+1)) * t/2 + ..., то есть каждое v_i * t/2 встречается дважды, т.е. суммы равны, что я и хотел показать картинкой.

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

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

https://ru.wikipedia.org/wiki/Метод_трапеций

А вот тут есть оценка погрешности правых, левых и средних.

https://ru.wikipedia.org/wiki/Метод_прямоугольников

Как видишь, средние прямоугольники имеют оценку погрешности в два раза меньшую, чем трапеций, но тот же порядок погрешности (второй - O(h^2)), но средние у тебя все равно невозможны. А у правых и левых прямоугольников первый порядок погрешности O(h).

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

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

Да ты что?! Это кто такое сказал? Они работают параллельно только если не вызывается процедура прерывания. Вот сейчас они работают параллельно, так как прерываний не используются (переполнения не происходит), процессор спит, таймер считает. А с каких это пор процедура прерывания таймера тут не будет влиять на основной код? Это кто же такой в этом микроконтроллере параллельно основному коду выполняет прерывание? Прерывание поэтому и должно быть желательно коротким, но процессор делает что-то одно. Ты ж вроде не первый день с микроконтроллерами-то?

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

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

MSP430 и timestamps (комментарий)

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

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

Слушай, а вообще пользователь прибора в чем заинтересован? Чтобы газа насчиталось меньше реального или больше реального? Может, вообще определять из двух соседних значений максимальное на каждом шаге и умножать его на период? :) Хе-хе, не совсем честно, но зато, практически покроет весь график с горкой. :)

Эх, если бы всё было так просто :D

В общем, по стандарту разброс значений не может превышать 1%, отклонение от эталона не больше 3%. То есть через счетчик пропускают 10 литров 5 раз, и он должен показать от 9.7 до 10.3, но разница между любыми двумя из пяти измерений должна быть не больше 0.1 литра.

А это достаточно сложно, так как при изменениях температуры меняются параметры ультразвуковых датчиков и сигнала, что приводит к ошибкам в измерениях (движения газа нет, а счетчик будет говорить что у тебя 0.1 литр в час скорость). Что приводит к ошибкам, при скорости около 16 литров в час 0.6%, что близко к тому самому 1%. А если ещё и время неточно считать, то вообще конец :)

На этом фоне метод интегрирования не выглядит особо решающим фактором, так как измерения занимают час, как минимум, и статистика берет своё.

Нечестным способом было бы идентифицировать стандартные тестовые скорости и «корректировать» показания, но это легко вскрывается и вообще, теперь у меня счетчик должен проходить тесты. Да и не уедешь далеко так, если честно. Volkswagen далеко точно не уехали :D

А как вы у себя в конторе тестируете прибор? Неужели никак, а тупо носите на испытания куда-то и каждый раз обламываетесь? Свой стенд с образцовыми, я не знаю, скоростями потоков есть?

А с температурой как поступаете? Может, термокомпенсация нужна?

Хороший, правильный испытательный стенд есть у заказчика. Они присылают данные, я им обновления прошивки.

На плохом стенде этот 1% померять очень сложно.

А у себя достаточно, чтобы не было того самого

движения газа нет, а счетчик будет говорить что у тебя 0.1 литр в час скорость

на всём диапазоне температур. Ну и ещё пары тестов.

Но вообще много разных моментов, тут не буду их расписывать. Если интересно, могу расказать в личку :)

А ты вообще чем занимаешься? Взялся бы за разработку платы на этом MCU?

А ты вообще чем занимаешься? Взялся бы за разработку платы на этом MCU?

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

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