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

[RC2SC]

Тоже версия 85

Случайно не подскажите что обозначает знак ~ и # в двух разных снимках? Реплика уместна или нет?

[US-E-12]

что обозначает знак ~ и #

Модуляцию к примеру ~ - FT8.

[UT8NT]

знак ~ и #

~ - FT8
# - JT65
@ - JT9

выбирая моду-меняется значек

конечно не совсем корректно сравнивать SNR разных программ и режимов работы...
SNR-23 не часто встречающийся рапорт в FT8 в программе JTDX , поэтому я и выложил скрин с благодарностью Игорю за возможность провести qso c таким низким SNR
в предыдущих версиях минимальный SNR у меня был- 21

[UA3DJY]

А как Вам такие SNR!

Погрешность индикации. WSJT-X при включенном FT8AP декодирует 4 FT8 сигнала из 5000 (сигналы без QSB) с SNR -23дБ, и один сигнал из 5000 при выключенном FT8AP. C QSB декодирование ощутимо хуже.

Если предположить за сутки равномерное распределение сигналов на диапазоне по SNR от 0 до -23дБ то декодирование сигнала без QSB с уровнем -23дБ SNR на WSJT-X будет наблюдаться примерно (20 (сигналов/интервал) * 5760 (интервалов/сутки) * 4 (декодирования тестовых сигналов) / 24 (варианта SNR) * 5000 (тестовых сигналов)) = 4 раза в сутки.

C учетом QSB менее одного FT8 декодирования с уровнем -23 дБ SNR в сутки.

[US-E-12]

Игорь, не рассматривали вопрос о переводе фортрановских библиотек на C++. LZ2HV полностью перевёл всё на C++. Довольно быстро работает декодер в его программе + запущено ещё RAD Studio (среда разработки) + браузер + программа под дебаггером и обновления антивируса, никаких выпаданий интервалов и загрузка двух ядер 75-78% при декоде, JTDX при аналогичных условиях пропускает интервалы декодирования, загрузка ядер 100%, как впрочем и в WSJT-X. Отпадёт повод меряться у кого круче проц.

[UA3DJY]

Игорь, не рассматривали вопрос о переводе фортрановских библиотек на C++. LZ2HV полностью перевёл всё на C++. Довольно быстро работает декодер в его программе + запущено ещё RAD Studio (среда разработки) + браузер + программа под дебаггером и обновления антивируса, никаких выпаданий интервалов и загрузка двух ядер 75-78% при декоде, JTDX при аналогичных условиях пропускает интервалы декодирования, загрузка ядер 100%, как впрочем и в WSJT-X. Отпадёт повод меряться у кого круче проц.

Увы, перевод кода на C++ пока вне моих возможностей.

Сейчас в коде C++ используется POSIX threading, в коде Фортрана OMP компилятора. Возможно что выпадание интервалов связано с независимой работой двух вариантов многопотока, когда OMP отбирает все ресурсы на потоки декодера в JTDX а приоритеты потоков в OMP не выставляются.
Если я добавляю вычислений в декодере то на 4-х ядрах i5-4460 наблюдаю насыщение нагрузки в 100% и выпадание каждого второго интервала.

WSJT-X использует OMP только для преобразования Фурье.

[UA3DJY]

Игорь, не рассматривали вопрос о переводе фортрановских библиотек на C++. LZ2HV полностью перевёл всё на C++. Довольно быстро работает декодер в его программе + запущено ещё RAD Studio (среда разработки) + браузер + программа под дебаггером и обновления антивируса, никаких выпаданий интервалов и загрузка двух ядер 75-78% при декоде, JTDX при аналогичных условиях пропускает интервалы декодирования, загрузка ядер 100%, как впрочем и в WSJT-X. Отпадёт повод меряться у кого круче проц.

Олег, попробуйте пожалуйста 86_6. У меня неоднозначные впечатления от ее использования, я в исходнике ft8b.f90 включал if(swl) ndeep=4 для режима SWL специально загоняя нагрузку ядер в насыщение а время на декодирование интервала росло до 8..12 секунд.

