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

[R2ADF]

Что, соскучились? Ничего, ничего... сейчас продолжим.

[здесь я хотел показать картинку. Но кто-то запретил мне вставлять картинки. За что отдельное спасибо]

Вместо картинки будет только описание. Но если картинку всё-таки можно будет показать - я ее покажу. Она у меня сохранена.

Работаем в WSPR-2, JTDX 2.0.1-rc129. Весь протокол "ловим" по UDP, и аккуратно записываем. С экраном JTDX - полное соответствие. Увы, перенабивать всё с окна JTDX нет никакой возможности.

16:56 Decode (40M) DB7EN
16:57 Tune (30M)
17:00 Transmit (40M)
17:01 Tune (80M)
17:02 Decode (80M) M0HGU
17:03 Tune (40M)
17:04 Decode (40M) DL0PBS
17:04 Decode (40M) DD2HZ
17:04 Decode (40M) ON4PDV
17:04 Decode (40M) PE4BAS
17:05 Tune (40M)
17:06 Decode (40M) DK8JP
17:06 Decode (40M) DG7RJ
17:07 Tune (30M)

... и так далее

Вопросы:
Почему нет "16:59 Tune (40M)", если тюнинг в Band hopping включен, а следующим циклом (уже известно в 16:59) пойдет передача на 40M?
Зачем нужно "17:05 Tune (40M)", если диапазон не переключается, передача не ожидается, и просто слушается эфир - условия не изменялись вообще?
Отчего меня лишили возможности вставить картинку - снимок окна с логом, и вынуждают перенабивать всё врукопашную?

Хотелось бы получить ответы. Возможно, и не мне одному.

[UA3DJY]

Игорь, здравствуйте!
Вопрос- будет ли реализован в JTDX полноценный режим Hound?
Потому что то, что есть сейчас, на Hound мягко говоря непохоже))
Пока работал V84SAA, в принципе все было нормально, он просто работал в режиме multy QSO, проблем не возникало. Включал hound только для того, чтоб передачу не отрубало, в случае ответа другому корреспонденту(В принципе можно было просто снять галочку в настройках, но так было оперативнее)
Но тут появился XX9D, который работал уже полноценной лисой.И тут начались пляски с бубном и тестирование оператора на скорость реакции)))

Изначально был протокол QSO DXpedition разработанный командой WSJT и реализованный в программе WSJT-X. Этот протокол включает в себя управление TX частотой оператора Hound во время проведения QSO и закрыт в программе WSJT-X для использования в общих диапазонах: команда разрабочиков WSJT разумно считает что нет такого приоритета у DX оператора чтобы занять собой существенную часть общего FT8 диапазона в нескольких слотах. В JTDX совместимость с WSJT-X Fox DXpedition обеспечивается режимом HoundFC (режим гончей с управлением TX частотой) и этот режим включается только вне общих FT8 диапазонов.

Позже появился режим многослотовой передачи в программе MSHV который в большей своей части повторяет режим Fox DXpedition но не требует от корреспондентов управления TX частотой, также у автора MSHV свое уникальное видение возможности включения до 5 слотов передачи сигнала в общих КВ FT8 диапазонах (диапазоны которые и без многослотовой работы MSHV уже перегружены в несколько раз). Также есть операторы кто считает необходимым использовать данную в программе MSHV возможность многослотовой передачи в общих КВ диапазонах.

В итоге у нас есть два немного отличающихся протокола проведения QSO в многослотовом режиме и частичная несовместимость программ WSJT-X и MSHV между собой.

Чтобы обеспечить совместимость с многослотовым режимом передачи MSHV в JTDX был реализован режим Hound без управления TX частотой. Проблема возникает вне общих диапазонов когда оператор не всегда достоверно знает какую программу использует DX, то есть DX корреспондент может использовать MSHV и вне общих диапазонов. Если DX корреспондент указал на своем Интернет сайте или в других источниках свою частоту VFO для каждого диапазона то распознать MSHV можно по факту передачи выше звуковой частоты 1000 Гц, но когда DX передает ниже 1000 Гц то это может быть как MSHV так и WSJT-X.

