Форум: Техническая поддержка

Подскажите, как правильно выяснить, сколько Вольт получится выдаст на выходе LTR-35 в ответ на загрузку данного кода ЦАП.
Есть ли для этого функция API? Или какую формулу для этого использовать?

(Задача, для которой это понадобилось: ведётся управление развёртками мелкими шагами (1 шаг = единица младшего разряда кода ЦАП), но при этом есть ограничения по напряжению, которые нельзя превышать. Причём эти ограничения меняются со временем. Поэтому про каждый код ЦАП нужно выяснять, попадает ли он в безопасный диапазон по напряжению.)

Во первых в LTR35 по умолчанию используется калибровка на уровне ПЛИС (пункт 3.5 https://www.lcard.ru/download/ltr35api.pdf), если Вы управляете по кодам напрямую, то насколько я понимаю перед LTR35_Configure() Вы устанавливаете коэффициенты равные Scale = 1 и Offset = 0?

Тогда для точного сопоставления Вольт и кодов Вам нужно использовать калибровку в обратную сторону, т.е. после Open прочитать значения Scale и Offset нужных выходов и сохранить их перед установкой в 1 и 0. Далее по обратной формуле вычислить какой некалиброванный код соответствует выставленному X = Y/Scale - Offset.

Далее перевести этот код в Вольты, путем V = (X/CodeMax) * AmpMax, где CodeMax - код, который при калибровке соответствует верхней границе номинального диапазона - 0x600000 (константа LTR35_DAC_SCALE_CODE_MAX), а AmpMax - само верхнее значение диапазона - 10 или 1 В, в зависимости от того, какой выход используется (1:1 или 1:10) для LTR35-1 или 20 для LTR35-2 (ну или они же сохранены в соответствующих полях ModuleInfo.DacOutDescr).

Вышеописанное верно для всего диапазона возможных кодов ЦАП?

Если речь идет о кодах, для которых соответствующее напряжение находится внутри номинального диапазона, то данная формула работает в пределах заявленной погрешности модуля, а для напряжений вне заявленного диапазона уже значение ошибки не нормируется

Подскажите, в каком порядке в структуре .Module.CbrCoef расположены структуры с калибровочными коэффициентами. Там их 8 пар, как я понимаю, по одной паре на канал вывода, соответственно для выходов 1:1 и 1:10. Но в Руководстве программиста не указано, какой элемент пары относится к 1:1, а какой к 1:10.

Сперва идут коэффициенты канала 1 для выхода 1:1, затем для выхода 1:10, и так далее для остальных 7.
Для доступа можно использовать значения из перечисления e_LTR35_DAC_OUTPUT как значение индекса, т.е. номер выхода в конфигурации соответствуют позиции в калибровках и в описании каналов в ModuleInfo.DacOutDescr.

Мне остаётся добавить к сказанному выше Алексеем, что данный метод калибровки соответствия "код-напряжение" реализуется для условия нулевого тока нагрузки. В реальных рабочих условиях для пересчёта выходного напряжения (в диапазоне рабочих нагрузок) необходимо также учесть собственное выходное сопротивление ЦАП 50,0 ± 2,5 Ом  и 389,0 ± 4,0 Ом (на диапазонах 1:1 и 1:10 соответственно) и величину сопротивления внешней нагрузки.   
Также для учёта непревышения пикового значения напряжения на выходе ЦАП в динамическом режиме следует учесть, что в тракте ЦАП имеются фильтры, создающие переходный процесс  (аппаратные в микросхеме ЦАП и корректирующее звено ФВЧ в FPGA). Для того, чтобы воспроизвести этот переходный процесс нужно создать на выходе ЦАП "ступеньку" максимальной величины для данной задачи - отклик будет носить затухающий колебательный характер. В частности, если задача не требует компенсации спада АЧХ на высоких частотах, то корректирующее звено ФВЧ можно программно отключить, что уменьшит переходный процесс (но не исключит его полностью). Отключение  звена ФВЧ не влияет на калибровку ЦАП по постоянному напряжению, но вызовет дополнительную погрешность по переменному напряжению на высоких частотах полосы частот воспроизведения сигнала.

Возник ещё вопрос. Возможно ли, зная настройки арифметического генератора, узнать точную последовательность кодов, которые будут выданы на ЦАП? Т. е. алгоритм, по которому LTR-35 эти коды вычисляет.

Здравствуйте, Алексей.

Возможно. Для этого необходимо воспользоваться режимом получения данных от эхо-канала LTR35 ( https://www.lcard.ru/download/ltr35api.pdf , п. 3.2.5). При этом, полученные эхо-данные будут соответствовать физическим кодам, отправленным в соответствующий канал микросхемы сигма-дельта ЦАП. Но эти коды арифметического генератора будут с коррекцией (в соответствии с калибровочными коэффициетами данного канала и после корректирующего ФВЧ, о котором я писал выше). В то же время, эти коды не будут отражать реальную физическую переходную характеристику микросхемы сигма-дельта ЦАП с внутренним фильтром высокого порядка. С другой стороны, если допустить, что в Вашей задаче упраление ЦАП происходит малыми приращениями сигнала, то переходными (динамическими) характеристиками системы (и реакцией фильтров на переходный процесс) можно пренебречь. В случае арифметического генератора SIN(a) и  СOS(a), малые приращения сигнала соответствуют очень низкой частоте генерации и малому приращению угла a.

Вообще, предоставление пользователям алгорима арифметического генератора не планировалось... Но, я полагаю, что здесь достаточно знать, что это - алгоритм непосредственного вычисления SIN(a), и  СOS(a), где угол а имеет целочисленное 32-битное двоичное представление с возможностью установки целочисленного приращения угла, с обычной 32-битной циклической логикой (число значений угла 2^32). Разрядность результата вычисления SIN, COS - 24 бита.
Алексей, прошу пояснить, какая пользовательская задача (или обнаруженная проблема) вызвала подобные специфические вопросы?

Речь идёт о физическом процессе (эксперименте), чувствительность которого превышает единицу младшего разряда кода ЦАП LTR-35 (а именно, речь идёт о сканировании электронной дифракционной картины, выдаваемые LTR-35 напряжения используются для генерации токов развёрток в отклоняющих катушках).

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

Чтобы считанный из LTR35 эхо-сигнал арифметического генератора снова отправить в LTR35 c целью воспроизведения "цифровой копии" сигнала в потоковом режиме, необходимо считать этот эхо-сигнал в режиме LTR35 с предустановленными в начальные значения калибровочными коэффициентами (и коэффициентами фильтра ФВЧ). Но это - нештатный режим работы с LTR35  - необходима консультация с нашим программистом Алексеем на предмет возможности специального режима работы LTR35 с начальными значениями всех коэффициентов (но без изменения информации во flash-памяти LTR35).  После получения эхо-сигнала в этом специальном режиме необходимо будет снова отправить этот сигнал в LTR35 в потоковом режиме, вернувшись к штатным калибровочным коэффициентам, повторяя все остальные условия эксперимента, включая условия начальной синхронизации старта LTR35.     
Но понятно также, что при воспроизведении "цифровых копий", могут проявиться и малые "аналоговые отличия" (аналоговые шумы и помехи), термозависимые отличия,  а также тонкие отличия в задержке сигнала, связанные с начальной фазой частоты преобразования сигма-дельта ЦАП.

Применение циклического режима LTR35 для получения "цифровой копии" арифметического генератора вряд ли возможно, поскольку:
- Размер цикла пробега уникальных целочисленных значений тригонометрического угла не должен быть больше, чем количество отсчётов данного канала, записанных в страницу циклической памяти (это накладывает сильные ограничения на возможные значения приращения тригонометрического угла).
- В текущей реализации LTR35 временнЫе интервалы смены страниц циклической памяти не могут иметь постоянный периодический интервал (интервалы смены страниц будут кратны времени цикла, но кратность будет непостоянной из-за асинхронного характера обновления страниц).

Алексей, арифметическая модель работы LTR35 - это нетривиальная задача и для Вас и для нас, поскольку:
1. Для запуска модели Вам потребуется применение той или иной среды симуляции (интерпретации) с VHDL исходными текстами.
2. Кроме выдачи самой модели в читабельном варианте (п.1), нам потребуется подготовка подробного низкоуровневого описания LTR35, поскольку в модели будут использованы низкоуровневые объекты (работа с которыми осуществляется через API-функции LTR35).
Как альтернатива пп.1,2, если пытаться выдать для Вас максимально удобную арифметическую модель на языке С относительно всех сущностей, описанных на уровне LTR35 API, то это ещё более нетривиальная задача, с учётом необходимой задачи верификации полученной модели относительно оригинальной VHDL-логики (после перевода этой логики на язык С).

С другой стороны, если работать в потоковом режиме со сброшенными коэффициентами в начальное состояние, то в FPGA LTR35 никакой арифметической обработки не будет и необходимую обработку можно делать и на верхнем уровне. Правда, и в этом случае применение режима "эхо канала" далеко не бессмысленно - он может выполнять важную контрольную функцию высылаемых кодов в микросхему ЦАП, правда только - по одному каналу. Как работать с LTR35 со сброшенными коэффициентами в начальное состояние без порчи заводской информации во flash-памяти LTR35 - об этом может рассказать наш Алексей.

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

Для отключения фильтра АЧХ достаточно установить флаг LTR35_CFG_FLAG_DISABLE_AFC_COR (поле Cfg.Flags) до вызова LTR35_Configure(), действительно для работы на уровне кодов это по хорошему нужно делать для любого режима. Про калибровочные коэффициенты  уже в начале данной темы писалось, что соответствующие Sacale и Offset нужно установить в 1 и 0 также до LTR35_Configure().

Установка флага LTR35_CFG_FLAG_DISABLE_AFC_COR решила имевшиеся проблемы. Спасибо за подсказку.

Но после этого (не знаем, вследствие ли этого) после нескольких часов работы с конфигурацией с установленным флагом модуль LTR-35 завис. После чего на всех выходах появились близкие к нулю, но не равные нулю точно, постоянные напряжения. Содержимое журнала (время записи об ошибке 20:42:24, 10.11.2022 совпадает с фактическим временем возникновения ошибки):

14:16:22, 10.11.2022	Информация	Service:ltrd (v2.1.8.9) started
14:16:22, 10.11.2022	Информация	Service:New host address: intf name: eno1, addr 192.168.0.99, msk 255.255.255.0
14:16:22, 10.11.2022	Информация	Crate init [TCP, 192.168.0.35]:Start connection
14:16:22, 10.11.2022	Информация	Crate LTR-CEU-1 [TCP, 2T728370]:New crate initialized successfully: 
14:16:22, 10.11.2022	Информация	Crate LTR-CEU-1 [TCP, 2T728370]:   Location            = 192.168.0.35
14:16:22, 10.11.2022	Информация	Crate LTR-CEU-1 [TCP, 2T728370]:   Crate type name     = LTR-CEU-1
14:16:22, 10.11.2022	Информация	Crate LTR-CEU-1 [TCP, 2T728370]:   Serial              = 2T728370
14:16:22, 10.11.2022	Информация	Crate LTR-CEU-1 [TCP, 2T728370]:   Firmware version    = 1.0.4.0
14:16:22, 10.11.2022	Информация	Crate LTR-CEU-1 [TCP, 2T728370]:   Bootloader version  = 2.1.0.0
14:16:22, 10.11.2022	Информация	Crate LTR-CEU-1 [TCP, 2T728370]:   CPU Type            = LPC4337
14:16:22, 10.11.2022	Информация	Crate LTR-CEU-1 [TCP, 2T728370]:   Board revision      = 1
14:16:22, 10.11.2022	Информация	Crate LTR-CEU-1 [TCP, 2T728370]:   FPGA name           = LTR-CEU-1
14:16:22, 10.11.2022	Информация	Crate LTR-CEU-1 [TCP, 2T728370]:   FPGA version        = 1.0.4
14:16:22, 10.11.2022	Информация	Crate LTR-CEU-1 [TCP, 2T728370]:   mode                = 2
14:16:22, 10.11.2022	Информация	Crate LTR-CEU-1 [TCP, 2T728370]:   Protocol version    = 1.1
14:16:22, 10.11.2022	Информация	Crate LTR-CEU-1 [TCP, 2T728370]:New module detected in slot 1
14:16:22, 10.11.2022	Информация	LTR35-1 (Crate LTR-CEU-1 [TCP, 2T728370], slot 1):Initialized successfully
14:16:24, 10.11.2022	Информация	Service:New host address: intf name: tun0, addr 10.8.0.102, msk 255.255.255.255
20:42:24, 10.11.2022	Ошибки (-505)	Crate LTR-CEU-1 [TCP, 2T728370]:Crate ping failed: Command reply timeout
20:42:24, 10.11.2022	Информация	Crate LTR-CEU-1 [TCP, 2T728370]:Crate closed
20:42:39, 10.11.2022	Информация	Service:New host address: intf name: eno1, addr 192.168.0.99, msk 255.255.255.0
20:42:39, 10.11.2022	Информация	Crate init [TCP, 192.168.0.35]:Start connection
20:42:39, 10.11.2022	Предупреждения	Crate init [TCP, 192.168.0.35]:Connection already established! Force primary connection!
20:42:39, 10.11.2022	Информация	Crate LTR-CEU-1 [TCP, 2T728370]:New crate initialized successfully: 
20:42:39, 10.11.2022	Информация	Crate LTR-CEU-1 [TCP, 2T728370]:   Location            = 192.168.0.35
20:42:39, 10.11.2022	Информация	Crate LTR-CEU-1 [TCP, 2T728370]:   Crate type name     = LTR-CEU-1
20:42:39, 10.11.2022	Информация	Crate LTR-CEU-1 [TCP, 2T728370]:   Serial              = 2T728370
20:42:39, 10.11.2022	Информация	Crate LTR-CEU-1 [TCP, 2T728370]:   Firmware version    = 1.0.4.0
20:42:39, 10.11.2022	Информация	Crate LTR-CEU-1 [TCP, 2T728370]:   Bootloader version  = 2.1.0.0
20:42:39, 10.11.2022	Информация	Crate LTR-CEU-1 [TCP, 2T728370]:   CPU Type            = LPC4337
20:42:39, 10.11.2022	Информация	Crate LTR-CEU-1 [TCP, 2T728370]:   Board revision      = 1
20:42:39, 10.11.2022	Информация	Crate LTR-CEU-1 [TCP, 2T728370]:   FPGA name           = LTR-CEU-1
20:42:39, 10.11.2022	Информация	Crate LTR-CEU-1 [TCP, 2T728370]:   FPGA version        = 1.0.4
20:42:39, 10.11.2022	Информация	Crate LTR-CEU-1 [TCP, 2T728370]:   mode                = 2
20:42:39, 10.11.2022	Информация	Crate LTR-CEU-1 [TCP, 2T728370]:   Protocol version    = 1.1
20:42:39, 10.11.2022	Информация	Crate LTR-CEU-1 [TCP, 2T728370]:New module detected in slot 1
20:42:39, 10.11.2022	Информация	LTR35-1 (Crate LTR-CEU-1 [TCP, 2T728370], slot 1):Initialized successfully

А каким образом крейт был подключен к ПК? Напрямую, через свич, еще каким-то способом?

Подключение через WiFi-роутер по проводам. В одно из гнёзд LAN роутера подключён компьютер, в другое - крейт с LTR-35.

В приведенном журнале есть строка:

20:42:39, 10.11.2022	Информация	Service:New host address: intf name: eno1, addr 192.168.0.99, msk 255.255.255.0

Насколько я понимаю eno1 это и есть интерфейс связи ПК -> роутер (судя по его адресу и адресу LTR), к которому подключен LTR.
Это строка свидетельствует, о том, что этот интерфейс заново появился, т.е. до этого он исчезал (про исчезновение в ltrd не выводит сообщений, он отслеживает только появление новых, поэтому точное время не известно, по идее оно должно быть незадолго до ошибки, скорее всего это можно посмотреть по логам системы). Это свидетельствует о полном пропадании канала связи между роутером и ПК (причины могут быть разные: отключен кабель, роутер перезагрузился, каким-то образом интерфейс был выключен в ПК). При этом сам LTR-крейт на это повлиять не мог (он подключен к другому порту), как и софт верхнего уровня (отключение сетевого интерфейса не выполняется какими-либо программами LTR и вообще как правило требует прав рута).

Соответственно из-за отсутствия связи на участке ПК-роутер была разорвана связь ltrd -> крейт, из-за чего и была ошибка.
Далее после появления сетевого интерфейса ltrd снова установил связь с крейтом (я так понимаю стоит флаг автоподключения "A" у записи IP-адреса крейта).
Далее запись в журнале:

20:42:39, 10.11.2022	Предупреждения	Crate init [TCP, 192.168.0.35]:Connection already established! Force primary connection!

дает понять, что крейт исправно работал все это время, и у него осталось незвершенное старое содинение с ltrd для передачи данных (о том что оно разорвано со стороны ПК LTR не знает, сообщений о закрытии ему не приходило, т.к. не было связи), которое при новом подключении ltrd отключает соответствующем запросом, после чего устанавливает новое.

Далее после установления нового соединения ltrd всегда сбрасывает все обнаруженные модули при инициализации (без этого не возможно даже определить состав модулей крейта), что и привело к сбросу выходов в начальное состояние соответствующее состояниям выходов ЦАП при его сбросе  (т.к. это не откалиброванный нулевой код, то тут будет близкое к 0 значение, но не 0). В штатном режиме LTR это не автономное устройство, все управление полностью идет с ПК и сброс связи требует полной переинициализации устройства и работы c "чистого листа" (если не рассматривать написание специализированной прошивки крейта под конретную задачу с перносом часть функций внутрь).

Но в общем в любом случае судя по журналу этот разрыв связи никак не связан с LTR крейтом или модулем LTR35.

Опять столкнулись с проблемой самопроизвольного отключения LTR35.
Перед началом работы проверили, что в LTR Manager (версия 1.5.5) у крейта не стоят галочки A и R.
После возникновения проблемы оказалось, что стоит галочка A (появилась сама собой), галочки R не было.
Проблема возникла первый раз за несколько месяцев работы, до этого (с момента предыдущего сообщения на форуме) всё было в порядке.
Условия подключения с тех пор не менялись, всё осталось как было и как описано выше.

Лог LTR Manager:

16:03:01, 5.01.2023	Информация	Service:New host address: intf name: eno1, addr 192.168.0.99, msk 255.255.255.0
16:04:29, 5.01.2023	Информация	Crate init [TCP, 192.168.0.35]:Start connection
16:04:29, 5.01.2023	Информация	Crate LTR-CEU-1 [TCP, 2T728370]:New crate initialized successfully: 
16:04:29, 5.01.2023	Информация	Crate LTR-CEU-1 [TCP, 2T728370]:   Location            = 192.168.0.35
16:04:29, 5.01.2023	Информация	Crate LTR-CEU-1 [TCP, 2T728370]:   Crate type name     = LTR-CEU-1
16:04:29, 5.01.2023	Информация	Crate LTR-CEU-1 [TCP, 2T728370]:   Serial              = 2T728370
16:04:29, 5.01.2023	Информация	Crate LTR-CEU-1 [TCP, 2T728370]:   Firmware version    = 1.0.4.0
16:04:29, 5.01.2023	Информация	Crate LTR-CEU-1 [TCP, 2T728370]:   Bootloader version  = 2.1.0.0
16:04:29, 5.01.2023	Информация	Crate LTR-CEU-1 [TCP, 2T728370]:   CPU Type            = LPC4337
16:04:29, 5.01.2023	Информация	Crate LTR-CEU-1 [TCP, 2T728370]:   Board revision      = 1
16:04:29, 5.01.2023	Информация	Crate LTR-CEU-1 [TCP, 2T728370]:   FPGA name           = LTR-CEU-1
16:04:29, 5.01.2023	Информация	Crate LTR-CEU-1 [TCP, 2T728370]:   FPGA version        = 1.0.4
16:04:29, 5.01.2023	Информация	Crate LTR-CEU-1 [TCP, 2T728370]:   mode                = 2
16:04:29, 5.01.2023	Информация	Crate LTR-CEU-1 [TCP, 2T728370]:   Protocol version    = 1.1
16:04:29, 5.01.2023	Информация	Crate LTR-CEU-1 [TCP, 2T728370]:New module detected in slot 1
16:04:29, 5.01.2023	Информация	LTR35-1 (Crate LTR-CEU-1 [TCP, 2T728370], slot 1):Initialized successfully
19:29:10, 5.01.2023	Ошибки (-505)	Crate LTR-CEU-1 [TCP, 2T728370]:Crate ping failed: Command reply timeout
19:29:10, 5.01.2023	Информация	Crate LTR-CEU-1 [TCP, 2T728370]:Crate closed
19:29:19, 5.01.2023	Информация	Service:New host address: intf name: eno1, addr 192.168.0.99, msk 255.255.255.0
19:29:19, 5.01.2023	Информация	Crate init [TCP, 192.168.0.35]:Start connection
19:29:19, 5.01.2023	Предупреждения	Crate init [TCP, 192.168.0.35]:Connection already established! Force primary connection!
19:29:19, 5.01.2023	Информация	Crate LTR-CEU-1 [TCP, 2T728370]:New crate initialized successfully: 
19:29:19, 5.01.2023	Информация	Crate LTR-CEU-1 [TCP, 2T728370]:   Location            = 192.168.0.35
19:29:19, 5.01.2023	Информация	Crate LTR-CEU-1 [TCP, 2T728370]:   Crate type name     = LTR-CEU-1
19:29:19, 5.01.2023	Информация	Crate LTR-CEU-1 [TCP, 2T728370]:   Serial              = 2T728370
19:29:19, 5.01.2023	Информация	Crate LTR-CEU-1 [TCP, 2T728370]:   Firmware version    = 1.0.4.0
19:29:19, 5.01.2023	Информация	Crate LTR-CEU-1 [TCP, 2T728370]:   Bootloader version  = 2.1.0.0
19:29:19, 5.01.2023	Информация	Crate LTR-CEU-1 [TCP, 2T728370]:   CPU Type            = LPC4337
19:29:19, 5.01.2023	Информация	Crate LTR-CEU-1 [TCP, 2T728370]:   Board revision      = 1
19:29:19, 5.01.2023	Информация	Crate LTR-CEU-1 [TCP, 2T728370]:   FPGA name           = LTR-CEU-1
19:29:19, 5.01.2023	Информация	Crate LTR-CEU-1 [TCP, 2T728370]:   FPGA version        = 1.0.4
19:29:19, 5.01.2023	Информация	Crate LTR-CEU-1 [TCP, 2T728370]:   mode                = 2
19:29:19, 5.01.2023	Информация	Crate LTR-CEU-1 [TCP, 2T728370]:   Protocol version    = 1.1
19:29:19, 5.01.2023	Информация	Crate LTR-CEU-1 [TCP, 2T728370]:New module detected in slot 1
19:29:19, 5.01.2023	Информация	LTR35-1 (Crate LTR-CEU-1 [TCP, 2T728370], slot 1):Initialized successfully

С появлением самой по себе галочки "A" не совсем конечно понятно. У Вас в программе функции вроде LTR_SetIPCrateFlags или LTR_AddIPCrate не используются?
Но в любом случае, основная проблема это не сам флаг A (без него просто бы подключение не восстановилось бы),  а  как и в прошлый раз возникновение строки:

19:29:19, 5.01.2023	Информация	Service:New host address: intf name: eno1, addr 192.168.0.99, msk 255.255.255.0

которая говорит, что в самой системе исчезал сетевой интерфейс, и с самим ПО LTR не связана.
Если посмотреть через dmesg или журнал системы (journalctl)  сообщения за интервал где-то от 19:29:00 до 19:29:19, будет там что-то про отключение сетевого интерфейса?  У самого роутера есть какой-то журнал, возможно ли определить, не перезагружался ли сам роутер?

В изложенных выше данных я не вижу ни малейшей зацепки в пользу какой-либо версии, связанной с проблемой на уровне модуля LTR (в данном случае, модуля LTR35). Судя по всему, проблема находится на уровне сетевого соединения Ethernet, и дополнительную информацию здесь явно нужно искать в журналах ОС ПК и роутера на момент возникновения сбоя.

Фрагмент вывода dmesg -T за интервал времени, заведомо перекрывающий промежуток [19:29:00 до 19:29:19]:

[Чт янв  5 16:04:56 2023] igb 0000:02:00.0 eno1: igb: eno1 NIC Link is Down
[Чт янв  5 16:04:59 2023] igb 0000:02:00.0 eno1: igb: eno1 NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX/TX
[Чт янв  5 16:05:10 2023] igb 0000:02:00.0 eno1: igb: eno1 NIC Link is Down
[Чт янв  5 16:05:12 2023] igb 0000:02:00.0 eno1: igb: eno1 NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX/TX
[Чт янв  5 19:11:42 2023] nouveau 0000:01:00.0: Direct firmware load for nouveau/nv106_fuc084 failed with error -2
[Чт янв  5 19:11:42 2023] nouveau 0000:01:00.0: Direct firmware load for nouveau/nv106_fuc084d failed with error -2
[Чт янв  5 19:11:42 2023] nouveau 0000:01:00.0: msvld: unable to load firmware data
[Чт янв  5 19:11:42 2023] nouveau 0000:01:00.0: msvld: init failed, -19
[Чт янв  5 19:31:15 2023] igb 0000:02:00.0 eno1: igb: eno1 NIC Link is Down
[Чт янв  5 19:31:17 2023] igb 0000:02:00.0 eno1: igb: eno1 NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX/TX
[Чт янв  5 19:31:28 2023] igb 0000:02:00.0 eno1: igb: eno1 NIC Link is Down
[Чт янв  5 19:31:30 2023] igb 0000:02:00.0 eno1: igb: eno1 NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX/TX

С интерфейсом eno1, действительно, что-то происходило, но не в то время, которое указано в логе LTR Maneger (19:29:19), а на 2 минуты позже.

Функции LTR_SetIPCrateFlags или LTR_AddIPCrate в программе не используются.

Вопрос заключается в том, как в случае возникновения проблем (пропадания связи с LTR-35 по какой-либо причине) избежать возникновения дополнительных проблем, возникающих из-за действий ПО. В логике нашего эксперимента наиболее удачным решением было бы не перезагружать автоматически LTR-35 каждый раз в таком случае, а вывести сообщение об ошибке и ожидать реакции оператора. Как выяснилось, убрать галочки A и R для этого оказалось недостаточно.

Перезагрузок роутера в указанное время не наблюдалось - судя по тому, что в этот момент роутер также был задействован для передачи других данных (не связанных с LTR-35) в рамках того же эксперимента, и с теми данными ничего не случилось.

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

А только Вы работаете с LTR Manager за этим компом, не мог кто-то еще установить?
Как вообще штатно у Вас происходит процедура подключение крейта? Вы после запуска ПК вручную выполняете подключение крейта из LTR Manager каждый раз? В 16:03 в журнале подключение чему соответствует? Включению ПК? Она тогда уже была установлена?