проект WSJT-X: моды JT65,JT9,WSPR,JT4,JTMS,MSHV - работа с тестовым софтом

**UA3DJY** · 31.01.2016, 16:49

Сообщение от RA3RKA

15-16-17 Станций за проход
уже не умещаются в окошке и в AjTaler - 2 строки мало стало

с каждым днем растет количество станций на диапазонах, а значит третий проход будет выдавать больше декодирований

**UA3DJY** · 31.01.2016, 17:24

небольшой сюрприз - значение порога может быть менее 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 секунды на один интервал

Количество декодирований для двух последних тестов на мощных процессорах может быть больше.

**RK4LWA** · 31.01.2016, 22:52

2.4-0.5-0.5 -1162 декодов .2.4-1.0-1.0 1166-так что не имеет смысла на мощном процессоре -у меня во всяком случае точно

**RK4LWA** · 01.02.2016, 00:22

оказалось что при включении режима 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

**RK4LWA** · 01.02.2016, 02:04

перепроверил-я не правильно подсчитал -с 2.5-1.0-0.5 -1187+1 ложное декодирований в моде jt9+jt65

**RK4LWA** · 01.02.2016, 05:54

А в чистом режиме jt65 при таких же данных 1159 +3 ложных -то есть уже на лицо выигрыш режима jt65+jt9

**UA3DJY** · 01.02.2016, 07:33

Сообщение от RK4LWA

с 2.5-1.0-0.5 -1187+1 ложное декодирований в моде jt9+jt65

А в чистом режиме jt65 при таких же данных 1159 +3 ложных -то есть уже на лицо выигрыш режима jt65+jt9

В режиме "JT65+JT9" доступная производительность процессора возрастает пропорционально количеству ядер по сравнению с режимом "только JT65".

**RK4LWA** · 01.02.2016, 09:28

Да я в курсе про производительность-но опять получаю плавающие результат-вообще не так все однозначно с этими порогами-сильная зависимость от сторонних программ таки имееться

**RK4LWA** · 01.02.2016, 11:39

Оказалось,что не от программ зависит -пре перекомпиляции был сделан лишний отступ в начале строки -я только с этим связываю-полностью обновил командой check-out .поменял все пороги не изменяя более ничего -все восстановилось -1185+3 ЛОЖНЫХ при 2.4-0.5-0.5

**UA3DJY** · 01.02.2016, 11:53

Сообщение от RK4LWA

Оказалось,что не от программ зависит -пре перекомпиляции был сделан лишний отступ в начале строки -я только с этим связываю-полностью обновил командой check-out .поменял все пороги не изменяя более ничего -все восстановилось -1185+3 ЛОЖНЫХ при 2.4-0.5-0.5

1185 правильных JT65 декодирований, верно? какое при этом на Вашей машине получается среднее время на один файл?

**RK4LWA** · 01.02.2016, 12:41

да 1185 правильных -а время -8-9 сек при 2.4-0.5-0.5

**UA3DJY** · 01.02.2016, 16:21

Сообщение от RK4LWA

да 1185 правильных -а время -8-9 сек при 2.4-0.5-0.5

попробуйте в исходнике symspec65.f90 выключить строки

! 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) и уменьшится среднее время затрачиваемое на декодирование.

Интересно, этот прирост за счет правильных или за счет ложных декодирований?

**UA3DJY** · 01.02.2016, 19:02

Сообщение от UA3DJY

попробуйте в исходнике symspec65.f90 выключить строки
...
Должно немного вырасти количество декодированных сигналов (у меня при 2.4-1.0-1.0 с 1152 до 1155) и уменьшится среднее время затрачиваемое на декодирование.

Интересно, этот прирост за счет правильных или за счет ложных декодирований?

14 ложных декодирований из 1155 с прямоугольным FFT окном (*1).

8 ложных декодирований из 1152 с FFT окном от разработчиков.

Пробовал несколько разных FFT окон-функций https://en.wikipedia.org/wiki/Window_function , в итоге пришел к выводу что та функция которую использовали разработчики работает лучше всего, пробовать изменение кода что в предыдущем посте смысла нет.

**UA3DJY** · 01.02.2016, 19:14

Был доступ за пределы массивов dbits() и sym() без каких либо ошибок при компиляции и работе кодера JT9 WSJT-X.

Joe K1JT предполагает что запись данных за пределы массива sym(i) при i>69 могла быть причиной проблемы отсутствия декодирования некоторых JT9 сигналов.

**UA3DJY** · 03.02.2016, 10:59

Небольшой выигрыш в количестве декодированных сигналов дает применение синусоидальной весовой функции смещенной на два отсчета во временной области (на два бина в частотной).

При трех проходах с порогами 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+АРУ.