Приветствую .Сегодня посмотрел, как грузит процессор лог .У меня выдал 34% .Интересно, у Вас какой показатель .По мне, это всё же многовато .Пробовал убирать окна, ни чего не меняется .
Вид для печати
Приветствую .Сегодня посмотрел, как грузит процессор лог .У меня выдал 34% .Интересно, у Вас какой показатель .По мне, это всё же многовато .Пробовал убирать окна, ни чего не меняется .
многоватоЦитата:
Сообщение от Dgon621
Вложение 380478
что бы сравнивать, надо указать на каком компе (проц, память)
старый и не очень мощныйЦитата:
Сообщение от UD2F
Вложение 380481
Извиняюсь, забыл указать .Моноблок довольно таки старенький, но не много модернизированный .Цитата:
Сообщение от UD2F
Спасибо всем .Всё решилось переустановкой самого лога .Может кто будет переустанавливать, сохраните две папки .Папку INI и папку Log .После установки закиньте их в папку с программой с заменой файлов .Лог загрузится в таком виде, в каком Вы его удалили .Цитата:
Сообщение от R4WH
Здесь нужно понимать, что значит лог грузит процессор:Цитата:
Сообщение от Dgon621
- если лог ничего не делает, то загрузка процессора должна быть 0!
- если загрузка процессора от лога больше 0, значит лог что то делает. Что может делать лог? Принимать споты, если споты включены от пскрепортер, то загрузка может быть достаточно большая. Получать данные от JTDX/WSJT-X. Это так что первое в голову приходит. Но это пиковая нагрузка. Если лог ничего этого не делает, а нагрузка есть - это не хорошо, нужно развираться, почему так.
После переустановки какое то время было всё нормально .Потом лог начал грузить процессор по новой .И это были действительно споты .В заблуждение вводило то, что при отключении спотов, лог всё равно грузил процессор .Т.е они почему то продолжали подгружаться после их выключения .Решилось тем, что выключил интернет и перезагрузил лог .Всё стало работать штатно .Загрузка меньше 1% .Почему так, не знаю .Цитата:
Сообщение от RX4HX
Алексей, прошу прощения за назойливость, снова о взаимодействии с JTDX. Перепробовал все варианты настроек и в LogHX и в JTDX. Не "залетают" позывные из JTDX в лог и всё тут! Помните, у меня и у Вас перестал работать E-Coder, и причина оказалась в установленной программе от Logitech? Может и в данном случае какая-то посторонняя программа перехватывает посылки от JTDX в LogHX? Тут ещё есть "зацепочка" - частота у лога, JTDX-а и трансивера - синхронизирована, а вот модуляция, не смотря на "галочку" "частота от JTDX" живёт своей жизнью, часто переключаю вручную. Кстати, с установленным видом модуляции в трансивере FT8, декода нет, работает только с установкой USB.
- - - Добавлено - - -
Кстати, ка добавить в выпадающее окно FT8?Вложение 380520
Ваших настроек не видно. Вы их просто не выложили. Проверьте в точности свои наастройки с настройками ниже в скринах.Цитата:
Сообщение от R0WC
LogHX
JTDX основные
JTDX дополнительные
Добрый день. Вчера возникла проблема (как раз в Аврору...). А именно. Когда запускаешь из LogHX3 внешнюю программу CW type, то трансивер автоматически переходит в cw-r. Из меню смены модуляции самого трансивера режим не меняется на CW. Отдельно, когда запускаешь терминал - все нормально. В чем проблема?
Трансивер IC-9700, в настройках Radio 2 используется протокол Omnirig.
Николай, спасибо большое! Что засорять тему - настройки в точности, как у Вас. Люди предлагали разные варианты, все их попробовал. Скорее всего дело во внешнем "раздражителе", который перехватывает пакеты информации... Понять бы принцип передачи данных!Цитата:
Сообщение от EU1FQ
Принцип простой - использование транспортного протокола передачи данных UDP. Информации в инете по этому протоколу, как для чайников, так идля профессионалов, очень много.Цитата:
Сообщение от R0WC
А в общем, если настройки соответствуют, и запускаете JTDX из под лога, то остаются только следующие причины. Блокировка брандмауэром Windows UDP соединения через 127.0.0.1 (localhost).
А также другое приложение может занимать UDP порт или ошибки привязки сокета (Bind). С брандмауэром ясно как разобраться. С остальными проблемами сложнее, но тоже реально. Очень часто в Windows 10/11 после обновлений петлевой интерфейс может работать некорректно для определенных протоколов. Попробуйте сбросьте настройки сети командой netsh winsock reset и перезагрузите компьютер. Чтобы проверить порт и убедиться, что приложение действительно слушает нужный порт, используйте команду netstat -an | findstr UDP. Скачайте и установите утилиту Packet Sender для отправки тестового пакета на 127.0.0.1:[порт] (https://packetsender.com/download). Теперь дальше. Используйте команду netstat -ano она добавит колонку с PID (идентификатором процесса), чтобы вы могли увидеть в Диспетчере задач, какая именно программа занимает порт. Чтобы не листать огромный список портов, используйте команду netstat -ano | findstr :<номер_порта> В последнем столбце будет указан PID. Зная PID, в Диспетчере задач (раздел подробности) найдете тот процесс, который занимает данны порт Но лучше всего, скачать от Microsoft утилиту TCPView. Она позволяет наглядно отображать все портоы и процессы в реальном времени. (https://learn.microsoft.com/ru-ru/sy...nloads/tcpview)
В моем случае, не обязательно запускать из под лога (правда, работаю с WSJT). Достаточно поставить в нужном месте птичку "Использовать внешнюю программу"Цитата:
Сообщение от EU1FQ
при ранее запущенном WSJT. Без этой птички, как мне помнится, диапазоны из WSJT переключаются, но позывные в лог не падают даже при правильных настройках.
Это и есть запуск программы из под лога! Так было раньше. Теперь уже нет этой пимпочки. (783). Если нет связи LogHX с JTDX (WSJT) через UDP, то информация из JTDX (WSJT) просто не может быть передана в LogHX.Цитата:
Сообщение от EW4DX