Далеко не все досконально читают условия работы DX и понимают разницу между WSJT-X Fox DXpedition и MSHV multislot, что неизбежно будет приводить к излишним помехам.

Еще одна особенность режимов WSJT-X Fox DXpedition и MSHV multislot в том что протокол DXpediton четко оговаривает что QSO завершается передачей сообщения RR73 от DX, то есть сообщение 73 в сторону DX не передается. И WSJT-X и MSHV вносят QSO в лог при передаче сообщения RR73, в ранней имплементации обе программы вносили QSO в лог до трех раз, поскольку протокол DXpedition допускает двухкратное повторение сообщения RR73 если корреспондент продолжает передавать сообщение R+рапорт.

Как распознать в каком режиме работает DX на программе MSHV? Например от него декодировано 2 сообщения со сдвигом частоты кратным 60 Гц - это многослотовый режим. Либо от него декодировано специальное сообщение, в JTDX оно выглядит как два стандартных сообщения адресованных разным корреспондентам на одной частоте, одно сообщение RR73, второе сообщение рапорт: и это тоже многослотовый режим.

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

Автор программы MSHV своим подходом создал много проблем окружающим, например время потраченное на этот пост тоже результат созданной им несовместимости протоколов.

[UA3DJY]

to: UA3DJY (Несколько месяцев назад делали патч который очищал позывной из истории QSO)

Игорь, добрый день. На выходных заметил такую вещь, вызывал корреспондента несколько раз, он не ответил, провел связь с другим, и тут первый даёт ответ R -... , моя прога даёт ему RR73, он 73, и вроде всё нормально. Обратил внимание что связь сохранилась, но мой рапорт не такой как я давал, а какой рапорт давал второму кор-ту. Это из-за очистки историй QSO?

Если JTDX передал RR73 значит программа в истории QSO видит что этому корреспонденту уже было передано сообщение с рапортом. При очистке позывного из истории QSO на сообщение R+рапорт JTDX ответит сообщением R+рапорт.

[UA3DJY]

Появилась проблема. Лог не может понять или программа.

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

А в чем проблема?
PS на водопаде сплошные продукты интермодуляции сигналов, при такой перегрузке входа звуковой карты либо приемного тракта программа не будет декодировать слабые сигналы.

[UA3DJY]

Работаем в WSPR-2, JTDX 2.0.1-rc129. Весь протокол "ловим" по UDP, и аккуратно записываем. С экраном JTDX - полное соответствие. Увы, перенабивать всё с окна JTDX нет никакой возможности.

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

16:56 Decode (40M) DB7EN
16:57 Tune (30M)
17:00 Transmit (40M)
17:01 Tune (80M)
17:02 Decode (80M) M0HGU
17:03 Tune (40M)
17:04 Decode (40M) DL0PBS
17:04 Decode (40M) DD2HZ
17:04 Decode (40M) ON4PDV
17:04 Decode (40M) PE4BAS
17:05 Tune (40M)
17:06 Decode (40M) DK8JP
17:06 Decode (40M) DG7RJ
17:07 Tune (30M)

... и так далее

Вопросы:
Почему нет "16:59 Tune (40M)", если тюнинг в Band hopping включен, а следующим циклом (уже известно в 16:59) пойдет передача на 40M?
Зачем нужно "17:05 Tune (40M)", если диапазон не переключается, передача не ожидается, и просто слушается эфир - условия не изменялись вообще?
Отчего меня лишили возможности вставить картинку - снимок окна с логом, и вынуждают перенабивать всё врукопашную?

Начиная с JTDX v2.0.1-rc130 приведу void MainWindow::WSPR_scheduling () в соответствие WSJT-X 2.0.

Режим WSPR в JTDX почти не дорабатывался и был взят как есть с древней версии WSJT-X r6462, унаследованные особенности работы WSPR c WSJT-X также не будут исправляться пока идет работа c кодом FT8.

[UA3DJY]

К вопросу об использовании Split Rig/Fake It для борьбы с нечетными гармониками звукового сигнала в излучаемом спектре.

