Эта тема будет посвящена обсуждению использования LogHX в цифровых видах связи, в том числе и взаимодействие в внешними программами.
Вид для печати
Эта тема будет посвящена обсуждению использования LogHX в цифровых видах связи, в том числе и взаимодействие в внешними программами.
Вот:
Вложение 179332
Алексей прочитал в ветке по сансдр2 Ваше сообщение. Переключитесь на диджи
Вложение 179364
Вложение 179375
, в нем компрессор и прочие обработчики сигнала передачу отключаются.
Для верных показаний частоты:
В настройках трансивера так должно быть:
Вложение 179366
В настройках JTDX так:
Вложение 179370
Пик моего гт-65 сигнала, Вложение 179388
у Вас выше?
Обновил LogHX до 240, теперь при закрытии JTDX (17.4) наблюдаюВложение 179413 причем в логе после этого перестают переключаться моды по клику на спотах.
Откатил до 235 - данный баг пропал, все работает как надо.
Просто лог при закрытии JTDX не приостаналивает использоние внешней программы.
При нажатии кнопки принудительного отключения внешней программы все работает штатно.
Баг однако.
Да, все верно. Перед закрытием JTDX нужно нажать на кнопку - Прекратить использовать внешнюю программу.
Вот подправил чтоб не ругался лог:
http://rx4hx.qrz.ru/files/loghx/prer...11_01_2017.exe
Не ругается, но связка работает не устойчиво, как и с предыдущими релизами. Снова откат на 235 релиз - самый устойчивый. Но даже в нем не сохраняется в лог County. Непосредственно при работе в самом логе сохраняется все, а при сохранении из JTDX 17.4 версии - нет. Также не переключается JT65/JT9 в логе при переключении в JTDX (сохраняется в логе правильная мода). Ну и не работает связка совершенно с UDP сервером.
Алексей при использовании с логом MixW не коректно происходит обмен данными.
Например в MixW щелкаем по споту позывной заносится в MixW в лог иногда нормально иногда с задержкой.
Щелкаем по другому споту в MixW записывается новый позывной частота мода в логе висит старый.
Такая же фигня и с UR5EQF. Такое наблюдается на двух рабочих местах.
Да не корректно. И вина в этом - Микса))) Он данные некорректно отдает. Неделю бился над этой проблемой и решить ее так и не сумел.
Вот тоже: автор WSJT не сделал нормального взаимодействия с логами, а я мучайся)))
Дело в том, что в версии 235 сделана "не правильная" с точки зрения программирования реализация получения данных, а в последней версии - "правильная". Но прикол в том, что неправильная реализация работает более стабильно. Хотя у меня и последняя, и 235 реализация работают одинаково стабильно.
У кого то работает, у кого то нет. Такое впечатление, что у Вас что то не дает работать по UPD.
... Вообще я весьма серьезно намерен решить проблему с WSJT-X/JTDX, так что работы в этом направлении прекращать не намерен!
Удалось частично подружить лог с JTDX. В JTDX выбрал не модель трансивера, а Омнириг-1. PTT и CAT заработали, но трансляции данных в лог нет.
Вернулся к варианту 235:
http://rx4hx.qrz.ru/files/loghx/prer...11_01_2017.exe
попробуйте!
Олег, что б это понять, пришлось залезть в исходники WSJT-X)))
Для более полной информации в исходниках WSJT-X посмотрите файл NetworkMessage.hpp
Привожу сокращенно заголовок из этого файла:
* Status Out 1 quint32
* Id (unique key) utf8
* Dial Frequency (Hz) quint64
* Mode utf8
* DX call utf8
* Report utf8
* Tx Mode utf8
* Tx Enabled bool
* Transmitting bool
* Decoding bool
Это сообщение приходит когда изменяется инфа в полях WSJT-X
* QSO Logged Out 5 quint32
* Id (unique key) utf8
* Date & Time QDateTime
* DX call utf8
* DX grid utf8
* Dial frequency (Hz) quint64
* Mode utf8
* Report send utf8
* Report received utf8
* Tx power utf8
* Comments utf8
* Name utf8
А это при сохранении QSO.
Если нужна более подробная инфа - могу прислать по емайлу.
Ах вот оно где, а я посмотрел в NetworkMessage.cpp, а в NetworkMessage.hpp поленился. Спасибо будем разбираться.