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

[RX3ASP]

Начало и окончание QSO определяется по переданному/принятому сообщению и состоянию кнопки Enable TX, как я уже сказал состояние кнопки AutoTx не проверяется при включении фильтра в Auto RX frequency filter.

Убрал проверку состояния кнопки Enable Tx при включении фильтра в этой сборке:

Что-то мы с Вами совсем о разном.
Поставил 67. Ничего не изменилось на первый взгляд.
Как же не проверяется состояние AutoTX, когда без неё фильтр сам не включается.
При окончании QSO (73) Enable TX гаснет и фильтр выключается. Это уже было в 66 и ранее. С этим всё ОК.
А вот Фильтр, как не включался так и не включается без AutoTX.

Лучше давайте эту затею оставим, если кроме меня это никому не интересно. Иначе весь алгоритм может нарушиться.

Сейчас вижу, что в 67 Фильтр самопроизвольно отключается. Удалите пожалуйста этот файл, а то сейчас народ наскачивает.

[UA3DJY]

Что-то мы с Вами совсем о разном.
Поставил 67. Ничего не изменилось на первый взгляд.
Как же не проверяется состояние AutoTX, когда без неё фильтр сам не включается.
При окончании QSO (73) Enable TX гаснет и фильтр выключается. Это уже было в 66 и ранее. С этим всё ОК.
А вот Фильтр, как не включался так и не включается без AutoTX.

Лучше давайте эту затею оставим, если кроме меня это никому не интересно. Иначе весь алгоритм может нарушиться.

Сейчас вижу, что в 67 Фильтр самопроизвольно отключается. Удалите пожалуйста этот файл, а то сейчас народ наскачивает.

Просто алгоритм автоматического включения фильтра сделан внутри функционала AutoSeq, Вы же начинаете QSO в ручном режиме и поэтому включение фильтра не отрабатывает.

То есть Вам необходим дополнительно функционал автоматического включения фильтра в ручном режиме начала QSO, он же может потребовать доработки функционала автоматического отключения фильтра.

[RX3ASP]

Просто алгоритм автоматического включения фильтра сделан внутри функционала AutoSeq, Вы же начинаете QSO в ручном режиме и поэтому включение фильтра не отрабатывает.

Я понял. Нет так нет

[RZ1OA]

Влияет ли как то размер лога на скорость декодирования? Залил в файл лога около 10 т. связей, показалось, что декодировать стало медленнее. Так ли это?

[RJ7M]

Где нужно поставить "птичку" или точку, что бы после окончания ЩСО, не нажимать кнопку "клеар ДХ", а что бы очищалось автоматически?

Здесь:

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

[UA3DJY]

Просто алгоритм автоматического включения фильтра сделан внутри функционала AutoSeq, Вы же начинаете QSO в ручном режиме и поэтому включение фильтра не отрабатывает.

Я понял. Нет так нет

В этой версии я прослабил требования к включению кнопки Filter в режиме автоматического фильтра при ручном старте QSO и включенном AutoSeq, надо пробовать, если будет работать без новых сбоев то оставим это изменение на постоянку:

собранный софт: https://cloud.mail.ru/public/6Y7f/DVBysmtsZ

исходный код: https://cloud.mail.ru/public/3yen/KHfq1T3Nk

кодовые суммы:
File name: JTDX-18.1.0.67_2-win32.exe
MD5: 609D6ECEF96D7763B9F71DDDAA5C0A57
SHA-1: D5F8D366D5428715460E26C594B9F2F56544AACE
SHA-256: E687FA4DC3AF8FF5F0A43CCD72D17B2248BB38A17842FCBE7039A5E36B5AA61F
SHA-512: F1964192F4D370F3389B97476AC0F085DF71D992E1541F7E2AE758885697D48ADBC51C B10BFA3A72934A5B8D8F225CB850D78989FECCAF87CCB03D8549A067AF
RIPEMD: 8DB837BC5696558FD7561ABB8B8893B38025F7CE

[RW4LN]

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

Да, подтверждаю, ни какого эффекта, есть галки или нет, не очищаются.

[UA3DJY]

Влияет ли как то размер лога на скорость декодирования? Залил в файл лога около 10 т. связей, показалось, что декодировать стало медленнее. Так ли это?

тестовый софт, позволит Вам видеть время потраченное на декодирование FT8 при разном количестве сигналов на диапазоне, разном размере лога, включенных/выключенных уведомлениях, включенном/выключенном декодере Hint (FT8AP), показывает время начала и окончания декодирования - можно увидеть в какой момент времени включился декодер и успел ли процессор декодировать сигналы до начала TX интервала

Время включения/выключения декодера в диагностике местное, формат ччммсс.(мс). Время потраченное на декодирование в секундах.

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

собранный софт https://cloud.mail.ru/public/2tUR/J4veS3Uip

исходный код https://cloud.mail.ru/public/E6X5/ei2QVUszz

