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

1. Тест с примером LCard.
Примеры LCard получают только измерительные данные.
Вопрос о временных метках опускается, хотя это важнейший вопрос при разработке систем непрерывного мониторинга объектов.
По этой причине мы немного доработали аналог тестового приложения LCard по мотивам примеров для LTR114 и LTR212.
Тестовое приложение создает один поток сбора измерительных данных с модуля LTR114.
Используем 6 каналов, как в одном из модулей основной программы.
Частота оцифровки каждого канала 100Гц, как в основной программе.
Текст теста прилагаем к ответу.
Добавили для каждого 2-сек блока (по 200 значений на канал) выдачу времени после получения блока с точностью до мс по часам компьютера.
Тестовое приложение назвали ltr114.
Откомпилировано в Qt под Ubuntu24.04.

2. Результаты теста.
При подключении через сложную сеть.
Тестовая программа по мотивам примеров LCard работает и работает, так как не контролирует длительность интервала между приемами порций данных.
Среднее значение интервала между примами порций данных составляет 2сек.
Но разброс очень большой. Это для нас критично с учетом того, что в нашей системе несколько крейтов, содержащих по несколько модулей. При этом требуется обеспечить предоставление синхронных данных в реальном времени .
ВОПРОС: Как снизить разброс ?

3. Прилагаются:
- Тестовое приложение «ltr114» с исходниками (1893-ltr114.7z).
- файл, содержащий лог программы (251112-1893-ltr114.txt.7z).
По разностям времени получения соседних порций данных определяли интервал получения данных.
- График интервалов (ltr114-dt.GIF).

Да. Забыл важное. При работе i5 при правильном подключении время берем с компьютера при получении очередной 2сек порции данных. В этом случае интервал между последовательными получениями порций 2сек с точностью до 1мс. При неправильном подключении этот интервал в среднем около 2сек, но разброс от 0.018 до 5.012сек.

Кроме ltrmanager, описание перепрошивки есть в ltr_cross_sdk.pdf и https://www.lcard.ru/download/#libpart9.
В последнем месте предложен bat-файл.
Так как наши люди были уже на объекте, они попробовали вариант с bat-файлом. Он сработал.

1) Высылаю файл wireshark, полученный в результате запуска сбора пакетов на wireshark, затем запуска нашей программы сбора данных с 2 крейтов с 3 и 4 модулями LTR (114-ые, 212-ые и 12-й - 7 потоков сбора данных модулями и основной поток записи данных), затем фиксируем прекращение сбора данных и после небольшой задержки завершаем программу сбора данных с LTR, а затем сбор пакетов wireshark.

2) Описание сети

2.1) Два крейта LTR, разнесенные на 20м, подключены к коммутатору в шкафу одного из этих крейтов.
В работающем (временном) варианте в том же шкафу устанавливаем компьютер с ltrd, на котором одна программа нашей система собирает измерительные данные с LTR, а другая - картинки с двух видеокамер.
Все прекрасно работает.

2.2) Другой (основной) вариант:
далее от упомянутого коммутатора по меди через 2 репитера через 100м подключение к коммутатору, от которого по оптике подключение через километры к местному провайдеру, от которого далее подключение компьютера, на котором крутится ltrd и наша система.
Сбор данных с LTR довольно быстро нарушается.
Сбор ведется порциями по 2сек.
Иногда в сессии таких порций собираем несколько десятков до прекращения работы, иногда одну порцию, довольно часто вообще не собираем.

При использовании двух RS-485/422-UART и двух линий RS485 можно будет использовать оба сигнала СТАРТ и СЕКУНДА или есть какие-то ограничения на этот счет?

Поставленный вопрос можно сформулировать так: "Как программно вызвать перезагрузку крейта, чтобы от него отвалились все коннекты?"

Сбой обычно происходил после длительной работы в одном из потоков. Обычно в функции LTR114_ProcessData. Закрывали после этого все потоки и выходили из приложения, после чего запускали с самого начала. Программа должна была работать постоянно, что мы обеспечивали ее перезапуском.