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

[R0AEB]

r0aeb...чтоб посмотреть окуда работают корреспонденты (опыта мало, по префиксам не все догоняю)- это как то можно поправить?????

....установите JTAlert:
Вложение 167891
заодно покажет,с кем вы уже работали(В4)

Коллеги подскажите где такую красивую софтинку можно взять, с оф сайта не такая?????

[EU1FQ]

Коллеги подскажите где такую красивую софтинку можно взять, с оф сайта не такая?????

Точно такая. Версия 2.8.1 Еще больше возможностей, чем в версии 2.6.17 "Красота" наводится в настройках программы.

[UA3DJY]

С usb все нормально. Откатился на v1.6.0 также мой сигнал не декодируется.Перешел на jt65 от hb9hqx все нормально-отвечают.
Где искать причину?

Частота дискретизации аудиоустройства в тракте передачи, должна быть 48кГц.

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

[US-E-12]

Заметил у себя В JTDX v16.3 меню Save стоит None, а программа всё равно производит запись. Это у всех так.

[UA3DJY]

Заметил у себя В JTDX v16.3 меню Save стоит None, а программа всё равно производит запись. Это у всех так.

Да, но при этом записывает интервалы в звуковые файлы с большой скважностью.

[UA3DJY]

В домашней директории находится файл timer.out куда софт аккумулирует статистику потраченного времени на каждой процедуре исходного кода Фортран: суммарное время в секундах по каждой процедуре(или определенному куску исходного кода) за время работы софта и количество запусков процедур.

Из чего можно рассчитать среднее время при каждом обращении к определенной процедуре.

Ранее в этот файл еще складывалась статистика по количеству декодированных сигналов но в последних версиях JTDX я ее подсчет полностью убрал.

[UA3DJY]

Пока идет работа над JTDX v16.4 решил начать цикл заметок по архитектуре декодирования в JTDX(WSJT-X), поскольку JT65a в софте намного больше развит чем JT9 то в основном будем
рассматривать декодирование JT65a. Поскольку с софтом работаю только 7 месяцев и начинал с нуля то наверняка в заметках будут ляпы и ошибки, буду рассказывать как вижу софт со своей колокольни..

Исходный код написан на языках
C: декодеры BM и FTSRD
C++: в основном интерфейс взаимодействия с пользователем, модуляторы сигналов
Fortran: обработка сигналов на прием, декодеры с использованием согласованных фильтров("подсказка").

Основная программа jt9.f90(jt9.exe) в WSJT-X, в основном с целью тестирования, позволяла работать с командной строкой и аргументами, в JTDX функционал командной строки не поддерживается(но перечень аргументов в исходном коде остался).

Если софт работает под управлением wsjtx.exe(под управлением интерфейса пользователя) то из jt9.f90 запускается подпрограмма jt9a.f90 которая вызывает многомодовый декодер(в JTDX
это JT9 и JT65a, в WSJT-X еще и JT4), исходный код decoder.f90.

В многомодовый декодер передается массив отсчетов(интервал с сигналами) id2 с частотой дискретизации 12000 отсчетов в секунду, используется тип данных INTEGER*2, диапазон значений от -32767 до +32767, что примерно соответствует динамическому диапазону 90дБ. Кроме этого с общей памяти в декодер передаются настройки(параметры) с интерфейса пользователя.

В многомодовом декодере запускаются две параллельных ветви вычислений: JT9(исходный код jt9_decode.f90) и JT65a(исходный код jt65_decode.f90), что при наличии многоядерного процессора позволяет использовать одновременно два ядра процессора.

Многомодовый декодер отдает декодированные сообщения в сторону интерфейса пользователя.

Для JT65a исходный массив данных id2() преобразуется в массив с именем dd() и типом данных REAL*4, c этого момента используются операции с плавающей запятой.

В JTDX в отличие от WSJT-X в многомодовом декодере для JT65a данные в массиве dd() смещаются(задерживаются) на 26000 отсчетов, что повышает эффективность декодирования.

В последующем процессе обработки данных используются только 12000*52 секунды = 624000 отсчетов входных данных, 52 секунды идут от декодирования на 52-ой секунде для проведения связей с отражением от Луны, с учетом задержки распространения сигнала.

[LY3BG]

