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

**EU1FQ** · 20.11.2019, 14:59

Сообщение от RA3DEM

......Теперь бы JTDX научить..

Да хоть десять радио на один лог

**RA3DEM** · 20.11.2019, 16:46

Сообщение от EU1FQ

Да хоть десять радио на один лог

покажете как несколько радио одновременно, без переключений в одном логе LoGHX?

**RC3C** · 20.11.2019, 16:50

@RA3DEM Миша привет

**RA3DEM** · 20.11.2019, 17:13

Сообщение от RC3C

@RA3DEM Миша привет

Приветы Антон

) сорри за спам)

**R2EA** · 20.11.2019, 17:19

Сообщение от R0JF

Если Вы и правда это руками делаете, то какое Вам дело до счетчиков???

Ну перестала программа АВТОМАТИЧЕСКИ звать кого-то, кто мешает руками позвать?
На экране-то его видно. И видно, что еще не В4. Зовите инициативным порядком.

Опять Ваши пожелания - по поводу роботизации, а никак не по улучшению функционала.
Запустить программу и раз в час подходить к экрану. Утром лог посмотреть. Фу.

Я бы вообще предложил Игорю ОТКЛЮЧИТЬ функционал автовызова (4+ Call and search through CQ messages) и уж ТЕМ БОЛЕЕ - Call worked B4 callsigns !

Игорь, я устал бодаться с тобой так же, как и очищать списки тех кого ранее звал.
У тебя кругом - робот!!! Это не обоснование для отказа. Проще напиши...:
- Я такой то такой то, участвую в разработке JTDX и все новые идеи от R2EA
воспринимаю в штыки и сделаю всё для того, чтобы его хотелки были не реализованы...

Сообщение от UA3DJY

Пользователям

Игорь можно ответ получить на сообщение 21189?

**UR5LCZ** · 20.11.2019, 19:43

Сообщение от R2EA

Игорь, я устал бодаться с тобой так же, как и очищать списки тех кого ранее звал.
У тебя кругом - робот!!! Это не обоснование для отказа. Проще напиши...:
- Я такой то такой то, участвую в разработке JTDX и все новые идеи от R2EA
воспринимаю в штыки и сделаю всё для того, чтобы его хотелки были не реализованы...

Роман!
Круто вы разговариваете со своим наемным работником!
У вас, смотрю, не забалуешь.

**US4IRT** · 20.11.2019, 20:42

Уже вижу в FT4 появился многослотовый режим. Наверное в MSHV.

->Скрытый текст<-

Заметил давно одну особенность: в FT4 DT всегда лучше, чем в FT8.

**UA3DJY** · 20.11.2019, 22:03

Сообщение от US4IRT

Заметил давно одну особенность: в FT4 DT всегда лучше, чем в FT8.

JTDX: Окно синхронизации декодера в FT4 почти в 2.3 (SWL в 2.5) раза меньше по сравнению с FT8, поэтому на экране DT лучше. FT4 cигналы корреспондентов с плохой синхронизацией часов и сигналы корреспондентов с частой синхронизацией часов ощутимо чаще не захватываются декодером по сравнению с FT8. Такая же проблема может быть с синхронизацией часов в сетапе оператора.

JT65/JT9/T10 хороши тем что мало чувствительны к плохой синхронизации часов, с уменьшением продолжительности интервала в FT8 и тем более в FT4 растут требования к точности синхронизации часов компьютера. Если в JT65 выпадают 2 секунды сигнала то это потеря примерно четырех процентов символов, если в FT4 выпадают 2 секунды сигнала то это уже потеря примерно 40 % символов сигнала. С учетом особенностей LDPC кода начало передачи FT4 сигнала раньше на 2 секунды (то есть потеря первых 40% символов) гарантирует невозможность его декодирования, по этой причине DT окно захвата сигналов FT4 декодером в коде программ установлено меньше чем в FT8 и намного меньше чем в JT65.

**UB3GDZ** · 20.11.2019, 23:40

Сообщение от UA3DJY

JTDX: Окно синхронизации декодера в FT4 почти в 2.3 (SWL в 2.5) раза меньше по сравнению с FT8, поэтому на экране DT лучше. FT4 cигналы корреспондентов с плохой синхронизацией часов и сигналы корреспондентов с частой синхронизацией часов ощутимо чаще не захватываются декодером по сравнению с FT8. Такая же проблема может быть с синхронизацией часов в сетапе оператора.

JT65/JT9/T10 хороши тем что мало чувствительны к плохой синхронизации часов, с уменьшением продолжительности интервала в FT8 и тем более в FT4 растут требования к точности синхронизации часов компьютера. Если в JT65 выпадают 2 секунды сигнала то это потеря примерно четырех процентов символов, если в FT4 выпадают 2 секунды сигнала то это уже потеря примерно 40 % символов сигнала. С учетом особенностей LDPC кода начало передачи FT4 сигнала раньше на 2 секунды (то есть потеря первых 40% символов) гарантирует невозможность его декодирования, по этой причине DT окно захвата сигналов FT4 декодером в коде программ установлено меньше чем в FT8 и намного меньше чем в JT65.

А какой интервал синхронизации времени предпочтителен ? Извиняюсь если вопрос не слишком уместен ...

**UA3DJY** · 21.11.2019, 00:14

Сообщение от UB3GDZ

А какой интервал синхронизации времени предпочтителен ? Извиняюсь если вопрос не слишком уместен ...