кодовые суммы:
File name: JTDX-18.1.0.67_2_test-win32.exe
MD5: 86E83AF142CE87D95B6092660D66BD18
SHA-1: 1E340EE4C0EF643B0E91FD3AA64F770CCF16077F
SHA-256: 1E95E1F7DEAEF542E678F816D2A146A553D439594A642C58738EA339B292BC78
SHA-512: 24AE3CEEC5ACFD41EC8ED7BE3782FA5FE95FFC1E30E3DDE7FC1D1FE652E2A44FCB7274 B2DFF5480E227B29EA12BA2E3745B464A2A6BAC0DA41D161F1D6D12E77
RIPEMD: 80B9F06EFEA52289874EE0E9ABABEB1904C1BD88


измерение времени декодирования выполнено в исходнике decoder.f90

[RW4LN]

Версия самая последняя, заметил, корреспондент дает раппорт, программа посылает RR73, и так несколько раз, но ответа от корреспондента не декодируется, хотя след на водопаде виден. И все ЩСО срывается. Это только у меня?
Вот последняя связь



Не думаю, что из-за медленного процессора.

[K2PAL]

Не очищается окна.
Я могу с уверенностью сказать если связь завершилась все очищается!
Не очищается только тогда когда связь не завершилась по разным причинам их может быть много.
Он не принял от вас RR73 или RRR и по этому вы не получили его 73.Это хорошо хоть оператору есть что делать что бы не заснуть, а иначе получится всё в автомате и кому такая связь нужна.
Да вот какая неприятность выползает когда я ему даю RR73.
И жду от него репорт, а вместо этого повторяется его репорт, но с перечеркнутой линией -09 то бишь вместо 73 и все программа заходит в цикл и приходится вручную все остановить и даже убегать на другой диапазон.
Успехов

[UA3DTK]

AG2T... совершенно верно

[UA3DJY]

Да вот какая неприятность выползает когда я ему даю RR73.
И жду от него репорт, а вместо этого повторяется его репорт, но с перечеркнутой линией -09 то бишь вместо 73 и все программа заходит в цикл и приходится вручную все остановить и даже убегать на другой диапазон.

результат упорного использования -dev версий WSJT-X собранных до появления общедоступной r8193, в которых RR73 WSJT-X воспринимает как QTH квадрат и отвечает на него рапортом

Не зря разработчики WSJT-X запрещают распространение самостоятельно собранных -dev ревизий.

[R0AX]

одна проблема при работе на вызов если qso начинается с рапорта после получения RR73 программа два раза передает 73 и отключается(это постоянно) с передачи шаг 65 и 66 при любых autoseg,автофильтр не использую,только при необходимости в ручном режиме.При полноценном qso любой autoseg работает без проблем и без автофильтра.По работе на поиск пока ничего сказать не могу провел всего пару связей.Да свободное сообщение с 73 отрабатывает без проблем
Еще когда передача отключается позывной остается в окне dx call хотя в лог он уже внесен убираешь уже вручную

[RZ1ZR]

Версия самая последняя, заметил, корреспондент дает раппорт, программа посылает RR73, и так несколько раз, но ответа от корреспондента не декодируется, хотя след на водопаде виден. И все ЩСО срывается. Это только у меня?

аналогично, грешил на прохождение )))

[UA3DJY]

"Аглицкий" не проходили в школе, да и немецкого не знаю... translate.google.ru помог не много.
Вот это может проблема: This only seemed to start with the latest release of Alert. (Это только начиналось с последней версии Alert.).
Вчера как раз за одно и JTAlert обновил.
Правда в AutoSeg3 не заметил вроде такого: я ждал от корреспондента 73, после получения сразу же нажал сохранение. Но окна очистились раньше, и прога ругнулась.
В AutoSeg3 работал с предыдущей версией JTAlert и обычно всё было ОК.
Да и сейчас пробовал, после одного КуЕсО только сохранил, сразу окна очистились (это 5 секунд). Последующие - сохранил, и очищение окон в конце цикла приёмного...

Факт что баг есть, (но в какой проге?)!

P.P.S.-если можно сразу в журнал MixW 3.2 с программы направлять, подскажите как настроить... попробуем без JTAlert (хотя она больше, и достовернее инфо даёт)!

Вот и решение для этой проблемы, если кратко то в JTAlert 2.10.9 было сделано уведомление о том что QSO которое вносится во внешний лог из софта JTAlert имеет позывной отличающийся от позывного в окне DX Call софтов WSJT-X/JTDX.

В сборке JTAlert 2.10.9 build 0001 для тех кого такое уведомление не устраивает Laurie VK3AMA сделал его опциональным, активируется на усмотрение оператора:

There are several JTAlert users who don't like the newly added (in JTAlert 2.10.9) warning and non-logging when the Callsign trying to be logged doesn't match the Callsign of their current QSO partner. That is the DX Call in WSJT-X/JTDX has been changed or cleared before their last QSO has been logged.

My intention with the change was to protect users from potentially logging incorrect data. That is all the data displayed in the Log Fields area which is accurate for the new DX Call (your new QSO partner), but not the Call trying to be logged.

If your happy to log bad data, as it will likely go unnoticed in the fast paced FT8 world, turn the option off by downloading the latest build of JTAlert and visit the Logging section of the Settings, scrolling down to the last option "Ignore DX Call and Logged Call mismatch warning" and enable it.

The latest JTAlert build can be found here...
https://dnl.HamApps.com/Testing/HamA...0001_Setup.exe

This new option will be a permanent addition to all future public JTAlert releases.

de Laurie VK3AMA