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

[UR5NMZ]

Сейчас в эфире работает PJ4P, у этого оператора синхронизация часов компьютера настроена чаще чем раз в минуту. В результате одна передача сигнала от него идет с DT 1.5 секунды, следующая с DT 3.4 секунды, естественно для последнего варианта WSJT-X его сигнал не декодирует поскольку захват синхропоследовательности в WSJT-X от -1.5 до +2.5 секунды. В итоге периодически корреспонденты не декодируют сообщения от PJ4P и сам оператор PJ4P периодически не декодирует сообщения корреспондентов. Каша, хаос и уйма бестолковых помех другим операторам на диапазоне.

Не ставьте у себя период синхронизации менее 30...60 минут, особенно если Вы интенсивно работаете на общий вызов.

Утром работал с ним, не но заметил что DT так меняется. Возможно на разных рабочих местах по разному настроена синхронизация времени.. Кстати, отвечал он одновременно двум зовущим, но не F/H.

[UA3DJY]

А какая программа передаёт два разных сообщения в одном цикле на одной частоте? Иногда наблюдаю такое. Или это замена одного сообщения на другое и обе части случайно проскочили через декодер?

WSJT-X в режиме Fox DXpedition создает специальные сообщения адресованные сразу двум корреспондентам, но в WSJT-X режим Fox DXpedition закрыт для использования в общих FT8 диапазонах. Скорее всего в общих диапазонах специальными сообщениями работает программа MSHV.

JTDX при декодировании разбирает одно специальное сообщение на два стандартных, поэтому в JTDX специальное сообщение можно отличить только по одинаковой частоте и разным позывным корреспондентов в нем. В файле ALL.TXT JTDX добавляет в конец таких сообщений символ '1', унаследован с протокола 75 бит где он назывался битом специального сообщения (i3bit).

[R2PU]

Тема распухла и что-либо понять крайне сложно.
Кто нибудь может четко и доступно объяснить, какая версия с точки зрения приема и декодирования слабых сигналов оптимальна для работы с DX, в том числе для сбора слотов на DXCC Challenge (в особенности на 50 МГц в предстоящем сезоне). Звоночки, свисточки, кружочки, галочки и радужные расцветки не интересуют.

Попробую , под спойлером (тем кому тестирование декодирования софтом JTDX и некоторые технические подробности мешают обсуждать очередную порцию их "хотелок" кружочки-цветочки : просьба под спойлер не заглядывать):

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

Сейчас - оптимальна последняя (rc126,127) , при этом желательно попробовать включить функционал "low thresholds" (меню Decode-FT8 decoding - decoder sensitivity).
---------------
Как будет дальше всегда сможете оценить сами по мере выхода новых версий : некоторая (возможно не самая правильная) методика тестирования декодирования слабых сигналов JTDX изложена здесь
Очень коротко суть методики :
1. "гоняем" JTDX (кому как актуальнее : разных версий\с разными настройками\на разных компах) на тестовых пакетах с SNR -23\-24 (файлы пакетов есть в теме )
2. При этом сравниваем : количество декодированных позывных из пакета , время декодирования пакета , загрузку ЦП , результаты фиксируем в произвольной форме (хоть в виде рукописной таблички- как удобней).
3. Для большей уверенности "гоняем" тестирование несколько раз .
4. Сравниваем по нужным критериям и делаем выводы.

Стоит задача сравнить декодирования слабых сигналов разными версиями JTDX и выявить лучшую ?
Да нет проблем , "гоняем" по методике выше разные версии JTDX , сравниваем сколько они надекодируют позывных из пакетов (и попутно мониторим загрузку компа).
Иллюстрация по существу (вырезка из исходной таблички в которую помимо "исходной" rc117 сейчас дописаны результаты тестирования rc126 ) :

Сравниваем (Ваши результаты естественно будут отличаться!): JTDX rc126 отноcительно JTDX rc117 :
а) "вытаскивает" из пакетов больше позывных (особенно заметно на пакете SNR -23)
б) декодирует пакеты дольше - но при этом меньше загружает ЦП
в) активирование функционала "low thresholds" по прежнему значительно "помогает" декодированию слабых сигналов
г) функционал "use subpass" по прежнему не добавляет (относительно "low thresholds") к декодированию слабых сигналов - кроме увеличения времени декодирования и загрузки ЦП.

