....
Насколько имеет смысл использование ОП32 по сравнению с ОП8.
Я уже говорил здесь, что изменение прохождения может нивелировать
разницу. Может более активно использовать ОП8.
согласен
Да, 32мин многовато для прохождения - в том смысле, что или провалится посреди передачи, или не хватит всплеска для программной декодировки того, что принято
Поэтому при рваном, коротком прохождении Ор8 может легко "сделать" Ор32
А вот WSJT-15, WSJT-5|-10 врядли - там, помимо синхронизации по времени, еще мощная программа декодировки - см.ниже
Тут один ньюанс заметил в WSJTX.
При отсутствии помех, программа вроде успевает декодировать
до начала цикла передачи.
Если рядом имеется помеха, то процесс декодирования
затягивается секунд на 10 после начала цикла передачи.
Может ресурса требует больше ?
Я раньше никогда не работал в WSJT, а тут решил полистать manual и нашел кусок как декодируется принятое.
Оказалось, что на русском есть - хоть и для WSJT6, но думаю, что здесь такое-же
Так вот кусок:
Декодер JT65 использует многоуровневую процедуру. Полное описание его работы приведено здесь: http://pulsar.princeton.edu/~joe/K1JT/JT65.pdf. Если декодер Рида-Соломона не дает результата, применяется декодер «глубокого поиска», основанный на принципе фильтра совпадений. Декодер составляет список гипотетических сообщений, комбинируя позывные из базы данных с “CQ” и позывным пользователя программы. Каждое возможное сообщение кодируется так, как это сделала бы передающая сторона, включая все символы, необходимые для FEC (прямой коррекции ошибок). Полученные сообщения затем проверяются на хорошее совпадение с принятым сигналом. При несовпадении даже одного символа декодирование считается неуспешным. Вы можете задать список возможных позывных, какой Вам требуется. Стандартная база данных с именем CALL3.TXT поставляется с WSJT, содержит более 4800 позывных станций, активно работающих с DX на диапазонах VHF/UHF. Настоятельно рекомендуется Ваш список позывных периодически обновлять и адаптировать его под свои нужды.
В дополнение к DT и DF, строки декодированного текста содержат информацию об относительном уровне синхронизации, среднем соотношении сигнал/шум в дБ (относительно мощности шумов в полосе 2500 Гц), и W, измеренной ширине полосы синхросигнала, в Гц. Символ, следующий за W, показывает, что был получен достаточный уровень синхронизации: * будет напечатана для обычных сообщений, # для сообщений, содержащих рапорт ООО. В конце каждой строки есть два числа. Первое число показывает, был ли получен результат декодером
Рида-Соломона, 0 – не получен, 1 – получен. Второе число показывает относительный уровень достоверности в шкале от 0 до 10 для результата, полученного декодером «глубокого поиска». В строках с декодированными
короткими сообщениями эти числа отсутствуют
Если сигнал JT65 правильно засинхронизировался, информация о его спектре добавляется в накапливающий массив. Информация от последующих передач, добавляемая в массив, может позволить декодировать это «усредненное»
сообщение, даже если отдельные передачи не декодировались. Результат такого декодирования появляется в окне усредненного текста.
Декодер «глубокого поиска» JT65 обязательно имеет «серую зону», когда он нашел результат, но достоверность этого результата невелика. В таких случаях декодер добавляет “?” в строку декодированного текста, и окончательное
решение о правдоподобности этого декодирования должен принять оператор.
Имейте ввиду, что из-за специальной математической структуры сообщения, результат неправильного декодирования не будет отличаться от правильного несколькими символами, скорее всего в нем будут совсем не те позывные и
локаторы. Когда у Вас появится опыт распознавания графических и числовых признаков правильной синхронизации сигнала (Sync, dB, DT, DF, W, и вид зеленой, красной и голубой кривых), а также влияния несущих и других помех, Вы
станете экспертом в распознавании и отбрасывании результатов случайных ложных декодирований. Если Вы видите, что Вас неожиданно зовет экзотическая станция, подождите, пока декодируете ее сообщение в следующей передаче.
Случайные ошибки декодирования повторяются редко
я давно собирался спросить что там за цифры и декоде-то...
Так вот надо CALL3.TXT делать ?
Может длительное декодирование можно уменьшить своей "базой данных" в виде call3.txt?
набросал немного нашего
DF6NM,JN59,,,
DK7FC,JN49,,,
G8HUH,IO81,,,
R7NT,KN97,,,
RN3AUS,KO86,,,
RV3APM,KO86,,,
RX3QFM,KO91,,,
UA0AET,NO65,,,
UA4WPF,LO66,,,
UW8SM,KN28,,,
W1TAG,FN43,,,
W1VD,FN31,,,
Можете глянуть оригинальный ихний - не понятно с множеством ,,,,, в конце - может там еще чего можно добавить?
теперь понятнее стали полные строчки
2210 10 -25 0.9 1120.53 0 UA0AET UA4WPF RRR RN3AGC
2150 2 -37 2.2 1120.25 0 UA0AET UA4WPF -33 UA0SNV
2130 1 -36 0.4 1134.97 0 DF6NM JN59NJ UW8SM
