Like Tree15934Спасибо

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

  1. #15631
    Модератор
    Регистрация
    05.03.2015
    Сообщений
    5,064
    Поблагодарили
    7445
    Поблагодарил
    752
    Цитата Сообщение от RW3AH Посмотреть сообщение
    И снова странности 2 версии JTDX.
    Несколько раз прога дает "RR73" японцу, а в это время смотрю, что RX3DTN дает мне тоже RR73, хотя QSO с ним не было (!)
    Тоже самое с другим корреспондентом. Пробовал стереть данные, но прога настойчиво возвращается к япу и дает ему все те же "RR73" даже после ручного перехода на CQ.
    Пришлось перезагрузить прогу по новой.
    Это явный глюк и что-то с алгоритмами.73
    В JTDX есть несколько триггеров автоматической очистки истории QSO, также ее можно очисть вручную правой клавишей мыши на кнопке Clear DX. Информация по работе AutoSeq JTDX есть здесь https://ru.jtdx.tech/ru-faq/28-autos...-v18-1-russian

  2. #15632
    Модератор
    Регистрация
    05.03.2015
    Сообщений
    5,064
    Поблагодарили
    7445
    Поблагодарил
    752
    Цитата Сообщение от RX3ASP Посмотреть сообщение
    20 минут назад на 20-ке все звали P5/RK4FD
    Большинство как P5/RK4FD/R, но некоторые P5/RK4FD/R/R так видно было в JTDX
    В WSJT видел как <....>, после ввода в DX Call, как <P5/RK4FD>
    К сожалению самого P5/RK4FD не принимал ни в каком формате.
    Цитата Сообщение от RX3ASP Посмотреть сообщение
    Пытался ответить на CQ EP/PH7Y , программа почему-то добавила в сообщение EP/PH7Y/P , причём не только у меня.
    /P это пират? )))
    Дефект упаковки/распаковки сообщения в JTDX 2.0.1-rc115, уже устранили в rc117, дадим в широкое тестирование предположительно завтра.
    Цитата Сообщение от RX3ASP Посмотреть сообщение
    Больше стало фантомных декодирований. И в WSJT и в JTDX 77битных
    054245 -19 0.8 860 ~ TU; 6O7OBN 0I3ZVV 569 Somalia и т.п. ерунда.
    В rc117 доработали фильтрацию ложных декодов, будут попадать на экран реже.

  3. #15633
    Модератор
    Регистрация
    05.03.2015
    Сообщений
    5,064
    Поблагодарили
    7445
    Поблагодарил
    752
    Цитата Сообщение от EU1FQ Посмотреть сообщение
    Версия 115. Если оператор передает RRR, то программа вместо 73 повторно передает мой рапорт. Приходится ручками включать 73. Если оператор передает RR73, то все нормально.
    Случай не единичный. Наблюдал во всех случаях когда оператор передавал RRR.
    Как у других?
    В лабе не могу воспроизвести, возможно сбой привязан к какой то комбинации настроек либо к INI файлу?

  4. #15634
    Экстра-класс Аватар для R5ZQ
    Регистрация
    07.09.2013
    Адрес
    Губкин
    Возраст
    57
    Сообщений
    1,024
    Поблагодарили
    321
    Поблагодарил
    59
    Цитата Сообщение от UA3VFL Посмотреть сообщение
    А вот это уже не в первый раз V 115
    Наблюдал такое и в последней американской программе.

  5. #15635
    Модератор
    Регистрация
    05.03.2015
    Сообщений
    5,064
    Поблагодарили
    7445
    Поблагодарил
    752
    Цитата Сообщение от RA1WZ Посмотреть сообщение
    Запустил одновременно обе программы от одной и той же звуковой карты. Рапорты и количество декодов отличаются в пользу WSJTX
    Сделал первичный тест эффективности декодирования FT8v2 в JTDX и заодно сравнил с WSJT-X: В режиме deep+FT8AP (Hint) JTDX на 4-х потоках декодирования дает на 7.7% больше декодированных сообщений чем WSJT-X. JTDX при переходе на новый протокол потерял часть функционала отвечающего за чувствительность и эффективность декодирования, потребуется время для того чтобы восстановить этот функционал. Пока сфокусированы на проблемах с более высоким приоритетом.

  6. #15636
    Модератор
    Регистрация
    05.03.2015
    Сообщений
    5,064
    Поблагодарили
    7445
    Поблагодарил
    752
    Цитата Сообщение от UR4UM Посмотреть сообщение
    кажется что JTDX при хорошей силе сигнала, не может декодить...
    Если поймаете такой сильный сигнал что декодирует WSJT-X и не декодирует JTDX, покажите пожалуйста звуковой файл - устраним.

  7. #15637
    Модератор
    Регистрация
    05.03.2015
    Сообщений
    5,064
    Поблагодарили
    7445
    Поблагодарил
    752
    Цитата Сообщение от RA1WZ Посмотреть сообщение
    Запустил одновременно обе программы от одной и той же звуковой карты. Рапорты и количество декодов отличаются в пользу WSJTX
    В JTDX SNR был калиброван еще для FT8v1, в WSJT-X - нет.
    Минутное дело добавить в коде JTDX смещение рапортов на 1 дБ, сразу появится много положительных отзывов о росте чувствительности на основании выводимого на экран рапорта .

  8. #15638
    Экстра-класс Аватар для RA3QH
    Регистрация
    02.04.2007
    Адрес
    п.Подлесный
    Возраст
    55
    Сообщений
    2,813
    Поблагодарили
    624
    Поблагодарил
    261
    Цитата Сообщение от UA3VFL Посмотреть сообщение
    это уже не в первый раз V 115
    Цитата Сообщение от R5ZQ Посмотреть сообщение
    Наблюдал такое и в последней американской программе.
    Про это уже не раз писали тут...эта комбинация показывает что позывной не был еще ни разу не декодирован вашей программой

  9. #15639
    Модератор
    Регистрация
    05.03.2015
    Сообщений
    5,064
    Поблагодарили
    7445
    Поблагодарил
    752
    Цитата Сообщение от RA2FI Посмотреть сообщение
    Одновременно с UA4PAY позвал UY5MU.
    Прога ответила первому, в соотв. с настройкой (max distance).
    Прошло QSO. Вызывает UY5MU с рапортом. Вместо ответного рапорта RR-?? прога дала RR73.
    QSO logged. UY5MU отвечает RR73 и вроде бы QSO состоялось, но формально нет: я рапорт не передавал.
    До этого такого ни разу не встречал.
    Цитата Сообщение от US4IRT Посмотреть сообщение
    115-я - таже картина на 160м звали два японца и оба рапортом. С первым QSO нормально, второму сразу начала давать RR73. Пришлось "втыкать" вручную" то что положено. Дальше сама "добивала".
    Дефект, был в JTDX 18.1.106 и более ранних версиях. Патч есть в 2.0.1-rc117, нам проверить сейчас нечем - придется Вам смотреть в эфире ушел ли этот сбой.

  10. #15640
    Модератор
    Регистрация
    05.03.2015
    Сообщений
    5,064
    Поблагодарили
    7445
    Поблагодарил
    752
    Цитата Сообщение от RA2FI Посмотреть сообщение
    А вот кто подскажет? JTDX. Режим "AutoTX". Устанавливаю фильтр на Европу, ну или какой другой. Естественно в окне в декодированном тексте сообщений от европейцев нет, а вот вызов "европейца" прога распознает и отвечает вызывающему.
    Т.е весь эффект фильтрации в том, что я не вижу часть "все-таки декодированных" сообщений?
    Или фильтр отменяет таки декод этих станций?
    Описание функционала фильтрации сообщений в JTDX: https://ru.jtdx.tech/ru-faq/26-filte...-v18-1-russian

  11. #15641
    Модератор
    Регистрация
    05.03.2015
    Сообщений
    5,064
    Поблагодарили
    7445
    Поблагодарил
    752
    Цитата Сообщение от RA3QDP Посмотреть сообщение
    вопрос - какое максимальное отклонение времени допустимо по протоколу этого вида связи ?
    В разных программах поддерживается разный диапазон времени захвата синхропоследовательности сигнала FT8.
    Например в WSJT-X этот диапазон находится в пределах от -1.5 до + 2.5 секунды.
    Синхропоследовательность состоит из трех одинаковых блоков по 7 тонов каждый(массив Костаса), занимает 1..7-й, 37..43-й, 73..79-й тона передаваемой последовательности сигнала.

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

    Синхропоследовательности FT8v2 и FT8v1 в указанных блоках отличаются настолько что декодер FT8v2 не будет пытаться декодировать сигнал FT8v1 и наоборот.

  12. #15642
    CQ DE: Аватар для R7CA
    Регистрация
    24.04.2007
    Адрес
    KR-40
    Сообщений
    10,635
    Поблагодарили
    3406
    Поблагодарил
    1111
    Цитата Сообщение от UA3DJY Посмотреть сообщение
    Если оператор или программа включает передачу позже начала интервала то теряется часть тонов, то есть пропущенные за счет опоздания тона не передаются
    А вот скажите... ФТ8 один раз передаёт сообщение или несколько? В jt65 вроде несколько раз..
    И что в начале сообщения мы так боимся пропустить когда передача идёт с задержкой

  13. #15643
    Модератор
    Регистрация
    05.03.2015
    Сообщений
    5,064
    Поблагодарили
    7445
    Поблагодарил
    752
    Цитата Сообщение от RX4HX Посмотреть сообщение
    Вот это мне не очень понятно - хэш, да, может совпадать для разных позывных - позывные очень короткие, вот и хэш совпадает. Но то, что это приводит к ложному декодированию... весьма удивительно.
    Допустим для позывных RX4HX и UA3ALE хэш может быть одинаковый, и если программа приняла UA3?LE и хэш, она должна по хэшу восстановить позывной UA3ALE (часть то принято!), но уж никак не RX4HX.
    Или WSJT-X/JTDX вообще целиком позывные по хэшу восстанавливает? Типа хешь есть, значит это или UA3ALE, или RX4HX.
    Целиком, при использовании в QSO одного нестандартного позывного вместо одно из позывных сообщения в эфир передается вычисленный хэш этого сообщения. Сообщение с двумя нестандартными позывными не поддерживается протоколом FT8v2, чтобы операторы с дробными или специальными позывными провели между собой QSO им придется очень постараться печатая свободные сообщения.

    Сценарий который встретил Виталий UA3ALE - он проводил QSO с таким специальным позывным и декодировал сообщение RR73, но софт поискав в оперативной памяти соответствие хэш нашел недавно бывший в эфире позывной R2AE хэш которого совпадает с хэшем позывного UA3ALE.
    В результате декодер выдал сообщение R2AE S511NNN RR73 которое AutoSeq у Виталия явно не ожидал после получения рапорта от корреспондента.

    Ассоциацию позывного с хэшем в версии протокола FT8v2 в WSJT-X перенесли в модуль упаковки/распаковки сообщений, при этом не сделали проверку на наличие позывного корреспондента с окна DX Call в этом сообщении, факта проведения QSO с этим позывным и в этом случае приоритет проверки принятого хэша с позывным пользователя программы. Результат налицо, сейчас чтобы в JTDX устранить такое поведение программы придется дублировать сравнение хэша для уже распакованного сообщения с неправильным позывным с позывным пользователя и при выполненнии указанных выше критериев подменять неправильно распакованный позывной позывным пользователя.

  14. #15644
    Модератор
    Регистрация
    05.03.2015
    Сообщений
    5,064
    Поблагодарили
    7445
    Поблагодарил
    752
    Цитата Сообщение от R7CA Посмотреть сообщение
    А вот скажите... ФТ8 один раз передаёт сообщение или несколько? В jt65 вроде несколько раз..
    И что в начале сообщения мы так боимся пропустить когда передача идёт с задержкой
    На пальцах: сообщение представляет из себя кусок информации. Этот кусок нарезается на мелкие кусочки которые определенным образом перемешиваются и компонуются в передаваемые информационные тона так что каждый информационный тон содержит кусочек каждого слова в передаваемом текстовом сообщении.
    Когда передача включается с задержкой по отношению к началу интервала то часть тонов не передается(теряется) но при этом оставшиеся тона содержат кусочки слов текстового сообщения и при определенном их количестве это сообщение можно восстановить из оставшихся тонов.

    То есть сообщение передается один раз и при этом много раз одновременно.

    Чем ниже SNR сигнала тем меньше оставшихся тонов принимается без ошибок, соответственно тем ниже вероятность восстановления сообщения. Поэтому при начале передачи вместе с началом интервала будет наилучшая синхронизация декодера с принимаемым сигналом (первые 7 тонов - 1.12 секунды относятся к синхропоследовательности сигнала, далее идут и при задержке начала передачи теряются информационные тона).

  15. #15645
    Мастер Аватар для RX3ASP
    Регистрация
    26.11.2003
    Адрес
    Москва
    Возраст
    57
    Сообщений
    657
    Поблагодарили
    210
    Поблагодарил
    48
    После обмена рапортами в JTDX получаю от корреспондента RR73, записываю QSO в LOG (или автоматом), передаю 73, перехожу на приём.
    Сигнал моего корреспондента - новое CQ или ответ другому, УЖЕ декодирован и выведен на экран!
    Но программа ждёт окончание цикла декодирования всех сигналов в полосе. Только после этого очищается DX Call и сбрасывается Enable TX.
    Зачем ждать окончания декодирования в этом случае? Если декодирования нет, тогда другое дело. В этом случае правильно было бы отключить Enable TX, но оставить DX Call - для принятия решения оператором.
    На не очень шустрых компьютерах этот процесс тянется долгие секунды. В это время включается передача повторного 73 и перебивает корреспонденту возможность принять ответ другого.
    При декодировании обычного 73, программа реагирует мгновенно.