Так как я перешёл с JT65-HF HB9HQX на JTDX v16.3, поделюсь своими наблюдениями, сравнением и пожеланиями.
Декодирование сигналов происходит несравненно лучше, особенно при QRM, за что большое спасибо UA3DJY!
Но вот с удобством пользования дела хуже.

Если JTDX предназначена для КВ, то от “Show DXCC entity and worked before status” и „New Call“ никакой пользы. Вместо этого должно быть „QSO B4“ с проверкой позывного по диапазону и моде. Очень желательно проверку позывных делать не только зовущих CQ, но и в QSO (второй позывной в макросе). Название страны показывать излишне, хватило бы только префикса по DXCC. Только для В4 включать JTAlertX не удобно, надо смотреть в две таблицы.

Если снять галочку от „Lock TX=Rx“, то при двойном нажатии на позывной частота ТХ=RX перескакивает на частоту корреспондента. Не редьки случаи, когда корреспондент зовёт на другй частоте и при нажатии на его частота ТХ прыгает на частоту корреспондента. Этого не должно быть. Если „Lock TX=Rx“ не отмечено, то должен появиться позывной корреспондента в макросах и настроится на его частоту только RX. При поставленной галочке логика правильная.

В редактируемые макросы должна быть возможность автоматического вставления позывного корреспондента, напр. “@ TU 73” (где @ - позывной корреспондента) чтоб корреспондент видел, что послание послано ему.

Желательно файл лога поместить папку самой программы. Папка AppData не очень удобна для заливки лога в журнал.
У HB9HQX есть опция автоматической пересылки данных связи в Logger32. Было бы очень хорошо иметь такую опцию и здесь.

Постоянно записывать аудио файлы смысла нет, эту функцию желательно сделать отключаемую.

Вот такие пожелания. Спасибо!

[UA3DJY]

Если JTDX предназначена для КВ, то от “Show DXCC entity and worked before status” и „New Call“ никакой пользы. Вместо этого должно быть „QSO B4“ с проверкой позывного по диапазону и моде. Очень желательно проверку позывных делать не только зовущих CQ, но и в QSO (второй позывной в макросе). Название страны показывать излишне, хватило бы только префикса по DXCC. Только для В4 включать JTAlertX не удобно, надо смотреть в две таблицы.

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

Если снять галочку от „Lock TX=Rx“, то при двойном нажатии на позывной частота ТХ=RX перескакивает на частоту корреспондента. Не редьки случаи, когда корреспондент зовёт на другй частоте и при нажатии на его частота ТХ прыгает на частоту корреспондента. Этого не должно быть. Если „Lock TX=Rx“ не отмечено, то должен появиться позывной корреспондента в макросах и настроится на его частоту только RX. При поставленной галочке логика правильная.

Дефект, найду причину и устраню. Благодарю за важную информацию.

В редактируемые макросы должна быть возможность автоматического вставления позывного корреспондента, напр. “@ TU 73” (где @ - позывной корреспондента) чтоб корреспондент видел, что послание послано ему.

Желательно не использовать свободные сообщения при проведении QSO и для этого есть серьезная причина: декодеры с использованием согласованной фильтрации позволяют декодировать сигналы с уровнем -28..-29дБ сигнал/шум, при проведении QSO до -31дБ сигнал/шум. Но согласованная фильтрация может использоваться только для стандартных сообщений.
Допустим вызвавший Вас корреспондент декодировал Ваш общий вызов с уровнем -28 дБ сигнал/шум. Если при окончании QSO Вы будете использовать свободное сообщение то оно скорее всего будет потеряно корреспондентом, потому что для декодирования свободного сообщения необходим -25..-26дБ сигнал/шум при отсутствии QRM на частоте.

Также нет стимула в JTDX сделать стандартными сообщения CQ NA, CQ AS, CQ SA - они потребуют дополнительных декодеров с согласованной фильтрацией, усложнения софта и приведут к росту ложных декодирований при редкости и направленности использования таких сообщений.

Желательно файл лога поместить папку самой программы. Папка AppData не очень удобна для заливки лога в журнал. У HB9HQX есть опция автоматической пересылки данных связи в Logger32. Было бы очень хорошо иметь такую опцию и здесь.

При переустановке сама программа удаляется, 'домашняя' папка в Application Data с логом остается. На компьютере может быть установлено несколько разных версий JTDX использующих лог из 'домашней' папки. Для удобства использования можете попробовать лог RX4HX, он имеет возможность связки с WSJT-X/JTDX.

