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

[UA3DJY]

Добрый день ! А уровень ,,градусника,, в правом нижним углу как регулируется и какой уровень должен быть ?

Настройками вне программы JTDX. На пустом участке диапазона должен быть не менее 30 dB, в рабочем участке не должен уходить в перегрузку/красный цвет.

[LY3BG]

Как понять кто меня вызывает? JTDX v.2.2.156.

[ES1JA]

Как понять кто меня вызывает? JTDX v.2.2.156.

Stupid user with long callsign is calling with report. No way to understand.

[UA3DJY]

Как понять кто меня вызывает? JTDX v.2.2.156.

Вызывающий игнорирует протокол FT8, в основном это ручной выбор сообщения для передачи. В последних версиях JTDX оператору с нестандартным позывным недоступна опция вызова рапортом.

[US5WE]

Have not seen more callsigns using Dxped mode and where /A is changing DXCC.

I mean this(RO9O instead of SV2RSG/A):
20211202_182900 -9 0.3 292 ~ OH2XX RO9O RR73 1
20211202_182900 -9 0.3 292 ~ PA3FQA RO9O +02 1
20211202_182900 -9 0.3 352 ~ UA1OLM RO9O RR73 1
20211202_182900 -9 0.3 352 ~ ES2MC RO9O +00 1
And in message #380:
https://forum.qrz.ru/54-ekspeditsii-...ml#post1848260
Crazy stuff

[kronas]

Здравствуйте. Подскажите почему программа занижает рапорта? По S метру трансивера 9 балов, а в программе( -8). JTDX rc148.

[LY3BG]

Тут как-то не правильно.
Я его вызывал в 2152, но он не ответил. Ответил только в 0114. Почему время начала QSO пишется такое, когда я первый раз его вызывал? Это время идёт в LOTW, eQSL и т.д. Получается не совпадение по времени.
Вызывал рапортом, почти всегда так делаю.

[UA3DJY]

Тут как-то не правильно.
Я его вызывал в 2152, но он не ответил. Ответил только в 0114. Почему время начала QSO пишется такое, когда я первый раз его вызывал? Это время идёт в LOTW, eQSL и т.д. Получается не совпадение по времени.
Вызывал рапортом, почти всегда так делаю.

В JTDX 157 исправили, информация есть в перечне измененного функционала. 157 версия работает ощутимо лучше чем 156, в том числе FT8 декодер, есть смысл перейти на нее.

- - - Добавлено - - -

Здравствуйте. Подскажите почему программа занижает рапорта? По S метру трансивера 9 балов, а в программе( -8). JTDX rc148.

S-метр показывает сумму уровней всех сигналов + шума в полосе приемника в dBm пересчитанную(откалиброванный) в S единицы, JTDX показывает соотношение уровней сигнал/шум для сигнала корреспондента замеренное в полосе сигнала и приведенное к полосе 2500 Гц. Поскольку у большинства пользователей в приемнике включена АРУ и динамический диапазон сквозного тракта оставляет желать лучшего(если выключить АРУ придется эмулировать работу АРУ вручную ручкой усиления ВЧ/ПЧ тракта) то по уровню звукового сигнала невозможно предсказать показание S-метра, по этой причине программы работающие со звуком могут показать только соотношение сигнал/шум.

В JTDX опционально реализован вывод показаний S-метра в окно интерфейса пользователя при использовании CAT Hamlib либо TCI, но не все модели трансиверов поддерживают передачу этих показаний через CAT.

[RC3C]

Обновился на 2.2.157-х64/Вынь10

После 5-и дневной работы (наблюдений) вылетела с такой ошибкой

Случилось это после нескольких минут отключения от "эфира"
== ERROR TEXT ==
Running: L:\JTDX\bin\jtdxjt9 -s JTDX -w 1 -m 7 -e L:\JTDX\bin -a C:\Users\RC3C\AppData\Local\JTDX -t D:\Temp\JTDX -r L:\JTDX\share\jtdx
At line 954 of file C:\JTSDK64-Tools\tmp\wsjtx\lib\ft8b.f90
Fortran runtime error: Index '15' of dimension 2 of array 'ndxnsaptypes' above upper bound of 14== /ERROR TEXT ==

После нажатия на ОК программа вылетела

[UA3DJY]

I mean this(RO9O instead of SV2RSG/A):
20211202_182900 -9 0.3 292 ~ OH2XX RO9O RR73 1
20211202_182900 -9 0.3 292 ~ PA3FQA RO9O +02 1
20211202_182900 -9 0.3 352 ~ UA1OLM RO9O RR73 1
20211202_182900 -9 0.3 352 ~ ES2MC RO9O +00 1
And in message #380:
https://forum.qrz.ru/54-ekspeditsii-...ml#post1848260
Crazy stuff

