делали бы UDeP многоканальный, а то все зациклились на одинаковых цифрах.
Увы... у меня наоборот. Сигнал часто идет уровнем меньше на 1Дб и чаще пропуски декодирования слабых станций.:s9:
Вложение 201398
декодер FT8 пока идентичен, разница есть в подаваемом на декодер сигнале
WSJT-X Звуковая карта 48 кГц 16 бит integer -> 12 кГц 32 бит float -> 12 кГц 16 бит integer -> 12 кГц 32 бит float -> декодер
JTDX Звуковая карта 48 кГц 16 бит integer -> 12 кГц 32 бит float -> декодер
Из-за двойного преобразования целые/дробные числа WSJT-X может вносить ошибку округления при малом уровне сигнала на входе АЦП.
Это одна из причин почему результаты декодирования сейчас могут отличаться,
вторая причина: JTDX использует другой фильтр при понижении частоты дискретизации 48-12 кГц,
остальные причины находятся вне софта.
я уже запутался, общение по JTAlert перешло исключительно в форум hamapps support где Laurie VK3AMA написал что версия с поддержкой будет не ранее 1 января
В итоге я поменял символы у мод T10 и FT8, дал линк на новый софт 18.1.0.31 в форум hamapps, и почти синхронно Laurie VK3AMA на форуме написал что выпустил патч JTAlert 2.10.6 для JTDX 18.1.0.29.
На письмо с предложением заменить спецсимволы мод на текст с названием моды Laurie с утра так и не ответил.
А с логом EQF и WSJTInterface JTDX v18.1.0.30 работает. Мне написали, что нет. У меня v18.1.0.29 всё работало, за исключением клика в окне Activity по станциям дающим CQ. Сейчас поставил v18.1.0.30 и всё пусто, не работает обмен по UDP вообще и это очень плохо. Вот, что значит подстраиваться под одну конкретную программу :s8:.
Ну будем надеяться.
Чем дальше тестирую v18.1.0.29, тем больше багов. Решил понаблюдать за JT65 и заодно посмотреть, что отдаёт программа по UDP схема 5, пропал первый символ в сообщении. Вместо CQ... Q..., вместо IW3ERT UA1AA... - W3ERT UA1AA... В самой программе правильно.
Ее и так нет.
Вложение 201410
"высиживать" действительно пока неудобно - но главное как в том мультике - "урааа заработало (с)"
Можно ещё при очистке окон оставить возможность повторно быстро передать "call call 73" ? - на случай если оператор не принял финальное 73 и повторно шлёт RRR ( JT например решил эту проблему "в лоб" - при нажатии F4 в WSJT-X очищается всё - но Tx5 "call call 73" остаётся , в принципе удобно ).
FT8 быстрая , там это нужно иногда (одним быстрым нажатием повторно передать "call call 73" , если оператор не принял в предыдущем цикле и опять прислал RRR ).
P.S. На данном этапе некритично , главное что уже всё работает , Игорь огромное Вам спасибо что запустили FT8 в JTDX.
P.P.S. Связка LogHX3 + JTDX (не знаю как будет с другими журналами) - всё работает (как и всегда) - но JTDX и лог шлют на eQSL одно и то же QSO FT8 с разницей по времени , соответственно получаются дубли на eQSL. Подробнее в теме LogHX3 .
Хорошо быстро заметил (вычищать потом вручную дубли с eQSL то ещё удовольствие , да и перед корреспондентами будет неудобно)..... Проблема похоже в логе (округляет секунды) или может вообще во мне )))).
[QUOTE=US-E-12;1421798]Ну будем надеяться.
Чем дальше тестирую v18.1.0.29, тем больше багов. Решил понаблюдать за JT65 и заодно посмотреть, что отдаёт программа по UDP схема 5, пропал первый символ в сообщении. Вместо CQ... Q..., вместо IW3ERT UA1AA... - W3ERT UA1AA... В самой программе правильно.[/QUOTEС]
С символическими ссылками проблем в работе лога UR5EQF и программы НЕТ! И UDP получается лишним!