проект WSJT-X: моды JT65,JT9,WSPR,JT4,JTMS,MSHVK - работа с тестовым софтом

**R0LM** · 01.03.2019, 11:18

Сообщение от UA3DJY

Картинку с последним пожалуйста. Какая версия программы?

Игорь, похоже проблема возникает во время переброса данных из JTDX в Logger32. При этом Logger сам по себе связи с одинаковым временем фиксирует без проблем, проверил специально... В adif JTDX, если отключить Logger, тоже записывается все нормально...
Такая ситуация неоднократно возникала и на нескольких предыдущих версиях, сейчас в работе -rc130...

**UA3DJY** · 01.03.2019, 11:37

Сообщение от R0LM

Игорь, похоже проблема возникает во время переброса данных из JTDX в Logger32. При этом Logger сам по себе связи с одинаковым временем фиксирует без проблем, проверил специально... В adif JTDX, если отключить Logger, тоже записывается все нормально...
Такая ситуация неоднократно возникала и на нескольких предыдущих версиях, сейчас в работе -rc130...

В этом окне говорится что Logger32 отказался принять пакет-команду от JTDX внести QSO в лог по причине того что QSO с этим временем и датой уже внесено в лог Logger32. Такой сценарий например может быть если софт JTAlert дублирует внесение QSO во внешний лог.

Проблема решается отключением функционала в одной из двух программ, либо в JTDX либо для приведенного примера в JTAlert.

**UA3DJY** · 01.03.2019, 11:57

JTDX v2.0.1-rc131 измененный функционал:

->Скрытый текст<-

- добавлена защита от изменения значений параметров подаваемых на декодер при возможном разрушении содержимого памяти
- добавлена в код проверка значений части параметров файла JTDX.ini при запуске программы
- в функционал поиска позывного добавлена поддержка дробных позывных, в функционал поиска по префиксу добавлена поддержка дроби
- функционал динамических кнопок должен отрабатывать при событии изменения вертикального размера основного окна, сам функционал переработан
- декодеры FT8SD/FT8SD1 не должны пытаться декодировать сообщение если оно уже декодировано
- добавлен дополнительный критерий проверки в декодер FT8SD1 для уменьшения количества возможных ложных декодов
- ряд изменений улучающих функционал декодеров FT8SD1/FT8SD
- устранен дефект в функционале подпрохода FT8 декодера (опция 'use subpass')
- устранен дефект в коде запуска модулятора
- работающая программа должна отслеживать изменения файла лога wsjtx_log.adi выполненные внешними приложениями и должна загружать лог заново в оперативную память по окончании декодирования периода при наличии таких изменений. Добавлена запись события перезагрузки лога в файл ALL.TXT.
- патч для правильного отображения(в том числе уведомления) названия страны и префикса KG4
- обновленный модуль упаковки/распаковки FT8 сообщений и работы с хэш таблицей WSJT-X v2.0.1 интегрирован в код JTDX
- версия JTDX 2.0.1-rc131 собрана с обновленным модифицированным кодом Hamlib включающем изменения программы Hamlib по состоянию на 26.02.2019г.

Измененные исходники: chkfalse8.f90, chklong8.f90, chkcrc14a.f90, chkspecial8.f90, bpdecode174_91.f90, decoder.f90, ft8apset.f90, ft8_decode.f90, ft8_downsample.f90, ft8b.f90, ft8s.f90, ft8sd.f90, ft8sd1.f90, genft8.f90, packjt77.f90, sync8.f90, sync8d.f90, tone8.f90, about.cpp, CMakeLists.txt, Configuration.cpp, countrydat.cpp, logqso.cpp/h, mainwindow.cpp/h/ui, modulator.cpp, soundin.cpp, soundout.cpp, widegraph.cpp/ui

Из файла JTDX.ini удалены следующие параметры: "SaveNone","SaveDecoded","SaveAll","CallNone","CallFirst","CallMid","C allEnd","MaxDistance","ReportMessagePriority","FT8SensMinimum","UseLow FT8thresholds","UseFT8subpass","NoSuffix"

Параметры добавленные в JTDX.ini: "SaveWav","CallMode","AutoSeqPriorityCriterion","FT8Sensitivity"