Хеш позывного RO9O был позже записан в хеш таблицу и совпал с хеш значением позывного SV2RSG/A. Если окно DXCall пусто то с хеш значением ассоциируется позывной попавший в хеш таблицу позже, если в окне DXCall есть позывной то он должен иметь преимущество над списком позывных в хеш таблице, иначе это дефект в коде.

- - - Добавлено - - -

Обновился на 2.2.157-х64/Вынь10

После 5-и дневной работы (наблюдений) вылетела с такой ошибкой
..
At line 954 of file C:\JTSDK64-Tools\tmp\wsjtx\lib\ft8b.f90
Fortran runtime error: Index '15' of dimension 2 of array 'ndxnsaptypes' above upper bound of 14

Дефект, благодарю, исправим.
Сбой происходит когда в настройках позывной оператора нестандартный либо отсутствует, и в окне DX Call находится нестандартный позывной корреспондента.

В таком сценарии провести QSO невозможно, но FT8 декодер должен работать без сбоев.

[US5WE]

Хеш позывного RO9O был позже записан в хеш таблицу и совпал с хеш значением позывного SV2RSG/A. Если окно DXCall пусто то с хеш значением ассоциируется позывной попавший в хеш таблицу позже, если в окне DXCall есть позывной то он должен иметь преимущество над списком позывных в хеш таблице, иначе это дефект в коде.

1844 монах работает 2 канала F/H народ зовет
А это как объяснить?
181515 -13 0.1 1286 ~ J35AC UT9EG KN78 •Ukraine
181515 -6 0.2 1655 ~ SV2RSG DL5AN JN49 °Germany
181515 -10 0.1 1459 ~ SV2RSG/A 9A2RZ JN75 Croatia
181515 -13 0.1 1360 ~ SV2RSG I1WXY JN43 °Italy
181515 -14 0.3 1488 ~ SV2RSG F6DAY JN05 France
181515 -12 0.1 2487 ~ J35AC YO8BSE KN36
Grenada в это время на 160м не ходит от слова вообще и сигнала такого на частоте не было.
Там же есть еще такой 183215 -12 0.2 1997 ~ ZC4GR DF2TT JN58
Garry на 160м замечен не был.

[UA3DJY]

1844 монах работает 2 канала F/H народ зовет
А это как объяснить?
181515 -13 0.1 1286 ~ J35AC UT9EG KN78 •Ukraine
181515 -6 0.2 1655 ~ SV2RSG DL5AN JN49 °Germany
181515 -10 0.1 1459 ~ SV2RSG/A 9A2RZ JN75 Croatia
181515 -13 0.1 1360 ~ SV2RSG I1WXY JN43 °Italy
181515 -14 0.3 1488 ~ SV2RSG F6DAY JN05 France
181515 -12 0.1 2487 ~ J35AC YO8BSE KN36
Grenada в это время на 160м не ходит от слова вообще и сигнала такого на частоте не было.
Там же есть еще такой 183215 -12 0.2 1997 ~ ZC4GR DF2TT JN58
Garry на 160м замечен не был.

Если у Вас включена запись декодированных сообщений в файл ALL.TXT, посмотрите пожалуйста декодировали ли Вы сообщения от J35AC и ZC4GR в этот день на других диапазонах.

По этим двум строкам одного интервала видно что FT8 декодер JTDX правильно ассоциировал хеш с позывным SV2RSG/A в стандартном сообщении:

181515 -13 0.1 1286 ~ J35AC UT9EG KN78 •Ukraine
181515 -10 0.1 1459 ~ SV2RSG/A 9A2RZ JN75 Croatia

Могу предположить что сбой происходит на стороне операторов UT9EG YO8BSE DF2TT и они действительно передают сообщения с этими стандартными позывными в эфир (не используя хеш при передаче сообщения), на pskreporter не вижу какой софт они используют, у них отключено репортирование спотов.

Для специального сообщения используется своя хеш таблица, для стандартного сообщения с нестандартным позывным используется другая хеш таблица, с отличающейся длиной хеш. Потенциально такой подход в протоколе DXpedition может приводить к некорректной ассоциации позывных с хеш значениями в некоторых сценариях. ИМХО DXpedition 'недопиленный' протокол имеющий конфликты с FT8 протоколом. Также пользователь может включить режим гончей Hound, а может и не включить. В том числе MSHV имеет возможность передачи специальных сообщений (два в одном) в общих FT8 диапазонах. Потенциально конфликтных сценариев уйма..

