JT65-HF

[EW1CL]

Появился вопрос - от какого базового уровня отсчитывается уровень принимаемого сигнала JT65?
И почему уровень сигнала не имеет положительных значение, а только отрицательные?

[RX4CD]

Ну и напоследок самое интересное: по результатам моделирования hinted-decode matched-filter алгоритм дает выигрыш в чувствительности по сравнению с FTRSD более 3 дБ.

Спасибо за новость, но ... какой смысл использовать такую чувствительную программу, когда рядом по частоте стоит "бульдозер" на 200-500 ватт с комбинационными составляющими в полосе его сигнала на 100Кгц! Даже с отключенной АРУ кроме него никто не декодируется.
P.S. Народная мудрость - "Достался дураку хрустальный ....й, а он им орехи колет!"

[RK1NA]

И почему уровень сигнала не имеет положительных значение, а только отрицательные?

Имеет.
К сожалению всё чаще.
Но это плохой тон.
В JT не следует "мощщу" гнать.
"От какого уровня" наверное коллеги лучше меня объяснят.

[RW3DY]

В JT не следует "мощщу" гнать.

+100500

[UA3DJY]

Появился вопрос - от какого базового уровня отсчитывается уровень принимаемого сигнала JT65?
И почему уровень сигнала не имеет положительных значение, а только отрицательные?

Где то видел упоминание что к шуму в полосе 2500 Гц (шум измеряется последние 10 секунд интервала в отсутствии сигналов станций)

Но думаю что на самом деле шум измеряется в полосе задаваемой значением bins/pixel на окошке водопада(этим же параметром определяется полоса в которой декодируются сигналы).

Положительных значений, в отличие от JT9, нет по двум причинам:

1. мода JT65A была изначально создана для работы на УКВ (EME и через Луну) где значений выше -01 не бывает
2. Компрессия сигнала в JT65 настолько сложна что сейчас внести изменение с положительными уровнями в JT65 приведет к переделке не только протокола JT65 но и большой части софта

Мода JT9 создана для КВ, в ней, в отличие от JT65A, протокол разработан с запасом и реализованы уровни сигнал/шум до +50

Так что увы, JT65A - наследственность и тяжкий груз совместимости с УКВ.

[UA3DJY]

Эта отдельно запускаемая программка есть у каждого кто использует WSJT-X и позволяет показать для любого сообщения следующее:

1. Тип сообщения (стандартное, префикс первого типа, префикс второго типа, свободный текст, короткое сообщение(УКВ))
2. В каком виде конкретное сообщение будет передано в эфир и декодировано у Вашего корреспондента.
3. Сообщение после компрессии (упакованное) в шести-битных символах
4. Сообщение в символах на радиочастоте (в тонах)

Например сообщение K1ABC UA3DJY RR73 является стандартным сообщением, потому что RR73 распознается софтом как грид локатор.

А сообщение UA3DJY JA1ZZZ RR88 будет передаваться софтом как 3D2/UA3DJY JA1ZZZ потому что часть грид локаторов находящихся возле Северного полюса Земли зарезервирована под компрессию дробных префиксов в протоколе JT65/софте WSJT-X. Сами грид локаторы в протоколе JT65 тоже не передаются отдельной частью сообщения - они компрессируются в неиспользуемую область позывных сигналов, применение компрессии связано с ограничением длины сообщения поддерживаемой протоколом JT65 - длина упакованного сообщения всегда будет равна 12 символам.

Короткие сообщения RO, RRR, 73 используются исключительно на УКВ.

Прикладываю файлик с примерами использования этой программки.

[RC2SC]

Но думаю что на самом деле шум измеряется в полосе задаваемой значением bins/pixel на окошке водопада(этим же параметром определяется полоса в которой декодируются сигналы).

Да вроде тоже как что то помню что не более 2500-2600 Гц. А водопад он живёт своей жизнью от программы и об этом писали тоже. А полоса не более 4,5-5 кГц (тоже по памяти, надо искать) в которой декодирует не в зависимости от того как широко растяните водопад.
Нашёл, до 5 кГц.

[UA3DJY]

А водопад он живёт своей жизнью от программы и об этом писали тоже. А полоса не более 4,5-5 кГц (тоже по памяти, надо искать) в которой декодирует не в зависимости от того как широко растяните водопад.
Нашёл, до 5 кГц.

