История изменений

По идее должно занимать около 22мс и быть стабильным.

Если будет так, то можно вернуться назад и дополнительно рассмотреть вариант с равномерным интервалом измерений по таймеру. То есть задается интервал, который заведомо больше времени измерения и расчета. Скажем, 200 мс и выше. По событиям таймера делать измерения, считать и складывать во временный буфер, а потом в удобный момент отправлять это все скопом. Можно и сразу по одному. но это все если измерение по времени стабильно, а не скачет в диапазоне 10 мс.

Плюс равномерной шкалы будет в случае, если нужно будет гнать измерения по интерфейсу (не текущий объем, а мгновенное значение скорости). Если ты знаешь, что данные сняты с шагом 200 мс, то и нет проблем с интерпретацией. Данные могут приходить неравномерно, но ты точно знаешь, что там содержатся отсчеты каждые 200 мс и измерять на компьютере интервалы не надо. Вот сейчас информации об интервале нет и GUI вынуждено считать интервал по таймеру, что дает ошибку. Минус в том, что надо заведомо знать, сколько времени работает алгоритм, чтобы знать минимально возможный интервал отсчетов, иначе до следующего измерения не успеет посчитать.

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

По идее должно занимать около 22мс и быть стабильным.

Если будет так, то можно вернуться назад и дополнительно рассмотреть вариант с равномерным интервалом измерений по таймеру. То есть задается интервал, который заведомо больше времени измерения и расчета. Скажем, 200 мс и выше. По событиям таймера делать измерения, считать и складывать во временный буфер, а потом в удобный момент отправлять это все скопом. Можно и сразу по одному. но это все если измерение по времени стабильно, а не скачет в диапазоне 10 мс.

Плюс равномерной шкалы будет в случае, если нужно будет гнать измерения по интерфейсу (не текущий объем, а мгновенное значение скорости). Если ты знаешь, что данные сняты с шагом 200 мс, то и нет проблем с интерпретацией. Данные могут приходить неравномерно, но ты точно знаешь, что там содержатся отсчеты каждые 200 мс и измерять на компьютере интервалы не надо. Вот сейчас информации об интервале нет и GUI вынуждено считать интервал по таймеру, что дает ошибку. Минус в том, что надо заведомо знать, сколько времени работает алгоритм, чтобы знать минимально возможный интервал отсчетов, иначе до следующего измерения не успеет посчитать.

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

По идее должно занимать около 22мс и быть стабильным.

Если будет так, то можно вернуться назад и дополнительно рассмотреть вариант с равномерным интервалом измерений по таймеру. То есть задается интервал, который заведомо больше времени измерения и расчета. Скажем, 200 мс и выше. По событиям таймера делать измерения, считать и складывать во временный буфер, а потом в удобный момент отправлять это все скопом. Можно и сразу по одному. но это все если измерение по времени стабильно, а не скачет в диапазоне 10 мс.

Плюс равномерной шкалы будет в случае, если нужно будет гнать измерения по интерфейсу (не текущий объем, а мгновенное значение скорости). Если ты знаешь, что данные сняты с шагом 200 мс, то и нет проблем с интерпретацией. Данные могут приходить неравномерно, но ты точно знаешь, что там содержатся отсчеты каждые 200 мс и измерять на компьютере интервалы не надо. Вот сейчас информации об интервале нет и GUI вынуждено считать интервал по таймеру, что дает ошибку. Минус в том, что надо заведомо знать, сколько времени работает алгоритм, чтобы знать минимально возможный интервал отсчетов, иначе до следующего измерения не успеет посчитать.

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

По идее должно занимать около 22мс и быть стабильным.

Если будет так, то можно вернуться назад и дополнительно рассмотреть вариант с равномерным интервалом измерений по таймеру. То есть задается интервал, который заведомо больше времени измерения и расчета. Скажем, 200 мс и выше. По событиям таймера делать измерения, считать и складывать во временный буфер, а потом в удобный момент отправлять это все скопом. Можно и сразу по одному. о это все если измерение по времени стабильно, а не скачет в диапазоне 10 мс.

Плюс равномерной шкалы будет в случае, если нужно будет гнать измерения по интерфейсу (не текущий объем, а мгновенное значение скорости). Если ты знаешь, что данные сняты с шагом 200 мс, то и нет проблем с интерпретацией. Данные могут приходить неравномерно, но ты точно знаешь, что там содержатся отсчеты каждые 200 мс и измерять на компьютере интервалы не надо. Вот сейчас информации об интервале нет и GUI вынуждено считать интервал по таймеру, что дает ошибку. Минус в том, что надо заведомо знать, сколько времени работает алгоритм, чтобы знать минимально возможный интервал отсчетов, иначе до следующего измерения не успеет посчитать.

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