с каждым днем растет количество станций на диапазонах, а значит третий проход будет выдавать больше декодированийЦитата:
Сообщение от RA3RKA
с каждым днем растет количество станций на диапазонах, а значит третий проход будет выдавать больше декодированийЦитата:
Сообщение от RA3RKA
небольшой сюрприз - значение порога может быть менее 1.0
время дано в среднем на один интервал для моего процессора, пропорция в увеличении времени применима к любому процессору
два прохода:
2.5 + 2.5 1071 декодирований, 2.5 секунды на один интервал
2.4 + 1.0 1109 декодирований, 4.8 секунды на один интервал
три прохода:
2.4 + 1.0 + 1.0 1152 декодирований, 7.4 секунды на один интервал
2.4 + 1.0 + 0.5 1154 декодирований, 9.8 секунды на один интервал
2.4 + 0.5 + 0.5 1155 декодирований, 12.8 секунды на один интервал
Количество декодирований для двух последних тестов на мощных процессорах может быть больше.
2.4-0.5-0.5 -1162 декодов .2.4-1.0-1.0 1166-так что не имеет смысла на мощном процессоре -у меня во всяком случае точно
оказалось что при включении режима jt9+jt65-падает кол-во декодированных и у меня становиться при 2.4-1.0-1.0 1154 декодированных -а я то думал ну в чем дело -включаю чистый jt65 все норма-на файле 1410 из пакета с откл ару -10 декодированных jt65 -последний в третьем проходе -вкл jt65+jt9 -9 декодирований -нет декода из третьего прохода -установка коэффициента 2.4-1.0-0.5 решает эту проблему но общее кол-во все равно меньше на 4 декода чем в чистой моде jt65- вот такой дефект нашел-буду пробовать коэффициенты 0.5-1
перепроверил-я не правильно подсчитал -с 2.5-1.0-0.5 -1187+1 ложное декодирований в моде jt9+jt65
А в чистом режиме jt65 при таких же данных 1159 +3 ложных -то есть уже на лицо выигрыш режима jt65+jt9
В режиме "JT65+JT9" доступная производительность процессора возрастает пропорционально количеству ядер по сравнению с режимом "только JT65".Цитата:
Сообщение от RK4LWA
Да я в курсе про производительность-но опять получаю плавающие результат-вообще не так все однозначно с этими порогами-сильная зависимость от сторонних программ таки имееться
Оказалось,что не от программ зависит -пре перекомпиляции был сделан лишний отступ в начале строки -я только с этим связываю-полностью обновил командой check-out .поменял все пороги не изменяя более ничего -все восстановилось -1185+3 ЛОЖНЫХ при 2.4-0.5-0.5
1185 правильных JT65 декодирований, верно? какое при этом на Вашей машине получается среднее время на один файл?Цитата:
Сообщение от RK4LWA
да 1185 правильных -а время -8-9 сек при 2.4-0.5-0.5
попробуйте в исходнике symspec65.f90 выключить строкиЦитата:
Сообщение от RK4LWA
! Compute the FFT window
pi=4.0*atan(1.0)
width=0.25*nsps
do i=1,NFFT
z=(i-NFFT/2)/width
w(i)=exp(-z*z)
enddo
знаком комментария:
! Compute the FFT window
! pi=4.0*atan(1.0)
! width=0.25*nsps
! do i=1,NFFT
! z=(i-NFFT/2)/width
! w(i)=exp(-z*z)
! enddo
а строку x=fac1*w*dd(i0+1:i0+NFFT)
заменить на строку
x=fac1*dd(i0+1:i0+NFFT)
Должно немного вырасти количество декодированных сигналов (у меня при 2.4-1.0-1.0 с 1152 до 1155) и уменьшится среднее время затрачиваемое на декодирование.
Интересно, этот прирост за счет правильных или за счет ложных декодирований?
14 ложных декодирований из 1155 с прямоугольным FFT окном (*1).Цитата:
Сообщение от UA3DJY
8 ложных декодирований из 1152 с FFT окном от разработчиков.
Пробовал несколько разных FFT окон-функций https://en.wikipedia.org/wiki/Window_function , в итоге пришел к выводу что та функция которую использовали разработчики работает лучше всего, пробовать изменение кода что в предыдущем посте смысла нет.
Был доступ за пределы массивов dbits() и sym() без каких либо ошибок при компиляции и работе кодера JT9 WSJT-X.
Joe K1JT предполагает что запись данных за пределы массива sym(i) при i>69 могла быть причиной проблемы отсутствия декодирования некоторых JT9 сигналов.
Небольшой выигрыш в количестве декодированных сигналов дает применение синусоидальной весовой функции смещенной на два отсчета во временной области (на два бина в частотной).
При трех проходах с порогами 2.4 1.0 1.0:
- для функции используемой разработчиками получаю 1152 декодирования из которых 7 ложных
- для синусоидальной функции смещенной на два отсчета получаю 1157 декодирований из которых 6 ложных,
итого прирост на 6 верных декодирований.
Изменения кода в исходнике symspec65.f90:
кусок кода:
if(first) then
! Compute the FFT window
pi=4.0*atan(1.0)
width=0.25*nsps
do i=1,NFFT
z=(i-NFFT/2)/width
w(i)=exp(-z*z)
enddo
first=.false.
endif
меняем на следующий код:
if(first) then
! Compute the FFT window
pi=4.0*atan(1.0)
do i=1,NFFT
w(i)=sin(pi*(i+2)/NFFT)
enddo
first=.false.
endif
Результат получен для линейного приемного тракта SDR, чуть позже протестирую с файлами SDR+АРУ.