Глюк со временем в FT-8 - может кто сталкивался?

[Илья RW3FY]

Илья, при всем уважении к вам эта цитата звучит смешно и нелепо.
Эти ЙТ-виды связи своей популярностью уже угрохали полноценную автономность радиосвязи именно тем, что привязали жестко к циклы приема-передачи к времени!

Сергей, уже говорил, вопросы эти были успешно решены в космической/военной цифровой радиосвязи больше чем 60 лет назад. Нас в 80-х гг прошлого века в "в школе" всем этим премудростям учили как давно существующей замшелой данности)) Квазиоптимальный приём, автокорреляция, тактовая и символьная синхронизация, и т.д. и т.п.. Для успешного декодирования ведь достаточно синхронизироваться (причём по радиотехническим меркам очень грубо) с началом передачи корреспондента, не более того - а привязка к всемирному времени при этом не более чем приятная опция для удобства контроля логов, но никак не обязательное условие декодирования)). Так что технически проблем никаких)). А то, что большинство радиолюбителей пошли по пути наименьшего сопротивления, ограничившись использованием суррогата... То их проблемы)) Тем более, оно решаемо уже сейчас и на базе уже имеющегося софта/железа - просто пока не всегда удобно и не совсем прямо)

А проблема действительно интересная, если время убегает после отработки программы на передачу, может быть какой-то скрытый глюк программы (ее взаимодействия с системными таймерами ОС), который просто никто не видит долгое время в обычных условиях, когда есть интернет или друга постоянная синхронизация времени.

И кстати, как уплывает, после приема-декода "вала из сигналов" или даже если после отработки на передачу не включать/выключить (увести на другую частоту) приемник?!

Я не заметил какой либо корреляции ухода таймера с количеством станций в полосе приёма. Хоть пустой или почти пустой эфир, хоть забит станциями под завязку - плывёт примерно одинаково. Хотя от загрузки компа в целом зависимость есть. Но неявная. Типа комп может стоять с чистым списком запущенных приложений (не считая wsjt), а время всё равно плывёт из за загрузки компа его внутренними процессами. И скорость ухода таймера во времени не постоянная, может меняться на десятки процентов и даже в разы без каких либо внешних признаков изменения нагрузки.

СтОит разработчикам в международный мейл-лист написать. Но все объяснить во вводной детально, чтобы как обычно не предлагали поставь что-то для постоянной синхронизации "из вне".

Было бы хорошо. Но я не настолько владею иностранческим, чтобы связно изложить такой сложный текст. Если бы кто-нибудь взялся перевести изложение постановки задачи (за основу можно взять первое сообщение темы) и переслать разработчикам - было бы классно. Я думаю, проблема имеет место на всех старых/медленных компах, просто решается костылями в виде интернета либо gps - хотя по факту наверняка есть красивое решение на уровне поправить алгоритмы взаимодействия с системой и таймерами - что позволило бы использовать ресурсы компа полноценно, а не заливать проблему явным переизбытком ресурсов.

Добавлено через 5 минут(ы):

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

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

Отключение синхронизации в настройках винды - это всего лишь отключение синхронизации по сети - приоритеты таймеров при этом не меняются.

[Oleg 9]

Нашёл вот такое, через локальные политики. Правда там для десятки. Сейчас нет семёрки под рукой чтобы проверить, скорее всего и там должна быть такая возможность.https://compuals.ru/windows-10/bloki...a-v-windows-10 Имею ввиду, что если даже системе запретить изменение времени, что из этого выйдет, надо попробовать )

[vadim_d]

всего лишь отключение синхронизации по сети

При этом вроде как программный таймер у них просто привязан к другому кварцу, где ФАПЧ на него позволяет поднять разрешение за счет более высокой частоты, но в детали не вникал, помню, что в вызове функции (в одном из них) есть число тактов на текущий момент и сама их частота. Вроде как при такой организации причен для заметного ухода не видно

[Serg]

Для успешного декодирования ведь достаточно синхронизироваться (причём по радиотехническим меркам очень грубо) с началом передачи корреспондента,

Это понятно и довольно просто, когда ожидаешь прием одного сигнала.
А тут в ЙТ-видах поступили иначе, все передачи заведомо загнали во временные интервалы, именно привязанные к абс. времени всех корреспондентов! И циклы идут последовательно, фактически без "защитных интервалов" на толерантность ко времени.
Т.е. по завершению "окна" времени приемного цикла программа запускает проигрывание звукового буфера, накопленного за этот интервал цикла и все десятки-сотня сигналов, начало передач которых уже заранее ожидается в узком интервале разбежности, как через сито пропускают дальше на декодер-синхронизатор.

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

Я думаю, проблема имеет место на всех старых/медленных компах,

