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

[UA3DJY]

По поводу проблем с Адиф рискну предположить пот что .... а вот 40m <> 40M - это не все анализаторы Адиф делают. А учитывая что повторные QSO опредялются не по частоте, а по бенду - может быть в этом причина.
Но это лишь мое предположение, потому как не знаю, как в JTDX (WSJT-X) трактуется ситуация со значением поля BAND.

В JTDX: band.compare(q.band,Qt::CaseInsensitive)

[UA3DJY]

В 131 версии наблюдаются повторы

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

Вложение 229740

Вложение 229741

Пришлось вручную останавливать

Без записи диагностики в файле ALL.TXT по этому сбою ничего нельзя сказать. В rc132 будет доработка функционала окончания QSO, может быть она решит проблему которую Вы наблюдаете.

[UN5J]

У Вас при экспорте с AALOG отсутствует параметр <station_callsign:>,

При создании Adif добавил - Used callsign, на первый взгляд, заработало.

[UR4UM]

У меня из cqrlog и LogHX3 нормально получается.

У меня из MixW 3.2 выбираю преобразовать в файл mixw2.adi все связи модами JT, FT8, T10 (название файла меняю сразу, или в уже преобразованном файле), и вроде всё ОК...
Вставляю в обе проги, и WSJTX и в JTDX...

[RX4HX]

Алгоритм обработки одной строки и нескольких разный.

Касательно Адиф это в корне не верно. Я весь файл Адиф анализирую "в одну строчку", чтоб как раз не обращать внимания на переносы строк, если они есть.

[R7TQ]

Создайте adi файл из всего UR5EQF. Не надо даже выделять FT8 связи. Переименуйте его в wsjtx_log.adi и замените им существующий в программе.

Это первое ,что я сделал. Ничего не выделял. Тупо переименовал. Вот только не помню, шапку удалял или нет... Доберусь до дома - посмотрю. Спасибо.

[R7TQ]

Александр, пожалуйста более детально в чем заключается сам сбой?

Если у Вас отрабатывает уведомление 'новый QTH квадрат' для позывного JA9BFN то при наличии только одной записи <gridsquare:0> для этого позывного/диапазона/моды в логе уведомление будет отрабатывать на любой переданный оператором JA9BFN QTH квадрат.

Сбой не в этом. Эту запись распознает и уведомляет как положено. А вот, если она будет в файле ADI из логгера (запись в столбик), то она вообще не распознается.

[US5WE]

Прошу прощения за наивный вопрос, очевидно кто-то сталкивался с подобной проблемой.
Учитывая, что 6м сезон не за горами а на 50 МГц иногда прохождение длится минуту хочу выяснить, как решить периодически возникающую проблему.

Итак, Лена работает на поиск и вызывает нужного .DX. Связь проходит по классике.
134630 -8 2.4 913 ~ CQ E20WXA OK03 Thailand
134645 Tx 1791 ~ E20WXA UR5WA -08
134700 -18 2.4 913 ~ UR5WA E20WXA R-17 Thailand
134715 Tx 1791 ~ E20WXA UR5WA RR73
134730 -7 2.4 912 ~ UR5WA E20WXA 73 Thailand

Но достаточно часто, после получения от DX Tx3 (R-XX), программа не переходит на передачу сообщения Tx4 (RR73), а тупо продолжает передавать Tx2.
Приходится вручную жать клавишу Tx4, но если это не сделать быстро, программа снова норовит передать Tx2.
В результате связь срывается. Это весьма критично на 160м, гдe DX сигналы слабые и с QSB.
В появлении этой ошибки нет системы, может проявится в любой момент при работе как на CQ так и на поиск, отсюда вопрос - как от нее избавиться?
Иногда, если DX редкий и нужный, нервы не выдерживают.
Фильтр на Европу включен постоянно.
Заранее благодарим за рекомендации.

[R7TQ]

если у Вас включена фильтрация лога в закладке General (общие) настроек то такая запись ADIF не будет учитываться потому что она не привязана к позывному пользователя, с точки зрения фильтра лога эта запись не несет какой либо информации.

Да! ЗАРАБОТАЛО! Причина в этом!
Далее делать не обязательно:
В файле ADI из UR5EQF удалил заголовок, подставил "WSJT-X ADIF Export<eoh>", методом замены на "ничто" удалил все тэги <OPERATOR:4>R7TQ,

Потом прочел цитируемый пост - поставил - снял "галку" - заработало.
Проверил еще раз ничего не корректируя в файле из UR5EQF - все связи вижу.
Все дело в "галке", она не давала , в смысле... в программе.
Еще раз спасибо UA3DJY за пинок в нужном направлении.