Т.е. на данный момент например оптимально по приёму и декодированию слабых сигналов использовать JTDX 2.0.1 -rc126 (127 ещё не сравнивал) c активированным функционалом "low thresholds" (меню Decode-FT8 decoding - decoder sensitivity) , по мере выхода новых версий всегда можно сравнить что изменилось по приёму\декодированию .
Для чего так долго и подробно вместо этого абзаца ? Да чтоб сами могли понимать\сравнивать\выбирать что оптимальнее под Ваши конкретные задачи - тем более что новые версии помимо кружочков-цветочков пока ещё демонстрируют прогресс и по части декодирования (остаётся надеятся что так будет и дальше)

Чётко и доступно ? Не уверен , но по другому не умею (конкретные цифры показательней субьективного : "лучше\хуже , тормозит\летает") , хочется надеяться что немного поможет уважаемому US5WE самому в дальнейшем сравнивать оптимальные версию\настройки - применительно к конкретным целям и задачам.

P.S. Расцветки\раскраски\собачки-кружочки (или что там сейчас) у меня отключены в JTDX как таковые , мне неактуально .

Note к всё-таки прочитавшим: все действия по вышеописанным сравнениям делаете на свой страх и риск , как минимум стоит понимать что в ходе тестирования Вы "нагружаете" свой ПК несколько больше "обычной" работы с JTDX

Не нужно косить всё подряд.
За грёбанной толпой СQлистов не видно dx,
давка как в метро.
Увидел dxа, сработал.
Дипломов им не хватает, электронных что ли.
Вообще не понимаю зачем просто так cq работать?
Ну в тлг там кайф, в тлф общение, а тут?
Сколько можно поляков и итальянцев собирать?

Под спойлером (только для непонимающих вроде меня или R7CA , любителям работать на .....цать тысяч QSO - просьба не тратить время и нервы на прочтение):

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

Андрей , я тоже не понимаю - но предполагаю следующее:
Загляни для примера сюда и сюда , и посмотри количество QSO в FT8 в прошедшем 2018м у занявших первые места.
Реально "намолотить" 10-15-20 тысяч QSO за год не работая "всех подряд" (если самому не быть DXом) ?
Поляки , итальянцы , соседняя улица - даёшь ......цать тысяч QSO и будешь первым !
CQ CQ CQ (вплоть до нескольких бэндов разом) - кто нить да подойдёт добавив в "копилку" до первого места.
Попутно можешь поискать где то там себя и меня (211й и 246й) - не , нам вообще не понять - куда нам .
Деликатные просьбы хоть немного думать о других с треском провалились , боюсь эту машину уже не остановить.....
По 2019му думаю найдёшь сам - там только за неполный январь у лидера наработано уже больше чем у R7CA или R2PU за целый прошлый год , куда уж тут до понимания (в т.ч. и некоторых публикуемых "хотелок от СQлистов" - в теме JTDX )

Сейчас в эфире работает PJ4P, у этого оператора синхронизация часов компьютера настроена чаще чем раз в минуту. В результате одна передача сигнала от него идет с DT 1.5 секунды, следующая с DT 3.4 секунды, естественно для последнего варианта WSJT-X его сигнал не декодирует поскольку захват синхропоследовательности в WSJT-X от -1.5 до +2.5 секунды. В итоге периодически корреспонденты не декодируют сообщения от PJ4P и сам оператор PJ4P периодически не декодирует сообщения корреспондентов. Каша, хаос и уйма бестолковых помех другим операторам на диапазоне.

Не ставьте у себя период синхронизации менее 30...60 минут, особенно если Вы интенсивно работаете на общий вызов.

Игорь , Вас неоднократно (и не первый год , например вот) просили встроить синхронизацию времени прямо в JTDX (причём без зависимости от наличия интернета).
В т.ч. предлагалось (опционально включаемый функционал ) вообще уйти от привязки "захват синхропоследовательности по системному времени" - а привязать захват синхропоследовательности к моменту появления сигнала на маркере Rx (а дальше пользователь сам решит под кого ему строиться : "по большинству" станций , или под конкретного DXа со "сбитым временем")

Увы - но воз и ныне там (решать безусловно Вам) - программа JTDX обросшая дополнительными расцветками\кружочками\свисточками и прочими "хотелками большинства" - по прежнему не способна декодировать при ситуации выходящей за стандартное : "DT на передающей\приёмной стороне в допуске" - и всяк решает это как может (синхронизируется через интернет\GPS\сигналам точного времени - или с хрустом давит кнопки пытаясь вручную попасть в желаемый интервал).