Постоянно записывать аудио файлы смысла нет, эту функцию желательно сделать отключаемую.

По подавляющему большинству интервалов запись в файлы отключается если выбрать Save -> None.

Небольшое отступление: софт WSJT-X создавался целой командой разработчиков-профессионалов в программировании, цифровой обработке сигналов, кодировании сообщений более десяти лет. Один человек не сможет сделать все и как пример Ваш отказ от софта HB9HQX несмотря на удобства которые этот софт предоставляет.

То же со временем произойдет и с JTDX если за него не возьмется команда.

[LY3BG]

Желательно не использовать свободные сообщения при проведении QSO и для этого есть серьезная причина: декодеры с использованием согласованной фильтрации позволяют декодировать сигналы с уровнем -28..-29дБ сигнал/шум, при проведении QSO до -31дБ сигнал/шум. Но согласованная фильтрация может использоваться только для стандартных сообщений.
Допустим вызвавший Вас корреспондент декодировал Ваш общий вызов с уровнем -28 дБ сигнал/шум. Если при окончании QSO Вы будете использовать свободное сообщение то оно скорее всего будет потеряно корреспондентом, потому что для декодирования свободного сообщения необходим -25..-26дБ сигнал/шум при отсутствии QRM на частоте.

Также нет стимула в JTDX сделать стандартными сообщения CQ NA, CQ AS, CQ SA - они потребуют дополнительных декодеров с согласованной фильтрацией, усложнения софта и приведут к росту ложных декодирований при редкости и направленности использования таких сообщений.

Если есть такая возможность - почему бы и нет. Ведь свободные сообщения довольно часто передются. Пусть каждый сам решит, передавать его или нет. Так что просьба @ остаётся.

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

Не надо так раскрашивать. На КВ в полне хватит В4.
Код (source) HB9HQX находится
https://sourceforge.net/projects/jt65hfhb9hqxedi/
Можно на него глянуть, что-то позаимствовать. Не думаю, что это в данном случае криминал.
Мой сын работает програмистом, кажется С++, на днях с ним поговорю, может он согласится помочь.

[UA3DJY]

Обработка JT65a сигналов в WSJT-X/JTDX разбита на три составляющие:

1. Построение списка сигналов кандидатов на декодирование
2. Понижение частоты дискретизации и обработка сигнала каждого кандидата с последующим декодированием согласно полученному списку.
3. Вычитание декодированного сигнала из массива временных отсчетов dd().

_____________________

1. Построение списка сигналов кандидатов на декодирование, используется
исходный код:

symspec65.f90 - грубое получение спектра состящего из 3413 точек из массива временных отсчетов dd()
sync65.f90 - обработка спектра и построение списка кандидатов, грубое определение величины DT(задержки/опережения сигнала) для каждого кандидата
xcor.f90 - вычисление значения функции корреляции с заранее известной синхропоследовательностью (сигнал JT65a состоит из 126 символов-тонов из которых
63 являются общей для сигналов протокола JT65 синхропоследовательностью и передаются на одной частоте, остальные 63 это закодированное сообщение).

Подпрограмма xcor в sync65 сначала вызывается для определения частот в спектре из 3413 точек содержащих пики значений функции корреляции, затем по каждому кандидату в отдельности из полученного списка частот.

Шаг отсчетов (бинов) в спектре составляет примерно 1.465 Гц (12000 отсчетов в секунду / 8192 точек преобразования Фурье), соответственно symspec65 выдает спектр 0..5 кГц.

Спектр поиска кандидатов ограничен выставленными в окне водопада частотами, в JTDX дополнительно сделано верхнее ограничение частоты поиска сихропоследовательности сигналов JT65a в 2700 Гц.

Правильное построение списка кандидатов определяет эффективность и продолжительность последующего декодирования сигналов.

2. Понижение частоты дискретизации и обработка сигнала каждого кандидата с последующим декодированием согласно полученному списку.

- decode65a.f90 - обработка сигналов, использует
-- filbig.f90 - фильтр нижних частот с частотой среза и дециматор с дробным коэффициентом понижения частоты дискретизации равным примерно 8.713 раз,
на выходе частота дисретизации равна 1378.125 Гц. Выполняется большое преобразование Фурье из временной в частотную область используя 672000 точки, смещение спектра так чтобы частота сихропоследоваельности сигнала-кандидата была возле 0 Гц, эффективная по затратам ресурсов фильтрация зеркального сигнала
в частотной области и понижение частоты дискретизации с преобразованием обратно во временную область с количеством отсчетов равным 77125.
Выходной массив отсчетов во временной области cx (он же c4a) имеет тип данных COMPLEX*4, используется для декодирования сигналов и содержит спектр достаточный для работы с JT65c.