[UA1OMZ]

У Вас при экспорте с AALOG отсутствует параметр <station_callsign:>, если у Вас включена фильтрация лога в закладке General (общие) настроек то такая запись ADIF не будет учитываться потому что она не привязана к позывному пользователя, с точки зрения фильтра лога эта запись не несет какой либо информации.

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

[UA3DJY]

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

Чем поможет импорт из одного ADIF файла в другой ADIF файл если сбой вызван кривым экспортом в файл ADIF из внешнего лога, как в данном случае? Недостающую в файле информацию уже не восстановить.

JTDX и WSJT-X парсят (импортируют) файл ADIF лога в оперативную память где его и держат уже в необходимом программе виде.

[UA3DJY]

Прошу прощения за наивный вопрос, очевидно кто-то сталкивался с подобной проблемой. ...
Но достаточно часто, после получения от DX Tx3 (R-XX), программа не переходит на передачу сообщения Tx4 (RR73), а тупо продолжает передавать Tx2.
Приходится вручную жать клавишу Tx4, но если это не сделать быстро, программа снова норовит передать Tx2.
В результате связь срывается. Это весьма критично на 160м, гдe DX сигналы слабые и с QSB.
В появлении этой ошибки нет системы, может проявится в любой момент при работе как на CQ так и на поиск, отсюда вопрос - как от нее избавиться?

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

[R2PU]

JTDX v2.0.1-rc131 измененный функционал:
- ряд изменений улучающих функционал декодеров FT8SD1/FT8SD
- устранен дефект в функционале подпрохода FT8 декодера (опция 'use subpass')

Функционал подпрохода действительно заработал , впервые с момента перехода на FT8v2 . Очень чувствуется на тестовом пакете -23 и не очень на -24 )))).
Факт того что в софте JTDX ещё улучшился функционал декодирования слабых сигналов - очень радует , спасибо что не забываете о декодере как таковом.

Хочешь крутой сервис по повторам, дипломам, LoTW, загрузке диапазонов, колокольчикам и т.п. - установи JTAlert... Сейчас меня побьют камнями.

Или поставят спасибо ))).
Увы но это еденично , редкие посты вроде Вашего или например моего неизменно тонут в общем потоке : "хотим ещё новых расцветок-собачек-точечек + цать вариантов AutoSeq"

Проверка-уведомление по списку префиксов и позывных сейчас занимает всего несколько строк в коде, для проверки по диапазонам добавим еще две...три строки. С точки зрения нагрузки процессора для декодированного сообщения невелика разница просматривать десяток префиксов с общего списка или 10+10 префиксов с учетом диапазона. Редко кто будет вносить в строку поиска более 10 префиксов, такую строку уже тяжело просматривать глазами.

Игорь , в том то и дело что к примеру на 40м у меня CFM 154 DXCC - и соответственно WANTED 186.
Забивать в строку поиска все префиксы этих 186 DXCC , да ещё с разбивкой по бэндам занятие слабовероятное )))
Тут уже всё давно придумано до нас и вовсю маячит выделением и голосит из колонок при появлении на бэнде любой из этих 186ти :

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

А ещё оно умеет выискивать в любых мыслимых сочетаниях (например wanted DXCC + wanted State + wanted call и т.п.) , показывает уйму полезной инфо , и мониторит B4 вне зависимости от того каким софтом (JTDX\WSJT-X) я работал и вышивает крестиком здорово помогает повысить подтверждаемость (показывая например месяц-год когда конкретный LoTW user выгружался на LoTW) + ещё немерено функционала.

Т.е. это давно и виртуозно реализовано в JT Alert и возможно отчасти в некоторых логах (например LogHX3) , соответственно большой вопрос какой ценой в итоге удастся вогнать в JTDX столько функционала - и сколько в итоге машинных ресурсов потребует получившийся монстр "всё в одном" ...
Решать безусловно Вам - но по мне софт JTDX это в первую очередь декодирование слабых сигналов DX , и здесь ещё очень есть куда двигаться ...

[UA3DJY]

по мне софт JTDX это в первую очередь декодирование слабых сигналов DX , и здесь ещё очень есть куда двигаться ...

Постепенно двигаемся, в rc132 будет выше чувствительность на RX частоте при проведении QSO.

[LY3BG]

Но достаточно часто, после получения от DX Tx3 (R-XX), программа не переходит на передачу сообщения Tx4 (RR73), а тупо продолжает передавать Tx2.

Что помечено в AutoSeq? 2? Пометьте 3 и, скорее всего, всё будет ОК.
Может быть компьютер не успевает декодировать, а уже надо передавать.