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

Вид для печати

17.12.2020, 19:29
UX8IW

Цитата:

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

Далее надо посмотреть нет ли вверху приёмного окна надписи о потере звуковых блоков. Если нет то там надпись "окно диапазона" и можно двигаться дальше.

Виктор, а если есть? Какие настройки изменять?
Периодически потери бывают..
17.12.2020, 19:39
UA3DJY

Цитата:

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

Идём на диапазон где есть прохождение и смотрим информацию "Lag=.../... Если в первой части сообщения величина начинается с 0, то можно вернуться в настройки: "Декодирование" - FT8 декодер, чувствительность на приёмной частоте QSO - и вместо Минимальная
установить Среднее. Опять смотреть на Lag. Меньше 2 секунд? Тогда пробуем чувствительность на приёмной частоте QSO установить на Высокая. Возвращаемся к приёму и опять смотрим Lag. В вашем случае вероятно он начнёт частенько превышать 2 секунды.

Нет нет, чувствительность на приемной частоте QSO не влияет на время декодирования(пользователь не замечает этого влияния), она определяет порог срабатывания декодера на согласованных фильтрах и от нее только зависит количество правильных и ложных декодов во время QSO. С повышением чувствительности декодера на согласованных фильтрах растет количество правильных декодов на зашумленных сигналах, в нагрузку растет и количество ложных декодов.

Начиная с версии JTDX 154 снижение задержки декодирования настраивается через спинбокс (в переводе вращающееся окно, кстати колесо мыши в нем шустро работает) CL.
17.12.2020, 20:49
UF8T

Цитата:

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

Виктор, а если есть? Какие настройки изменять?
Периодически потери бывают..

Смотреть диспетчер задач и анализировать запущенные процессы, что-то грузит.

- - - Добавлено - - -

Цитата:

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

...чувствительность на приёмной частоте QSO не влияет на время декодирования(пользователь не замечает этого влияния)...

Игорь, проверился, не влияет. Видимо при опробовании влияния выбора чувствительности у меня наложились посторонние факторы, спасибо!
17.12.2020, 20:50
RW6APC

Вложений: 1

Цитата:

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

Олег первоначально сделайте установки так:
- после нескольких циклов декода посмотрите величину среднего DT от принимаемых станций. Это вверху приёмного окна "Средн=...". К примеру как на указанном скрине "Средн=0.08, в этом случае установите спин бокс DT+0.1. То есть сколько среднее и с каким знаком столько и ставьте.
В "Декодирование" - FT8 декодер:
- количество запусков декодера 1;
- чувствительность на приёмной частоте QSO - Минимальная;
- чувствительность в широкой полосе - Минимальная
- Автовыбор - первый входящий вызов.
- спин бокс CL 100%.
Далее надо посмотреть нет ли вверху приёмного окна надписи о потере звуковых блоков. Если нет то там надпись "окно диапазона" и можно двигаться дальше. Идём на диапазон где есть прохождение и смотрим информацию "Lag=.../... Если в первой части сообщения величина начинается с 0, то можно вернуться в настройки: "Декодирование" - FT8 декодер, чувствительность на приёмной частоте QSO - и вместо Минимальная
установить Среднее. Опять смотреть на Lag. Меньше 2 секунд? Тогда пробуем чувствительность на приёмной частоте QSO установить на Высокая. Возвращаемся к приёму и опять смотрим Lag. В вашем случае вероятно он начнёт частенько превышать 2 секунды. Теперь надо спин бокс "CL" уменьшать, попробуйте кардинально сразу уменьшить до 10%. Если в этом случае Lag редко будет превышать 2 секунды то работать можно.
Что сильно увеличивает Lag: это "количество запусков декодера" и "чувствительность в широкой полосе в следующих положениях от Минимальная".

Вот что получилось.

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

Вложение 287574
17.12.2020, 21:15
UF8T

Цитата:

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

Вот что получилось.

