Доброго времени суток.

Разрабатываю систему сбора данных на основе LTR114.
За основу взял код из примера. Все, вроде, и работает, но есть одно НО:
данные приходят из АЦП с задержкой. Грубо говоря, выдергиваю входной кабель из модуля и еще с пол минуты наблюдаю стабильную правильную картину.
Пробовал изменять FreqDivider, Interval и частоту вызова LTR114_Recv.
При попытке установить режим, в котором данные на АЦП собираются с той же частотой, либо реже чем осуществляется вызов LTR114_Recv при обработке полученных данных возникает ошибка что-то вроде 'неверный номер канала'.
Попытки использовать LTR114_GetFrame пока также ни привели к чему-либо, т.к. сразу же возникает ошибка 'модуль занят'.

Посоветуйте, как побороть проблему с запаздыванием данных.

Здравствуйте.

А сам исходный пример при этом у Вас работает правильно?

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

Вам нужно построить сбор так, чтобы:
1. Вычитывать все данные из буфера
2. в PorcessData при этом всегда нужно передавать блоки данных кратные размеру кадра и только принятые слова (анализировать возвращенное значение Recv()).

Есть как минимум два подхода:
1. В отельном потоке постоянно вычитывать и обрабатывать данные задами блоками с таймаутом, взятым с запасом (как сделано в примере)
2. По периодическому таймеру принимать все данные, что пришли, указывая размер с запасом и минимальный таймаут (1). Эти данные складывать в циклический буфер и уже доставать их оттуда блоками, нужными для обработки и передавать в ProcessData()

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

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

В Recv я передаю буфер, кратный размеру кадра. Также я обрабатываю возвращаемое значение, соответствующее количеству принятых данных. Непонятно, почему возникает ошибка 'неверный номер канала' (или что-то в этом роде).

Подскажите, пожалуйста, на сколько быстро работает GetFram? Например, при старте сбора данных выполняется 13 калибровочных циклов (устанавливаю режим калибровки INIT), что довольно долго при низких частотах дискретизации. Возможно, простейшим решением моей проблемы было бы вызывать GetFrame с заданной периодичностью, но есть ли возможность, что я смогу делать это раз в секунду?

Предположительно потому, что Recv() может вернуть значение меньше размера буфера, если за заданное время не прейдет нужное количество слов, при этом возвращенное значение не обязательно кратно размеру кадра (в этом случае часть кадра может прийти в конце одного Recv(), а конец - в начале следующего Recv(), тогда если этот блок как есть передать в ProcessData(), то она выругается на второй блок, т.к. она ожидает, что данные начинаются с начала кадра. Вам нужно тогда это обеспечивать самому (склеивать разорванные кадры).

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