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

**UA3DJY** · 14.01.2019, 09:49

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

Поддерживаю проблему!!! Именно проблему! Приходится почти каждое QSO заканчивать вручную, хотя режим авто... Я понимаю начинать QSO вручную, что бы не было непрерывного цикла, но "умная концовка" из WSJT-X была бы очень в тему!

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

**RV9CX** · 14.01.2019, 10:16

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

Здесь отмечен факт использования сырого тестового софта WSJT-X для работы в экспедиции TY7C в еще не законченном режиме Fox DXpedition, отличилась та же команда операторов F6KOP

хочу сказать, что с TY7C у меня была первая ЩСО в режиме FOX. Так вот, прежде чем ее провести, пришлось ставить новую WSJT. Потом мы с RW5C потренировались проводить ЩСО меж собой, все стало понятно. Однако, когда на 160 работали с TY7C, то я оказался в логе, а RW5C - нет. Похоже, у них там в Королевстве свои правила)

**UA3DJY** · 14.01.2019, 10:38

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

хочу сказать, что с TY7C у меня была первая ЩСО в режиме FOX. Так вот, прежде чем ее провести, пришлось ставить новую WSJT. Потом мы с RW5C потренировались проводить ЩСО меж собой, все стало понятно. Однако, когда на 160 работали с TY7C, то я оказался в логе, а RW5C - нет. Похоже, у них там в Королевстве свои правила)

Скорее всего это был сбой в работе функционала DXpedition, на тот момент он был в самой начальной стадии разработки/тестирования и Joe K1JT тогда просил не использовать программу для работы в эфире, были специально назначены окна тестирования.

**UA1OMZ** · 14.01.2019, 10:40

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

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

Спасибо, Игорь. Возможно ли сделать в режиме autoseq1 отключение Enable Tx при получении RRR или RR73 сразу после одной своей ответной передачи?

**RX3ASP** · 14.01.2019, 11:04

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

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

Тем не менее есть некоторые неприятные моменты именно с последовательностью декодирования и ответных сообщений. Да, это из-за старых или плохо настроенных компьютеров, но таких пока очень много в эфире.
1. Передача повторных 73 из-за ожидания полного окончания декодирования. 73 должно передаваться один раз. Если надо больше 73 или что-то ещё передать, то только после вмешательства оператора.
2. Задержка передачи аудио сигнала на трансивер на некоторых многоядерных, но устаревших ПК. Если сделать один поток, то эта проблема исчезает, но декодирование становится очень медленным. Вероятно это неразрешимая проблема для владельцев слабых ПК.
3. Не явный приоритет декодирования частоты RX во время проведения QSO. WSJT декодирует в первую очередь адресованный вам вызов, а JTDX когда как. Возможно из-за этого часто на водопаде ровный сигнал, все соседи декодируются, а ваш корреспондент только со второго захода.

WSJT при обзорном декодировании широкой полосы работает однозначно хуже - меньше декодов и медленнее, но при проведении стандартного QSO как-то более предсказуемо, хотя и там есть серьёзные проблемы, например КМК преждевременная очистка DX Call.

Вчера обратил внимание, что несмотря на включенный hide dupe messages, декодируются побочные сигналы, если маркер RX на них попал случайно, а основной сигнал с более мощным уровнем блокируется.

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

Возможно ли сделать в режиме autoseq1 отключение Enable Tx при получении RRR и RR73 сразу после одной своей ответной передачи?

После RRR полагается дождаться 73, а на 73 JTDX реагирует мгновенно и адекватно, как и на ответ вашего корр. другому.

**RA3QH** · 14.01.2019, 11:06

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

Laurie VK3AMA (спонсор ресурса hamspots.net) возражает против прямого доступа к его серверу, поэтому отправка спотов только через программу JTAlert.

Просто как то непонятно работает связка...то есть споты от меня то нет...Вот сейчас идут...

Нажмите на изображение для увеличения.

Название: ScreenShot082.jpg
Просмотров: 24
Размер: 43.5 Кб
ID: 226625

**UA3DJY** · 14.01.2019, 11:13

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

Вчера обратил внимание, что несмотря на включенный hide dupe messages, декодируются побочные сигналы, если маркер RX на них попал случайно, а основной сигнал с более мощным уровнем блокируется

Звуковой файл пожалуйста, на основании диагностики исправим.

**UA1OMZ** · 14.01.2019, 11:40

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

После RRR полагается дождаться 73, а на 73 JTDX реагирует мгновенно и адекватно, как и на ответ вашего корр. другому.

Полагается? После принятия RRR проведение связи уже фактически подтверждено и она заносится в лог именно в этот момент! А вот в случае не принятия 73, программу зачем то зацикливает на повтор...?!

**RA0ZIJ** · 14.01.2019, 11:43

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

Просто как то непонятно работает связка...то есть споты от меня то нет...Вот сейчас идут...

Аналогично. JTDX .123 в связке с EQF (h) без JTAlert - последние дни вообще ничего не шло, сегодня споты появились.

**UA3DJY** · 14.01.2019, 12:05

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

Полагается? После принятия RRR проведение связи уже фактически подтверждено и она заносится в лог именно в этот момент! А вот в случае не принятия 73, программу зачем то зацикливает на повтор...?!

Связь заносится в лог при передаче сообщения RR73/73. Отсутствие декодирования может означать и 'не принятие' повторного сообщения RRR. В этом случае Ваш корреспондент не занесет QSO в лог.

**UA1OMZ** · 14.01.2019, 13:21

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

Связь заносится в лог при передаче сообщения RR73/73. Отсутствие декодирования может означать и 'не принятие' повторного сообщения RRR. В этом случае Ваш корреспондент не занесет QSO в лог.

Игорь, а как тогда это реализовано в WSJT-X и было в старых версиях JTDX, что не было повторных сообщений "73" вообще? Может ещё одну галочку? Или например в меню "настройки" - "последовательность" - "передал сообщение RR73(73)..." - минимальное значение повторов можно было бы ставить не "1", а "0", т.е. вообще без повторов!?

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

73 должно передаваться один раз. Если надо больше 73 или что-то ещё передать, то только после вмешательства оператора.

Ну а если корреспондента зациклит, на RRR или RR73, то ведь всегда можно и вручную ему передать 73?!

**US-E-12** · 14.01.2019, 13:51

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

Просто как то непонятно работает связка...то есть споты от меня то нет...Вот сейчас идут...

Ребята ещё раз ни JTDX ни WSJT-X ни MSHV и любая другая программа споты на hamspots не отправляет. Споты идут только из JTAlert. И как появляются споты от тех, кто не использует JTAlert это нужно спросить у автора, возможно мониторит какой-нибудь ресурс время от времени.

**RA3QH** · 14.01.2019, 14:17

Сообщение от US-E-12

Ребята ещё раз ни JTDX ни WSJT-X ни MSHV и любая другая программа споты на hamspots не отправляет. Споты идут только из JTAlert. И как появляются споты от тех, кто не использует JTAlert это нужно спросить у автора, возможно мониторит какой-нибудь ресурс время от времени.

Все верно Олег...споты на PSK-репортер идут,а вот как связка репортер-хамспот работает...сие тайна велика есть