Похожие темы

  1. JT65/JT9 - имейте совесть, когда в "цифре" работаете!
    от RX4CD в разделе JT65, JT9, WSPR, JT4, JTMSK, FT8
    Ответов: 65
    Последнее сообщение: 05.10.2019, 07:15
  2. Как начать работать с CW?
    от Z80X в разделе Телеграф
    Ответов: 6
    Последнее сообщение: 23.12.2010, 13:43
  3. Новая мода JT65
    от RX3AIS в разделе Цифровые виды радиосвязи
    Ответов: 1
    Последнее сообщение: 28.06.2007, 23:02
  4. Как начать работу с OZiExplorer 3D ?
    от RX3AOE в разделе Win-XP/7
    Ответов: 4
    Последнее сообщение: 15.10.2006, 19:55
  5. Работаю с DXtelnet но через час он отклю...
    от в разделе Компьютеры и сети
    Ответов: 0
    Последнее сообщение: 16.12.2001, 20:54

Социальные закладки

Социальные закладки

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •  
Похоже, что вы используете блокировщик рекламы :(
Форум QRZ.RU существует только за счет рекламы, поэтому мы были бы Вам благодарны если Вы внесете сайт в список исключений!
как отключить
×
Рейтинг@Mail.ru
eXTReMe Tracker
Яндекс.Метрика