-
10.12.2020, 16:50 #25981
- Регистрация
- 05.03.2015
- Сообщений
- 5,356
- Поблагодарили
- 7745
- Поблагодарил
- 795
Сегодня был еще один патч в Hamlib для свежих моделей Yaesu, сделаю с ним сборку win64, опубликую линк на форуме.
- - - Добавлено - - -
Повторные запуски декодера сделаны для широкой полосы. Можно было бы сфокусироваться на DT корреспондента, но основная проблема в другом: декодирование и вычитание мешающих сигналов. Эти сигналы не всегда на приемной частоте QSO, и часто декодирование напоминает разгадывание кроссворда, где к сигналу корреспондента можно подобраться лишь последовательно декодировав и вычтя два..три других накладывающихся спектром сигнала, один из которых пересекается с сигналом корреспондента. То есть требуется декодирование в достаточно широкой полосе, в результате увеличение времени декодирования.Последний раз редактировалось UA3DJY; 10.12.2020 в 17:00.
-
10.12.2020, 16:54 #25982
-
10.12.2020, 18:10 #25983
- Регистрация
- 05.03.2015
- Сообщений
- 5,356
- Поблагодарили
- 7745
- Поблагодарил
- 795
Включение фильтра частот по списку кандидатов уже приводит к потере декодирования на приемной частоте в части интервалов, та же причина разгадывания кроссворда.
В этом отношении прореживание списка кандидатов наносит меньше ущерба чем использование фильтра JTDX.
- - - Добавлено - - -
Для пользователей у кого сбоит CAT Hamlib c трансиверами Yaesu, сборка JTDX rc154-win64 сделана на основе Hamlib commit 7a93ce3
собранный софт(win64) https://cloud.mail.ru/public/2CEJ/3TC2hLUXY
кодовая сумма JTDX-2.2.0-rc154_Yaesu_patch-win64.exe
SHA-256: FBC1FBB4D0705C6EAF4994D70E0E56FAD56788ADD3B0E0BF65980EF66242E8E7
Изменения в коде Hamlib можно посмотреть здесь.Последний раз редактировалось UA3DJY; 10.12.2020 в 18:32.
-
10.12.2020, 19:31 #25984
-
10.12.2020, 20:12 #25985
- Регистрация
- 14.05.2018
- Адрес
- Санкт-Петербург
- Возраст
- 57
- Сообщений
- 466
- Поблагодарили
- 352
- Поблагодарил
- 134
-
10.12.2020, 22:01 #25986
- Регистрация
- 05.03.2015
- Сообщений
- 5,356
- Поблагодарили
- 7745
- Поблагодарил
- 795
Пора ставить диагностику и задействовать разработчиков Hamlib.
Сборка с диагностикой CAT Hamlib, пишет два лога:
в папке %TEMP%, имя файла JTDX_trace.log
в папке где находится лог связей JTDX, имя файла JTDX_trace.log
Оба лога пожалуйста отправьте мне на почту c_igor inbox ru
собранный софт(win64) https://cloud.mail.ru/public/3sz7/3crJdr2KH
кодовая сумма JTDX-2.2.0-rc154_CAT_debug-win64.exe
SHA-256: 3574F361A3B80E5D5B9F1A4135B667B62DE5C203719D4AC6C7967B41D12D2AFB
PS пришло сообщение что последнее обновление Hamlib в rc154_Yaesu_patch починило CAT c FTDX101Последний раз редактировалось UA3DJY; 10.12.2020 в 22:11.
-
11.12.2020, 06:49 #25987
- Регистрация
- 03.09.2017
- Адрес
- Tula
- Возраст
- 43
- Сообщений
- 273
- Поблагодарили
- 381
- Поблагодарил
- 373
Плохо что больше не проходит , именно в таком "полуручном" режиме было сработано (и подтверждено!) около 10% из wanted DXCC\CQ zones\US States.
Человек он много на что способен : например заранее подведя указатель мыши к следующему в последовательности макросу "клацнуть кнопкой" отправив правильное ответное сообщение , это занимает не более 0,1 сек.
Вообще у нас в запасе изрядно времени на смену макроса (скрины старых экспериментов не нашёл , пришлось делать по новой).
Вот запоздалая реакция оператора "на ходу" меняющего макрос (то самое "полуручное" управление):
Видно, да - у нас "в запасе" 6 (!!!) секунд на "жмакнуть правильный макрос"
А вот так сказать наиболее приближённое к реальной ситуёвине в DXинге : запоздалый ответ "автомата" не тем макросом (вследствии большой задержки окончания декодирования) + ещё и запоздалая реакция оператора в полуручном режиме сменившего макрос:
Видно , да - умнющий софт на приёмной стороне декодирует вплоть до 4х секунд (!!!) задержки (3 секунды на Lag на передающей стороне +1 секунда на неторопливого оператора там же).
Помехи (не сказать хаос) будут как раз в варианте: "автопоследовательность не отработала - оператор моментально жмёт нужный макрос -но софт упорно блокирует передачу - и упустивший DXа оператор победив наконец софт видит что его Tx частоту уже тем временем заняли - и в попытках ещё раз дозваться DXа начинает таскать свой TX маркер по всему водопаду сея помехи и хаос"
Но никак не в варианте : "оператор в разумном интервале помог автопоследовательности быстро и вменяемо отработать QSO".
Сомнительный вариант , у меня на втором скрине добавилась как раз таки секунда из-за необходимости "таскать указатель мыши" по кнопкам Enable Tx - Tx2 нажимая их в необходимой последовательности. upd: И выбирал то в итоге не то (надо было Tx3 , но с этими "молниеносными тасканиями указателя мыши по кнопкам" жал на Tx2 , только сейчас заметил)
В то время как при работе в реальном эфире "жмакнуть" по нужному макросу (если указатель мыши уже заранее подведён к нему) занимает не более 0,1 сек. upd: возможность ошибки в выборе при этом многократно снижается (см первый скрин).
Усложняем и удлиняем минимально необходимое действие - сеем дополнительные помехи и хаос на бэндах (их и так там хватает).
Мда , если на максимальных то настройках декодирования вожделенный DX декодируется "на грани" , то для проведения QSO совсем не айс ухудшать декодирование вообще никак и не насколько .
К хорошему привыкаешь быстро (поэтому я например бил аларм прямо в теме когда с переходом на FT8v2 в JTDX перестал давать результат функционал подпрохода) , от каждой новой версии ждёшь : "ещё лучше , ещё злее - чтобы вытаскивало доселе невытаскиваемое и давало возможность отработать заведомо гиблое QSO" , а тут теперь вона как : "робот главнее человека" + уменьшить количество запусков декодера + проредить список кандидатов на декодирование (чёт мне сильно не по себе от мысли что софт "под эту гребёнку" проредит вдруг и меганужное).
С привычкой некоторых DX "прыгать" на частоту зовущего , или пропав на пару циклов вдруг обьявиться на другой частоте , да нередкой ситуёвиной : "долго и безуспешно зовём одного редчайшего DX , да вдруг в совершенно другом месте водопада возникает другой редчайший DX" - смысл декодировать по максимуму и во всей полосе есть всегда.Последний раз редактировалось R2PU; 11.12.2020 в 06:57.
Роман R2PU , ex R3PJT . Город - герой оружейников и мастеровых Тула.
Словом, делом, в сети или в реале - помогу коллегам чем смогу ... хоть чутка и в меру своих сил сделать этот мир немного лучше и светлей ))).
-
11.12.2020, 11:55 #25988
- Регистрация
- 11.12.2020
- Возраст
- 67
- Сообщений
- 1
- Поблагодарили
- 0
- Поблагодарил
- 0
Добрый день, подскажите по проблеме TX/RX IC-746Pro wid 7 -64 после установки.ошибка Hamlib откатить ни на какую версию не удаётся начиная с 147 до 152, вернул WSJX, то же самое,заранее благодарен
Последний раз редактировалось UA3DJY; 11.12.2020 в 12:25.
-
11.12.2020, 12:27 #25989
- Регистрация
- 05.03.2015
- Сообщений
- 5,356
- Поблагодарили
- 7745
- Поблагодарил
- 795
Исправил ошибку в описании алгоритма автоматического выбора количества потоков FT8 декодера начиная с JTDX rc153:
количество логических ядер процессора/количество потоков в декодере
1 / 1
2..4 / (количество логических ядер процессора)-1
5..8 / (количество логических ядер процессора)-2
9..15 / (количество логических ядер процессора)-3
>15 / 12
- - - Добавлено - - -
В деталях сообщения есть описание ошибки, покажите пожалуйста эту картинку.Последний раз редактировалось UA3DJY; 12.12.2020 в 09:35.
-
11.12.2020, 13:40 #25990
- Регистрация
- 03.02.2006
- Возраст
- 48
- Сообщений
- 12,265
- Поблагодарили
- 5014
- Поблагодарил
- 2720
73 de RX4HX, Alexei, http://rx4hx.qrz.ru
-
11.12.2020, 14:39 #25991
- Регистрация
- 05.03.2015
- Сообщений
- 5,356
- Поблагодарили
- 7745
- Поблагодарил
- 795
Разница может быть при внесении QSO в лог по приглашению и при автоматическом внесении QSO в лог:В любом случае мы алгоритм в этой части не меняли по крайней мере по сравнению с rc152.
- - - Добавлено - - -
Немного деталей по вопросу Виктора UA3QJJ:работал jtdx v152, появилась v154 скачал .установил, пропала catsistem?
пишет ошибка hamlib ввода вывода, и в mix, частота настройки меняется.на передачу не переходит
и после перезагрузки диапазон переключать перестала, может сможете проконсультировать,заранее благодарен
IC-746PRO если включаю JTDX, то пропадает Cat MixW, перезапускаю MixW работает
Коллеги, если кто нибудь использует JTDX/WSJT-X и MixW, подскажите пожалуйста по тонкостям конфигурации COM портов в таком сочетании и порядку запуска используемых в этой связке программ.Последний раз редактировалось UA3DJY; 11.12.2020 в 17:35.
-
11.12.2020, 16:52 #25992
-
12.12.2020, 01:35 #25993
- Регистрация
- 13.03.2017
- Сообщений
- 34
- Поблагодарили
- 27
- Поблагодарил
- 521
-
12.12.2020, 07:28 #25994
- Регистрация
- 02.01.2009
- Адрес
- Петровск
- Возраст
- 63
- Сообщений
- 9,515
- Поблагодарили
- 4648
- Поблагодарил
- 2187
Никогда не работал в "полуручном" режиме. Всегда, с самого освоения FT8, работал в полуавтомате - выбираю позывной сам, все остальное - программа. Вношу связь в лог сам. Считаю, что в "полуручном" режиме так используется не полные возможности программы. Зачем делать шаг назад, если можно идти вперед? А если, в нужный момент, вас отвлекли от монитора или зазвонил телефон, или ...что-то еще помешало. Что тогда? Ждать следующий цикл? Тем самым затягивая связь и отнимая время у других. Или попал мышкой не в тот макросс - это еще хуже. Считаю, что этот вариант, с ручным выбором макроссов, надо убрать вообще. Или сделать, чтобы они появлялись из отдельной вкладки в "Настройках". Результат - меньше ошибок будет, отсюда - меньше мешать друг другу будем. Ну, если понадобиться какому-нибудь "динозавру" такой "полуручной" режим, то включит.
Последний раз редактировалось RX4CD; 12.12.2020 в 07:31.
73. Sergey "Лучше самоизолироваться, чем заземлиться".
-
12.12.2020, 08:16 #25995
- Регистрация
- 09.02.2011
- Адрес
- Верхний Уфалей Челябинской области
- Сообщений
- 63
- Поблагодарили
- 10
- Поблагодарил
- 16
Здравствуйте дорогие форумчане! При работе в jtdx появляется сообщение: invalid floating point operation, какая запятая плавает? Подскажите, что не так? Спасибо, ua9aoh.
UA9AOH Виктор
Социальные закладки