JTDX при попытке передачи пустого сообщения выключает передачу.
Игорь, возвращаясь к вопросу об изменении передаваемого сообщения, подскажите, с какого момента (секунды) передаваемое сообщение может быть декодировано на приемной стороне? Это же не классическая мода, когда можно изменить передаваемый текст и тебя поймут. Как получившийся "цифровой винегрет" будет правильно декодирован? И вообще, корректно ли менять текст во время передачи? Какой из текстов будет декодирован, если будет?
Заметил, что при таком изменении, происходит всплеск мощности на выходе трансивера.
Зависит от ряда факторов: SNR, распределение QSB сигнала по интервалу, распределение помех по интервалу, момента изменения сообщения в интервале. В JTDX много декодеров и при нескольких проходах декодирования крайне редко мне сообщали что были декодированы оба сообщения.
Первая часть передаваемого сообщения в LDPC идет в открытом виде и более уязвима чем вторая часть сообщения, поэтому при смене сообщения во время передачи обычно декодируется последнее сообщение.
- - - Добавлено - - -
Подключение нескольких программ к одному источнику звука.
Несколько дней работы над диагностикой аудио потока дали результат: при мультиплексировании одного источника звука на несколько нагрузок, например при использовании одного виртуального кабеля на нескольких одновременно работающих JTDX/WSJT-X операционная система теряет часть звуковых фреймов, то есть на каждую нагрузку идет отличающийся набор звуковых фреймов.
Если необходимо выжать максимум возможностей с JTDX то используйте отдельное звуковое устройство, при этом проверяйте что в операционной системе это устройство не назначено звуковым устройством по умолчанию либо устройством связи по умолчанию.
При потере звуковых фреймов прыгает DT сигналов подаваемых на декодер, значит в JTDX отключается декодер на согласованных фильтрах и в результате резко падает чувствительность FT8 декодера для сообщений QSO.
При использовании VAC проблема более заметна, потому что VAC тоже нагружает процессор.
Проблема связана с непониманием работы операционной системы и похожа на проблему одновременного использования последовательного COM порта несколькими программами.
Задаю вопрос по интересующей меня теме.
Последнее время довольно часто на мой вызов кого то.....ответный рапорт повторяется два раза! Один раз подобное это случайность, десятки и более раз это система.В чем причина? Сами делают так или программа устанавливает количество ответных рапортов и зачем все это?
Почему был выбран этот корреспондент...чисто случайно ,связь небольшой мощностью.
А где взять переведенную последнюю версию WSJT-X?
Просить Владимира R5WM.
- - - Добавлено - - -
Сегодня утром было не плохое прохождение на Северную Америку. Поработал с 5:30 до 7:00 Мск. Провёл 51 QSO в основном на CQ NA. Программа rc150 отработала в целом ни плохо, но были и "закидоны", которые портят общую картину. Были периоды когда на направленный вызов на NA отвечали сразу несколько станций из США и Канады, но программа игнорируя всех продолжала молотить CQ. Видимо "растерялась" от неожиданности. Связи пришлось проводить в ручную. И ещё "запоздалых" корреспондентов, т.е. кто решил ответить через несколько периодов, тоже бывало игнорила в полный рост, но про это здесь писали. Но это было не всегда и отчего зависит не знаю. AutoSeq ставил и 1, и 2, хрен один. Пока откатился на 149. Обкатать толком 149 у меня не было возможности.
Насчет загруженного диапазона согласен,например на 20м ,у меня "передачу" вставить некуда. На скрине был диапазон 10м ,станций в периоде не более десятка. Уровни большие ....и главное это уже не в первый раз ,а довольно часто. Вот и задал вопрос по заинтересовавшей меня теме.Может что то новое ввели. Сейчас время десятки ,поэтому на другие диапазоны не ходок. Ну это временно.
А разве не может быть такой ситуации когда вместе с вами работает еще одна станция на вашей частоте совершенно с другим оператором, и вы одновременно вещаете создавая помеху друг другу, ваш корреспондент не принимает от вас рапорт и начинается бег по кругу. Уже замечал неоднократно если при хорошем рапорте не удается закончить связь со второй передаче, на полпути третьего цикла останавливаю передачу в подавляющем большинстве случаев ситуация как описывал выше, оперативно перехожу на свободное место, почти всегда удается получить RR73, но при последующих циклах, если до того времени ваш корреспондент на начал другую связь, но даже и в такой ситуации через пару циклов даст вам RR73. Может что то неправильно делаю, но помогает.
Мое мнение - во всем виноват "Автомат". Оператор включает работу в автоматическом режиме, а сам же, находиться рядом и занимается другими делами, иногда контролируя работу в FT8. Происходит какой-то сбой в процессе. То ли кто-то "сел" на вашу частоту и молотит CQ или зовет кого-то, то ли "бульдозер" встал рядом. Оператор видит, что автомат "завис" и вручную включает RR73. Вот и все!
Ну, а если, вам без конца дается рапорт в течении 10 и более циклов, то тут явно работа без контроля. Обычно я бросаю без сожаления и ухожу. И что интересно, автомат продолжает давать мне рапорт. Иногда до десятков минут.
Доброго времени суток всем.
Кто-нибудь настраивал связку GridTracker
https://tagloomis.com/grid-tracker/
с JTDX ?
По UDP сервер и порт выставлены в соответствии с стр. 57 мануала на GridTracker.
Но GridTracker порт 2237 никак не слушает...