JT65-HF

[R6LCF]

Подтверждаю,нужно удалять начисто

Читаю ,у меня подобные проблемы отсутствуют полностью. Первоначально удалял полностью ,каждую версию сторонней программой с чисткой в реестре,были проблемы с стыковкой UR5EQF_Log.Виталий UA3ALE подсказал, что удалять только Uninstall в самой программе,что и делаю.Тестирую все версии WSJT-x последовательно,проблем никаких.Как то так!

[RK4LWA]

у меня при erasuree pattern 8, agressive 5, robust sync off для 6256 вышло 853 декодированных из 1000 с -24 децибелами

[R6LCF]

сравнение декодирования r6266 c r6229

Только что вернулся на версию r6229 с r6266 попробую у себя!

[UA3DJY]

пост #9045 редактировал - читайте еще раз внимательно

[UA3DJY]

пост #9045 редактировал - читайте еще раз внимательно

только что получил ответ от разработчиков что они проводят пошаговые работы по изменению codeword acceptance logic (логика принятия кодовых слов) и что ближайших релизах может наблюдаться очередное ухудшение работы декодера до тех пор пока эти работы не будут закончены.

[R6LCF]

только что получил ответ от разработчиков что они проводят пошаговые работы

Спасибо за сообщение.Теперь, более-менее , понятно !

[UA3DJY]

после продолжительной дискуссии с разработчиками и чтения документа на протокол JT65 выяснил следующее:

- произвольные сообщения пользователя не кодируются и к ним не применяется математика устранения ошибок (forward error correction)

- стандартные сообщения: рапорт, RRR и 73 передаются специальными последовательностями на выделенных для этого частотах и имеют повышенную защиту от помех/ошибок. В стандартных сообщения позывные и grid локаторы кодируются, после чего применяется математика устранения ошибок. Резервирование по бинарной длине составляет 5.25 раза что могло бы быть эквивалентно пятикратной передаче сообщения за интервал, но математика дает намного лучшее исправление ошибок чем дала бы повторная передача.

В итоге стандартные сообщения имеют намного большую помехозащищенность чем произвольные сообщения пользователя, а значит и намного больше вероятность правильного их декодирования.

Протокол в варианте когда пользователь проводит QSO после своего CQ предусматривает передачу RRR как сообщения которое завершает QSO и передавать после RRR еще дополнительно сообщение 73 является нарушением принятых правил проведения QSO(главная проблема в увеличении интерференции на диапазоне из-за ненужной дополнительной передачи сообщения).

Поскольку пользователи очень часто передав RRR еще в дополнение передают 73 я попросил разработчиков рассмотреть возможность изменения кода следующим образом:

- на кнопке вместо надписи RRR надпись R73
- при нажатии кнопки R73 на передачу формируется сообщение RRR
- при получении сообщения RRR оно после декодирования заменяется на экране пользователя на R73

В этом варианте есть недостаток несовместимости с софтом JT65-HF, но думаю что достоинства превысят этот недостаток и надеюсь что разработчики WSJT-X согласятся с этим предложением.

[UA3DJY]

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

Теперь простой пример - в окошке появилось сообщение CQ от редкой станции. Все дружно кликают на него и начинают звать на одной и той же частоте.

Количество зовущих может быть более 10 станций - в результате софт корреспондента не может прочитать последовательность синхронизации, все сигналы слились в один на частоте вектора синхронизации.

В таких случаях я часто для вызова смещаюсь чуть ниже по частоте, примерно 10..15 процентов от ширины JT65 спектра и в большинстве случаев первым получаю ответ редкой станции.

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

Потеря вектора синхронизации основная причина малого количества декодирований при уровнях сигнала -28..-30дБ.

[UA3DJY]

все что происходит в проекте можно кратко увидеть здесь WSJT Activity

[UA3DJY]

Потеря вектора синхронизации основная причина малого количества декодирований при уровнях сигнала -28..-30дБ.

спросил разработчиков о возможности поднять уровень вектора синхронизации на 3 дБ над уровнем других тонов, интересно что ответят

[UA3DJY]

после продолжительной дискуссии с разработчиками и чтения документа на протокол JT65 выяснил следующее:

- произвольные сообщения пользователя не кодируются и к ним не применяется математика устранения ошибок (forward error correction)