[US5WE]

Если у Вас включена запись декодированных сообщений в файл ALL.TXT, посмотрите пожалуйста декодировали ли Вы сообщения от J35AC и ZC4GR в этот день на других диапазонах.

По этим двум строкам одного интервала видно что FT8 декодер JTDX правильно ассоциировал хеш с позывным SV2RSG/A в стандартном сообщении:

181515 -13 0.1 1286 ~ J35AC UT9EG KN78 •Ukraine
181515 -10 0.1 1459 ~ SV2RSG/A 9A2RZ JN75 Croatia

Могу предположить что сбой происходит на стороне операторов UT9EG YO8BSE DF2TT и они действительно передают сообщения с этими стандартными позывными в эфир (не используя хеш при передаче сообщения), на pskreporter не вижу какой софт они используют, у них отключено репортирование спотов.

Для специального сообщения используется своя хеш таблица, для стандартного сообщения с нестандартным позывным используется другая хеш таблица, с отличающейся длиной хеш. Потенциально такой подход в протоколе DXpedition может приводить к некорректной ассоциации позывных с хеш значениями в некоторых сценариях. ИМХО DXpedition 'недопиленный' протокол имеющий конфликты с FT8 протоколом. Также пользователь может включить режим гончей Hound, а может и не включить. В том числе MSHV имеет возможность передачи специальных сообщений (два в одном) в общих FT8 диапазонах. Потенциально конфликтных сценариев уйма..

Игорь,
ZC4GR активен, работали с ним на разных диапазонах, в том числе на 6 метрах, но на 80 и 160 не наблюдали ни разу.
Позывной подмены J35AC увидели первый раз, когда народ звал SV2RSG на 40 метрах (сладкая парочка SV2RSG<->J35AC получается). До этого о его существовании вообще не знали.
Что мешает отцам основателям "допилить" DXPedition protocol?

[R7WA]

157 версия ...-- Выскакивает табличка ----Ошибка управления трансивером...-- Ошибка Hamlib Ошибка протокола обмена while получение статуса PTT.... В156 версии такого не было .. Что надо исправить или обновить ?

- - - Добавлено - - -

..... добавилось еще и --Ошибка Hamlib Ошибка протокола обмена while получение частоты текущего VFO

- - - Добавлено - - -

157 версия ...-- Выскакивает табличка ----Ошибка управления трансивером...-- Ошибка Hamlib Ошибка протокола обмена while получение статуса PTT.... В156 версии такого не было .. Что надо исправить или обновить ?

- - - Добавлено - - -

..... добавилось еще и --Ошибка Hamlib Ошибка протокола обмена while получение частоты текущего VFO

WIN 11- 64bit

[UA3DJY]

Что мешает отцам основателям "допилить" DXPedition protocol?

Недостаток ресурсов. Команда WSJT постоянно идет вперед с разработкой новых мод и к ранее исполненному функционалу они возвращаются редко.

С уходом Bill G4WJS проблема недостатка ресурсов ощутимо усугубилась..

Проблема ограниченности ресурсов присуща разработке любого софта.

Нельзя объять необъятное

- - - Добавлено - - -

157 версия ...-- Выскакивает табличка ----Ошибка управления трансивером...-- Ошибка Hamlib Ошибка протокола обмена while получение статуса PTT.... В156 версии такого не было .. Что надо исправить или обновить ?

- - - Добавлено - - -

..... добавилось еще и --Ошибка Hamlib Ошибка протокола обмена while получение частоты текущего VFO

- - - Добавлено - - -



WIN 11- 64bit

Какая модель трансивера и конфигурация CAT сетапа? Какую сборку JTDX используете?

- - - Добавлено - - -

157.. вылетела с такой ошибкой
..
At line 954 of file C:\JTSDK64-Tools\tmp\wsjtx\lib\ft8b.f90
Fortran runtime error: Index '15' of dimension 2 of array 'ndxnsaptypes' above upper bound of 14

Дефект, благодарю, исправим.
Сбой происходит когда в настройках позывной оператора нестандартный либо отсутствует, и в окне DX Call находится нестандартный позывной корреспондента.

В таком сценарии провести QSO невозможно, но FT8 декодер должен работать без сбоев.

До выхода сборки с патчем пропишите пожалуйста в настройках программы используемой для наблюдения свой позывной RC3C.