-- fil6521.f90 - фильтр нижних частот и дециматор с коэффициентом понижения частоты дискретизации сигнала равным 4(WSJT-X) и 8(JTDX) для выделения и последующей обработки синхропоследовательности сигнала-кандидата.
Принимает массив cx(), возвращает массив c5x(), также с комплексными данными.
-- afc65b.f90 - точное определение частоты и DT синхропоследовательности сигнала,
обрабатывает данные из массива c5x()
-- twkfreq65.f90 - автоподстройка частоты при нестабильной частоте сигнала, принимает и после обработки возвращает измененный массив cx()

После подстройки частоты в decode65a выполняется преобразование массива данных cx() в символьный спектр-двумерный массив s2(66,126), тип данных вещественный REAL*4, содержащий по каждому из 126 символов(ось времени) спектр из 66 позиций (ось частот).

Далее вызывается подпрограмма decode65b.f90 и полученный символьный спектр передается ей.

[UA3DJY]

Не надо так раскрашивать. На КВ в полне хватит В4.

Вывод декодированных сообщений на экран в WSJT-X/JTDX выполняет многомодовый декодер decoder.f90 написанный на языке Фортран, сверку с логом - раскрашивание цветом - индикацию названия страны и отправку спотов декодированных сообщений выполняет код написанный на языке C++, несколько файлов исходного кода.

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

Но даже при полноценной индикации B4 в JTDX, есть смысл и будет удобно продолжать использовать звуковую сигнализацию JTAlert, который позволяет настроить фильтры на необходимые страны и/или позывные.

[US4IRT]

Еще одна бяка выползла - работа с позывными типа YB71RI/6 не получается в штатном режиме.Только в ручном.Только что на 40м.По поводу @ тоже поддерживаю Витаса - можно передавать,можно нет.Дело личное.

[UA3DJY]

Еще одна бяка выползла - работа с позывными типа YB71RI/6 не получается в штатном режиме.Только в ручном.

Нестандартные позывные не поддерживаются в протоколах JT, проведение QSO возможнo с ограничениями только через использование свободных сообщений.

"From "The JT65 Communications Protocol", QEX June 2005, available also
at http://physics.princeton.edu/pulsar/K1JT/JT65.pdf :

"An amateur callsign consists of a one- or two-character prefix, at
least one of which must be a letter, followed by a digit and a suffix of
one to three letters."

TM11FAJ does not conform to this definition of a standard amateur
callsign, as required for structured messages in the various JT protocols.

With care, you and others can send your special callsign as part of a
free-text message. (Maximum length is 13 characters.)

Part of the sensitivity advantages of JT65, JT4, and JT9 derives from
the fact that standard callsigns are compressible as described in the
above reference.

-- 73, Joe, K1JT "

Описание протокола JT65 на русском языке есть здесь http://physics.princeton.edu/pulsar/...T65_Rusian.pdf

[UA3DJY]

Если снять галочку от „Lock TX=Rx“, то при двойном нажатии на позывной частота ТХ=RX перескакивает на частоту корреспондента. Не редьки случаи, когда корреспондент зовёт на другй частоте и при нажатии на его частота ТХ прыгает на частоту корреспондента. Этого не должно быть. Если „Lock TX=Rx“ не отмечено, то должен появиться позывной корреспондента в макросах и настроится на его частоту только RX. При поставленной галочке логика правильная.

Дефект, найду причину и устраню. Благодарю за важную информацию.

Проверил на разных WSJT-X/JTDX софтах, этого дефекта не наблюдаю, логика при снятой галочке Lock TX=RX везде одинакова:

- если в строке присутствует Ваш позывной то при двойном клике клавиши мыши на строку включается разнос частот приема/передачи, частота передачи при этом не меняется

- если в строке на которую Вы кликаете нет Вашего позывного то меняются синхронно обе частоты: приема и передачи.

Проверьте пожалуйста еще раз, если поведение софта не соответствует этой логике то необходимо удалить файл WSJTX.INI и сконфигурировать настройки JTDX заново.