Мне в ФТ8 отвечают -17, -18 на близкие станции на хорошие антенны.
Добрый день всем!
Друзья, может кто подскажет как, или где прочитать по JTDX.
До вчерашнего дня не обращал внимания, что станции, с которыми отработал не отображаются в окне приема. Дело в том, что со станциями R105DA можно работать с разными операторами, а позывной один... Один раз сработал и все, больше я его не вижу..., хотя на водопаде вижу. Все галки в установках поснимал с повторных QSO и сообщений. То же самое произошло с соседом, когда с ним проверяли настройки его станции. Провел тестовую связь с ним, уровень +16. Потом решили еще раз провести с ним связь но пока не выбросил из файла лога, больше его и не увидел. Что у меня не так настроено, или в чем дело...
Работаю в связке TS590...UR5EQF...WSJTInterfase... JTDX V1.45
Видимо ещё эта галка осталась:
Спасибо Борис! век живи, век учись...
Вопрос по плохому качеству TX сигнала на диапазоне 160м, на других диапазонах проблем нет, на 160м осциллограф у оператора показывает такую картинку:
Вопрос имеет общий интерес, публикую ответ:Можно только добавить что низкочастотные ферритовые кольца далеко не всегда работают эффективно по нескольким причинам: необходимо ставить дроссель на кольце рядом с пучностью синфазного ВЧ тока чтобы он эффективно подавлял синфазные токи (делитель сопротивления), потери вносимые дросселем на ферритовом кольце зависят от материала кольца, паразитных резонансов обмотки и диапазона частот на котором применяется кольцо. По этим причинам оказавшиеся под рукой кольца установленные рядом с трансивером да еще и с произвольным количеством витков помогают редко.Цитата:
Сигнал на осциллографе не должен иметь какой либо огибающей, передатчик должен излучать чистую несущую.
То что Вы наблюдаете на экране осциллографа скорее всего является следствием режима насыщения НЧ каскадов трансивера из-за синфазной помехи создаваемой реактивным полем Вашей антенны.
На водопаде программы принимающие Ваш сигнал операторы будут видеть кроме основного сигнала побочные излучения, обычно с шагом 100 Гц реже 50 Гц по сторонам основного сигнала.
Вот хорошие документы по устранению синфазной ВЧ наводки, задача непростая и возможно потребует от Вас нескольких дней для ее решения:
http://audiosystemsgroup.com/RFI-Ham.pdf
http://audiosystemsgroup.com/AES-RFI-SF08.pdf
Последний месяц вижу высокую активность в проекте Hamlib связанную с предстоящим выпуском Hamlib 4.0 и огромную работу над кодом которую выполняет Michael W9MDB и другие участники команды этого проекта.
Все еще приходят письма с предположением что RRR сообщение более надежно и лучше декодируется чем RR73 сообщение, с просьбой автоматически менять сообщение RR73 на RRR если корреспондент не декодирует первое. Решил провести дополнительные тесты.
FT8 сигналы декодируются с использованием AP масок в программе WSJT-X 2.1.2
Используются симулированные звуковые wav файлы, в каждом один сигнал с -23дБ SNR, всего 1000 файлов/сигналов на каждый тест.
Процент декодированных сигналов:
43.7% AA1AAA BB1BBB RRR
43.9% AA1AAA BB1BBB RR73
45.2% CC1CCC DD1DDD RRR
44.2% CC1CCC DD1DDD RR73
43.2% EE1EEE FF1FFF RRR
40.6% EE1EEE FF1FFF RR73
42.7% GG1GGG HH1HHH RRR
44.8% GG1GGG HH1HHH RR73
Тесты показывают что в среднем вероятность декодирования сообщений RRR и RR73 одинакова.
Вероятность декодирования последовательной пары сообщений RRR+73 определяется произведением вероятности каждого из этих сообщений, например при вероятности для каждого типа сообщения в 40% вероятность декодирования последовательной пары сообщений будет равна 0.4*0.4= 16%
Сейчас примерно 3.5% операторов используют при проведении QSO последовательность (RRR+73) https://forum.qrz.ru/377-jt65-jt9-ws...ml#post1635612
проведение QSO с ними на слабых сигналах превращается в настоящее испытание :)
Я думаю, что эти писатели имеют ввиду не само качество декодирования, а многократное подтверждение обоюдного приёма сигналов. Ну и попутно с этим страдают от того, что не могут похвастаться своим шеком. (рассказать об этом можно, разместив информацию в station information и включив Enable PSK reporting или на худой конец в LogEQSLComments)
А кстати, почему в последнее время участились многократные передачи рапортов с изменяющимися dB? Раз уровень разный, значит принимают - а почему не подтверждают RRR или RR73? Какая-то из 3-х программ глючит или тоже не уверены в надёжности связи?
Здесь можно посмотреть все изменения выполняемые в Hamlib https://github.com/Hamlib/Hamlib/com...a1802018b4af5e