Мы рекомендуем удалить старый файл JTDX.ini при переходе на версию JTDX v2.0.1-rc131 с более ранних версий.

Линки:

->Скрытый текст<-

Результаты тестирования:

->Скрытый текст<-

**R3BB** · 01.03.2019, 12:03

Русская локализация JTDX v.2.0.1-RC131.
Линки :

->Скрытый текст<-

**UA3DJY** · 01.03.2019, 12:53

Документ с детальным описанием синхронизации FT8 (английский язык): http://www.sportscliche.com/wb2fko/FT8syncV8.pdf

**R6LCF** · 01.03.2019, 12:55

Более чем уверен что установив последнюю версию мало кто удосужится удалить файл конфигурации (ini) в соответствии с рекомендацией автора в аннотации к программе (версии).
Понятно , что удалить в соответствии с правилами ....не запуская программу. А далее постоянные жалобы от .....некоторых на работу программы ,в основном от не желания выполнять! Может начать следовать правилам и инструкциям ,особенно от автора.

**R0JF** · 01.03.2019, 12:58

JTDX v2.0.1-rc131 Linux version from original source files by Igor UA3DJY (Many Thanks him):
Hamlib4 version from February, 26 2019

->Скрытый текст<-

**LY3BG** · 01.03.2019, 14:29

Сообщение от RA9SQ

Прошу помочь в настройке FT-8 трансивер FT-2000 при включенной кнопке pkt работает на передачу как положено переходишь на прием трансивер переключается на rtty а в этом режиме вместо ft-8 идет тон настройки и приходится постоянно контролировать в каком режиме находится трансивер.

Если Вы управляете трансивером через OmniRig, то он понимает команду Data/Pkt как RTTY.
Можно переписать команды, но тогда не будет RTTY. Год назад с этим игрался.

**UA9FFV** · 01.03.2019, 15:29

Сообщение от LY3BG

Если Вы управляете трансивером через OmniRig, то он понимает команду Data/Pkt как RTTY.
Можно переписать команды, но тогда не будет RTTY. Год назад с этим игрался.

Я так же работаю в PKT и использую OmniRig. USB с первого раза показал узкую полосу, а играться не стал. Так и остался в пакете.
Что-то я правил в ини-файле. Сейчас уже не припомню. Но проблем с RTTY не испытываю. Если SQ интересно я вышлю эти ини. FT2K и FT5K имеют близкие протоколы.
А LCF-а я бы тоже поддержал. Далеко не все ведь читают конференцию. Скачают дистрибутив и поставят. Хорошо бы заложить версию ини в текст этого файла и при установке автоматом сносить старую. Но это, конечно, потребует дополнительных усилий от Игоря.

**RM1F** · 01.03.2019, 15:47

Сообщение от UA9FFV

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