проверил тестированием в r6322 - декодируются сигналы исключительно в полосе задаваемой bins/pixel на водопаде, об этом тоже писал пару месяцев назад.

Правильная установка bins/pixel критична для приема JT9 в смешанном JT65/JT9 режиме

[RC2SC]

проверил тестированием в r6322 - декодируются сигналы исключительно в полосе задаваемой bins/pixel на водопаде, об этом тоже писал пару месяцев назад.

Я не писал что не будет декодировать. Я писал что если поставить широкий фильтр, bins/pixel до 12 кГц, будет отображать только до 5. А про свою жизнь это то что не зависимо от того какую чувствительность и окраску водопада вы не сделаете программе это по барабану, не влияет.
Такое ощущение что сам с собой разговариваю.
Критична установка синего маркера.
Игорь когда займёшься переводом User Guide? В PDF есть возможность перевести с картинками?
Думал тысячу раз но руки не из того места.
Сделаешь, в ноженьки поклонюсь.

[RC2SC]

проверил тестированием в r6322

Кстати, JT65 декодирует по всему водопаду или только где маркер стоит?

[UA3DJY]

Я не писал что не будет декодировать. Я писал что если поставить широкий фильтр, bins/pixel до 12 кГц, будет отображать только до 5. А про свою жизнь это то что не зависимо от того какую чувствительность и окраску водопада вы не сделаете программе это по барабану, не влияет.
Такое ощущение что сам с собой разговариваю.
Критична установка синего маркера.
Игорь когда займёшься переводом User Guide? В PDF есть возможность перевести с картинками?
Думал тысячу раз но руки не из того места.

вот более детально:

кроме bins/pixel на декодирование влияет размер окошка водопада(как ни парадоксально это звучит), если окошко сделать коротким то и декодирование будет только в той полосе которую глазами видно на окошке.

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

По размеру окошка водопада и bins/pixel похоже на дефект, отзовитесь пожалуйста кто еще у себя наблюдает ограничение декодирования размером окошка при значениях bins/pixel = 1...3 ? Напишу разработчикам запрос.

[RC2SC]

кроме bins/pixel на декодирование влияет размер окошка водопада(как ни парадоксально это звучит), если окошко сделать коротким то и декодирование будет только в той полосе которую глазами видно на окошке.

Но ведь оно тянется и это не беда разработчиков что у пользователя задано малое разрешение экрана и не широкий монитор.
А с User Guide главное начать а там можно и дополнить и исправить. Почему бы, хотя бы от руководства для версии 1.7.0 не оттолкнутся.

[UA3DJY]

Кстати, JT65 декодирует по всему водопаду или только где маркер стоит?

JT65 по опыту декодируется и до и после маркера разделяющего JT65 и JT9, а вот JT9 строго - только после маркера.

Но сейчас настолько быстро меняется код программы что мой опыт уже может отличаться от действительности.

Логика маркера в том чтобы уменьшить нагрузку на процессор - если загнать маркер границы диапазона JT9 в ноль то все помехи с JT65 участка будут рассматриваться на кандидатов JT9, в итоге ощутимо возрастает время декодирования и даже может сработать-истечь Pano таймер еще до декодирования правильного JT9 участка.

Я у себя маркер нижней границы JT9 ставлю на 2400 - чтобы учесть возможную разницу калибровки частоты разных трансиверов, для снижения вероятности потери JT9 декодирования в начале JT9 участка из-за разницы частоты трансивера корреспондента.

[RC2SC]

JT65 по опыту декодируется и до и после маркера разделяющего JT65 и JT9, а вот JT9 строго - только после маркера.

Ты меня опять не понял. Спрашиваю, JT65 в версии 6322 декодируется только там где зелёный маркер или везде?

[UA3DJY]

А с User Guide главное начать а там можно и дополнить и исправить. Почему бы, хотя бы от руководства для версии 1.7.0 не оттолкнутся.

Его еще не существует, обычно создают экспромтом к моменту выхода -rc. А руководство 1.6 уже безнадежно устарело.

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

Параллельно приходится ликвидировать безграмотность в C++ и Fortran, ставить и разбираться - кучу сопутствующего софта, пока хватает чем заняться