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

[UA3DJY]

UA3DJY Игорь При тестах у меня стояла 2600 .все таки дело в процессорах

Это принципиальный момент, надо договориться об использовании одинаковых частот среза (нижняя и верхняя частоты водопада) и значения bins/pixel для тестов.

Предлагаю использовать нижнюю частоту 0 Гц, верхнюю 3600 Гц. Нижняя частота определяется установкой Start на водопаде, верхняя растяжением окна водопада на экране, по верхней частоте надо смотреть чтобы окно заканчивалось точно на 3600 Гц.

bins/pixel предлагаю для тестов ставить 5, границу JT9 на 2400 Гц.

Эти значения оптимальны с точки зрения работы в эфире в режиме JT65+JT9 с SDR, поэтому предлагаю все тесты проводить на них.

Нижняя частота передачи в WSJT-X ограничена значением 200 Гц, но никто не мешает позвать станцию у которой sync тон на выходе приемника находится ниже 200 Гц сплитом, то есть предлагаю учитывать 200 Гц в возможной разнице частоты передатчика корреспондента и своего приемника ставя стартовое значение водопада WSJT-X 0 Гц.

[RK4LWA]

так и будем делать только границу считаю 2500 лучше нижняя всегда 0 у меня

[RK1NA]

границу считаю 2500 лучше

Совершенно верно тем более что она по умолчанию такая

[RK4LWA]

Прогнал на 12 ядерном серверном процессоре сегоднЯ Xeon e5-2600 результаты хуже чем на моем fx и копия повторяют результаты UA3DJY

[UA3DJY]

так и будем делать только границу считаю 2500 лучше нижняя всегда 0 у меня

Из-за несоответствия частот трансиверов часто бывает что JT9 сигнал находится немного ниже 2500, поэтому практичнее держать планку на 2400, иначе такие сигналы не декодировать.

С нашей точки зрения, тестирования на файлах, нет четкой уверенности что в коде все чисто и смещение границы JT9 не влияет на декодирование JT65.

Как пример, расширение полосы приема у меня привело к тому, что несколько ранее декодировавшихся сигналов исчезли, но вместо них появились новые там где они ранее не декодировались на частотах в старой полосе. То есть в софте пока еще остаются проблемы с точностью вычислений.

[RK4LWA]

Да понимаю и JT65 сигналы я видел на 3000 просто я считаю что выставить полосу 2500 и оптимально-да чтот срежем возможно но зато применно приблизимся к одним отчетам. А то у нас разрыв большой

[RC2SC]

Да понимаю и JT65 сигналы я видел на 3000 просто я считаю что выставить полосу 2500 и оптимально-да чтот срежем возможно но зато применно приблизимся к одним отчетам. А то у нас разрыв большой

При bins/pixel = 3 показало 1249 декодирований (вместе с ложными)
при bins/pixel = 4 - 1253
при bins/pixel = 5 - 1261

[UA3DJY]

При bins/pixel = 3 показало 1249 декодирований (вместе с ложными)
при bins/pixel = 4 - 1253
при bins/pixel = 5 - 1261

Владимир, здесь для точной картины еще необходимы верхние частоты окна водопада для каждого bin/pixels, также стартовая частота.

Самое неудобство здесь в том, что потянув на край окна водопада, мы меняем верхний предел частоты декодирования сигналов.

В том числе верхняя граница может поменяться просто при изменении значения bins/pixel.

В исходном коде decoder.f90 эти частоты-границы проходят под именами nfa и nfb.

[R5WM]

Методом xxxx удалось сделать компиляцию WSJT-11 r6497

[UA9LEW]

Из-за несоответствия частот трансиверов часто бывает что JT9 сигнал находится немного ниже 2500, поэтому практичнее держать планку на 2400, иначе такие сигналы не декодировать..

Поставьте 0 и не мучайтесь.

С нашей точки зрения, тестирования на файлах, нет четкой уверенности что в коде все чисто и смещение границы JT9 не влияет на декодирование JT65..

Полгода назад не влияло, абсолютно точно. Две совершенно разные функции.

Как пример, расширение полосы приема у меня привело к тому, что несколько ранее декодировавшихся сигналов исчезли, но вместо них появились новые там где они ранее не декодировались на частотах в старой полосе. То есть в софте пока еще остаются проблемы с точностью вычислений.

Ну так на это еще 2 месяца Вам указывалось. Любые манипуляции с полосой ( в полосе) вели к изменению результатов.

[UA9OP]

Поставьте 0 и не мучайтесь.

не понял где 0 выставить, вначале?

[UA9LEW]

не понял где 0 выставить, вначале?

тут

бонусом получите что все декодирования теперь выстроятся строго по порядку в пределах прохода.

Плюс бывает что и вот на таких частотах умудряются работать.


пс На скорость декода практически не повлияет
пс2 Как это себя поведет в модифицированных версиях хз, не смотрел

[UA3DJY]

Продолжаю работать над исходником subtract65.

Временно прекратил попытки оптимизации вычитания сигналов в исходнике subtract65 по причине утечки памяти в WSJT-X, проявляющейся в периодическом отсутствии доступа к дробной части массива dd().

Этот массив содержит отсчеты(samples) входного цифрового звукового потока и является основой всего происходящего в WSJT-X.