Ну, усилий-то там всего ничего: вытащить файл из ресурса и записать на диск. Другое дело, что мне представляется, что вот так вот взять и перезаписать файл пользователя (даже из самых лучших побуждений!) некорректно. Более правильным мне кажется следующий алгоритм:
- проверить целостность INI-файла (например см. пост #17022),
- проверить номер версии и сборки ПО, указанные в INI-файле,
- если они отличаются от текущих (или новых) - вывести ругательство типа "Обнаружен INI файл времен царя Гороха! Программа может работать некорректно! Продолжить?" с кнопками Да, Нет, Обновить INI файл,
- если пользователь выбрал Обновить INI - то обязательно (!!) сохранить текущую версию как .bak. Можно даже пойти дальше - сгенерировать имя типа "JTDX.ini-20190301-154632.bak" (ну, тут зависит только от фантазии программиста

)

**UA3DJY** · 01.03.2019, 18:10

Сообщение от RM1F

Ну, усилий-то там всего ничего: вытащить файл из ресурса и записать на диск. Другое дело, что мне представляется, что вот так вот взять и перезаписать файл пользователя (даже из самых лучших побуждений!) некорректно. Более правильным мне кажется следующий алгоритм:
- проверить целостность INI-файла (например см. пост #17022),
- проверить номер версии и сборки ПО, указанные в INI-файле,
- если они отличаются от текущих (или новых) - вывести ругательство типа "Обнаружен INI файл времен царя Гороха! Программа может работать некорректно! Продолжить?" с кнопками Да, Нет, Обновить INI файл,
- если пользователь выбрал Обновить INI - то обязательно (!!) сохранить текущую версию как .bak. Можно даже пойти дальше - сгенерировать имя типа "JTDX.ini-20190301-154632.bak" (ну, тут зависит только от фантазии программиста

)

Простой сценарий: посыпались данные в оперативной памяти, пользователь закрывает программу JTDX и в момент закрытия она записывает ломанные данные в INI файл, после чего вычисляет CRC самого файла. В итоге при запуске программа на ушах а CRC проверка прошла нормально.

С контролем изменений файла лога сделанных внешними программами тоже оказалось не все просто: JTDX собирается под несколько платформ, на Линуксе при полной перезаписи файла она происходит через удаление файла, в итоге Qt watcher перестает смотреть за этим файлом. Пришлось делать танец с бубном для нормальной работы этого функционала под Линуксом.

**R0JF** · 01.03.2019, 18:21

Мне проще по поводу ini-файлов видится...

Ну и что такого, что в старом ini остались удаленные позиции? Если добавились новые - дописать в файл.
Считывать только то, что актуально. Вот и все.

Другой вопрос - не присваивать новым функциям "старые названия", чтобы в ini-файле путаницы не было.

Ну и не грех было бы рад в полугодие "чекер" выдавать. Чтобы проверял старый ini-файл и тупо удалял из него старые позиции....

Мне кажется, что вообще нет проблем.

**UA3DJY** · 01.03.2019, 18:33

Сообщение от R0JF

Мне проще по поводу ini-файлов видится... Ну и что такого, что в старом ini остались удаленные позиции? Если добавились новые - дописать в файл. Считывать только то, что актуально. Вот и все. Другой вопрос - не присваивать новым функциям "старые названия", чтобы в ini-файле путаницы не было.
Ну и не грех было бы рад в полугодие "чекер" выдавать. Чтобы проверял старый ini-файл и тупо удалял из него старые позиции....
Мне кажется, что вообще нет проблем.

Сбои INI скорее всего идут от изменения информации в оперативной памяти (либо железо сбоит либо какой софт залез куда его не просили), сбои характерны для операционных систем Windows, возможно что Линукс лучше разруливает работу с оперативной памятью.

В версии JTDX rc131 мы по максимуму перевели связанные параметры на integer где легко проверить соответствие значения допустимому диапазону, bool параметры самовосстанавливаются но имеют двоичную неопределенность в варианте Qt при считывании ломанного значения с INI файла. Поэтому для критичных bool параметров при поломанном значении в INI мы сделали откат на значение по умолчанию при котором ущерб минимален.

Проблема есть с геометрией окон и сохранением уровня передачи по диапазонам, которые записываются в виде QByteArray, проблемы есть с параметрами QString и настройками CAT. Все это либо слишком сложно либо невозможно проверить при запуске программы.

**UA3DJY** · 01.03.2019, 21:28

В JTDX rc132 будет доступен для выбора непрерывный диапазон количества потоков декодирования от 1 до 12.

Результаты тестирования на процессоре i7-6700 3.40GHz на звуковом файле (приложен) с которого декодируется около 30 сигналов, одновременно с JTDX на компьютере работали еще много разных приложений.

Левая колонка количество потоков декодирования, правая время декодирования файла в секундах:

1 0.974
2 0.701
3 0.535
4 0.391
5 0.352
6 0.323
7 0.344
8 0.31

**UR4QX** · 01.03.2019, 22:16

Разработчикам - UA3DJY его коллективу, Виктору R3BB, Спасибо с большой буквы за работу, над таким замечательным софтом для нас Р/Л.
МОЛОДЦЫ!!! Работаю в связке MixW_JTDX 7тыс.св., отдельная благодарность Виктору.
Огромная просьба к команде, если не отвлечет от основной работы, - реализовать возможность выбора цвета фона основного интерфейса программы.
Выжигает глаз, а мы тут большинство уже не молоды...
Если не в тему, просьба не пинать с Ув. UR4QX.
С учетом быстрого исправления багов - критических замечаний к JTDX у меня нет.