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

**RX3ASP** · 25.02.2019, 10:28

Сообщение от UA3DJY

Декодер стартует на примерно на 14.3 секунде интервала и заканчивает декодирование на 14.7 секунде на современных процессорах, на медленных процессорах декодирование занимает примерно одну...три секунды, процессоры которые декодируют более трех секунд непригодны для работы в FT8 в широкой полосе. Добавьте к времени декодирования 2..3 секунды на принятие решения оператором и 1 секунду (Windows) на очистку буфера TX звука при смене TX сообщения.

В итоге сообщение которое пойдет на передачу не будет декодировано и будет напрасной помехой другим операторам. То есть станет четвертой (или третьей при Skip Tx1) передачей сообщения во время QSO. Теперь представьте что Вам вычитают с Вашей зарплаты 25...33 процента налог на окрас травы (создают помехи на диапазоне) объясняя тем что иначе жить неинтересно.

Проблема создана при разработке протокола FT8 (можно было сделать период 20 секунд отведя 6 секунд на декодирование и принятие решения оператором), AutoSeq это скорее попытка выжить на перегруженных диапазонах в рамках созданного протокола чем легкий путь к дипломам, тем более что далеко не все радиолюбители работающие в FT8 получают какие либо дипломы.

Нормально всё отправляется до 3-сек следующего цикла.
Ничуть не меньшую и более частую (в т.ч. на TX=RX частоте) помеху создаёт повторное 73 от владельцев медленных процессоров, но почему-то ваша команда этот вопрос принципиально игнорирует.

Может просто сделать блокировку включения ТХ начиная с 3-й секунды? Не успел? Жди следующего цикла. В конце-концов не корову проигрываем и не за зарплату QSO проводим. Скорость принятия решения о выборе с помощью глаз, головы и пальцев, это последнее, где оператор может продемонстрировать своё мастерство в FT8.

**US4IRT** · 25.02.2019, 12:29

Игорь! Мне не доходит для чего хэш нужен для обычных позывных (не выходящих за рамки "приличия")? Для нестандартных может и нужен. Сегодня очередной бред хэша - XX9D приравняло в декодах к VP8LP! Перезапуск программы помогает.

**UA1OMZ** · 25.02.2019, 13:15

Сообщение от RX3ASP

помеху создаёт повторное 73 от владельцев медленных процессоров, но почему-то ваша команда этот вопрос принципиально игнорирует.

И опять присоединяюсь... Вы и компани, так яро боретесь за свободное место в эфире и оперативное проведение связи и не убираете лишний цикл связи!? Ну сделайте вы уже один режим с ОРИГИНАЛЬНЫМ АЛГОРИТМОМ WSJT, пожалуйста?!

**K2PAL** · 25.02.2019, 16:17

Сообщение от UA1OMZ

Ну сделайте вы уже один режим с ОРИГИНАЛЬНЫМ АЛГОРИТМОМ WSJT, пожалуйста?!

Хоть я и не программист,но думаю,что это не возможно,сделать один цикл как WSJT.
Было бы здорово если бы две программы работали синхронно и программа JTDX каким то образом определяла,что чел работает на WSJT тогда она бы и закончила QSO,но это из области фантастики.

**UA1OMZ** · 25.02.2019, 16:45

Сообщение от K2PAL

это не возможно,сделать один цикл как WSJT

... один РЕЖИМ(autoseq1 by WSJT), всего лишь один режим из семи или восьми с ним...

**UA9FFV** · 25.02.2019, 16:52

Пишу потому что наболело.
Всем хороша JTDX: и при загрузке не меняет диапазон трансивера, и некоторые функции удобные заложены. Но, на мой взгляд, сильно перегружена "рюшечками". Пользуюсь v2.0.1-rc128. Стал замечать, что как-то она сбоит с последовательностями. С dx-ами стал загружать WSJT v2.0.0.
Сейчас зову ХХ9 на 40-ковке. Вдруг вижу после моего вызова в следующем цикле половина цикла идет со сдвигом частоты. Глянул на трансивер, а там 7.074.5. Затем следующая половина частота вернулась и прием закончился с частотой 7.074. "Собачий" режим был выключен. Причем это уже наблюдал второй раз.
Быстро перегрузился в JTDX и вижу, ХХ9 мне отвечает. Дал RR73 в ответ, связь вроде состоялась.
Но как-то это совсем не камильфо!!!
Понимаю, что версии уже не свежие использую. Но у меня нет уверенности, что обновление не добавит новых сюрпризов. Кажется добавление сервисов в обеих программах начало убивать их основной функционал.

