Вложений: 1
компиляция измененного кода в JTSDK 2.0.4
r6462mod6 без проблем компилирую в JTSDK 2.0.3 и пока остаюсь на этой версии JTSDK.
Но при использовании команд build-wsjtx rinstall , build-wsjtx package в JTSDK 2.0.4, скрипт последнего идет на svn, берет оттуда последнюю ревизию кода разработчиков с которой есть проблема совместимости измененного кода r6462mod6, выдает ошибку:
"undefined reference to 'Configuration npreampass() Const' " после чего прекращает компиляцию. В приложенной ниже картинке скрипт пытается скомпилировать вместо r6462mod6 версию r6471mod6.
Если кто то разобрался с системой команд в JTSDK 2.0.4 и смог в нем скомпилировать r6462mod6, подскажите пожалуйста правильный набор команд для компиляции измененного кода в JTSDK 2.0.4. Должна быть какая то команда дающая компилятору указание использовать только локальную копию исходного кода.
Сам пока не разбирался с работой в JTSDK 2.0.4 и как временное решение проблемы могу только предложить переустановку JTSDK до версии 2.0.3, не делая update/upgrade команды до 2.0.4.
Выход скрипта компиляции JTSDK 2.0.4, для просмотра этой картинки необходимо изменить масштаб в браузере:
Вложение 158542
компиляция измененного кода в JTSDK 2.0.4
Цитата:
Сообщение от
UA3DJY
r6462mod6 без проблем компилирую в JTSDK 2.0.3 и пока остаюсь на этой версии JTSDK.
Но при использовании команд build-wsjtx rinstall , build-wsjtx package в JTSDK 2.0.4, скрипт последнего идет на svn, берет оттуда последнюю ревизию кода разработчиков с которой есть проблема совместимости измененного кода r6462mod6, выдает ошибку:
"undefined reference to 'Configuration npreampass() Const' " после чего прекращает компиляцию. В приложенной ниже картинке скрипт пытается скомпилировать вместо r6462mod6 версию r6471mod6.
Если кто то разобрался с системой команд в JTSDK 2.0.4 и смог в нем скомпилировать r6462mod6, подскажите пожалуйста правильный набор команд для компиляции измененного кода в JTSDK 2.0.4. Должна быть какая то команда дающая компилятору указание использовать только локальную копию исходного кода.
Сам пока не разбирался с работой в JTSDK 2.0.4 и как временное решение проблемы могу только предложить переустановку JTSDK до версии 2.0.3, не делая update/upgrade команды до 2.0.4.
Выход скрипта компиляции JTSDK 2.0.4, для просмотра этой картинки необходимо изменить масштаб в браузере:
Перед компиляцией необходима новая дополнительная команда:
wsjtx-list -u
После чего становится доступна компиляция с использованием новых опций командной строки JTSDK 2.0.4, то есть вопрос в новой командной строке для компиляции локальной копии исходного кода.
Из документации на JTSDK 2.0.4 (сама документация здесь https://sourceforge.net/projects/jts...release-notes/ но в ней не оговорен наш случай, возможно что нужная нам информация есть в help нового JTSDK-QT):
4.2. WSJT-X Build Lists
New in v2.0.4 is the ability to generate a list of GA-RC Release Tags and Development Branches that can be built using the current JTSDK-Win32 tool set. Updating the lists is particularly important when a new branch is created.
Before command line options can be used to build a specific branch of WSJT-X, you must first generate the builds list. The following matrix details the options to update, generate and display the lists.
# Using JTSDK-QT
Usage ....: wsjtx-list [ OPTION ]
Example ..: wsjtx-list -u
Table 2. WSJT-X Build List Options
Command Option Description
wsjtx-list
-h
Display the help message
-a
Display all lists
-d
Display the development branch list
-g
Display the GA and RC tags list
-u
Update or generate a new set of lists
компиляция измененного кода в JTSDK 2.0.4
Возможно что проблема с компиляцией r6462mod6 в JTSDK 2.0.4 связана с тем что пользователи изначально не синхронизировали локальный исходный код r6462 с версией ревизии с этим номером находящейся на svn.
Правильный порядок компиляции:
checkout-wsjtx (в JTSDK 2.0.4 может быть другая команда или вообще отсутствовать, при выполнении этой команды в локальную копию загружается исходный код последней ревизии исходного кода с svn)
svn update –r r6462 (при выполнении этой команды загруженный ранее в локальную копию исходный код меняется на исходный код ревизии r6462)
только после этого вычищаем папку C:\JTSDK\src\ и копируем в нее папку wsjtx с исходным кодом r6462mod6.
затем
build-wsjtx package (если спрашивает сделать update from svn - отвечаем N), для JTSDK 2.0.4 возможно потребуется использование опций.
Для JTSDK 2.0.3 компиляция модифицированного исходного кода необходимого номера ревизии WSJT-X с использованием такой последовательности работает без сбоев.
Вложений: 1
вероятность ошибочного декодирования JT65 разная для разных процессоров
Цитата:
Сообщение от
RK4LWA
Да я боюсь там ложных более -уже видим что пропустили в 1410 ложный декод -выглядит то как нормальный -пока не посмотришь что нет такого позывного
Цитата:
Сообщение от
RA9XQ
1224+25 ложных.
Цитата:
Сообщение от
RK4LWA
В результате полученном Вадимом насчитал 1197 правильных и 51 ложное декодирование.
На моем AMD процессоре для r6462mod6 Preamp ON получаю 1188 правильных и 62 ложное декодирование.
Файл сравнения двух процессоров прикладываю, ложные декодирования выделены желтым цветом.
Интересно то, что на разных процессорах мы получаем разную вероятность ошибочного декодирования, и разное количество правильных декодирований.
Вложение 158587
Вот что по этому поводу когда то мне ответил Joe K1JT, если перевести кратко то при одинаковых установках результат декодирования не должен отличаться на разных процессорах, в режиме JT65+JT9 на нескольких ядрах может отличаться только порядок расположения декодированных сообщений:
>> If configured in the same way and presented with the same data,
>> identical software should produce identical output -- at least, up to
>> differences caused by non-deterministic differences in the way time
>> slices have been allocated to different threads. In the JT9/JT65
>> decoder, multi-threading is used only in the combined JT9+JT65 operating
>> mode,
Но с тех пор как он это сказал многое поменялось в софте, в частности произошел переход на FTRSD декодер, тогда был KVASD декодер и ложных декодирований вообще не было.