На слабых процессорах в 00 секунды обычно еще продолжается декодирование предыдущего интервала, то есть загрузка процессора высока. Выполнять синхронизацию на автомате рисковано, лучше остановить прием кнопкой Monitor и выполнить синхронизацию принудительно, затем обратно включить прием.

Период синхронизации зависит от ряда факторов. Например есть Интернет браузеры которые во время работы пытаются выполнить синхронизацию системного времени, при этом они обычно выводят часы компьютера за пределы желательного диапазона синхронизации.

С учетом разброса DT сигналов разных корреспондентов в FT4 желательно вписаться в +- 0.2 секунды от точного времени. В зависимости от состояния самих часов и батарейки на материнской плате синхронизацию можно делать с разным периодом, для исправных часов достаточна синхронизация один раз в более чем 5 часов.

Самый тяжелый случай когда оператор ставит период синхронизации например раз в минуту и при этом на компьютере работают несколько программ синхронизации, либо Интернет браузер начинает конкурировать с программой синхронизации. В этом случае оператор не понимает что происходит: DT сигналов у него на экране прыгает раз в минуту, DT его сигнала прыгает раз в минуту у тех кто его декодирует.

В программах WSJT-X/JTDX немало сервисов в коде привязаны к системным часам, если часы прыгают то возможны сбои в работе программ, чем чаще прыгают часы тем больше будет сбоев в выполнении кода.

**UB3GDZ** · 21.11.2019, 02:06

Сообщение от UA3DJY

На слабых процессорах в 00 секунды обычно еще продолжается декодирование предыдущего интервала, то есть загрузка процессора высока. Выполнять синхронизацию на автомате рисковано, лучше остановить прием кнопкой Monitor и выполнить синхронизацию принудительно, затем обратно включить прием.

Период синхронизации зависит от ряда факторов. Например есть Интернет браузеры которые во время работы пытаются выполнить синхронизацию системного времени, при этом они обычно выводят часы компьютера за пределы желательного диапазона синхронизации.

С учетом разброса DT сигналов разных корреспондентов в FT4 желательно вписаться в +- 0.2 секунды от точного времени. В зависимости от состояния самих часов и батарейки на материнской плате синхронизацию можно делать с разным периодом, для исправных часов достаточна синхронизация один раз в более чем 5 часов.

Самый тяжелый случай когда оператор ставит период синхронизации например раз в минуту и при этом на компьютере работают несколько программ синхронизации, либо Интернет браузер начинает конкурировать с программой синхронизации. В этом случае оператор не понимает что происходит: DT сигналов у него на экране прыгает раз в минуту, DT его сигнала прыгает раз в минуту у тех кто его декодирует.

В программах WSJT-X/JTDX немало сервисов в коде привязаны к системным часам, если часы прыгают то возможны сбои в работе программ, чем чаще прыгают часы тем больше будет сбоев в выполнении кода.

Спасибо , надо будет вникнуть в этот вопрос поглубже. Сейчас в система отключена автосинхронизация времени и стоит программа Dimension для этого в которой по умолчанию выставлено 15 минут !

**UA3DJY** · 21.11.2019, 08:54

Сообщение от UB3GDZ

Спасибо , надо будет вникнуть в этот вопрос поглубже. Сейчас в система отключена автосинхронизация времени и стоит программа Dimension для этого в которой по умолчанию выставлено 15 минут !

Если Dimension выполняет синхронизацию в 59...00 секунд то на слабых процессорах момент синхронизации может совпасть с декодированием интервала / высокой загрузкой процессора, есть вероятность ошибки в установке часов.

**RK1NA** · 21.11.2019, 10:36

Сообщение от UA3DJY

момент синхронизации может совпасть с

Летом работаю из деревни. Там очень "хилый" интернет. Часто просто вырубается.
Как то заметил что "вдруг" через 15 минут работы программа перестает декодировать.
Не сразу разобрался. Проблема оказалась в корректировке времени.
Определил делая корректировку врукопашную.
Корректируется и на 2...5 мсек и на сотни мсек.
В Дименсион стоял период 15 минут и если при корректировка она сдвигала
время на 300...500 или более мсек естественно декод пропадал.
Посему есть смысл проверить свою прогу корректировки вручную.
...

**UA3DJY** · 21.11.2019, 11:53

Сообщение от RK1NA

Там очень "хилый" интернет. ...

Задержки передачи/приема пакетов в сети мобильного оператора, тоже одна из возможных причин сбоя синхронизации часов компьютера.

**UB3GDZ** · 21.11.2019, 14:28

Сообщение от UA3DJY

Если Dimension выполняет синхронизацию в 59...00 секунд то на слабых процессорах момент синхронизации может совпасть с декодированием интервала / высокой загрузкой процессора, есть вероятность ошибки в установке часов.

Спасибо , посмотрю как это будет на практике ! Я думаю процессор она мой не "упрет" , он не очень слабый на данный момент - i5 6600К в разгоне до 4.2Ghz. Меня что-то один момент со вчерашнего дня беспокоит , пару дней назад , эфир просто "громыхал" на 40М в FT8 и позывные бежали много и очень быстро , а вот вчера что-то станций очень мало стало ! Подумал , что проход ослабел , но на водопаде очень много несущих , все пищит и гудит как и ранее. Даже удалил rc143 , думал это связано , но на rc142 тоже самое. Если только несущие от другой моды на водопаде ?! Вы меня извините за подобные вопросы , я в этом деле совсем новичок и цифру "щупаю" всего пару дней !