Прекрасный результат, Олег. Скорректируйте "чувствительность на приёмной частоте QSO" с учётом мнения Игоря. В AutoSeq1 даже при заходе Lag под 4 секунды вполне комфортно работается на CQ. Удачи!
17.12.2020, 21:20
UX8IW

Вложений: 1

Цитата:

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

Смотреть диспетчер задач и анализировать запущенные процессы, что-то грузит.

Вот, что может грузить, только JTDX и система.

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

Вложение 287589

- - - Добавлено - - -

Цитата:

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

Начиная с версии JTDX 154 снижение задержки декодирования настраивается через спинбокс (в переводе вращающееся окно, кстати колесо мыши в нем шустро работает) CL.

Игорь, хорошо бы алгоритм настройки, предложенный Виктором, с вашими поправками, закрепить в шапке темы или на сайте программы. Этот вопрос будет часто повторяться.
17.12.2020, 21:31
EU1FQ

Цитата:

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

... Какие настройки изменять?
Периодически потери бывают..

Борис, попробуйте DPC Latency Checker - https://www.softpedia.com/get/System...-Checker.shtml
Прога производит анализ мультимедиа-потоков данных в среде операционной системы. Будете видеть где затык.
17.12.2020, 21:52
UF8T

Цитата:

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

...только JTDX и система

Eset устроит проверку или как и Windows начнут грузить обновления... А так да, все хорошо.
17.12.2020, 22:36
UX8IW

Вложений: 2

Цитата:

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

Борис, попробуйте DPC Latency Checker - https://www.softpedia.com/get/System...-Checker.shtml
Прога производит анализ мультимедиа-потоков данных в среде операционной системы. Будете видеть где затык.

Вот такая картинка получается, Николай.

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

Вложение 287603

Как понять, где затык?

такая же картинка и без потерь звука..

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

Вложение 287604

- - - Добавлено - - -

Цитата:

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

Eset устроит проверку или как и Windows начнут грузить обновления..

Это понятно, win8.1 не часто грузит обновления, да и NOD не сильно настырный:), с этой стороны как бы грузить не должно.
Видимо, где-то в недрах самого компа что-то не так..
17.12.2020, 23:00
RX3ASP

Вложений: 1

Цитата:

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

Как понять, где затык?

Это у вас в момент декодирования заснято? Для компьютера. который нормально не тянет, очень много всего запущено, в частности Хром. Прерываний 3%!
У меня так в пиковый момент при CL=100% При 20% Lag ниже нуля. А вообще Лаг очень от характера шума зависит. Иногда на совсем пустом диапазоне больше секунды.
Потери Аудио у меня иногда бывают в момент синхронизации времени.

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

Вложение 287611
17.12.2020, 23:18
UX8IW

Вложений: 2

Цитата:

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

Это у вас в момент декодирования заснято? Для компьютера. который нормально не тянет, очень много всего запущено, в частности Хром. Прерываний 3%!
У меня так в пиковый момент при CL=100% При 20% Lag ниже нуля. А вообще Лаг очень от характера шума зависит. Иногда на совсем пустом диапазоне больше секунды.
Потери Аудио у меня иногда бывают в момент синхронизации времени.

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

Вложение 287611

Хром может давать такой процент прерываний. Вот без хрома, начало и окончание декодирования.

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

Вложение 287613

Вложение 287614
17.12.2020, 23:25
UA3DJY

Цитата:

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

Потери Аудио у меня иногда бывают в момент синхронизации времени.

Ожидаемо, подсчет звуковых блоков привязан к системному времени и если оно скачет то блоков будет либо больше чем надо либо меньше(меняется продолжительность интервала приема сигналов). Первое незаметно пользователю, второе видно по выводу количества потерянных блоков.
17.12.2020, 23:26
EU1FQ

Вложений: 1

Цитата:

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

Как понять, где затык?

Борис, Latency Checker, это скорее наглядное пособие, что есть проблемы с системными прерываниями. 1000 ms не есть хорошее время для работы в FT8.
Сравните.

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

Вложение 287615

