Именно из-за этого я вынужден менять комп в деревне ))) Хотя до сих пор он меня совершенно устраивал. Но с появлением уже JT65/JTDX пришло понимание, что в этой гонке вооружений придется участвовать. Уже из CW народ ушел - все сидят в FT8.
Вложение 202341
Моей пенсии хватит только на 1-вый процессор
Игорь нужно снижать нагрузку на компьютер!
99% съедает декодер FT8, точно так же как и в WSJT-X. Для слабых процессоров есть опция Decode->Fast, на которой декодирование будет значительно быстрее с меньшим количеством сообщений на экране.
В JTDX еще есть опция Filter позволяющая сократить количество кандидатов на декодирование, добавлена опция AutoSeq Call first.
измененный функционал:
- полоса фильтра FT8 уменьшена до 100 Гц по несущей (150 Гц по спектру декодируемых сигналов)
- выполнен опциональный функционал AutoSeq Call 1st (ответить первому вызвавшему не дожидаясь окончания декодирования интервала), предназначен для использования на медленных процессорах. Активация функционала через закладку Misc.
- добавлена возможность вызова корреспондента рапортом в режиме AutoSeq (Skip grid/TX1)
- устранен дефект показа SNR более +49 dB при использовании Filter. В изначальном коде WSJT-X применены две методики расчета SNR: для декодирования в широкой полосе и для повторного декодирования на RX частоте, есть условие при котором на ходу может быть использована другая методика расчета. Поэтому SNR при выключенном и включенном Filter может отличаться, точно так же как может отличаться SNR при повторном декодировании FT8 сигнала в WSJT-X.
- изменено управление функционалом направленного вызова в закладке 2, AutoSeq теперь должен передавать любое сообщение направленного вызова
- изменен формат времени в файле ALL.TXT на "yyyymmdd_hhmmss", совместимость с логом UR5EQF при получении данных из этого файла
- многочисленные доработки в функционале AutoSeq
собранный софт https://cloud.mail.ru/public/JgXJ/afiLFsKMt
исходный код https://cloud.mail.ru/public/MAs4/QB6oomAxX
кодовые суммы:
File name: JTDX-18.1.0.48-win32.exe
MD5: 10E1CE252CE92D0B0B53388EFE7633E8
SHA-1: 6BC89636BA249FBC04C9AA60767725715730ADB1
SHA-256: B3B64EB365DF8043CB800F435E47405D015356501E3ED050E855E868C99C9A7D
SHA-512: F2C9DB2FB44C86C83655DAEF09DD6930598C9498B3FC8FB206773B785AE517577E6FB2 47D2EFEF1893339388DB19EE0A84EF17B85B86F374B4C11F23B31567DB
RIPEMD: 5AE4981F4C96870A24917ACF30798304F10D9DB6
Изменен формат файла JTDX.INI, добавлены настройки "CallFirst", "CQdirection"
Удаление файла рекомендуется только в случае неадекватной работы софта при переходе с предыдущей версии.
Если DXpedition mode начнут использовать операторы в Европе то на диапазонах не останется DX, их накроет помехами возникающими при переходе от тона к тону при широком частотном разносе тонов и мультиплексировании во временной области в этом режиме.
Софту не будет равных, но на диапазонах настанет эпоха локального прохождения.
Уже сейчас я получаю письма от DX о том что в FT8 моде без киловатта они не могут дозваться до Европы.
Чем, таким принципиальным, отличается кодирование ft8 от psk, что требует таких ресурсов?
Помнится, в разгар psk, применяли самые наипростейшие системы с оооочень скромными параметрами. А ведь там идёт многоканальное декодирование (куча станций одновременно) и в реальном масштабе времени.
Судя по сжираемым ресурсам, ft8 должна работать ниже уровня шумов, ан нет. Нисколько, по-моему, не лучше psk, по отношению сигнал/шум.
Степенью резервирования и расстоянием между символами в коде, эффективностью сочетания алгоритма кодирования и вида модуляции, замешиванием синхропоследовательности в информационный сигнал, то есть доступной глубиной декодирования и измеряется в % декодированных сигналов при определенном SNR.
SNR рассчитывается к полосе шума 2500 Гц.
Ресурсы требуются сопоставимо с JT65, проблемы вызывает малое отведенное время на декодирование интервала, заложенное при дизайне моды FT8.
Не оценивал PSK, не могу сказать. Очень сильно зависит от скорости передачи PSK сигнала и ширины занимаемого им спектра.
Также у PSK есть огромный недостаток в высоких требованиях к линейности передающего тракта от микрофона до антенны. У тональных модуляций FSK можно держать выходной каскад усилителя мощности в ключевом режиме.
Часто можно встретить такую таблицу:
WSPR..ROSMF1.....................-31-33дБ
JT65В...................................-29-30дБ
JT-65A................................. -28дБ
CMSK63................................-21дБ
MFSK16...... ......... .......... ....-14дБ
Olivia 16/500.........................-13дБ
PSK63F...... ...... .......... ........-12дБ
PSK31....... ......... ... .............-10дБ
MFTTY (1/2 Speed)............... -6дБ
Если в пск "стрелять" такими же короткими сообщениями, по-моему скорость будет выше. И ширина там от 40 гц.
В ft8 некоторые коллеги тоже умудряются "засрать" диапазон перекаченным сигналом.
И всё таки, на мой взгляд, главное в новых протоколах должно быть способность принимать с наименьшим отношением сигнал/шум, а не возможность работы УМ в ключевом режиме.