Так вот - такие цифры будут только у SDR нового поколения, в которых формирование сигнала происходит прямым синтезом ВЧ сигнала. У них нет сигнала НЧ, поэтому и не возникают гармоники

Так пишем что у трансивера SunSDR2 такого в принципе не возможно. А у меня SunSDR2Pro да же и "близко " такого быть не может. Говорил же ранее что очень внимательно и скрупузезно проверял. Меня чужие мнения интересуют постольку/поскольку ,пока сам не убедился не утверждаю.

Однозначно нельзя сказать что SunSDR2 не может создать гармоники звукового сигнала. У SunSDR2 есть аналоговый микрофонный вход, то есть потенциально можно подать на этот вход аналоговый сигнал выходящий за пределы динамического диапазона АЦП подключенного к этому входу, в результате будут нечетные гармоники.
Второй вариант - подключение звука от WSJT-X/JTDX к программе обслуживающей SunSDR2 через виртуальный звуковой кабель. Судя по документу который создал Erik EI4KF (здесь перевод на русский язык https://eesdr.com/images/Document/UMAnew_RUS.pdf) тоже существует диапазон допустимых уровней сигнала. Любой цифровой поток имеет свой динамический диапазон, для 16-ти бит динамический диапазон составляет чуть более 90 дБ. Увеличивая усиление сигнала в виртуальном кабеле можно выйти в ограничение сигнала в цифровом потоке, при таком ограничении также будут создаваться нечетные гармоники.

Если рассматривать АЦП SunSDR2 как линейный элемент то при подаче на него сигнала в рамках динамического диапазона АЦП либо при подаче цифрового сигнала в рамках динамического диапазона цифрового потока при прямом цифровом синтезе ВЧ сигнала гармоник звукового сигнала в спектре SunSDR2 не будет.

Но в случаях с классическим трансивером проблема гармоник вызвана тем что часто пользователь не понимает что он подает НЧ сигнал на модулятор (либо микрофонный тракт) выходящий за рамки динамического диапазона последнего, значит для SunSDR2 может быть такая же причина, то есть наличие трансивера с прямым цифровым синтезом еще не означает правильного использования такого трансивера.

Чем действительно отличается трансивер с прямым цифровым синтезом от аналогового трансивера так это крутизной скатов фильтра передатчика. Если подача чрезмерного уровня на аналоговый трансивер часто связана с попыткой пользователя сохранить уровень выходной мощности работая на скате фильтра передатчика то в SunSDR2 нет ската фильтра передатчика на частотах 200...600Гц.

[UA3DJY]

Началось с того, что стал замечать как JTDX мне заведомые "дупы" не помечает как B4... То показывает, то нет. Вроде выделения как B4 нет, а в LogHX3 вижу, что QSO уже было. Этой же модой, на этом же диапазоне... Недолгий анализ позволил предположить, что сама программа JTDX не виновата, причина в другом - у меня ОДИН файл wsjtx_log.adi для всех нужд, хранится он на домашнем прокси-сервере, а на клиентских машинах симлинки на него. Имхо так удобнее - неважно, на каком компьютере я вздумал поработать (да хоть и на двух сразу) - все пишется в один единственный файл, который и собирает общую статистику.

При запуске программы читается .adi файл и требуемые данные для проверки записываются в память. Дальше вся проверка происходит в памяти, к файлам на диске обращаемся только для записи. При записи новой связи требуемые данные записываются в память и ещё в несколько файлов на диске.
Поэтому если вручную или другой программой сделать изменения в .adi файле (ввести новые связи), программа их видеть не будет пока её не закроем и снова запустим.

Ну, технологически отслеживать изменения в файле лога - даже если их вносит сторонняя программа или другой логгер - не просто, а очень просто - в Кьюте есть специально для этого предназначенный класс QFileSystemWatcher. Но полагаю, эта задача для команды Игоря далеко не первостепенной важности. Юз-кейс довольно редкий.

Есть проблема отслеживания изменений в логе когда несколько одновременно работающих программ пишут QSO в один общий файл wsjtx_log.adi. Благодарю, добавил в очередь на доработку.

[LY3BG]

Еще одна особенность режимов WSJT-X Fox DXpedition и MSHV multislot в том, что в одно время передаётся несколько частот, а и из-за этого требуется высокая линейность передатчика. Если в одноканальном режиме появляются только гармоники как по НЧ, так и по ВЧ, которые при правильном подходе не сложно подавить, т.е. линейность передающего тракта не очень важна, то в многоканальном режиме возникают комбинационные частоты, попадающие в полосы фильтров. Мощность передатчика распределяется между каналами и для связи используется усилители мощности. В них тоже возникают комбинационные частоты.
Это ещё одна из причин работать в многоканальном режиме не на общепринятых частотах.

[UA3DJY]

Для пользователей с слабым CPU компьютера и пользователей кому не нравится функционал автовыбора JTDX, в версии JTDX rc130 готовим функционал AutoSeq0 c полностью отключенным автовыбором, в этом режиме пользователь будет выбирать корреспондентов вручную.

[UA3DJY]

Коллеги, посоветуйте программу для работы в FT-8 для начинающего в освоении "цифры". Пока для себя выбрал JTDX v2.0.1 .

Для начинающего пользователя наиболее проста в понимании программа WSJT-X, переход на JTDX оправдан когда пользователь уже имеет опыт работы в FT8 и хочет добиться более высокой чувствительности и эффективности декодирования, также JTDX дает ряд сервисов делающих работу в эфире более удобной и комфортной.

[R6LCF]

У SunSDR2 есть аналоговый микрофонный вход, то есть потенциально можно подать на этот вход аналоговый сигнал выходящий за пределы динамического диапазона АЦП подключенного к этому входу, в результате будут нечетные гармоники.

Микрофонных входов 3. Эл.микрофон ,динамический микрофон и от микрофона компа или от линейного выхода звуковой карты компа. Все верно.
Я честно не думаю что кому то придет в голову подключить программу цифровых мод через указанные входа. Через виртуальный кабель VAC ,сом порта через com0com .Кто то подключает через VSPE ,у меня на W10Pro 64bit не работало. У кого Лог через TCI то вообще мгновенно ,а если наши и звук по TCI сделают ,ну тогда.......вообще.
Теоретически все возможно ,а практически все на отлично ,проверяем постоянно!
В результате очень мощный комп. чувствительный,низкошумящий с отличными фильтрами приемник,чувствительная отлично работающая программа JTDX только и успевай проводить связи которые хочешь и получай удовольствие.
Игорь ,а вам большое спасибо за отлично работающую программу!

[R0JF]

Уважаемые Коллеги - Linux`оиды!

Жизненная ситуация диктует мне необходимость апгрейда до Ubuntu 18.04, в связи с чем сборки jtdx для amd64 возможно перестанут работать на более старых версиях...

Я приношу всем свои глубочайшие извинения, возможно смогу найти возможность компилить программу и под привычной Ubuntu 16.04... Прошу меня понять правильно.

Версии i386 и armhf пока буду продолжать компилить в среде 16.04.

73!

[US4IRT]

в версии JTDX rc130 готовим функционал AutoSeq0 c полностью отключенным автовыбором, в этом режиме пользователь будет выбирать корреспондентов вручную.

Так вроде бы он и так отключаемый кнопкой.

[UA3DJY]

в версии JTDX rc130 готовим функционал AutoSeq0 c полностью отключенным автовыбором, в этом режиме пользователь будет выбирать корреспондентов вручную.

Так вроде бы он и так отключаемый кнопкой.

AutoSeq в JTDX состоит из двух частей: автовыбор + автопоследовательность. AutoSeq0 будет поддерживать только автопоследовательность, эквивалент AutoSeq WSJT-X при снятой галочке Call 1st.

[RA9CUU]

уже не в первый раз при работе со спецпозывными после обмена рапортами при передаче 73 вместо моего позывного подставляется другой, не мой позывной. Версия JTDX 109RU. При связи с R120MG прощался уже не я, а JA3BXF. Подскажите что у меня не так в настройках