Всё бы и ничего , у подавляющего большинства нет проблем со временем - и они радуются новым цветочкам\кружочкам :
- Но когда после некислого цикла постов о синхронизации времени через GPS (цена вопроса 500-1000 руб) уважаемая (очень уважаемая! , команда просто супер!) экспедиция едет в места без постоянного интернета - и при первых же попытках работы в FT8 собирает шквал сообщений в духе: "PSE SYNC TIME" , после чего сворачивает работу в FT8 (я от своих слов не отказываюсь - знал бы что так будет - сам бы подарил им "таблетку" GPS).
- Когда у другой команды сейчас с Ваших слов : "Каша, хаос и уйма бестолковых помех другим операторам на диапазоне" (и не факт что там трабл : "синхронизация часов компьютера настроена чаще чем раз в минуту" , системное время может прыгать до нескольких раз в минуту по многим причинам - вплоть до проблем с "железом" компа)
- Когда редчайшего DX намертво гасит оттакой сигналище зовущего по частоте да со сбитым временем (механизм прост до безобразия: начало передачи DXа "накрывается" окончанием передачи зовущего у которого сбито время)
- Когда на вопросы в теме вновь и вновь даются рецепты вида : "или используйте интернет - или вручную тыкайте в стрелки" (а было дело вплоть до советов : "лучше купите вместо GPS шашлыка да пива")

Вот тут поневоле задумаешься: был бы в WSJT-X\JTDX встроенный опциональный функционал синхронизации (возможно с предупреждающим окном на предмет возможных конфликтов с прочими средствами синхронизации) - может поменьше было бы каши , хаоса и помех .....

[R5WM]

Желающие могут принять участие в Дне Активности на УКВ!
Сегодня 14:00-22:00 UTC
FT8 144.174, 432.174

to R5WM: Владимир, пожалуйста используйте для выделения текста цвет отличающийся от красного.

3.3.10 Использование красного цвета в Ваших сообщениях или подписях. Красный цвет - разрешён только администрации форума

[R5WM]

[

А какая программа передаёт два разных сообщения в одном цикле на одной частоте? Иногда наблюдаю такое. Или это замена одного сообщения на другое и обе части случайно проскочили через декодер?

MSHV в режиме Мультиответ MSHV Amateur Radio Software | LZ2HV Amateur Radio Website

Русская версия 2.10 тут: https://drive.google.com/open?id=1Lh...0rv93VpiAfc_Gi

[UA3DJY]

Игорь , Вас неоднократно (и не первый год , например вот) просили встроить синхронизацию времени прямо в JTDX (причём без зависимости от наличия интернета).

Роман, как Вы относитесь к тому что Вашим компьютером будут пользоваться и управлять неизвестные Вам люди для решения своих задач? Синхронизация системного времени из JTDX означает запуск программы с правами администратора, что открывает возможность для удаленного управления компьютером без ведома пользователя. Когда права администратора открывает сам пользователь это его личное решение и его ответственность за результат использования компьютера находящегося в сети Интернет, если это делает производитель программного обеспечения то он подвергает риску всех пользователей программы.

Попытка смещать отсчет времени внутри программы при 100% загрузке процессора приведет к хаосу в работе программы, рассинхронизации периодов приема передачи. Сейчас в коде mainwindow.cpp есть несколько точек запроса системного времени, на слабых CPU во время декодирования этот запрос работает с ощутимой ошибкой в результате.

[US4IRT]

Скорее всего в общих диапазонах специальными сообщениями работает программа MSHV.

Так оно и есть. Тот же PJ4P использует MSHV (отвечает и на рапорт, и на локатор) в общих диапазонах. Правда, становится в самом низу.

[R7CA]

Так оно и есть. Тот же PJ4P использует MSHV (отвечает и на рапорт, и на локатор) в общих диапазонах. Правда, становится в самом низу.

Его при этом всём звать обычным способом или F/H¿
Я рапортом привык уже звать...

[R2ADF]

Попробуйте запустить JTDX напрямую, отдельно от UR5EQF и второй вариант при выключенном UR5EQF.

Честно говоря, разницы между предложенными вариантами - не увидел. "Отдельно от ..." и "при выключенном..." ? :-(

Ради чистоты эксперимента, вообще отказался от UR5EQF_Log3 и WSJTinterface. В работающей конфигурации остались: JTDX 2.0.1-125, OmniRig (куда-ж-без-него!) 1.16. Для логгирования (TCP) пришлось написать и отладить отдельный плагин LogTCPSRV.ext для CheckLog. JTDX запускается самостоятельно, ни из-под какой-либо другой программы. Симптомы остаются:

1). При первом запуске мощность "задавлена". При этом все приседания вокруг аппаратуры выполнены, на голосовой связи с теми же настройками и при том же согласовании антенн мощность отдает и связи проводятся "с пол-пинка".

2). Если вызвать Settings -> Radio и нажать Test CAT (оно ОЧЕНЬ долго чем-то нзанимается, но "зеленым" потом загорается)... а потом нажать Test PTT (здесь срабатывает сразу, горит красным, включвает и выключает передачу).... то после закрытия окна Settings "замирает" водопад.