Запросто может такое быть.
Более того, как часто бывает в общении с иностранцами, они могут ответить по принципу на от...сь, т.е. что никто разбираться со старым железом и ОС не будет, покупайте что-то работающее на Вин10-11 - у нас там проблем нет...

А перевести текст - могу, но надо покороче простыню, они точно такое не осилят.
Но сам отправлять не буду, просто дам текст англ тут или в личные. Т.к. в целом не сильно заинтересован в этих видах связи, где как идиотов всех привязали к циклами времени, убив тактику оператора и все другое то, от чего настоящий ДХ-мен получает удовольствие.

[Илья RW3FY]

Нашёл вот такое, через локальные политики. Правда там для десятки. Сейчас нет семёрки под рукой чтобы проверить, скорее всего и там должна быть такая возможность.https://compuals.ru/windows-10/bloki...a-v-windows-10 Имею ввиду, что если даже системе запретить изменение времени, что из этого выйдет, надо попробовать )

Почитал по ссылке. На мой взгляд, навряд ли сработает - там речь о запрете изменения времени не системой, а пользователями и внешними источниками. Но идея запретить вообще переходить с железного таймера на программный абсолютно здравая. Только не знаю, можно ли это сделать. Хотя... у меня частично (до первой передачи)) работает). Я позже поищу, о какой конкретно команде речь, где то в файлике оно лежит на диске, поищу. Может тогда удастся дожать тему, задав более корректные параметры команды. Сам я не настолько в этом шарю, тупо нашёл в сети два разных варианта забивки в командную строку (по сути одно и то же со слегка различающимся синтаксисоом), и их попробовал.

При этом вроде как программный таймер у них просто привязан к другому кварцу, где ФАПЧ на него позволяет поднять разрешение за счет более высокой частоты, но в детали не вникал, помню, что в вызове функции (в одном из них) есть число тактов на текущий момент и сама их частота. Вроде как при такой организации причен для заметного ухода не видно

Как я понял из чтения разных источников, время там не на фапч опирается, а именно вычисляется по тактам работы процессора, и по факту зависит от срабатывания всевозможных прерываний и т д., считается с паузами на более поиоритетные процессы - по итогу зависит от загрузки проца и шин данных. Что как раз и наблюдаем). Если проц быстрый и оперативки много, то возникающая из за этого погрешность ничтожна, и ей пренебрегают. Но если ресурсов мало, оно вылезает в явном виде. На домашнем компе проблем с уходом таймера нет, можно легко обходиться без сети - вручную синхронизируемся по среднестатистической станции, и дальше время держится сутками. Но. Когда я комп сильно загружаю (Альтиум + оса +опера с сетью + ещё куча всякой хрени), то заметил, что и на этом компе таймер начинает заметно плыть. Но поскольку есть резерв по ресурсам, тут просто достаточно закрыть лишний софт, ненужный при работе в эфире)

[vadim_d]

по итогу зависит от загрузки проца и шин данных

Насколько сильна пиковая загрузка при включении передачи? Если подозрение на нагрузку, то можно взять какой-нибудь тупой код с загрузкой всех ядер и посмотреть, какой эффект даст он. Если подозрение на загрузку шины к периферии или ограничение при обращении к памяти, то и тут наверное можно подумать об отдельных тестах. Но по названию темы - вспомнить Менделеева и лорда Кельвина ("наука начинается там, где начинают измерять"), купить глюкометр

[Илья RW3FY]

2 Serg

То, что в этих видах связи станции работают не хаотично, а распределены на два временнЫх слота, задачу не усложняет, а упрощает))). Посмотрите, как работает DMR - там вообще временнЫх слотов может быть не два, а целая куча, и все в одном канале, и с намного более жёсткими требованиями по синхронизации (требования в миллисекунды) - и всё великолепно фунциклирует без всяких инетов и спутников, и даже без термостатированных кварцев, а порой и без термокомпенсированны х). Причём в сети могут работать даже тормознутые станции с вообще жуткими тайминггами, просто часть временнЫх слотов тупо пропускают из за того, что медленно переключаются тх/rx - что для абонентского оборудования как выясняется некритично, важно только для ретрансляторов)). Так что с тем, что кто то там кого то куда то загнал и построил вопреки хэм спирит я в корне несогласен. Наоборот, то, что всех построили и заставили идти в ногу есть гут и элемент прогресса))) Просто пока половинчатый, ибо должны и могут в таком режиме топать сами, а не по внешнему зелёному свистку вверх))))

