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

[RA3DNC]

Теперь можно смотреть логи с диагностикой, в zip их и мне на почту пожалуйста, необходимо время сбоя в UTC.

Отправил

[UA3DJY]

Трансивер FT-1000MP Mark V, работает в связке с microHAM Station Master при помощи SDC. При необходимости подключаю на прием SS2, поэтому выбран протокол TS-480.

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

Расстройка выключена, но ситуация именно такая, то вверх, то вниз.

У Вас microHam отвечает что трансивер использует режим RTTY, это режим нижней боковой полосы. Hamlib для TS480 в режиме RTTY определяет полосу пропускания фильтра 500 Гц и, несмотря на то что в JTDX выбран SPLIT RIG, Hamlib в момент сбоя пытается управлять частотой VFO A:

Hamlib: kenwood_get_mode called
Hamlib: kenwood_transaction: cmdstr = MD
Hamlib: kenwood_transaction: read_string(len=4)='MD6;'
Hamlib: kenwood2rmode called
Hamlib: rig_passband_normal called
Hamlib: rig_passband_normal: return filter#2, width=500
"HamlibTransceiver::do_poll:" rig_get_mode mode = RTTY bw = 500
...
Hamlib: rig_set_freq called vfo=currVFO, freq=1.40775e+07
Hamlib: kenwood_set_freq: tvfo=VFOA
Hamlib: kenwood_transaction called
Hamlib: kenwood_transaction: cache invalidated
Hamlib: kenwood_transaction: cmdstr = FA00014077500

Какой вид модуляции выбран на трансивере? Думаю что сбой уйдет если на трансивере выбрать USB, кроме этого эмуляция SPLIT Fake It на VFO A использует меньше кода Hamlib, а значит и меньше вероятность сбоя при стыковке разных CAT протоколов через microHAM.

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

Нашел в логе причину сбоя, ответ microHam на команду IF при нормальной работе:

Hamlib: kenwood_transaction: read_string(len=38)='IF0000357300000000+000000000060010000;'
Hamlib: kenwood_get_vfo_if: priv->tx_vfo=VFOB

и при сбое:

Hamlib: kenwood_transaction: read_string(len=38)='IF0001407700000000+000000000060000000;'
Hamlib: kenwood_get_vfo_if: priv->tx_vfo=VFOA

сбой произошел раньше появления скачков частоты, вот момент сбоя:

2021-01-04T21:22:26.521Z(C:\JTSDK64-Tools\tmp\wsjtx\HamlibTransceiver.cpp:60)Debug: Hamlib: kenwood_transaction: read_string(len=38)='IF0000357300000000+000000000060010000;'
2021-01-04T21:22:27.518Z(C:\JTSDK64-Tools\tmp\wsjtx\HamlibTransceiver.cpp:60)Debug: Hamlib: kenwood_transaction: read_string(len=38)='IF0000357300000000+000000000060000000;'

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

Интересно, 04 января в 21:22:27 UTC Вы выключали SPLIT на самом трансивере?

[R0JF]

а значит и меньше вероятность сбоя при стыковке разных CAT протоколов через microHAM.

Игорь, а microHAM разве не просто транслирует обмен? Я думал, что задача всех этих интерфейсов - просто приведение к норме уровней TX/RX, ну и эмуляция COM-порта при USB подключении. А microHAM сам обрабатывает CAT команды что-ли? Но зачем?

Я просто не в курсе, не пользовался этим интерфейсом.

[UA3DJY]

Игорь, а microHAM разве не просто транслирует обмен? Я думал, что задача всех этих интерфейсов - просто приведение к норме уровней TX/RX, ну и эмуляция COM-порта при USB подключении. А microHAM сам обрабатывает CAT команды что-ли? Но зачем?

Я просто не в курсе, не пользовался этим интерфейсом.

В инструкции на эту модель нет информации что обрабатывает, но по блок схеме процессор находится между USB разъемом и подключением CAT к трансиверу (процессор занимается ретрансляцией CAT команд и ответа трансивера, кроме этого есть поддержка Y соединения трансивера с двумя программами, то есть процессор может раскладывать CAT ответы трансивера в определенные адреса/виртуальные последовательные порты и объединять CAT команды двух программ в один физический CAT интерфейс, такое исполнение приводит к задержкам и уже вызвало ряд проблем в работе CAT Hamlib c трансиверами Yaesu, в результате уже есть несколько патчей в Hamlib учитывающих задержки microHam).

[R0JF]

В инструкции на эту модель нет информации что обрабатывает,

Да нет, есть! Кстати, спасибо за ссылку! Не читал раньше.

"The CAT channel is used by the host application to control transceiver frequency, mode, and many otherparameters. The application communicates with the radio using a serial protocol. " - заметь! Разговор идёт об APPLICATION! Вот она - информация, что обрабатывает. Раз ПРИЛОЖЕНИЕ работает с CAT. (Если "между строк" читать).