Причин может быть десятки, и все их не перечислишь. Теперь, скачайте LatencyMon https://www.softpedia.com/get/Others...tencyMon.shtml
Программа проанализирует возможные причины опустошения буфера, измеряя задержки таймера ядра и сообщая о времени выполнения DPC и ISR, а также о аппаратных сбоях страниц. Она найдет модули и процессы ядра, ответственные за возникновение задержек звука. В большинстве случаев она также найдет драйверы и процессы, ответственные за их выполнение которые приводят к задержкам.
Т.е. это будет подспорьем для уменьшения времени задержек.
18.12.2020, 00:31
UX8IW

Цитата:

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

Борис, Latency Checker, это скорее наглядное пособие, что есть проблемы с системными прерываниями. 1000 ms не есть хорошее время для работы в FT8.
Сравните.

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

Вложение 287615

Причин может быть десятки, и все их не перечислишь. Теперь, скачайте LatencyMon https://www.softpedia.com/get/Others...tencyMon.shtml
Программа проанализирует возможные причины опустошения буфера, измеряя задержки таймера ядра и сообщая о времени выполнения DPC и ISR, а также о аппаратных сбоях страниц. Она найдет модули и процессы ядра, ответственные за возникновение задержек звука. В большинстве случаев она также найдет драйверы и процессы, ответственные за их выполнение которые приводят к задержкам.
Т.е. это будет подспорьем для уменьшения времени задержек.

Та да, сравнил, у вас ОК..

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

LatencyMon пишет, что норма:
Your system appears to be suitable for handling real-time audio and other tasks without dropouts.
LatencyMon has been analyzing your system for 0:11:24 (h:mm:ss) on all processors.

Highest measured interrupt to process latency (µs): 425.034928
Average measured interrupt to process latency (µs): 3.834257

Highest measured interrupt to DPC latency (µs): 415.342649
Average measured interrupt to DPC latency (µs): 1.509649

Highest ISR routine execution time (µs): 325.994989
Driver with highest ISR routine execution time: portcls.sys - Port Class (Class Driver for Port/Miniport Devices), Microsoft Corporation

Highest reported total ISR routine time (%): 0.343466
Driver with highest ISR total time: USBPORT.SYS - Драйвер порта USB 1.1 и 2.0, Microsoft Corporation

Total time spent in ISRs (%) 0.468953

ISR count (execution time <250 µs): 1297398
ISR count (execution time 250-500 µs): 0
ISR count (execution time 500-1000 µs): 2
ISR count (execution time 1000-2000 µs): 0
ISR count (execution time 2000-4000 µs): 0
ISR count (execution time >=4000 µs): 0

Highest DPC routine execution time (µs): 446.395880
Driver with highest DPC routine execution time: ndis.sys - NDIS (Network Driver Interface Specification), Microsoft Corporation

Highest reported total DPC routine time (%): 0.731209
Driver with highest DPC total execution time: USBPORT.SYS - Драйвер порта USB 1.1 и 2.0, Microsoft Corporation

Total time spent in DPCs (%) 1.856952

DPC count (execution time <250 µs): 3174346
DPC count (execution time 250-500 µs): 0
DPC count (execution time 500-10000 µs): 189
DPC count (execution time 1000-2000 µs): 0
DPC count (execution time 2000-4000 µs): 0
DPC count (execution time >=4000 µs): 0

- - - Добавлено - - -

Одну причину я нашел - отключил WI-FI адаптер. Звук перестал терятся, Lag уменьшился и стал более стабильным, число декодов увеличилось.
Но, если делаю сриншот, в следующем цикле декодирования есть потери звука.
18.12.2020, 01:43
RN9AZ

Вложений: 1

Цитата:

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

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

Игорь. Сейчас заметил такую хрень, стоит появится станции с поганым сигналом. Сразу появляются потерянные звуки и растёт время задержки декодирования. Можешь объяснить? Настройки в меню декодирования по минимуму. За исключением Чутьё на приёмной частоте Высокое. Остальное в скрытом тексте видно.

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

Вложение 287665