ВременнОе разделение каналов - это вообще фишка наших стааааарых вояцких систем передачи данных, пиндосы в те стародавние времена, в отличие от наших, пошли по тупиковому пути частотного разделения каналов. А наши не побоялись всех этих синхронизаций и иже с ними - по итогу чего много студенческой крови было выпито в своё время на изучении всяческих РТС с ВРК мохнатых лет, в попытках разобраться как оно работает, иногда удачных))

По иностранцам - тут на кого попадёшь, зависит от конкретных людей. Обычно энтузиасты, что то делающие для народа бесплатно (ну или имеющие некий профит с железа при бесплатном софте), у них вполне отзывчивы. А народу, использующих старое железо, у них поболее чем у нас - менталитет другой - там столетиями прививалась экономия на всём - а мы пошиковать любим и любили во все времена).

Из моего опыта - в своё время слушая SDR-1000, обнаружил косяк работы АРУ, приводящий к искажениям, и сумел ситуацию подловить стабильно с помощью приборов (оно проявлялось не всегда, а при определённых условиях). Подробно описал расклад здесь на форуме, с выкладыванием подробностей по эксперименту, воспроизводящему ситуацию со 100%вероятностью. А Сергей RW3PS (если не путаю имя и позывной, дело давнее) написал обо всём этом Флексам - и те быстренько нашли косяк в программе и исправили.

Другая ситуация - была заморочка по САТ системе TS-50 (у него САТ критична к соблюдению не задокументированных таймингов опроса, иначе подвисает), в частности, в программе N1MM - тоже кому то из ребят передал подробное и внятное описание ситуации, опирающееся на экспериментальные данные, чтобы переслал авторам проги - по итогу авторы косяк исправили и начиная с какой то версии оно прекрасно с TS-50 работает

Так что идея перевести на буржуинский описание проблемы и передать авторам проги вполне здравая и имеющая шанс на успех. Как ужать текстовое описание без потерь информативности я подумаю. Изначально суть максимально разжёвывал с упоминанием всех пунктов возможных отсылок на уже пройденные мной этапы специально, чтоб не тратить время на разъяснение зачем мне оно нужно и какие шаги я уже сделал

Насколько сильна пиковая загрузка при включении передачи? Если подозрение на нагрузку, то можно взять какой-нибудь тупой код с загрузкой всех ядер и посмотреть, какой эффект даст он. Если подозрение на загрузку шины к периферии или ограничение при обращении к памяти, то и тут наверное можно подумать об отдельных тестах. Но по названию темы - вспомнить Менделеева и лорда Кельвина ("наука начинается там, где начинают измерять"), купить глюкометр

Вадим, дело не в загрузке проца в режиме передачи (она там наоборот меньше), а в том, что после включения на передачу (или при её включении) каким то чудесным образом происходит отмена прописанного мной в реестр запрета системе подменять показания железных часов программными) И чтобы снова заработало как надо, нужно wsjt/jtdx перезапустить) Но снова до первой передачи)

Добавлено через 33 минут(ы):

2 Serg

ЗЫ
И насчёт того, что виды а-ля фт-8 якобы убили тактику охоты за DX, я тоже в корне не согласен. Ибо сейчас всё с точностью до наоборот. Что такое DXCC в CW/SSB? Тупо DX-Clucter Clickers - кто не вылазит из кластера и тупо может всех задавить энергетикой, того и тапки) DX ещё ни разу на частоте не включился, а его уже ошалелая толпа зовёт))) Нормальная работа на поиск в этих видах умерла как класс. А в фт-8 этот кластер что мёртвому припарки, там реальная работа на поиск и реальная тактика, тупая энергетика ничего не решает, важнее где ты будешь звать DX и как. И гораздо более реальный шанс отловить его раньше, чем на нег толпа накинется. Да и толпа более цивилизованная, размазана по всему частотному участку, а не все в кучу в общую кашу, кто кого перекричит)

[Oleg 9]

На мой взгляд, навряд ли сработает - там речь о запрете изменения времени не системой, а пользователями и внешними источниками.

Проверил, LOCAL SERVICE даже если удалить, то после перезагрузки опять появляется. Но попутно в списке служб обнаружил одну интересную - на картинке. Возможно в левоватых виндах она отключена, можно попробовать включить или выключить если включена. Иногда так методом научного тыка и удаются устранять проблемы )

[Oleg 9]

Вот ещё по теме, может интервал таймера надо уменьшить или увеличить...
https://habr.com/ru/articles/522212/
https://timerresolution.soft112.com/

[ua3rmb]

Вопрос можно? Вы кому писать-то собираетесь? Разработчикам wsjt или jtdx? Так это совершенно разные люди.
Думаю, что в вашем случае проблема все же с железом. У меня старый ноутбук на i7-3632qm под Windows 7 x64, никаких фокусов со временем не наблюдаю, и на остальных компах на xeon-ах под Windows 10 x64 тоже.