Понял. Не хочу себе microHAM.

[UA3DJY]

Да нет, есть! Кстати, спасибо за ссылку! Не читал раньше.

"The CAT channel is used by the host application to control transceiver frequency, mode, and many otherparameters. The application communicates with the radio using a serial protocol. " - заметь! Разговор идёт об APPLICATION! Вот она - информация, что обрабатывает. Раз ПРИЛОЖЕНИЕ работает с CAT. (Если "между строк" читать).

Понял. Не хочу себе microHAM.

Application здесь например JTDX. Но скорее всего microHam запоминает идущие в сторону трансивера команды чтобы потом разруливать на них ответы при использовании двух applications (двух программ и виртуальных COM портов).

Потенциально конфликтное решение для случаев когда например одна программа запросит вид модуляции CW либо Data/Packet а другая USB, впрочем как и все остальные решения с использованием Y-соединения нескольких виртуальных COM портов.

[R0JF]

Application здесь например JTDX. Но скорее всего microHam запоминает идущие в сторону трансивера команды чтобы потом разруливать на них ответы при использовании двух applications (двух программ и виртуальных COM портов).

Хм... Ну, может и так. Я не очень силён в "техническом английском". Вернее - совсем плох.

Но имхо на аппаратном уровне делать сплиттер ещё приемлемо (я про буферизацию и не более), но почему он свои "фантазии" вносит в протокол? Скопировал-задержал-передал -- это типа нормально. Хотя далеко не везде! Но изменения в посылках?
Нет, я иначе мыслю. Всё-таки сам комп должен этим заниматься. А "интерфейс" - у него задача простая -- "что принял -- то и передал".

ЗЫ Игорь, я тебе сбросил ссылку на сборку RC155 для Raspberry PI4 под RaspiOS. Может кто нуждается.

[UA3DJY]

ЗЫ Игорь, я тебе сбросил ссылку на сборку RC155 для Raspberry PI4 под RaspiOS. Может кто нуждается.

Благодарю, сборка JTDX rc155 под операционную систему RaspiOS Buster опубликована на сайте JTDX.

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

Но имхо на аппаратном уровне делать сплиттер ещё приемлемо (я про буферизацию и не более), но почему он свои "фантазии" вносит в протокол? Скопировал-задержал-передал -- это типа нормально. Хотя далеко не везде! Но изменения в посылках?

Ждем ответа от Олега RA3DNC, если Олег сам выключил Split на трансивере то требуется уведомление о несоответствии состояния Split в трансивере настройкам программы JTDX, если это microHam чудит то еще и перепрошивка microHam.

[UA3DJY]

В Северной Америке сейчас обкатывают новую моду Q65, предназначена для "проведения минимального двухстороннего QSO в условиях особенно сложного прохождения":

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

Эффективна для тропосферного и ионосферного рассеивания, связи с отражением от Луны, для сигналов с быстрыми замираниями и большой девиацией частоты(эффект Доплера).

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

JTDX, сохранение уровня звука на передачу по диапазонам: в rc156 будет доработка этого функционала для тех пользователей кто переключает диапазоны с трансивера.

[UN5J]

В Северной Америке сейчас обкатывают новую моду Q65, предназначена для "проведения минимального двухстороннего QSO в условиях особенно сложного прохождения" Эффективна для тропосферного и ионосферного рассеивания, связи с отражением от Луны, для сигналов с быстрыми замираниями и большой девиацией частоты(эффект Доплера).

Игорь, жду с нетерпением... Нужно для 160М.

[UA6JBQ]

С Новым Годом и Рождеством всех!
После установки rc155 стал пропадать прием.
Лечится только полной переустановкой программ и удалением INI-файла и то до выключения компьютера.

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

для примера в MMVARI все работает.

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

[RX3ASP]

После установки rc155 стал пропадать прием

А если Монитор нажать?

[UA3DJY]

Игорь, жду с нетерпением... Нужно для 160М.

На 160 и 80м быстрые замирания сигналов есть в основном для небольшого радиуса связи (менее 2000 километров), по опыту эти замирания в определенных условиях прохождения(одинаковый уровень сигналов многолучевого прохождения под разными углами возвышения) успешно ломают прием RTTY сигналов со своего континента при достаточно высоком уровне сигнала на входе приемника.

[UN5J]

На 160 и 80м быстрые замирания сигналов есть в основном для небольшого радиуса связи (менее 2000 километров), по опыту эти замирания в определенных условиях прохождения(одинаковый уровень сигналов многолучевого прохождения под разными углами возвышения) успешно ломают прием RTTY сигналов со своего континента при достаточно высоком уровне сигнала на входе приемника.

Понял, прошу прощения! Вопрос снят.

[RU9MN]

Игорь, жду с нетерпением... Нужно для 160М.

Здесь поможет FST4, которая уже есть и успешно используется на ДВ (136 кГц).