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

[UA1OMZ]

Если переключало, значит и дальше будет переключать, как там у авто-механиков, хороший стук он .........

Надеюсь, будем ждать 145..., а пока и ручками не в тягость моду передернуть...

[R6LCF]

И мне тоже безразлично Ваше мнение

Александр.
Как говорят вы становитесь в "позу" и ничего и никого не желаете слушать.Повторюсь это ваше личное дело.
Когда писал вам ответ ,упомянул что предыдущие аппараты были соединены с компом через внешний интерфейс ,это был RigExpert T1-5 ,ушел к новому пользователю,отлично связка работала.Хотя оговорюсь, что с Kenwood.....звук был через USB AudioCodec по USB шнурку,а САT и PTT через интерфейс,мне было так удобнее и прием был значительно лучше.
Решать вам!

[UA1OMZ]

Переслал почтой линк на сборку rc145_2, возможно на этой сборке проблема уйдет.

Игорь, спасибо за внимание и оперативность, проверил, проблема не ушла, со всех мод (PKT,RTTY,AM/FM,CW-USB,CW-LSB) переключает, а с LSB не хочет...
Так же в 145_2 попробовал удалил ini, настроил cat, результат такой же.

[UA3DJY]

Игорь, спасибо за внимание и оперативность, проверил, проблема не ушла, со всех мод (PKT,RTTY,AM/FM,CW-USB,CW-LSB) переключает, а с LSB не хочет...
Так же в 145_2 попробовал удалил ini, настроил cat, результат такой же.

Сверил код, в папке 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.

[LZ2HV]

HI UA3DJY
"старого аккаунта с позывным LZ2HV" у меня нет
Проста два года назад я питался сделат регистрациу на вашем форуме, но не палучилас (мжет бйт мая ошибка)
Из етова мамента в базе даннйх вашем форуме "lz2hv@abv.bg" етат mail адрес не-может сделат регисрациу
Если можна разблокирават из базу дннйх "lz2hv@abv.bg" и я сделайу регистрацйу снова как паложена
73
LZ2HV Christo Developer of MSHV Software

[UA1OMZ]

До конца этого года команда Hamlib собиралась выпустить версию 4.0 в общий доступ, желательно чтобы дефект был устранен до ее выпуска, чтобы патч попал в JTDX и WSJT-X.

Каким образом о дефекте можно сообщить команде Hamlib? Может кто-нибудь сделает это технически грамотно? Пожалуйста!

[RM1F]

Удалось "поймать" описанный в #21449 баг. Даже понятно, в результате какой дискуссии в форуме он был внесен
Диагностику отправил Игорю. Не сомневаюсь, что он и команда исправят быстро.

Я же пока, пожалуй, откачусь на 143 как более предсказуемую....

[UA3DJY]

Удалось "поймать" описанный в #21449 баг. Даже понятно, в результате какой дискуссии в форуме он был внесен
Диагностику отправил Игорю. Не сомневаюсь, что он и команда исправят быстро.

Я же пока, пожалуй, откачусь на 143 как более предсказуемую....

В этом сценарии есть конфликт опции JTDX 'Отключить передачу при ответе корреспондента другому оператору'. Конфликт возникает только когда корреспондент в общем диапазоне начинает передавать сообщения в нескольких слотах с программы MSHV. Режим гончей (Hound) игнорирует эту опцию при работе на специально выделенных частотах в F/H, при многослотовой передаче с MSHV в общем диапазоне в JTDX для проведения QSO с таким корреспондентом в настройках придется вручную отключить опцию.

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

Другого решения не видим поскольку корреспондент при ответе в FT8/FT4 часто меняет частоту передачи, попытка привязать смену частоты к шагу 60 Гц многослотовой передачи в FT8 в общих диапазонах будет явно проблемным решением.

[RW3DY]

Если можна разблокирават из базу дннйх "lz2hv@abv.bg" и я сделайу регистрацйу снова как паложена
73

Христо пароль старый логин LZ2HV

[UA3DJY]

Каким образом о дефекте можно сообщить команде Hamlib? Может кто-нибудь сделает это технически грамотно? Пожалуйста!

Наверно через подписку https://sourceforge.net/projects/ham...mlib-developer и запрос уже в переписке с разработчиками Hamlib. Обычно требуется сбор дополнительных данных либо проверка возможного решения, поскольку сбой идет на конкретном трансивере то общаться лучше Вам.

Для JTDX мы используем код Hamlib c ветки wsjtx (wsjtx branch).

[US4IRT]

Мне кажется, Игорь, что эту штуку пора убрать с виду. Пользуются ей единицы. Скорее всего те, кто не знает как отключить. Или пусть поживет?

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

[RM1F]

В этом сценарии есть конфликт опции JTDX 'Отключить передачу при ответе корреспондента другому оператору'. Конфликт возникает только когда корреспондент в общем диапазоне начинает передавать сообщения в нескольких слотах с программы MSHV.

Конфликт возникает не только в этом случае. Если бы только в многослоте - да и бог бы с ним... Хотя, с другой стороны, и MSHV имеет право на жизнь, и будет использоваться, а значит, и многослот неизвбежно придет в нашу реальность.

Я лично наблюдал (ага, в описанном в #21449 случае) как почти на частоте +/- несколько герц внезапно "выплывает" передача другого корреспондента. Что при нонешнем нестабильном прохождении с глубокими QSB бывает часто. И успешно декодируется. И эта посторонняя как бы передача сбивает алгоритм AutoSeq. При этом мой корреспондент отвечает мне - а передача отключается... Наверняка удастся поймать и увидеть в диагностике и такую ситуацию, правда, "ловля" может занять время, ибо требуется сочетание нескольких независимых факторов.

[LZ2HV]

Благодарности к RW3DY и UA3DJY
Сейчас все работает.

[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.

[UA3DJY]

Конфликт возникает не только в этом случае. Если бы только в многослоте - да и бог бы с ним... Хотя, с другой стороны, и MSHV имеет право на жизнь, и будет использоваться, а значит, и многослот неизвбежно придет в нашу реальность.

Я лично наблюдал (ага, в описанном в #21449 случае) как почти на частоте +/- несколько герц внезапно "выплывает" передача другого корреспондента. Что при нонешнем нестабильном прохождении с глубокими QSB бывает часто. И успешно декодируется. И эта посторонняя как бы передача сбивает алгоритм AutoSeq. При этом мой корреспондент отвечает мне - а передача отключается... Наверняка удастся поймать и увидеть в диагностике и такую ситуацию, правда, "ловля" может занять время, ибо требуется сочетание нескольких независимых факторов.

Есть еще одна возможная причина: AF TX/RX 666/666Hz, в этом случае критично определение 'владельца' частоты.

Если будете работать с разносом звуковых частот приема передачи то сбоев быть не должно. Особенно критично для многослотового режима MSHV - поскольку Христо заложил в код MSHV скачки частоты при передаче сообщений одному и тому же корреспонденту.

To LZ2HV: Христо, функционал смены TX частоты при передаче сообщений одному и тому же корреспонденту в режиме multianswering сделан преднамеренно? Если нет то можно ли такое поведение программы MSHV устранить хотя бы в общих FT8 диапазонах?