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

[US5WE]

К большому сожалению. Глюки бывают только в голове. А тут, нарушение алгоритма работы программы. И ещё, Здесь идёт тестирование софта. И софт вместе с базовой версией WSJT-X давно ушёл вперёд. Сейчас в тестирование, версия JTDX v2.1.0-rc151. Будьте внимательней.

Может у Вас они и бывают, и кто-то куда-то может и "ушел", а тут приведена реально и регулярно возникающая эфирная ситуация, которая в одном случае привела к срыву связи с квадратом EL87, а учитывая, что диапазон на Северную Америку открывается крайне редко, второго шанса в текущем сезоне может и не случиться.
Если у Вас есть, что сказать по существу, буду благодарен.

Порт управления PTT физический? COM или USB?
что говорит $ls -l /dev/ttyS* (для COM) или $ls -l /dev/ttyUSB* (для USB)?
И хорошо бы глянуть настройки CAT-PTT. Попробуем разобраться.

По поводу звука. Давно заметил, что если прервать передачу практически сразу после ее начала (не более чем через 1-2 секунды), то в следующем цикле звука не будет. Но последующие будут со звуком.

Я использую только физические порты - один на мамке плюс 2 на PCI мультяшке. Конфигурация машины в посте ниже.
Управление по ttyS0, адрес и IRQ стандартные.

[RN9AZ]

Может у Вас они и бывают, и кто-то куда-то может и "ушел", а тут приведена реально и регулярно возникающая эфирная ситуация, которая в одном случае привела к срыву связи с квадратом EL87, а учитывая, что диапазон на Северную Америку открывается крайне редко, второго шанса в текущем сезоне может и не случиться.
Если у Вас есть, что сказать по существу, буду благодарен.



Я использую только физические порты - один на мамке плюс 2 на PCI мультяшке. Конфигурация машины в посте ниже.
Управление по ttyS0, адрес и IRQ стандартные.

Вы сами при проведении QSO, похоже наступаете на одни и те же грабли. Не давая программе закончить QSO самостоятельно. А ввод CALL из окон, нарушает работу программы. Зачем вводить вновь, программа сама введет что надо. Даже если вы дадите команду на CQ. Да и с проблемой COM PTT. Её решили в последней версии. Да и со звуком сейчас всё а полном порядке. Всё что вы описали, было и у меня. Но сейчас всё работает.

[UR5LCZ]

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

[US5WE]

... Не давая программе закончить QSO самостоятельно. А ввод CALL из окон, нарушает работу программы. Зачем вводить вновь, программа сама введет что надо. Даже если вы дадите команду на CQ. Да и с проблемой COM PTT. Её решили в последней версии.

Почему софт на полученный R+01 независимо от того, кликнут ли позывной или нажата снова клавиша EnableTX начинает передавать R-06, а не RR73? Что касается СОМ РТТ, вы что в Линуксе работаете что утверждаете о том что "проблема решена"?
Надеюсь, что специалисты, которые в отличие от Вас, понимают о чем речь и помогут описанные проблемы решить.

- - - Добавлено - - -

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

Иван спасибо, интересно.
Мы тут с локатором зовем только экспедиции F/H, которых на 50 МГц с прошлого года не наблюдалось. Остальное время только рапортом опять же из-за экономии времени. Вчера проскочил KX4R давший 10-й штат GA.

[R0JF]

Управление по ttyS0, адрес и IRQ стандартные.

А что отвечает на $ls -l /dev/ttyS0 ?

[US5WE]

А что отвечает на $ls -l /dev/ttyS0 ?

crw-rw---- 1 root dialout 4, 64 Jun 26 23:47 /dev/ttyS0

[R0JF]

crw-rw---- 1 root dialout 4, 64 Jun 26 23:47 /dev/ttyS0

Угу.
А юзер, включён в группу dialout?

Попробуйте скомандоватьв терминале
$sudo chmod 666 /dev/ttyS0
и проверьте будет ли работать PTT.

[UA3DJY]

У меня пропадали аудио блоки время от времени, раз в несколько минут.
После того, как я выставил высокий приоритет обеим файлам, это стало происходить постоянно.
Если посмотреть по загрузке проца, то программа jtdx.exe практически не потребляет ресурс ЦП.
А jtdxjt9.exe потребляет до 70 процентов в момент декодирования, при 7 ядрах, закрепленных для декодирования (SWL).
После того, как вернул приоритет до "среднего" и закрепил 4 ядра для декодирования, аудио блоки перестали пропадать. Тьфу-тьфу.
Может аудио блоки и пропадали из-за того, что вся моща проца (7 ядер) была принудительно задействована на декодирование.
Lag увеличился на пол секунды, загрузка проца упала до 45 процентов в момент декода.
Буду наблюдать.

Поэтому и говорил что приоритет можно попробовать поднять только для процесса jtdx.exe - этот процесс отвечает за прием аудио, процесс jtdxjt9.exe отвечает за работу декодеров и конкурирует с jtdx.exe за ресурсы процессора.

[US5WE]

Угу.
А юзер, включён в группу dialout?

Попробуйте скомандоватьв терминале
$sudo chmod 666 /dev/ttyS0
и проверьте будет ли работать PTT.

Скомандовал, завтра буду на позиции - проверю. Пока безрезультатно "пасем" 6W1TA но из DX видим только Казахстан. Фильтр на Европу включен.

[UA3DJY]

Знаете, не обижайтесь, но... Столько слов было о "выдающемся" компе, а по-факту... Как бы сказать... ДОрого, ОЧЕНЬ дОрого, но нерационально.

https://ark.intel.com/content/www/ru...38,97147,97129 -