- стандартные сообщения: рапорт, RRR и 73 передаются специальными последовательностями на выделенных для этого частотах и имеют повышенную защиту от помех/ошибок. В стандартных сообщения позывные и grid локаторы кодируются, после чего применяется математика устранения ошибок. Резервирование по бинарной длине составляет 5.25 раза что могло бы быть эквивалентно пятикратной передаче сообщения за интервал, но математика дает намного лучшее исправление ошибок чем дала бы повторная передача.

В итоге стандартные сообщения имеют намного большую помехозащищенность чем произвольные сообщения пользователя, а значит и намного больше вероятность правильного их декодирования.

Протокол в варианте когда пользователь проводит QSO после своего CQ предусматривает передачу RRR как сообщения которое завершает QSO и передавать после RRR еще дополнительно сообщение 73 является нарушением принятых правил проведения QSO(главная проблема в увеличении интерференции на диапазоне из-за ненужной дополнительной передачи сообщения).

Поскольку пользователи очень часто передав RRR еще в дополнение передают 73 я попросил разработчиков рассмотреть возможность изменения кода следующим образом:

- на кнопке вместо надписи RRR надпись R73
- при нажатии кнопки R73 на передачу формируется сообщение RRR
- при получении сообщения RRR оно после декодирования заменяется на экране пользователя на R73

В этом варианте есть недостаток несовместимости с софтом JT65-HF, но думаю что достоинства превысят этот недостаток и надеюсь что разработчики WSJT-X согласятся с этим предложением.

разработчики меня поправили - для КВ компрессия и математика исправления ошибок используются во всех сообщениях
дополнительная помехозащищенность коротких стандартных сообщений работает только для УКВ

Стандартные полные сообщения имеют больший уровень компрессии (за счет части пространства неиспользуемой области позывных) и поэтому позволяют скомпоновать более 13 символов в одно сообщение.
Нестандартные, они же пользовательские сообщения, ограничены 13-ю символами.

> As RR73 in the free message box has lack of compression and forward
> error correction
Hi Igor,

that is not correct. All messages in the HF implementation of WSJT-X
have the same degree of FEC and some compression mechanism. The
compression is higher with the standard form messages because the
components are treated specially, this does not change the probability
of their being decoded it simply allows more that 13 characters to be
encoded within the constraints of the fixed standard message forms.

In the VHF & up mode JT65 short codes may be selected and that causes
special tone patterns to be used that do have a higher probability of
being decoded from shorter incomplete periods of reception.

[RA0ZIJ]

завтра на твоём рассвете, спишемся о частоте тут

Сейчас вызываю 3.576 even + 500

[UA3DJY]

Потеря вектора синхронизации основная причина малого количества декодирований при уровнях сигнала -28..-30дБ.

спросил разработчиков о возможности поднять уровень вектора синхронизации на 3 дБ над уровнем других тонов, интересно что ответят

ответ Joe K1JT ниже, если кратко то на КВ смысла поднимать мощность нет, а на УКВ усилители и так в насыщение народ загоняет.
Опубликованный документ на JT протокол написан в основном для УКВ.

Получается что если на КВ диапазоне только дальнее прохождение то основная проблема в замираниях сигнала, если появляется ближнее то основная проблема интерференция. Первая частично лечится пространственным разносом антенн, вторая - узкой диаграммой направленности.


As far as I know your principal interest in JT65 is its use at HF.
Failures to decode JT65 signals at HF seldom have anything to do with
failure to synchronize. Indeed, at HF it would be better to have a
*smaller* (definitely NOT a larger) fraction of total Tx energy devoted
to the synchronization task.

The JT65 protocol document
http://physics.princeton.edu/pulsar/K1JT/JT65.pdf is mainly focused on
the EME path. Most amateurs doing EME run high power, with PAs running
at or near saturation. Nobody would choose to transmit their sync tones
at larger power than used for the message's information content.

-- 73, Joe, K1JT

[RX4CD]

TO UA3DJY
Игорь, попросите разработчиков в следующих версиях сделать возможность передвижения курсора на водопаде при помощи колесика на мышке.

[UA3ALE]

TO UA3DJY
Игорь, попросите разработчиков в следующих версиях сделать возможность передвижения курсора на водопаде при помощи колесика на мышке.

А для чего,стесняюсь спросить!