Надеюсь, будем ждать 145..., а пока и ручками не в тягость моду передернуть...:s10:
Александр.
Как говорят вы становитесь в "позу" и ничего и никого не желаете слушать.Повторюсь это ваше личное дело.
Когда писал вам ответ ,упомянул что предыдущие аппараты были соединены с компом через внешний интерфейс ,это был RigExpert T1-5 ,ушел к новому пользователю,отлично связка работала.Хотя оговорюсь, что с Kenwood.....звук был через USB AudioCodec по USB шнурку,а САT и PTT через интерфейс,мне было так удобнее и прием был значительно лучше.
Решать вам!
Сверил код, в папке Yaesu Hamlib есть измененный исходник newcat.c, возможно этот добавленный кусок кода поломал установку USB при запуске программы:
case '2':
if (newcat_is_rig(rig, RIG_MODEL_FT891)) {
*mode = RIG_MODE_USB;
}
else { /* every other Yaesu */
*mode = RIG_MODE_LSB;
}
break;
Такой же код Hamlib должен быть в WSJT-X 2.1.2, если под ним тоже идет сбой то можете открывать запрос на поддержку у разработчиков софта Hamlib.
Альтернативно можете откатить этот кусок кода к варианту JTDX rc143 (WSJT-X 2.1.0):
case '2':
*mode = RIG_MODE_USB;
break;
После чего собрать Hamlib и уже с ним собрать rc144.
До конца этого года команда Hamlib собиралась выпустить версию 4.0 в общий доступ, желательно чтобы дефект был устранен до ее выпуска, чтобы патч попал в JTDX и WSJT-X.
HI UA3DJY
"старого аккаунта с позывным LZ2HV" у меня нет
Проста два года назад я питался сделат регистрациу на вашем форуме, но не палучилас (мжет бйт мая ошибка)
Из етова мамента в базе даннйх вашем форуме "lz2hv@abv.bg" етат mail адрес не-может сделат регисрациу
Если можна разблокирават из базу дннйх "lz2hv@abv.bg" и я сделайу регистрацйу снова как паложена
73
LZ2HV Christo Developer of MSHV Software
Удалось "поймать" описанный в #21449 баг. Даже понятно, в результате какой дискуссии в форуме он был внесен :)
Диагностику отправил Игорю. Не сомневаюсь, что он и команда исправят быстро.
Я же пока, пожалуй, откачусь на 143 как более предсказуемую....
В этом сценарии есть конфликт опции JTDX 'Отключить передачу при ответе корреспондента другому оператору'. Конфликт возникает только когда корреспондент в общем диапазоне начинает передавать сообщения в нескольких слотах с программы MSHV. Режим гончей (Hound) игнорирует эту опцию при работе на специально выделенных частотах в F/H, при многослотовой передаче с MSHV в общем диапазоне в JTDX для проведения QSO с таким корреспондентом в настройках придется вручную отключить опцию.
То есть не дефект, конфликт имеющегося функционала связанный с внедрением возможности использования передачи в нескольких слотах программой MSHV в общих FT4/FT8 диапазонах.
Другого решения не видим поскольку корреспондент при ответе в FT8/FT4 часто меняет частоту передачи, попытка привязать смену частоты к шагу 60 Гц многослотовой передачи в FT8 в общих диапазонах будет явно проблемным решением.
Наверно через подписку https://sourceforge.net/projects/ham...mlib-developer и запрос уже в переписке с разработчиками Hamlib. Обычно требуется сбор дополнительных данных либо проверка возможного решения, поскольку сбой идет на конкретном трансивере то общаться лучше Вам.
Для JTDX мы используем код Hamlib c ветки wsjtx (wsjtx branch).
Мне кажется, Игорь, что эту штуку пора убрать с виду. Пользуются ей единицы. Скорее всего те, кто не знает как отключить. Или пусть поживет?
Конфликт возникает не только в этом случае. Если бы только в многослоте - да и бог бы с ним... Хотя, с другой стороны, и MSHV имеет право на жизнь, и будет использоваться, а значит, и многослот неизвбежно придет в нашу реальность.
Я лично наблюдал (ага, в описанном в #21449 случае) как почти на частоте +/- несколько герц внезапно "выплывает" передача другого корреспондента. Что при нонешнем нестабильном прохождении с глубокими QSB бывает часто. И успешно декодируется. И эта посторонняя как бы передача сбивает алгоритм AutoSeq. При этом мой корреспондент отвечает мне - а передача отключается... Наверняка удастся поймать и увидеть в диагностике и такую ситуацию, правда, "ловля" может занять время, ибо требуется сочетание нескольких независимых факторов.
Благодарности к RW3DY и UA3DJY
Сейчас все работает.
RRR возможно еще используется в JT65 на диапазоне 6м, как опция в JTDX (по умолчанию RR73) она не мешает, убрать совсем - можем лишить функционала кого нибудь из пользователей JTDX.
Статистика RRR/73/RR73 из 1147 декодированных таких сообщений в моде FT4:
RRR 1.5%
73 42.3%
RR73 56.2%
Учитывая что RRR идет в паре с 73 то примерно 3.5% пользователей еще работают в последовательности сообщений RRR.
Есть еще одна возможная причина: AF TX/RX 666/666Hz, в этом случае критично определение 'владельца' частоты.
Если будете работать с разносом звуковых частот приема передачи то сбоев быть не должно. Особенно критично для многослотового режима MSHV - поскольку Христо заложил в код MSHV скачки частоты при передаче сообщений одному и тому же корреспонденту.
To LZ2HV: Христо, функционал смены TX частоты при передаче сообщений одному и тому же корреспонденту в режиме multianswering сделан преднамеренно? Если нет то можно ли такое поведение программы MSHV устранить хотя бы в общих FT8 диапазонах?