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

[R0JF]

Если читать умеете ,читайте.

Вы хвастаться решили? Или "пиписьками меряться"?

Я Вам конкретно написал - "схемотехника одинаковая"! Если Вы совершенно ничего не понимаете в принципах DDC/DUC - ну тогда гордитесь, что у Вас "PRO". По-сути НИЧЕМ они не отличаются. Да, более современный АЦП. Динамика чуть выросла. ВЫ ЛИЧНО ЭТО ЗАМЕТИЛИ??? ГДЕ И КАК???

У меня SunSDR2 и SunSDR2QRP - оба прекрасные аппараты. И не сравниваю я их. Хотя, по-Вашему
мнению "разные" (на разной элементной базе).

А вообще -- оффтопик это всё! Пусть меня накажут.

[RX4HX]

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

Без обид, но Ваш консультант лет эдак на 5 (а может и на 10) отстал от жизни. То о чем Вы пишите "SDR нового поколения" - сейчас только такие и есть. Естественно об этом и речь: SDR+звуковая карта ушли в прошлое!

[R0JF]

SDR+звуковая карта ушли в прошлое!

Не совсем еще! Те же Flex-1500, Flex-3000 Flex-5000... Да и 1000-ков еще
много рабочих. Плюс - самоделки.
Разные они, SDR. "Современные" и "не очень". Вот для "не очень" FakeIt -
как раз ОЧЕНЬ актуально!

[R6LCF]

Вы хвастаться решили?

Хвастаетесь это вы когда пишите ,а сколько ...да я....да за день ....в других темах. А нам то что хвастаться,,читаем вас на параллельном форуме в теме SunSDR2 тема №5 ,вот там эти вопросы задавайте. Знаток вы наш. Успокойтесь.
А мы работали на этом замечательном аппарате и будем продолжать работать без хвастовства. Выйдет новая модель будем на ней работать аналогично ,а выйдет может не так скоро как хотелось.

[RV9CX]

Почти у всех сигнал подается на микрофонный усилитель

Нормальные люди в микрофонный вход не суют кроме микрофона ничего. Для цифры НУЖНО использовать линейный вход тогда и с перегрузками меньше вопросов будет. Но проблему гармоник при выключенном fake it не решит ни то, ни другое. Только с микрофонным входом добавится еще других проблем, о которых Вы можете и не знать, пока Вас не ткнут носом. А сейчас все меньше желания это делать, потому что все такие обидчивые, как дети.
Так что, то что Вы еще не сидите - не Ваша заслуга, а наша недоработка (С) МВД

[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 дает ряд сервисов делающих работу в эфире более удобной и комфортной.