Часто бывает что при первичном чтении массива получаю например такие данные (номер отсчета, значение):

dd 2201 19.0000000
dd 2202 16.0000000
dd 2203 12.0000000
dd 2204 4.00000000
dd 2205 -16.0000000
dd 2206 -29.0000000
dd 2207 -10.0000000

При вычитании декодированного сигнала идет запись в массив dd() после чего часто ситуация возвращается к нормальной, например:

dd 2201 19.0524387
dd 2202 15.4829807
dd 2203 23.0843353
dd 2204 55.9010811
dd 2205 33.9535789
dd 2206 -26.7643013
dd 2207 -44.2844543

Такой же сбой доступа к памяти происходит и в обратном порядке, если изначально значения с массива считываются с дробной частью то после вычитания сигнала и записи в массив доступ к дробной части может исчезнуть.

Эффект на декодирование непредсказуемый, поэтому в присутствии этого дефекта в коде считаю вообще бессмысленной какую либо оптимизацию декодирования.

Дефект наблюдаю как в модифицированном r6462mod6 так и немодифицированном WSJT-X r6496, также в r6229.

Если есть желание пощупать диагностику самостоятельно то в исходник subtract65.f90 необходимо добавить следующий код(всего три строки прямо перед блоком вычитания сигнала):

.....
+ do i=1,20
+ print *, 'dd',2200+i,dd(nstart+2200+i)
+ enddo

! Subtract the reconstructed signal
call timer('subtr_3 ',0)
.....

В этом коде nstart означает стартовый отсчет с учетом DT вычитаемого сигнала/сообщения, отсчет 2200 примерно середина первого sync тона этого сигнала (точно середина - отсчет 2229).

Само декодированное сообщение в окошке будет ниже распечатанных значений напряжения отсчетов кодом диагностики.

Сразу можно только сказать что этот дефект скорее всего приводит к хаотическому уменьшению динамического диапазона сигналов, срезая примерно каждый второй слабый сигнал.

Информацию о дефекте передал разработчикам, жду ответа.

[UA3DJY]

Происходит в jt65_decode.f90 последовательно на каждом проходе по определенному предварительно списку кандидатов, логика следующая:

- определяется список кандидатов
- кандидаты по порядку декодируются из списка(этот порядок я в коде менял на обратный, прироста в количестве декодирований не было но декодирования немного отличались)
- после успешного декодирования первого в списке кандидата идет вызов процедуры вычитания сигналов subtract65.f90
- первый сигнал вычтен и после этого декодируется второй кандидат из списка, затем вычитается второй сигнал и т.д.

При вычитании сигналов используется массив dd() для чтения амплитуды сигнала до вычитания и записи амплитуды обратно в массив dd()
уже после вычитания сигнала. То есть значения амплитуд в этом массиве после каждого вычитания меняются.

Для вычитания сигнала в процедуре subtract65.f90, на основании известной sync последовательности тонов, общей для всех JT65 сигналов, и известной data последовательности тонов уже декодированного сигнала, по-тонально симулируется декодированный сигнал, перегоняется из временной области в частотную где применяется фильтр ФНЧ, после чего возвращается обратно во временную область, затем он вычитается из массива dd() с записью результата обратно в этот массив.

В процессе диагностики столкнулся с сценарием когда сигнал вычитается а в окошке не появляется декодированное сообщение, этот сценарий является результатом повторного декодирования уже ранее декодированного сообщения в рамках установленного в коде предела сдвига частот на повторное сообщение(freq-freq0 менее 3.0).

[UA3DJY]

Временно прекратил попытки оптимизации вычитания сигналов в исходнике subtract65 по причине утечки памяти в WSJT-X, проявляющейся в периодическом отсутствии доступа к дробной части массива dd().

Сразу можно только сказать что этот дефект скорее всего приводит к хаотическому уменьшению динамического диапазона сигналов, срезая примерно каждый второй слабый сигнал.

Информацию о дефекте передал разработчикам, жду ответа.

После продолжительного обсуждения этой темы с разработчиками получил подтверждение об отсутствии проблем в коде.

Сигнал с АЦП (или цифрового потока SDR) проходит через изменение частоты дискретизации и ФНЧ (исходник fil4.f90) после чего записывается в массив dd(). При первоначальной записи используются целые числа и затем последующая обработка с плавающей запятой. Диапазон значений в массиве -32767...+32767, что соответствует примерно 90 дБ динамического диапазона (20*log10(32767)) при максимально возможной амплитуде сигнала.

В процессе обработки на декодер уже попадают тона отфильтрованные полосой бина 2.69 Гц что увеличивает динамический диапазон еще на 10*log10(6000/2.69)= 33 дБ снизу за счет уменьшения мощности шума после узкополосного полосового фильтра.

Значит эффект подавления слабых сигналов сильным при использовании SDR с выключенной АРУ и цифровым аудио потоком связан исключительно со ступенькой боковых излучений за пределами передаваемой полосы JT65 сигнала, то есть с чистотой формирования сигнала в системе компьютер-трансивер-усилитель (паразитная амплитудная модуляция + ее интермодуляционные составляющие, использование линейного участка микрофонного тракта).

Отдельной темой является одновременная работа на передачу в JT9 и JT65 в одном интервале, особенно в части используемой на передачу мощности.