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

[RA3QH]

Если корреспондент не передал грид, то в лог непонятно откуда берётся и записывается не правильный грид. v.rc117

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

[US5WE]

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

Так ведь в базе локатора этого СПС нет и, вероятно, программа подставляет "с потолка". Еще 5 дней ARRL Grid Chase и тема локаторов снова станет актуальной только для 50MHz & up.

[UA3DJY]

Если корреспондент не передал грид, то в лог записывается не правильный грид непонятно откуда. v.rc117
...
Вот не давно меня позвал DB50EFAPB, конечно без грида, а в лог записывался грид KM18. Совсем не в тему.

1) Если его не откуда брать, он и не записывается
2) он берется из баз ALLCALL.TXT & CALL3.TXT

В JTDX длина позывных в этих файлах ограничена 6-ю символами, также файл ALLCALL.TXT который мы регулярно обновляем не содержит QTH квадратов.

Попробую воспроизвести это QSO/сбой с диагностикой.

[RX3ASP]

Оно то конечно так, долго ожидать. Но у Вас QSO заносится в лог автоматом с момента начала передачи 73. А для Вашего корреспондента, по регламенту, QSO еще не завершилось, он не получил от Вас 73. И если по каким то причинам он его не получит, то повторно начнет передавать RR73. А у Вас поле DX call будет уже очищенно и сброшено Enable TX. Придется ручками отправлять 73. Побочным эфектом этого будет dupe QSO в логе (если заносится автоматом).

EU1FQ Ещё раз: QSO окончено. А и B обменялись рапортами, А передал RR73, B передал 73, A принял 73 и начал передавать CQ A. Или отвечает кому-то третьему.
Но у В тормозной компьютер и В снова передаёт 73, хотя он УЖЕ ДЕКОДИРОВАЛ новое CQ от А, помеченное цветом в соответствии с нотификацией как WORKED, до тех пор, пока его тормознутый компьютер не декодирует весь цикл.

Я думаю после записи в ЛОГ должно быть так:
Как только декодировано сообщение от А не адресованное В, то DX Call и Enable TX должны быть очищены.
DX Call очищать не нужно только в том случае, если В не декодировал вообще ничего от А. Но Enable TX надо отключать, предоставив оператору немного поработать мышью и головой.

Когда A использует RRR и 73 всё работает без проблемю

[UN1O]

у меня 115 при установке с верху 117 ини файл убирать? Спасибо.

[RX3ASP]

Иллюстрация, чтобы было более понятна проблема.
QSO с PA3FYG безусловно закончено, но программа передаёт 73 до тех пор, пока все сигналы не будут декодированы. Зачем?

->Скрытый текст<-

[RC3C]

у меня 115 при установке с верху 117 ини файл убирать? Спасибо.

нет

[RX1AG]

Установил 117 версию на слабый комп Р4 2,5 Ггц. Мои наблюдения:

Работа на прием

Полоса декода 500-2500гц, другие настройки самые простые для слабого компа. Работает, декодирует... Провел несколько ЩСО.
Загрузка проца в цикле ДЕКОД с 0 сек до 10 равна 100%, затем падает до 10% и на 15 сек опять 100%

Работа в режиме проведения ЩСО картина странная:

При ДЕКОД нагрузка проца от 0 до 15 сек нагрузка 10 %
При цикле передачи ТХ ВКЛЮЧЕН нагрузка проца:
с 0 сек до 10 равна 100%, затем падает остальные 5 сек до 10%

------------------------------------------------------------------------

Повторил те же опыты на программе WSJT-x 2. 0 rc3

цикл приема
1 сек 100% 2-15 сек 10%

цикл передачи
1 сек 100 %, 2 сек 50 %, 3-15 сек 10%


Непонятно, почему такая разница? Получается, что JTDХ в отличие от WSJT-х бесполезно загружает процессор ненужными процессами?

Поясните, это нормально? Если нет, то почему и как поправить?

[UX8IW]

