нашел свой пост http://forum.qrz.ru/6-cifrovye-vidy-...ml#post1408010 можно использовать вместе с сигналами точного времени с эфира
рядом с ним еще есть несколько сообщений на тему коррекции часов компьютера
нашел свой пост http://forum.qrz.ru/6-cifrovye-vidy-...ml#post1408010 можно использовать вместе с сигналами точного времени с эфира
рядом с ним еще есть несколько сообщений на тему коррекции часов компьютера
Надо делать сложный адаптивный алгоритм, иначе выйдет так что в одном интервале декодирован всего один FT8 сигнал с DT=-2.5, в следующем интервале есть один сигнал с DT=1.0, но он уже не будет декодирован потому что время начала декодирования уже смещено на 2.5 секунды от точного времени и относительно "часов софта" DT этого сигнала стал равен 3.5 секунды.Цитата:
Сообщение от RW4LN
С другой стороны это будет офсет времени в самом софте, с уймой зависимостей и изменений в коде. Софт не может менять системное время потому что для этого необходимы права администратора, да и сам подход менять системное время из софта неправильный - остальные приложения могут нестабильно работать, использование прав администратора дает дыру в безопасности, возможные срабатывания антивирусного ПО.
Думаю что это предложение в случае реализации может как минимум сильно затруднить дальнейшее развитие проекта.
Проверил в варианте работы в поиске: при включенной галочке "Clear DX call and grid after logging" и включенной кнопке AutoSeq окна DX Call/Grid очищаются после декодирования завершающего QSO сообщения 73 (вариант когда корреспондент использует последовательность RRR + 73)Цитата:
Сообщение от RJ7M
либо в конце следующего(пустого) за передачей сообщения 73 если корреспондент использует сообщение RR73 для завершения QSO.
В последнем случае отсутствие сообщений от корреспондента является критерием завершения QSO.
Интересно,что и где заело......Вложение 202852
58-я версия, только запустил программу, а меня уже зовут ) и это я пока не передавал
я пока ничего не понимаю. Видно у словака такая же 58-я версия и мы оба не можем закончить куесо в автомате. Перевожу уже вручную, а оно снова мне выдачу рапорта.
To: UA3DJY
Игорь, от чего зависит скорость вывода декодированных сообщений в окне Band Activity?
Именно скорость вывода сообщения, а не скорость его декодирования.
Если процессор не успевает декодировать сигналы до начала следующего интервала то причина ясна и понятна.
А если процессор декодировал сигнал до начала следующего интервала, но не вывел в окно Band Activity?
Поясню на примере. Первый интервал - CQ, второй интервал- декодирование, третий интервал трансивер включается на передачу c рапортом, к примеру UA3DJY EU1FQ -15
но позывной UA3DJY еще не появился в окне Band Activity! а только спустя 1,5-2 сек после начала третьего цикла.
Наблюдаю это довольно часто и во всех версиях.
Сравнивал с WSJT, задержки скорости вывода декодированных сообщений не наблюдал. Настройки в обеих программах идентичные.
Win7x32, 2,7Гц, 2 ядра 8 Гб
еле закончил связь и снова ложный декод
Добрый вечер.
Тестирую v58 и вот что заметил.
Работаю на поиск
Режимы АutoSeg1, TX=RX
Если QSO проходит стандартно и после моего 73 корреспондент передает 73 или CQ кнопка Enable TX отключается и я успеваю в следующем периоде вызвать станцию работающую на CQ
скрины корректной работы:Вложение 202867 Вложение 202868
Но если корреспондент после моих 73 по каким то причинам не передал например CQ, программа становиться повторно на передачу
вот примеры Вложение 202873 Вложение 202874
с одной стороны вроде как правильно, что после моих 73 и сохраненного QSO кнопка Enable TX активна(красная) потому как корреспондент может еще раз передать RRR
и программа повторно ответит 73, но раньше эта функция была реализована при неактивной кнопке Enable TX. Как то это нужно побороть..
И вот еще
При вызове "QRZ OM7ASP JN98" передача включилась на секунду и прервалась...
Вложение 202875