3). Если закрыть окно JTDX, то оно как бы закрывается, но в памяти остается "висящий" процесс. Если об этом не знать, повторный запуск JTDX невозможен. Только после того, как в Task manager найти и убить jtdx.exe - можно запустить обычным образом повторно.

4). При повторно запущенном JTDX всё уже работает, как надо. Мощность отдаётся, водопад "ползет", связи протоколируются.

Видимо, что-то всё-таки "внутри" JTDX. Чем могу помочь ещё?

[US4IRT]

Его при этом всём звать обычным способом или F/H

F/H может не пройти (не передает 73). На 160м первый раз он не принял от меня 73 и в лог не внес. Прошло на второй день. Вызывать можно и рапортом (тоже так зову обычно), и локатором. Разница в дополнительном интервале передачи.

[UA1CSB]

Очередной вопрос уважаемому обществу.Хотелось бы по подробней узнать что это за кнопка (на скрине).Я думаю и другим будет интересно.

[UA1OMZ]

А какая программа передаёт два разных сообщения в одном цикле на одной частоте? Иногда наблюдаю такое. Или это замена одного сообщения на другое и обе части случайно проскочили через декодер?

Подтверждаю, вот пример такой передачи в одно и тоже время и на одной частоте RZ6HBK дает рапорт и мне и нидерландцу или баг приема?

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

[R6LCF]

интересно

Активирует группу декодеров основанных на согласованных фильтрах,для моды FT8 активирует FT8AP декодеры.
Сразу предупреждаю у меня вкл. фильтр на Европу ,почему их и нет.

Да вот еще.Не включайте SWL-этот режим предназначен для увеличения попыток декодирования.
У меня в компе мощный проц. и загрузка увеличивается на 20% с 50 до 70. Эффект в наличии по количеству декод. У кого слабые/средние проц.только на прием.

[US4IRT]

RZ6HBK дает рапорт и мне и нидерландцу или баг приема?

Такого никогда не видел. Обычно на одной частоте одному рапорт, другому 73

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

[R2PU]

Роман, как Вы относитесь к тому что Вашим компьютером будут пользоваться и управлять неизвестные Вам люди для решения своих задач? Синхронизация системного времени из JTDX означает запуск программы с правами администратора, что открывает возможность для удаленного управления компьютером без ведома пользователя. Когда права администратора открывает сам пользователь это его личное решение и его ответственность за результат использования компьютера находящегося в сети Интернет, если это делает производитель программного обеспечения то он подвергает риску всех пользователей программы.

Точно так же как и ко всему остальному софту требующему для работы запуск с правами администратора - осознаю риски и действую в соответствии с ними.
Разве используемые многими Dimension4 и т.п. программы синхронизации времени безопаснее в этом плане ?

Попытка смещать отсчет времени внутри программы при 100% загрузке процессора приведет к хаосу в работе программы, рассинхронизации периодов приема передачи. Сейчас в коде mainwindow.cpp есть несколько точек запроса системного времени, на слабых CPU во время декодирования этот запрос работает с ощутимой ошибкой в результате.

ОК , пусть так (жалко интересную идею вообще не привязываться к системному времени для захвата синхропоследовательности - но нет так нет).
Ждём светлого будущего когда все освоят (по обстановке) : синхронизацию по Интернету \ GPS \ "ручному тыканию".
Когда-то же это должно произойти ....