Иллюстрация, чтобы было более понятна проблема.
QSO с PA3FYG безусловно закончено, но программа передаёт 73 до тех пор, пока все сигналы не будут декодированы. Зачем?

Юрий у вас при декоде загрузка проца сколько процентов?
Из скрина похоже на то, то проц не успевает обрабатывать инфу.
У вас накладываются циклы передачи на циклы приема:
Декод еще не завершился, а уже идет цикл передачи.
Видимо, поэтому и передается повторное 73.

[RX3ASP]

Юрий у вас при декоде загрузка проца сколько процентов?
Из скрина похоже на то, то проц не успевает обрабатывать инфу.
У вас накладываются циклы передачи на циклы приема:
Декод еще не завершился, а уже идет цикл передачи.
Видимо, поэтому и передается повторное 73.

Именно так. Поэтому я использую полуручной режим - после записи в ЛОГ отключаю TX Enable. Но большинство использующих слабые компьютеры не заморачиваются и тупо создают помехи.
Цикл циклом, но сигнал DX декодируется вовремя и при обычном 73 всё ОК.

[RX4CD]

У меня также наблюдается что-то похожее, когда много станций на диапазоне. Загрузка ЦП достигает 100%, в пике.

[EU1FQ]

EU1FQ Ещё раз: QSO окончено. А и B обменялись рапортами, А передал RR73, B передал 73, A принял 73 и начал передавать CQ A. Или отвечает кому-то третьему.
Но у В тормозной компьютер и В снова передаёт 73, хотя он УЖЕ ДЕКОДИРОВАЛ новое CQ от А, помеченное цветом в соответствии с нотификацией как WORKED, до тех пор, пока его тормознутый компьютер не декодирует весь цикл.
Я думаю после записи в ЛОГ должно быть так:
Как только декодировано сообщение от А не адресованное В, то DX Call и Enable TX должны быть очищены.
DX Call очищать не нужно только в том случае, если В не декодировал вообще ничего от А. Но Enable TX надо отключать, предоставив оператору немного поработать мышью и головой.
Когда A использует RRR и 73 всё работает без проблемю

Ну что Вам по этому поводу ответить...... Хочешь ехать быстрее и комфортнее,- меняй автомобиль. Есть даже на дорогах ограничение скорости, меньше которй, ехать запрещено. Так и компьютерным железом.
Завтра сегоднешие топ модели компьютеров станут уже позавчерашним днем. Не дешевое это хобби. Так что или плати, или уходи из него. Никто протокол FT8 под слабые машины переделывать не будет.

Именно так. Поэтому я использую полуручной режим - после записи в ЛОГ отключаю TX Enable. Но большинство использующих слабые компьютеры не заморачиваются и тупо создают помехи.

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

[RX3ASP]

Мне есть на

Ну что Вам по этому поводу ответить...... Хочешь ехать быстрее и комфортнее,- меняй автомобиль. Есть даже на дорогах ограничение скорости, меньше которй, ехать запрещено. Так и компьютерным железом.
Завтра сегоднешие топ модели компьютеров станут уже позавчерашним днем. Не дешевое это хобби. Так что или плати, или уходи из него. Никто протокол FT8 под слабые машины переделывать не будет.

Очень оригинально, в стиле - "у кого нет миллиарда пошли на". Я думал посоветуете что в исходном коде поправить в алгоритме AutoSeq.
В данном случае проблема не в скорости декодирования, а в неточной последовательности переключения режимов.

[UX8IW]

Цикл циклом

Да нет, в этом то как раз и дело. В программу заложен алгоритм выполнения определенных последовательностей, а если он нарушается, то "звыняйте"...
Что делать, Николай вам предельно ясно ответил.

[RX4HX]

Но у Вас QSO заносится в лог автоматом с момента начала передачи 73. А для Вашего корреспондента, по регламенту, QSO еще не завершилось, он не получил от Вас 73

Николай, Вы не поняли - от меня больше никакого 73 не требуется, да и программа не передает. Так что QSO 100% завершено.