Появился вопрос - от какого базового уровня отсчитывается уровень принимаемого сигнала JT65?
И почему уровень сигнала не имеет положительных значение, а только отрицательные?
Вид для печати
Появился вопрос - от какого базового уровня отсчитывается уровень принимаемого сигнала JT65?
И почему уровень сигнала не имеет положительных значение, а только отрицательные?
Спасибо за новость, но ... какой смысл использовать такую чувствительную программу, когда рядом по частоте стоит "бульдозер" на 200-500 ватт с комбинационными составляющими в полосе его сигнала на 100Кгц! Даже с отключенной АРУ кроме него никто не декодируется.Цитата:
Сообщение от UA3DJY
P.S. Народная мудрость - "Достался дураку хрустальный ....й, а он им орехи колет!"
Имеет.Цитата:
Сообщение от EW1CL
К сожалению всё чаще.
Но это плохой тон.
В JT не следует "мощщу" гнать.
"От какого уровня" наверное коллеги лучше меня объяснят.
+100500Цитата:
Сообщение от RK1NA
Где то видел упоминание что к шуму в полосе 2500 Гц (шум измеряется последние 10 секунд интервала в отсутствии сигналов станций)Цитата:
Сообщение от EW1CL
Но думаю что на самом деле шум измеряется в полосе задаваемой значением bins/pixel на окошке водопада(этим же параметром определяется полоса в которой декодируются сигналы).
Положительных значений, в отличие от JT9, нет по двум причинам:
1. мода JT65A была изначально создана для работы на УКВ (EME и через Луну) где значений выше -01 не бывает
2. Компрессия сигнала в JT65 настолько сложна что сейчас внести изменение с положительными уровнями в JT65 приведет к переделке не только протокола JT65 но и большой части софта
Мода JT9 создана для КВ, в ней, в отличие от JT65A, протокол разработан с запасом и реализованы уровни сигнал/шум до +50
Так что увы, JT65A - наследственность и тяжкий груз совместимости с УКВ.
Эта отдельно запускаемая программка есть у каждого кто использует 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 используются исключительно на УКВ.
Прикладываю файлик с примерами использования этой программки.
Да вроде тоже как что то помню что не более 2500-2600 Гц. А водопад он живёт своей жизнью от программы и об этом писали тоже. А полоса не более 4,5-5 кГц (тоже по памяти, надо искать) в которой декодирует не в зависимости от того как широко растяните водопад.Цитата:
Сообщение от UA3DJY
Нашёл, до 5 кГц.
проверил тестированием в r6322 - декодируются сигналы исключительно в полосе задаваемой bins/pixel на водопаде, об этом тоже писал пару месяцев назад.Цитата:
Сообщение от RA9XQ
Правильная установка bins/pixel критична для приема JT9 в смешанном JT65/JT9 режиме
Я не писал что не будет декодировать. Я писал что если поставить широкий фильтр, bins/pixel до 12 кГц, будет отображать только до 5. А про свою жизнь это то что не зависимо от того какую чувствительность и окраску водопада вы не сделаете программе это по барабану, не влияет.Цитата:
Сообщение от UA3DJY
Такое ощущение что сам с собой разговариваю.
Критична установка синего маркера.:smile3:
Игорь когда займёшься переводом User Guide? В PDF есть возможность перевести с картинками?
Думал тысячу раз но руки не из того места.
Сделаешь, в ноженьки поклонюсь:молись:.
Кстати, JT65 декодирует по всему водопаду или только где маркер стоит?Цитата:
Сообщение от UA3DJY
вот более детально:Цитата:
Сообщение от RA9XQ
кроме bins/pixel на декодирование влияет размер окошка водопада(как ни парадоксально это звучит), если окошко сделать коротким то и декодирование будет только в той полосе которую глазами видно на окошке.
Руководство пользователя скорее всего не соберусь переводить - то что мы обсуждаем сейчас на форуме обгоняет существующее руководство пользователя на несколько месяцев, я уже не говорю что в руководстве есть много неточностей.
По размеру окошка водопада и bins/pixel похоже на дефект, отзовитесь пожалуйста кто еще у себя наблюдает ограничение декодирования размером окошка при значениях bins/pixel = 1...3 ? Напишу разработчикам запрос.
Но ведь оно тянется и это не беда разработчиков что у пользователя задано малое разрешение экрана и не широкий монитор.Цитата:
Сообщение от UA3DJY
А с User Guide главное начать а там можно и дополнить и исправить. Почему бы, хотя бы от руководства для версии 1.7.0 не оттолкнутся.
JT65 по опыту декодируется и до и после маркера разделяющего JT65 и JT9, а вот JT9 строго - только после маркера.Цитата:
Сообщение от RA9XQ
Но сейчас настолько быстро меняется код программы что мой опыт уже может отличаться от действительности.
Логика маркера в том чтобы уменьшить нагрузку на процессор - если загнать маркер границы диапазона JT9 в ноль то все помехи с JT65 участка будут рассматриваться на кандидатов JT9, в итоге ощутимо возрастает время декодирования и даже может сработать-истечь Pano таймер еще до декодирования правильного JT9 участка.
Я у себя маркер нижней границы JT9 ставлю на 2400 - чтобы учесть возможную разницу калибровки частоты разных трансиверов, для снижения вероятности потери JT9 декодирования в начале JT9 участка из-за разницы частоты трансивера корреспондента.
Ты меня опять не понял. Спрашиваю, JT65 в версии 6322 декодируется только там где зелёный маркер или везде?Цитата:
Сообщение от UA3DJY
Его еще не существует, обычно создают экспромтом к моменту выхода -rc. А руководство 1.6 уже безнадежно устарело.Цитата:
Сообщение от RA9XQ
Если садиться за документацию то надо это делать в первую очередь в помощь разработчикам в их команде, у меня другие интересы в познании JT - больше привлекает работа декодера и алгоритмика определения кандидатов на декодирование, что не оставляет времени на документацию.
Параллельно приходится ликвидировать безграмотность в C++ и Fortran, ставить и разбираться - кучу сопутствующего софта, пока хватает чем заняться:s7: