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

[UT8NT]

С введением в JTDX долгожданной моды FT4 пришлось перейти на UDP протокол для сохранения QSO в журнал как FT4. (Logger 32)
После нажатия на кнопку "ОК" в всплывающем окне для сохранения QSO в лог, запись в журнале логера появляется через 3-4 секунды.
По ТСР связь сохраняется мгновенно, но как MFSK. Так должно быть? я наверно не привык еще, но пока приходиться отвлекаться и контролировать "залетела" связь в журнал или нет...)

[UA3DJY]

Игорь вы написали:

- FT4 QSO вносится в лог в файл wsjtx_log.adi и через TCP сообщение как вид MFSK подвид FT4.
UDP команда Log QSO содержит вид FT4 и должна соотвествующим образом обрабатываться принимающей ее программой.

По UDP протоколу сохраняется в журнале как MFSK.
В программе MMVARI есть виды модуляции как MFSK-LSB, и MFSK-USB, и не дает возможности
произвести перестройку апаратного журнала по фильтру 'МОДУЛЯЦИЯ', с последующим подсчетом
количества проведенного QSO в данной моде, контроль повторов и т.д.
На мой взгляд не имеет значения вид это или подвид - если работаем в FT4, то и в LOG нужно передавать
по UDP как FT4 и все станет на свои места.

Передача UDP сообщения:

void MainWindow::acceptQSO2
..
m_messageClient->qso_logged (QSO_date_off, call, grid, dial_freq, mode, rpt_sent, rpt_received, tx_power, comments, name, QSO_date_on, operator_call, my_call, my_grid);

Проверил при внесении в лог, переменная mode имеет значение FT4, значит в UDP сообщении передается FT4 и то что Вы наблюдаете добавляет сам лог.

[UA3DJY]

С введением в JTDX долгожданной моды FT4 пришлось перейти на UDP протокол для сохранения QSO в журнал как FT4. (Logger 32)
После нажатия на кнопку "ОК" в всплывающем окне для сохранения QSO в лог, запись в журнале логера появляется через 3-4 секунды.
По ТСР связь сохраняется мгновенно, но как MFSK. Так должно быть? я наверно не привык еще, но пока приходиться отвлекаться и контролировать "залетела" связь в журнал или нет...)

Последняя версия ADIF стандарта 3.1.0:

mode: MFSK submodes: FSQCALL, FT4, JS8, MFSK4, MFSK8, MFSK11, MFSK16, MFSK22, MFSK31, MFSK32, MFSK64, MFSK128

То есть FT4 не получила самостоятельности как отдельный вид излучения, зарегистрирована как подвид излучения MFSK.

Logger32 обрабатывает UDP сообщение меняя FT4 на MFSK/FT4, если не задержка сообщений антивирусным ПО то задержка обработки в самом Logger32. Здесь немало пользователей Logger32, поделитесь пожалуйста своим опытом.

TCP сообщение содержит готовую ADIF строку с MFSK/FT4.

[RA3QH]

Кнопки SWL Hint Filter и опция autoFilter преднамеренно сделаны недоступными в FT4.

Игорь а в связи с чем это?
И будет ли режим контеста? Если будет то именно в этом режиме хотелось бы активную кнопку Filter

[EU1FQ]

Проверил при внесении в лог, переменная mode имеет значение FT4, то что Вы наблюдаете добавляет сам лог.

Если не интересно подтверждение в LoTW, то "фиолетово" как обозвать моду (субмоду) FT4. А если интересует, то только как Mode MFSK Submode FT4
https://lotw.arrl.org/lotwuser/defau...DXCC&ac_acct=1
Released ADIF Version 3.1.0, updated 2019/05/21

[LY3BG]

С введением в JTDX долгожданной моды FT4 пришлось перейти на UDP протокол для сохранения QSO в журнал как FT4. (Logger 32)
После нажатия на кнопку "ОК" в всплывающем окне для сохранения QSO в лог, запись в журнале логера появляется через 3-4 секунды.

У меня такой задержки нет.

[UA3DJY]

Кнопки SWL Hint Filter и опция autoFilter преднамеренно сделаны недоступными в FT4.

Игорь а в связи с чем это?
И будет ли режим контеста? Если будет то именно в этом режиме хотелось бы активную кнопку Filter

Filter пока ломает работу FT4 декодера, SWL в FT4 пока ничего не делает, Hint в FT4 должна быть включена из-за существующей в коде зависимости при этом сам FT4 AP декодер включен постоянно и независимо от кнопки Hint.

Поддержку контестов пока не планируем и сейчас в JTDX не применяются AP маски для декодирования контест сообщений при проведении QSO, то есть JTDX сейчас хуже декодирует сообщения при проведении QSO в контесте по сравнению с другими программами.

[UA3DJY]

Сейчас и в 139 версии окно DX Call не очищается при смене диапазона. Снова сделать очистку окна DX Call - ВОЗМОЖНО ?

JTDX: В закладке Misc/Разное есть опция которая очищает окно DX Call при смене диапазона:

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

[UA3DJY]

Если не интересно подтверждение в LoTW, то "фиолетово" как обозвать моду (субмоду) FT4. А если интересует, то только как Mode MFSK Submode FT4

Все верно, но WSJT-X придерживается устаревшего формата в UDP сообщении(думаю что на это есть причины, например придется доработать все логи под вариации mode/submode для обработки ранее созданных видов излучения) и чтобы не заставлять производителей логов делать уникальный код под JTDX мы остались на WSJT-X формате UDP сообщения.

[US4IRT]

А если интересует, то только как Mode MFSK Submode FT4

TQSL обрабатывает нормально и как моду FT4, и как моду FT8. Как MFSK не пробовал.

[LY3BG]

Если не интересно подтверждение в LoTW, то "фиолетово" как обозвать моду (субмоду) FT4. А если интересует, то только как Mode MFSK Submode FT4.

Нет сдесь никакой проблемы.

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

[RA3FP]

В новой версии JTDX-2.1.0-rc140 в режиме FT4 только на диапазоне 10.140 есть такая оранжевая полоска.



Что это значит?

[RC7C]

В новой версии JTDX-2.1.0-rc140 в режиме FT4 только на диапазоне 10.140 есть такая оранжевая полоска.

Что Вы можете стать в полосу моды WSPR .

[UA6JQ]

В новой версии JTDX-2.1.0-rc140 в режиме FT4 только на диапазоне 10.140 есть такая оранжевая полоска.
Что это значит?

...Это частоты WSPR. Что бы ТХ не включался в данном участке..

[EU1FQ]

TQSL обрабатывает нормально и как моду FT4, и как моду FT8. Как MFSK не пробовал.

Да, он сжёвывает все, что ему дадите Вот только отдает ее только как MFSK