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

[UA3DJY]

Ещё раз повторяю - <time_on:6>175115 <time_off:6>175645. Это в FT8 моде. Если я его буду звать 1 час, разница в time_on и time_of будет 1 час. Т.е. time_on берётся время первого вызова, а звать можно сколько угодно, час, два... пока ответит.
Напр. я начал звать в 1300, мне ответили и связь состоялась в 1520, то по существующей логике в лог запишется time_on 1300, time_of 1520.

Или еще есть сценарий когда Вам ответили час назад но QSO не состоялось и Вы продолжаете звать, да еще спустя час могут ответить сообщением 73, морока будет с определением Time_On и по переданному и по принятому сообщению.

В 18.1.0.34 сделано ограничение в коде, при разнице Time_On и Time_Off во времени более 150 секунд для моды FT8 и более 600 секунд для остальных мод время Time_On при записи в лог ставится равным времени Time_Off, то есть никаких сбоев в подтверждении eQSL и LoTW сейчас быть не должно.

void MainWindow :: on_logQSOButton_clicked()
...
if (dateTimeQSOOff < m_dateTimeQSOOn) m_dateTimeQSOOn = dateTimeQSOOff;
// 150 seconds delta for FT8, 600 seconds delta for other modes
if (qAbs(dateTimeQSOOff.toMSecsSinceEpoch() - m_dateTimeQSOOn.toMSecsSinceEpoch()) > m_TRperiod * 10000) m_dateTimeQSOOn = dateTimeQSOOff;

В этом коде переменная m_TRperiod имеет значение 15 секунд для FT8 и 60 секунд для JT/T мод.

[R3DL]

Здравствуйте, коллеги!
А нельзя ли фиксировать в качестве Time On время получения первого ответа от корреспондента в том случае, если связь состоялась?

[RA3QH]

Да фиг с ним с этим eQSL,есть поважнее...вот что заметил народ.....цитирую

При сохранении QSO из JTDX 34 - оно заносится по ДХСС предыдущего.Т. е. в логе последнее с RA9XX, а я сработал OE5XXX - OE5XXX заносится как Россия Азиатская. Хотя определяется до сохранения правильно. И так все связи. Проверил в WSJT-X - там все нормально.

Если сохранить связь в лог до того как в JTDX очистит окно ввода позывного, то связь сохраняется с правильной территорией, а если после очистки поля ввода позывного, то связи сохраняются с территорией, которая была последняя правильно сохранённая (т.е. до очистки поля ввода позывного в JTDX).

у себя тоже такое заметил после того как прочел...

[UA3DJY]

Да фиг с ним с этим eQSL,есть поважнее...вот что заметил народ.....цитирую

При сохранении QSO из JTDX 34 - оно заносится по ДХСС предыдущего.Т. е. в логе последнее с RA9XX, а я сработал OE5XXX - OE5XXX заносится как Россия Азиатская. Хотя определяется до сохранения правильно. И так все связи. Проверил в WSJT-X - там все нормально.

Если сохранить связь в лог до того как в JTDX очистит окно ввода позывного, то связь сохраняется с правильной территорией, а если после очистки поля ввода позывного, то связи сохраняются с территорией, которая была последняя правильно сохранённая (т.е. до очистки поля ввода позывного в JTDX).

у себя тоже такое заметил после того как прочел...

в каком логе?

[UA3DJY]

Или еще есть сценарий когда Вам ответили час назад но QSO не состоялось и Вы продолжаете звать, да еще спустя час могут ответить сообщением 73, морока будет с определением Time_On и по переданному и по принятому сообщению.

В 18.1.0.34 сделано ограничение в коде, при разнице Time_On и Time_Off во времени более 150 секунд для моды FT8 и более 600 секунд для остальных мод время Time_On при записи в лог ставится равным времени Time_Off, то есть никаких сбоев в подтверждении eQSL и LoTW сейчас быть не должно.

void MainWindow :: on_logQSOButton_clicked()
...
if (dateTimeQSOOff < m_dateTimeQSOOn) m_dateTimeQSOOn = dateTimeQSOOff;
// 150 seconds delta for FT8, 600 seconds delta for other modes
if (qAbs(dateTimeQSOOff.toMSecsSinceEpoch() - m_dateTimeQSOOn.toMSecsSinceEpoch()) > m_TRperiod * 10000) m_dateTimeQSOOn = dateTimeQSOOff;

В этом коде переменная m_TRperiod имеет значение 15 секунд для FT8 и 60 секунд для JT/T мод.

TO LY3BG:

Vytas, проверил под версией 18.1.0.34, софт четко срезает Time_On при превышении 150 секунд в FT8, на какой версии Вы наблюдаете приведенную Вами разницу времени?

[RA3QH]

в каком логе?

UR5EQF

[R0AX]

Почему JTDX последние шаги при включеном TX лекодирует через раз ,без передачи все без проблем

[UA3DJY]

Почему JTDX последние шаги при включеном TX лекодирует через раз ,без передачи все без проблем

все софты работают в режиме симплекса, либо передача либо прием

[R0AX]

так по скрину видно что TX через каждые 30 сек а RX раз в минуту

[R0AX]

а вот режим без передачи все периоды без пропуска

[UA3DJY]

а вот режим без передачи все периоды без пропуска

Включите пожалуйста запись звуковых файлов, закладка Save->Save All

Интересует звуковой файл за пропущенный интервал. Еще вопрос, какая у Вас загрузка процессора во время приема интервала, до момента начала декодирования?

И как часто настроена синхронизация времени?

[R0AX]

загрузка порядка 18-22% а wav файлы не хочет загружать сюда я записал 7 циклов прием передача

[R0AX]

171215_141700.wav171215_141800.wav171215_141830.wav171215_141930.wav171215_142000.wav171215_142015.wav171215_142030.wav171215_142045.wav
ну вот загрузил

[UA3DJY]

загрузка порядка 18-22% а wav файлы не хочет загружать сюда я записал 7 циклов прием передача

все файлы декодирую без проблем, по картинке могу сказать что у Вас в НЧ тракте идет с высоким уровнем пульсация 50 или 100 Гц, ее гармоники и множество продуктов интермодуляции, давайте сначала устраним эту проблему, потом уже будем смотреть что с декодированием

синхронизация времени в норме

[R0AX]

с НЧ разобрался,но проблема не исчезла.Новые wav файлы171215_150730.wav171215_150830.wav171215_150900.wav171215_151000.wav171215_151030.wav