Здравствуйте. Подскажите, в чем может быть проблема. При обработке буфера "сырых" данных с 41-го модуля функцией LTR41_ProcessData размер массива size становится равным 1. Как описано в документации, это происходит при возникновении ошибки во время обработки.

// буфер "сырых" данных
uint[] buf = new uint[1000];
// буфер обработанных данных
ushort[] data = new ushort[1000];
// буфер временных меток
uint[] tstamp = new uint[1000];

// забираем данные АЦП
int Size = (int)_ltr41api.LTR41_Recv(ref ltr41, buf, tstamp, 1000, 500); // здесь size=1000

if (Size > 0)
{
    _LTRNative.LTRERROR resProcess = _ltr41api.LTR41_ProcessData(ref ltr41, buf, data, ref Size); // здесь size=1. в чем причина???

}

По исходникам этой функции LTR41_ProcessData видна ошибка в dll. Выход без ошибки после первого преобразованного значения. Исправленный вариант этой функции можно просто использовать вместо её вызова в потоке приёма с LTR41. Я подобное реализовал под Делфи.

Добрый день. А можно подробней о решении проблемы. Дело в том что при работе с ltr41 при вызове ProcessData size становится равным 1. И еще меня смущает что в массиве tstamp (при внутренней генерации), секундные метки нарушают хронологическую последовательность и ведут себя довольно хаотично. Что это может быть?
Экспериментировал на C# с использованием ltrModulesNet.

Налицо нарушение непрерывности приёма данных от LTR41, обнаруженное по значениям поля циклического счётчика в формате 32-битного слова сырых данных. Позитивно то, что в LTR такая ситуация отлавливается. О возможных причинах коллеги подскажут в понедельник.

Добрый день. Вопрос еще актуален) Что делать с единичным размером?

Обновили библиотеку, в процессе заливки на сайт. Пока ссылка на наш FTP ftp://ftp.lcard.ru/pub/ltr/ltr_binary.zip

Сейчас вроде все работает корректно.
Спасибо за помощь.