Подход к приоритетам потоков в 86_6 снял насыщение нагрузки ядер, но при переходе декодирования в следующий интервал выросло время декодирования, при превышении 15 секунд на декодирование на одном из интервалов у меня кнопка Decode уже не отключилась.

Надеюсь что уйдут выпадение RX интервалов и задержки звука на передачу.

[US-E-12]

попробуйте пожалуйста 86_6

Погонял на 20м, когда есть загрузка станциями на диапазоне. Ну чуть получше. Загрузка 80-100%, при 100% Каспер одновременно обновлялся, пропуски присутствуют, но только если "шуршит" другая программа (получает обновления или в работе). Только вот ещё замечено и на предыдущей версии, вывод декодированных сообщений стал небольшими рывками, раньше было плавно, а тут сразу как-то "кусками". Выводит одно-два сообщения плавно друг за другом, затем чуть-чуть подвисло и сразу выскочили все остальные почти одновременно.

[UA3DJY]

Погонял на 20м, когда есть загрузка станциями на диапазоне. Ну чуть получше. Загрузка 80-100%, при 100% Каспер одновременно обновлялся, пропуски присутствуют, но только если "шуршит" другая программа (получает обновления или в работе). Только вот ещё замечено и на предыдущей версии, вывод декодированных сообщений стал небольшими рывками, раньше было плавно, а тут сразу как-то "кусками". Выводит одно-два сообщения плавно друг за другом, затем чуть-чуть подвисло и сразу выскочили все остальные почти одновременно.

Опять упираемся в ресурсы процессора, в варианте 86_6 на слабых процессорах ощутимо выросло время декодирования.

[RC3C]

при 100% Каспер одновременно обновлялся

Каспера лучше вообще снести с компа ибо он грузит большую часть проца. ИМХО.

[UA3DJY]

Сбой в декодере FT8 на сигналах с хорошим SNR, к сожалению W6THI не публикует свой email, не удастся узнать какие сообщения он передавал:

В приложении звуковые файлы.

[RN9AZ]

Сбой в декодере FT8 на сигналах с хорошим SNR, к сожалению W6THI не публикует свой email, не удастся узнать какие сообщения он передавал:

Игорь. Этот сбой я наблюдал несколько раз, вчера. 8Q7HI пытались звать параллельно его вызову. И так на протяжении всей работы этой станции. Тут по неволе программа сбоит. У меня он проходил до +8 и всё равно мешали принять нормально. Думаю только в этом причина сбоя.

[UA3DJY]

Игорь. Этот сбой я наблюдал несколько раз, вчера. 8Q7HI пытались звать параллельно его вызову. И так на протяжении всей работы этой станции. Тут по неволе программа сбоит. У меня он проходил до +8 и всё равно мешали принять нормально. Думаю только в этом причина сбоя.

Возможно что 8Q7HI менял сообщение во время передачи, по опыту много ложных декодирований FT8 связано с частичной передачей сообщения в интервале.

Но двойное декодирование не вписывается в это предположение, здесь возможно кто то навстречу звал оба интервала и 8Q7HI передавал одно и то же сообщение:

161730 -9 0.9 324 ~ ?Z 2BBU5H+E50
161800 -13 0.9 324 ~ ?Z 2BBU5H+E50

[RN9AZ]

Возможно что 8Q7HI менял сообщение во время передачи, по опыту много ложных декодирований FT8 связано с частичной передачей сообщения в интервале.

Но двойное декодирование не вписывается в это предположение, здесь возможно кто то навстречу звал оба интервала и 8Q7HI передавал одно и то же сообщение:

161730 -9 0.9 324 ~ ?Z 2BBU5H+E50
161800 -13 0.9 324 ~ ?Z 2BBU5H+E50

Игорь так и было. То Итальянец вместо 8Q7HI, декодировался то ещё кто нибудь то совсем ни кого. То вот такая белиберда. И точно как у тебя. С той разницей что и она менялась, в зависимости кто параллельно работал. Пытаясь дозваться в одном кадре. Пай лап на 8Q7HI, был как внук говорит, крутой. Увы это не JT65 не распознаёт станции, почти с одной частотой.

[UA3GSO]

Подскажите pls, почему в WSJT-X v1.9 нет диапазонов и как это исправить?