Это ссылка на страницу сравнения 3-х процессоров. Первые 2 у меня. Куплены давно уже (раньше 2017-го, это точно), довольно недОрого, но с предварительным подбором и оценкой возможностей.
Так открою Вам секрет, Ваш процессор всего лиш ненамного "шустрее", и то исключительно из-за тактовой частоты. 2 МБ кэша в прибавку тоже немного дают прирост скорости, но уже не так значительно. Реально, в "боевой" обстановке, (т.е. нагрузить равными задачами) Ваш аппарат будет ненамного шустрее моих (которые на 30% дешевле!!!). Да и греется Ваш как паяльник...
А уж тягаться с Xeon`ами с Али - тут Ваш "суперкомпьютер" явно будет аутсайдером.

Вы когда апгрейдом занимаетесь, не берите "топовые" процессоры"!!! Названия типа i9-i100 -- это еще не показатель скорострельности. Часто и i3 может в реальной обстановке обскакивать и i5 и i7. У меня на работе i3 компилит jtdx на 1,5 минуты быстрее, чем домашний i5... Специально засекал.
Хотя кэш меньше (но 4 ядра и тактовая чуть выше)...

Скромнее надо быть, когда хвастаетесь "железом". Цена и название далеко не всегда являются реальным показателем качества (и скорости работы).

Игорь, к сожалению в использовании JTDX Windows уступает операциокам Linux и OS X и требует дополнительного запаса по ресурсам процессора. Есть смысл сравнивать процессоры в рамках одной операционной системы.

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

- - - Добавлено - - -

Скомандовал, завтра буду на позиции - проверю. Пока безрезультатно "пасем" 6W1TA но из DX видим только Казахстан. Фильтр на Европу включен.

Можно попробовать широкополосный поиск FT8 декодером, поместив позывной в окно DX Call и включив опцию поиска. Желательно на rc151, на старых версиях в этом функционале есть ложные декоды.

[R6LCF]

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

Вас устроит таблица в LoTW по DXCC.Подвержденные страны по диапазонам и модам. Сразу предупреждаю ,страны я не собираю ,нет такой цели и скорее всего не будет никогда.Если займусть конкретно ,соберу ,без вопросов. Повторюсь ,меня страны не интересуют. Меня интересуют связи с редкими DX на проблемных в данный момент диапазонах с удаленных континентов и редких островов. Думаю вообще акцентировать внимание на 144МГц ,ну и понятно любимой мной 10м.куда же без десятки.
Да напишите ,нет ........Все понятно?

[UA3DJY]

Глюк №1.
Этот глюк переходит из версии в версию и особенно критичен на 6 метров, где прохождение открывается на минуты.
Например, вчера зову TF3ML.
173630 -12 0.1 670 ~ CQ DX TF3ML HP94 Iceland
173715 Tx 2219 ~ TF3ML US5WE -12
173745 Tx 2219 ~ TF3ML US5WE -12
173815 Tx 2219 ~ TF3ML US5WE -12
173845 Tx 2219 ~ TF3ML US5WE -12
Сигнал Олафура исчезает, останавливаю передачу, но тут прилетает:
173930 -6 0.1 670 ~ US5WE TF3ML R+01
Кликаю на него, но вместо RR73 система начинает передавать:
173945 Tx 2219 ~ TF3ML US5WE R-06
и приходится судорожно жать на Tx4, что приносит, через некоторое время, результат.
173949 Tx 2219 ~ TF3ML US5WE RR73
174015 Tx 2219 ~ TF3ML US5WE RR73
174045 Tx 2219 ~ TF3ML US5WE RR73
174115 Tx 2219 ~ TF3ML US5WE RR73
174130 -8 0.1 670 ~ US5WE TF3ML 73

JTDX рассматривает направление CQ DX на базисе континента, в данном случае CQ было адресовано не Вам. Но причин может быть несколько, чтобы установить причину смены рапорта в конкретном случае необходима запись диагностики в файл ALL.TXT.

Дополнение: в этом случае нажатие кнопки Halt TX очистило позывной из истории QSO:

void MainWindow:n_stopTxButton_clicked() //Stop Tx
{
...
if(m_skipTx1 && !m_hisCall.isEmpty() && (m_ntx==2 || m_QSOProgress==REPORT)) m_qsoHistory.remove(m_hisCall);

В следующий раз попробуйте пожалуйста вместо нажатия кнопки Halt Tx выключить кнопку Enable Tx, последняя кнопка не должна вызывать очистки позывного из истории.

[RW4M]

...
По поводу звука. Давно заметил, что если прервать передачу практически сразу после ее начала (не более чем через 1-2 секунды), то в следующем цикле звука не будет. Но последующие будут со звуком.

Тоже наблюдается на протяжении практически всех версий JTDX... rc-151, W64, i3, 8ГБ 3ГГц, Audio встроенное в материнку... Почему так?

[UA3DJY]

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

Вас устроит таблица в LoTW по DXCC.

Коллеги, сравнение достижений пожалуйста в личной переписке.

- - - Добавлено - - -

По поводу звука. Давно заметил, что если прервать передачу практически сразу после ее начала (не более чем через 1-2 секунды), то в следующем цикле звука не будет. Но последующие будут со звуком.

Тоже наблюдается на протяжении практически всех версий JTDX... rc-151, W64, i3, 8ГБ 3ГГц, Audio встроенное в материнку... Почему так?

Запись диагностики в ALL.TXT может подсказать причину, при сбое самого аудиоустройства если JTDX rc151 запустить с командного окна то ошибка может быть выведена в командное окно.

[R6LCF]

сравнение достижений пожалуйста в личной переписке.

Все понял.