сравнение декодирования r6266 c r6229
Цитата:
Сообщение от
UA3DJY
пост #9045 редактировал - читайте еще раз внимательно
только что получил ответ от разработчиков что они проводят пошаговые работы по изменению codeword acceptance logic (логика принятия кодовых слов) и что ближайших релизах может наблюдаться очередное ухудшение работы декодера до тех пор пока эти работы не будут закончены.
RRR или RR73 для завершения QSO
после продолжительной дискуссии с разработчиками и чтения документа на протокол 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 согласятся с этим предложением.
вектор синхронизации JT65
При модуляции самая нижняя частота является вектором синхронизации, на ней передается последовательность синхронизации.
При потере этого сигнала декодирование сообщения становится невозможным.
Теперь простой пример - в окошке появилось сообщение CQ от редкой станции. Все дружно кликают на него и начинают звать на одной и той же частоте.
Количество зовущих может быть более 10 станций - в результате софт корреспондента не может прочитать последовательность синхронизации, все сигналы слились в один на частоте вектора синхронизации.
В таких случаях я часто для вызова смещаюсь чуть ниже по частоте, примерно 10..15 процентов от ширины JT65 спектра и в большинстве случаев первым получаю ответ редкой станции.
Достоинство такого подхода в том что зовущие распределяются по частоте и корреспондент сможет декодировать если не всех то многих из зовущих и сделать свой выбор. Есть и недостаток, если звать немного в стороне то сообщение в софте WSJT-X не попадает в правое окошко а некоторые пользователи смотрят исключительно в правое окошко и не замечают что происходит в левом, но это уже исключение из правил.
Потеря вектора синхронизации основная причина малого количества декодирований при уровнях сигнала -28..-30дБ.
проект WSJT-X - текущая активность
все что происходит в проекте можно кратко увидеть здесь WSJT Activity
вектор синхронизации JT65
Цитата:
Сообщение от
UA3DJY
Потеря вектора синхронизации основная причина малого количества декодирований при уровнях сигнала -28..-30дБ.
спросил разработчиков о возможности поднять уровень вектора синхронизации на 3 дБ над уровнем других тонов, интересно что ответят