Меню
+7 (495) 785-95-25
sale@lcard.ru
sale@lcard.ru
Модуля действительно 2. Похоже, что номера действительно одинаковые, но пока это все еще не точно.
Но сейчас все проверки откладываются, т.к. оба модуля уезжают на испытания "в поля". Жаль, что проблему так и не удалось устранить до испытаний. Значит продолжим после.
нужно проверить, присутствует ли проблема действительно на обоих модулях, а также проверить с другим кабелем.
А кстати когда E-502 в таком состоянии на отключение кабеля он как реагирует по светодиодам. И последующее подключение кабеля все равно ничего не меняет до перезагрузки?
Проверим уже после испытаний.
Я подниму тему, когда снова можно будет проводить эксперименты.
Спасибо!
Если это действительно так, то это повод обратиться в наш отдел продаж.
Я сделал вывод, о том, что это второй E502 по IP адресу. Адреса на обоих настраивал я сам. Но местные могли и сами туда залезть зачем-то. Уточню.
Зачем обращаться в отдел продаж?
Кстати, сейчас у меня забрали тот E-502 с которым я начал эту тему.
Поставили второй. После перезагрузки ведет он себя точно так же как и первый. Версии прошивок у них идентичные.
Прошивку менял на втором.
Заметил, что на втором серийный номер такой же как на первом: 2T253082. Такое может быть?
Сетевые адаптеры на ПК разные, какие именно не уточнял. Смотрел подробности только на Линуксе, т.к. к нему у меня есть доступ.
Конфигурация сети везде была точка-точка, подключались кросс-овером. Кабель короткий, E502 лежит на столе рядом с компом. Категория кабеля 5е.
Сейчас накатил последнюю прошивку 1.0.21, прошло успешно. Но поведение не изменилось.
После прошивки E-502 сам перезагружается, чтоб загрузится на новой прошивке? lqmeasstudio показывает, что версия прошивки поменялась.
Визуально сравнили LED1 и LED2. На LED2 горит оранжевый.
Инидкация LAN адаптера на хосте:
Когда связь есть: горит желтый и зеленый одновременно, когда идет трафик желтый моргает.
Когда связи нет: так же горят желтый и зеленый одновременно. Когда пингуешь, то пинги не проходят индикация не меняется.
На хосте сетевой адаптер Intel i210, ОС Astra Linux Орёл ядро версии 4.15.3-2
С модулем при этом при перезагрузке идет какая-то работа?
При перезагрузки с модулем никакой работы не происходит.
Добрый день!
Модулей 2, по словам "местных товарищей" ведут себя одинаково. Но ко второму у меня сейчас доступа нет.
Сегодня накачу свежую прошивку, но результат, видимо, увижу только в понедельник, т.к. сейчас E502 подключили по USB к виндовому компу для перепошивки и нужно будет его физически переподключить обратно.
На счет прошивки - первым делом подумал накатить свежую, но на страничке устройства висит версия 1.0.19 и у нас такая же. Где взять 1.0.21?
Фото Е502 после перезагрузки хоста, пинг с хоста не идет.
Так же выглядит и до перезагрузки, когда нет трафика.
LED2 видимо больше оранжевый, чем красный. Попрошу местных сравнить цвета LED1 и LED2.
Проявляется всегда и на всех протестированных ПК и ОС.
Кабель использовали один и тот же (кабель тестировали с помощью тестера), попробуем прямой.
По светодиодам со стороны хоста уточню.
Что бы исключить вину хоста провели дополнительное тестирование - подключали E502 на другие компы с виндой. Там ситуация повторилась.
Добрый день!
По светодиодам:
Постоянно горят LED1 и LED2 красным, на LAN постоянно горит желтый индикатор.
В рабочем режиме, когда появляется трафик на LAN моргает зеленый.
После перезагрузки хоста индикаторы никак не изменяются, только "зеленый" на LAN уже не появляется.
При этом подключения по USB нет (только Ethernet), а LED2 все таки горит.
Серийный номер E502: 2T253082
Про светодиоды напишу уже завтра, т.к. с устройством работаю удаленно, а сейчас там уже ночь.
Добрый день!
Используем E-502 с обменом по Ethernet. E-502 подключен к хосту напрямую через кросс-овер патч корд.
Столкнулись со следующей проблемой - если перезагрузить хостовый компьютер, то Ethernet соединение не восстанавливается.
На хосте Astra Linux, после перезагрузки ip address show показывает, что сетевой интерфейс на котором висит E-502 в дауне. ethtool говорит "Link detected: no". Сброс и повторное поднятие интерфейса не помогают.
После перезагрузки E-502 связь восстанавливается.
E-502:
FPGA version: 0.15
ARM firware: 1.0.19.0
X502SDK: 1.1.14
Плис: 0.3
ARM: 1.0.19
Наконец то получил для тестов E-502.
Сделал вывод 0 на ЦАП, после вывода сигнала.
Почему то если вывести один нулевой отсчет, то сигнал в ноль не сбрасывается. Методом тыка выяснилось, что 2 нулевых отсчета сбрасывают сигнал.
Интересно, почему так происходит?
Отличная мысль! Спасибо!
Уровень выключенного ЦАП это сколько? Думал это 0.
Оперативно сработали :-)
У меня такая задача - сбор данных с АЦП идет постоянный, запись в ЦАП (буду использовать 2 канала ЦАП) - кратковременный вывод в ЦАП как реакция на настпуление событя.
Планирую использовать синхронный режим для АЦП и ЦАП.
Таким образом надо в самом начале включить все используемые потоки для АЦП и ЦАП (StreamsEnable), затем вызвать StreamsStart, после чего потоки на ЦАПы выключить (StreamsDisable).
После наступления событий включаю потоки ЦАПов, X502_Send, при достижении конца данных выключаю потоки ЦАПов.
Правильно ли я представляю себе последовательность действий?
Вопросы:
1.После выдачи StreamsDisable для ЦАП будут ли реально выведены на ЦАП данные, которые еще остались в промежуточном буфере вывода?
2.После выдачи StreamsDisable какой сигнал будет установлен на выходе ЦАП?
3.Нужно ли вызывать PreloadStart перед каждым вызовом StreamsEnable или только один раз перед StreamsStart?
4.Если у меня данные для обоих каналов ЦАП уже изначально разложены по фреймам (например фреймы прочитаны из звукового файла) могу ли я обойтись без вызова PrepareData? Чтоб не перекладывать по 2 раза выводимые данные.
Еще вопрос по теме созрел:
Описатель устройства (Е502) потокобезопасный?
Взаимодействие с одним Е502 в рамках одного процесса и одного описателя устройства можно разнести по разным потокам?
Т.е. чтение с АЦП в одном потоке, запись в ЦАП в другом. В еще одном потоке цифровой ввод/вывод.
Провел эксперимент - да с относительными путями все работает.
Потом при клонировании с удаленного репо так же нормально забираются сабмодули.
Прочитал вашу ссылку про относительные пути - да, похоже это должно сработать. Надо проэкспериментировать.
fast-export судя по всему явно просматривает директорию .git всех субмодулей по указанному url и ищет в ней соответствие ревизий git с ревизиями из hg, поэтому ему нужно наличие всех сконвертированных субмодулей на диске, а не на уделенном сервере
Да, вы правы.
Вчера для эксперимента удалил сабмодули и провел экспорт. Но похоже в процессе что-то напутал, т.к. сабмодули после update по одному у меня появились.
Но сегодня не смог воспроизвести эксперимент - проект экспортировался без сабмодулей, так же как у вас. Он даже .gitmodules не сгенерил.
Вариант с указанием относительных путей, решает проблему лишь частично, т.к. в итоге пользователю нужно будет руками клонировать сабмодули и сложить их в правильном месте. В принципе можно для этого написать shell скрипт.
Надеюсь разрабы fast-export что-нибудь придумают.
Все перепроверил с нуля. Сабмодули по истории синхронизированы.
Доплоню процесс парой замечаний:
1.Похоже что после того как сабмодули отдельно сконвертированы их нужно сразу заливать в окончательное место расположение (на битбакет или куда-то еще) и в мап файле указывать уже URLы туда. Т.к. при конвертации пути к сабмодулям прописываются в .gitmodules, а он коммитится как обычный файл и сохраняется в истории гита так же как и .hgsub.
Вообще не обязательно сначала конвертировать сабмодули, т.к. при конвертации основной репы обращения к сабмодулям не происходит, достаточно того, что они прописаны в мап файле. Проверял. Но при этом столкнулся с таким нюансом: при выдаче git submodule update --init --recursive процесс спотыкается на одном из удаленных сабмодулей и в итоге ничего не происходит. Но это можно обойти, если обновлять сабмодули по отдельности, только те, что указаны в текущем .gitmodules. Например так: git submodule update --init lib/ltimer.
Но в целом, думаю что правильней начать все таки с сабмодулей.
2.Номера из hg в .git/hg2git-marks увеличены на 1 - в файле они начинаются с 1, а в hg с 0.
URLы на сабрепах надо изменить на правильные, после конвертации они ссылаются на локальные репы на диске, которые были прописаны в мап файле.
Соответствие номеров комитов hg и гит sha можно увидеть в .git/hg2git-marks
Для того что бы сабрепы синхронизировались после checkout я давал команду:
git submodule update --init --recursive
Подобрал все сабрепозитории, добавил в мапинг файл и похоже все сработало.
Кроме текущих сабреп нужно еще timer и cmake_obs_packages.
Проверил историю - сабрепы откатываются куда надо.
Адрес: 117105, Москва, Варшавское шоссе, д. 5, корп. 4, стр. 2
Многоканальный телефон:
+7 (495) 785-95-25
Отдел продаж: sale@lcard.ru
Техническая поддержка: support@lcard.ru
Время работы: с 9-00 до 19-00 мск