**US4IRT** · 25.02.2019, 17:07

Чего то не пойму того , что проскакивает сейчас на 80м. Задержка сигнала 2.0 сек. . Это какой путь должен пройти сигнал, чтоб задержаться на 2 секунды?

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

**RX3ASP** · 25.02.2019, 17:09

Сообщение от K2PAL

Хоть я и не программист,но думаю,что это не возможно,сделать один цикл как WSJT.
Было бы здорово если бы две программы работали синхронно и программа JTDX каким то образом определяла,что чел работает на WSJT тогда она бы и закончила QSO,но это из области фантастики.

Не надо определять кто на чём работает. Если по каким-то причинам (???) требуется дождаться полного окончания декодирования всех кандидатов в полосе, то достаточно после отправки 73 в ответ на RR73 перевести программу в режим ожидания, отключив Enable TX.

**R0JF** · 25.02.2019, 17:35

Сообщение от UA9FFV

Пишу потому что наболело.
[...]
Вдруг вижу после моего вызова в следующем цикле половина цикла идет со сдвигом частоты. Глянул на трансивер, а там 7.074.5. Затем следующая половина частота вернулась и прием закончился с частотой 7.074. "Собачий" режим был выключен. Причем это уже наблюдал второй раз.

Ознакомьтесь с документацией на программу. Особенно режим fake it.

**UA9FFV** · 25.02.2019, 17:47

Сообщение от R0JF

Ознакомьтесь с документацией на программу.

Ладно, если бы не работало. А то ведь ранее постоянно с такими настройками работал и ничего.
Да и с этими версиями провел приличное число связей. Обычно не скачет частота.
Может у меня Омни Риг многопотоковый и им пользуется еще одна программа?
Придется, вероятно, мануал наконец-то почитать... ))))

**R0JF** · 25.02.2019, 18:34

Сообщение от UA9FFV

Придется, вероятно, мануал наконец-то почитать... ))))

Говорят же, что все инструкции на русском языке надо начинать фразой
"Ну, что **дак, всё-таки сломал?"

Мне кажется, у Вас просто fake it частоту дёргает (как ему и положено), а
Вы паникуете, хотя всё нормально.

**R0AX** · 25.02.2019, 18:38

вышла WSJT-X 2.0.1 WSJT Home Page

**K2PAL** · 25.02.2019, 19:28

Сообщение от RX3ASP

Не надо определять кто на чём работает. Если по каким-то причинам (???) требуется дождаться полного окончания декодирования всех кандидатов в полосе, то достаточно после отправки 73 в ответ на RR73 перевести программу в режим ожидания, отключив Enable TX.

Так это и баз вашего совета мы знаем.
Инноваций не будет, все привязано к программе WSJY-X и по этому следуем за обновлениями,a они будут всегда.
Спасибо Игорю и его команде.

**RX3ASP** · 25.02.2019, 19:49

Сообщение от K2PAL

Так это и баз вашего совета мы знаем.

Раз всё знаете, то объясните, пожалуйста - зачем JTDX ждёт полного окончания декодирования (именно полного, а не только корреспондента) RX цикла, следующего после отправки 73 в ответ на RR73?

**UA9FFV** · 25.02.2019, 19:53

Сообщение от R0JF

Мне кажется, у Вас просто fake it частоту дёргает (как ему и положено)

Игорь, как же это положено? А нафига, если я не "собака" дергать частоту.
Реально я несколько циклов смотрел ХХ9. Стабильно декодировался. Уровень был около минус 9.
После того как позвал наступил цикл приема. На водопаде вижу, что сигналы одной половины цикла относительно другой сдвинулись примерно герц на 50. И конечно в этом цикле несмотря на хороший сигнал декода не было.
РТТ идет через RTS отдельного СОМ-порта, а взаимодействие с трансивером, как я уже писал, через ОмниРиг.
...А моя программа (управление коммутатором) через Омни только считывает частоту.
Ладно, обновлю оба приложения и почитаю мануал...