А что не так?
Ваш корреспондент никак не может принять Ваш рапорт (помехи или что еще),
поэтому передает снова и снова. Ваша программа каждый раз адекватно отвечает.
Всё в порядке. Так и должно быть.
Может, кому то поможет.
Стал наблюдать, что при использовании опции фейк ит иногда (очень не часто) частота не возвращалась обратно, т.е. прием оставался на частоте предыдущей передачи (например 18101, а не 18100). Наблюдалось на разных компах и разных трансиверах. Выяснил, что так бывает, если одновременно запущен какой-либо лог, тоже использующий Cat. Софт может быть любым. Теперь просто выключаю такие программы при работе в JTDX и все гуд. Если фейк ит не испольщовать такой проблемы нет. И еще - у кого иногда выскакивает табличка с предложением настроить CAT - проблема того же рода - ищете, что еще запущено на компьютере и использует CAT.
Цитата Сообщение от US4IRT Да-а! При таком пайлапе лучше MSHV использовать на 5-ти сигналах, Роман.
UA3DJY <И тогда вся Европа будет ожидать/наблюдать пока Роман переработает все станции с Японии закрывая при помощи софта MSHV весь диапазон своей передачей и сигналами операторов которые его вызывают.>
...а если использовать один слот и выстроить их в очередь(10-30-50 позывных)...?
Насколько я понял вопрос "по непонятной причине премодерируемого" Романа UR0MC, речь шла не о попытках уменьшить количество зовущих, что само по себе абсурдно (мы всегда, что в тестах, что в повседневке стремимся чтобы нас звали, и много :s7:), а о том, что программа с пайлапом не справляется. Рекомендуемое "уменьшение мощности" про работе ремоут, как в случае нас с Леной, "по непонятной причине премодерируемого" Романа UR0MC или к, примеру, D41CV вряд-ли возможно.
Отсюда вопрос: как с пайлапами, в сотни раз больше, будет справляться грядущая широко разрекламированная экспедиция. Они что, на Baker&Howland для "охотничей" моды mainframe поволокут?
В оригинальном софте эта функция есть, зачем менять? Очень полезная функция, чтобы лог не распухал (В LoTW залил - убей). В общем логе все равно остается. Если кто-то тупит - это его проблема.
UA3DJY...<Будут продолжать звать поскольку у них нет информации что позывной внесен в очередь.>
...но,когда работает экспедиция,зовущие тоже не знают,что программа сама определяет кого звать в очереди допустим из 10-20 зовущих(по каким критериям пока не пойму)...
Есть ограничивающий фактор - емкость диапазона ограниченная полосой трансивера, подавляющее большинство будут звать в полосе от 1 кГц до 2.7...3.5 кГц и учитывая ограниченные возможности модуляции FT8 для декодирования накладывающихся спектров сигналов при таком пайлапе более 40 сигналов вряд ли будут декодироваться. При тестировании DXpedition режима WSJT-X наблюдали задержку декодирования интервала примерно в 1 секунду, для 40 сигналов эта задержка будет больше. Для одного скачка может быть некритично, но на трех и более скачках с учетом резкого снижения мощности в слоте при пятислотовой работе частично передаваемые сигналы экспедиции будут ощутимо хуже декодироваться. В итоге будет падать темп проведения QSO, что можно исправить регулировкой мощности но при дальнейшем снижении мощности исчезнет связь с корреспондентами далее третьего скачка, то есть экспедиция сможет работать быстрее но только с близко расположенными корреспондентами.
Насколько процессоры компьютеров экспедиции + WSJT-X будут справляться с нагрузкой покажет время.
Эта экспедиция будет работать вне общепринятых FT8 диапазонов, то есть не будет создавать своей работой помех операторам работающим в общих диапазонах.
FIFO: первый вошел в очередь - первый вышел. Очередь для больших пайлапов может быть не очень удачным решением: через 1..2 минуты после занесения позывного в очередь с большой вероятностью его сигнал может быть заблокирован более сильными сигналами.
В результате повторы сообщений и падение темпа QSO.