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

[R0JF]

Писал ранее, что долго длилась связь и при изменении величины принимаемого сигнала, связь не заканчивалась, а давался новый рапорт.
Я зафиксировал этот момент и прилагаю этот скрин.

А что не так?
Ваш корреспондент никак не может принять Ваш рапорт (помехи или что еще),
поэтому передает снова и снова. Ваша программа каждый раз адекватно отвечает.
Всё в порядке. Так и должно быть.

[UA3DJY]

Прошу помощи. Случайно, по недосмотру, очистил лог в формате .adi, но wsjtx.log содержит нужное. Есть ли какая-либо утилита чтобы преобразовать wsjtx.log в wsjtx.adi?
Руками уж очень муторно получается :-(

Уже думал о таком сценарии, может убрать эту опцию из JTDX чтобы пользователи машинально не удаляли свой лог?

[UA3DJY]

...Скопируйте файл wsjtx.log Потом скопированный файл переименуйте в wsjtx.adi вручную. Сотрите log, впишите adi.

Так не получится, файл wsjtx.log содержит данные в формате CSV (с использованием разделения запятой).

[RV9UP]

AdifMaster программка для преобразования текстовых в ADI. ADIF Master - advanced application for working with Ham Radio logbooks

Василий, спасибо. Разобрался и сделал быстро.

[RZ1OA]

Уже думал о таком сценарии, может убрать эту опцию из JTDX чтобы пользователи машинально не удаляли свой лог?

Убрать. Сам нажимал ночью Прада, копия была

[RZ1OA]

Может, кому то поможет.
Стал наблюдать, что при использовании опции фейк ит иногда (очень не часто) частота не возвращалась обратно, т.е. прием оставался на частоте предыдущей передачи (например 18101, а не 18100). Наблюдалось на разных компах и разных трансиверах. Выяснил, что так бывает, если одновременно запущен какой-либо лог, тоже использующий Cat. Софт может быть любым. Теперь просто выключаю такие программы при работе в JTDX и все гуд. Если фейк ит не испольщовать такой проблемы нет. И еще - у кого иногда выскакивает табличка с предложением настроить CAT - проблема того же рода - ищете, что еще запущено на компьютере и использует CAT.

[R6LCF]

чтобы пользователи машинально не удаляли свой лог?

Пользователем свои действия контролировать требуется и подумать прежде чем что то выполнить!

[UA3DTK]

Цитата Сообщение от US4IRT Да-а! При таком пайлапе лучше MSHV использовать на 5-ти сигналах, Роман.

UA3DJY <И тогда вся Европа будет ожидать/наблюдать пока Роман переработает все станции с Японии закрывая при помощи софта MSHV весь диапазон своей передачей и сигналами операторов которые его вызывают.>

...а если использовать один слот и выстроить их в очередь(10-30-50 позывных)...?

[UA3DJY]

Да-а! При таком пайлапе лучше MSHV использовать на 5-ти сигналах, Роман.

И тогда вся Европа будет ожидать/наблюдать пока Роман переработает все станции с Японии закрывая при помощи софта MSHV весь диапазон своей передачей и сигналами операторов которые его вызывают.

...а если использовать один слот и выстроить их в очередь(10-30-50 позывных)...?

Будут продолжать звать поскольку у них нет информации что позывной внесен в очередь. Все же пока самый оптимальный способ снизить мощность, поскольку зовут рапортами сразу видно какая мощность необходима.

[RV9UP]

Уже думал о таком сценарии, может убрать эту опцию из JTDX чтобы пользователи машинально не удаляли свой лог?

IMHO стоит убрать из корня меню "Файл". Оба действия "Очистить(Erase)". Перенести куда-нибудь в меню следующего уровня или в 'Misc'.
Что бы там не писалось про "Пользователь необходимо контролировать свои действия".

[US5WE]

Будут продолжать звать поскольку у них нет информации что позывной внесен в очередь. Все же пока самый оптимальный способ снизить мощность, поскольку зовут рапортами сразу видно какая мощность необходима.

Насколько я понял вопрос "по непонятной причине премодерируемого" Романа UR0MC, речь шла не о попытках уменьшить количество зовущих, что само по себе абсурдно (мы всегда, что в тестах, что в повседневке стремимся чтобы нас звали, и много ), а о том, что программа с пайлапом не справляется. Рекомендуемое "уменьшение мощности" про работе ремоут, как в случае нас с Леной, "по непонятной причине премодерируемого" Романа UR0MC или к, примеру, D41CV вряд-ли возможно.
Отсюда вопрос: как с пайлапами, в сотни раз больше, будет справляться грядущая широко разрекламированная экспедиция. Они что, на Baker&Howland для "охотничей" моды mainframe поволокут?

Уже думал о таком сценарии, может убрать эту опцию из JTDX чтобы пользователи машинально не удаляли свой лог?

В оригинальном софте эта функция есть, зачем менять? Очень полезная функция, чтобы лог не распухал (В LoTW залил - убей). В общем логе все равно остается. Если кто-то тупит - это его проблема.

[US4IRT]

Очень полезная функция, чтобы лог не распухал (В LoTW залил - убей).

Полезного в этом мало. А вот контроль дублей и новых стран пропадёт.

[UA3DTK]

UA3DJY...<Будут продолжать звать поскольку у них нет информации что позывной внесен в очередь.>

...но,когда работает экспедиция,зовущие тоже не знают,что программа сама определяет кого звать в очереди допустим из 10-20 зовущих(по каким критериям пока не пойму)...

[UA3DJY]

Отсюда вопрос: как с пайлапами, в сотни раз больше, будет справляться грядущая широко разрекламированная экспедиция. Они что, на Baker&Howland для "охотничей" моды mainframe поволокут?

Есть ограничивающий фактор - емкость диапазона ограниченная полосой трансивера, подавляющее большинство будут звать в полосе от 1 кГц до 2.7...3.5 кГц и учитывая ограниченные возможности модуляции FT8 для декодирования накладывающихся спектров сигналов при таком пайлапе более 40 сигналов вряд ли будут декодироваться. При тестировании DXpedition режима WSJT-X наблюдали задержку декодирования интервала примерно в 1 секунду, для 40 сигналов эта задержка будет больше. Для одного скачка может быть некритично, но на трех и более скачках с учетом резкого снижения мощности в слоте при пятислотовой работе частично передаваемые сигналы экспедиции будут ощутимо хуже декодироваться. В итоге будет падать темп проведения QSO, что можно исправить регулировкой мощности но при дальнейшем снижении мощности исчезнет связь с корреспондентами далее третьего скачка, то есть экспедиция сможет работать быстрее но только с близко расположенными корреспондентами.

Насколько процессоры компьютеров экспедиции + WSJT-X будут справляться с нагрузкой покажет время.

Эта экспедиция будет работать вне общепринятых FT8 диапазонов, то есть не будет создавать своей работой помех операторам работающим в общих диапазонах.

[UA3DJY]

UA3DJY...<Будут продолжать звать поскольку у них нет информации что позывной внесен в очередь.>

...но,когда работает экспедиция,зовущие тоже не знают,что программа сама определяет кого звать в очереди допустим из 10-20 зовущих(по каким критериям пока не пойму)...

FIFO: первый вошел в очередь - первый вышел. Очередь для больших пайлапов может быть не очень удачным решением: через 1..2 минуты после занесения позывного в очередь с большой вероятностью его сигнал может быть заблокирован более сильными сигналами.

В результате повторы сообщений и падение темпа QSO.