использует программу MSHV...
Понял. Спасибо за разъяснение
WSJT-X? Если так себя ведет JTDX то необходимо включить запись диагностики в ALL.TXT в закладке Reporting и переслать пример такого QSO (картинка + кусок ALL.TXT).
Программа MSHV имеет много несогласованных сюрпризов для протокола сообщений QSO в FT8, у автора свое видение как надо работать в FT8.
Подскажите как избавится от проблемы? JTDX v2.0.1 вначале декодирования и вначале передачи трансивер переключается в модуляцию CW. Это появилось вчера, ранее все было в норме.
Игорь, я в свое время решал похожую проблему следующим образом:
в ini-файле последняя строчка - это CRC32, рассчитанная от начала файла без учета этой строки. При чтении проверяю, если CRC не сошлась - вывожу ругательство типа "INI файл поврежден, возможна некорректная работа программы, продолжить?" - с кнопками Да, Нет, Обновить INI файл. После внедрения этой фичи непонятки и проблемы от пользователей по этой части исчезли навсегда.
Может, стоит сделать нечто подобное?
Более вероятен сценарий когда операционная система ломает INI файл при записи используя перекодировку символов (локальная кодировка в операционной системе), в этом случае CRC проверка к сожалению не поможет. Пока не нашли каких либо конфликтов в записи/чтении параметров и порядке их чтения в самом коде, но при явных общих случаях сбоя (сбои связанные с CAT у себя в лабе не могу проверить) можно будет попробовать диагностировать конкретный параметр приведший к сбою.
У пользователей JTDX под Линуксом вообще нет сбоев с JTDX.ini, одно из отличий в том что Линукс пишет параметры в файл по порядку а Windows как ей в голову взбредет.
Поэтому мы думаем что сбой вряд ли связан с изменением содержимого файла при выключенной программе JTDX, за исключением случаев когда пользователь сам редактирует этот файл нарушая зависимости параметров или устанавливая их вне допустимого диапазона значений.
Есть, более того, программа работает с UTF8, но MS Windows начал поддерживать UTF8 буквально несколько месяцев назад в режиме тестирования. С обилием разных операционных систем на которых работает код JTDX непросто принять решение о принудительной кодировке при вводе-выводе.
Игорь периодически наблюдаю
20190206_161015 9 1.4 1780 ~ HS0ZEE UR4MN KN98
20190206_161015 -7 0.2 1637 ~ <...> UW5KW
20190206_161015 0 -0.9 1041 ~ RA4LY UA4COA R-12
20190206_161015 -2 0.1 920 ~ UB4C RA3ST R-17 ^
20190206_161015 -2 0.0 1359 ~ SQ9SNG YL2GJX 73 ^
20190206_161015 -5 0.1 1308 ~ HS0ZEE R8AAU LO93
20190206_161015 0 -1.4 2323 ~ SM2MGQ R6DH KN96
20190206_161015 -12 0.2 2404 ~ PA3CPS UN7FW -24 ^
20190206_161015 -15 0.1 806 ~ DL3XS OE9RGI RR73
20190206_161015 -14 0.1 2242 ~ HS0ZEE LA6SLA -15 *
20190206_161015 -7 -0.9 1041 ~ ? |?gw?,4wX UA4COA R-1
20190206_161015 -15 0.1 669 ~ DO1MKH DF1BN JN68
20190206_161015 -15 -0.1 1994 ~ UA9XL DL6ZNG JO52
не часто но проскакивает
Подскажите, а можно сделать как-нибудь в в JTDX, чтобы история сработанных связей "читалась" из файла wsjtx, а не из файла wsjtx_log?
Логовый ADIF файл я периодически удаляю, перенося связи в основной лог и получается, что с пустым wsjtx_log - как с чистого листа - все станции new one для DXCC, в соответственной (настроенной) цветовой подсветкой...