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

[US4IRT]

А Hint декодеры работают в FT8? Вроде бы как нет ...

[UA3DJY]

А вот в JTDX сделано неправильно, отправлять на eqsl нужно с time_off иначе, если QSO длится более 5 мин., его просто не увидит в логе корреспондента и начнуться опять проблеммы.

посмотрел что по этому поводу пишут на eQSL, окно времени для подтверждения проведенной связи еQSL карточкой составляет плюс/минус один час, то есть допускается разница во времени в двух eQSL карточках до одного часа

Олег, а можно ли доработать UR5EQF лог чтобы он тоже поддерживал в отображении полученной eQSL разницу времени в один час, как сейчас на eQSL сервере?

В таком варианте почти все вопросы по разнице во времени отпадут.

[UA3DJY]

А Hint декодеры работают в FT8? Вроде бы как нет ...

там свой декодер, FT8AP, тоже включается кнопкой Hint

[US4IRT]

В таком варианте почти все вопросы по разнице во времени отпадут.

Так они и так отпадут при таком допуске, Игорь. В LoTW тоже приличный запас, но меньше часа.

[US-E-12]

а можно ли доработать UR5EQF лог чтобы он тоже поддерживал в отображении полученной eQSL разницу времени в один час

Игорь, дело не в этом. Человек имел ввиду, что у него совместно с LogHX работает JTDX и в обоих программах включена автоматическая отправка на eqsl. Так вот, JTDX отправляет время начала QSO, а LogHX, момент когда QSO заносится в лог (в JTDX это time_off), и это я считаю правильным, но отнюдь не время начала QSO. К примеру вызываем интересного кор-та (time_on запомнилось), но он отвечает другим, наконец QSO полностью состоялось через пол-часа (time_off). И какое время проведения QSO будет у кор-та. Я считаю, что правильным будет отправлять время фактического сохранения QSO во внутреннем логе.

[UA3DJY]

Игорь, дело не в этом. Человек имел ввиду, что у него совместно с LogHX работает JTDX и в обоих программах включена автоматическая отправка на eqsl. Так вот, JTDX отправляет время начала QSO, а LogHX, момент когда QSO заносится в лог (в JTDX это time_off), и это я считаю правильным, но отнюдь не время начала QSO. К примеру вызываем интересного кор-та (time_on запомнилось), но он отвечает другим, наконец QSO полностью состоялось через пол-часа (time_off). И какое время проведения QSO будет у кор-та. Я считаю, что правильным будет отправлять время фактического сохранения QSO во внутреннем логе.

QSO Time_Off не равно времени сохранения в логе и сейчас даже не уверен будет ли в новом AutoSeq Time_On браться с первого вызова, но все равно без проблем, дам возможность оператору выбрать какое время отправлять на eQSL

[R9FA]

Я считаю, что правильным будет отправлять время фактического сохранения QSO во внутреннем логе.

оно так есть, и правильней БЫТЬ не может, ЩСО-моё.
то что с еЩСЛ приходит от коллеги тоже его право (ну на дуэль

[US-E-12]

QSO Time_Off не равно времени сохранения в логе

Ну почему же

<call:5>RA2FU <gridsquare:4>KO04 <mode:3>FT8 <rst_sent:3>-15 <rst_rcvd:3>-15 <qso_date:8>20171214 <time_on:6>153258 <qso_date_off:8>20171214 <time_off:6>153432 <band:3>40m <freq:8>7.075614 <station_callsign:4>UR1E <my_gridsquare:4>KN78 <eor>

Time_off равно времени когда я (к примеру, сам не работаю) получил от RA2FU RRR и начал передачу RR73 и одновременно QSO сохранилось с этим временем в JTDX и основном логе.
Ха, сейчас мысленно провёл QSO и разница с кор-том будет в минуту (JT65, T10, JT9), передача начинается со следующей минуты.

[RZ3QS]

Можно сравнить, у кого какой прием.

UA3DJY, спасибо за FT8.

[R3OZ]

Интересно, как отличается прием DX в городе и за городом, и можно их сравнивать.
У меня в городе очень большой уровень шума на 160м, и не только на этом диапазоне.

[RZ3QS]

как отличается прием DX в городе и за городом, и можно их сравнивать.

Можно и нужно, как это делать я и показал.

в городе очень большой уровень шума на 160м

У меня не меньше на GP. Сейчас тихо, обычно на 10-15 дБ больше.

[LY3BG]

Игорь, дело не в этом. Человек имел ввиду, что у него совместно с LogHX работает JTDX и в обоих программах включена автоматическая отправка на eqsl. Так вот, JTDX отправляет время начала QSO, а LogHX, момент когда QSO заносится в лог (в JTDX это time_off), и это я считаю правильным, но отнюдь не время начала QSO.

Не пойму, зачем два раза слать в eQSL?

К примеру вызываем интересного кор-та (time_on запомнилось), но он отвечает другим, наконец QSO полностью состоялось через пол-часа (time_off). И какое время проведения QSO будет у кор-та. Я считаю, что правильным будет отправлять время фактического сохранения QSO во внутреннем логе.

Да, time_on теперь пишется не правильно. Вот пример, он мне ответил не сразу:
<call:5>A91ND <gridsquare:0> <mode:3>FT8 <rst_sent:3>-15 <rst_rcvd:3>-15 <qso_date:8>20171214 <time_on:6>175115 <qso_date_off:8>20171214 <time_off:6>175645 <band:3>40m <freq:8>7.074705 <station_callsign:5>LY3BG <my_gridsquare:4>KO24 <eor>
Time_on должно определятся по другому. Нельзя считать началом связи то время, когда я позвал первый раз. Думаю, что_time on должно показывать время, когда мне ответили.

[UA3DJY]

Да, time_on теперь пишется не правильно. Вот пример, он мне ответил не сразу:
<call:5>A91ND <gridsquare:0> <mode:3>FT8 <rst_sent:3>-15 <rst_rcvd:3>-15 <qso_date:8>20171214 <time_on:6>175115 <qso_date_off:8>20171214 <time_off:6>175645 <band:3>40m <freq:8>7.074705 <station_callsign:5>LY3BG <my_gridsquare:4>KO24 <eor>
Time_on должно определятся по другому. Нельзя считать началом связи то время, когда я позвал первый раз. Думаю, что_time on должно показывать время, когда мне ответили.

Обсуждали и у каждого своя точка зрения что считать началом QSO: передачу или прием сообщения, начало или конец сообщения. Поскольку у нас в разных вариантах при записи QSO в лог разброс получается не более чем пару минут для JT/T и менее минуты для FT8, то при допустимом разбросе 1 час в eQSL и 30 минут в LoTW сама дискуссия о том что считать началом и концом QSO теряет смысл.

У оператора есть файл ALL.TXT куда все действия теперь записываются посекундно, при необходимости он всегда может проверить что и когда происходило.

[LY3BG]

Поскольку у нас в разных вариантах при записи QSO в лог разброс получается не более чем пару минут для JT/T и менее минуты для FT8, то при допустимом разбросе 1 час в eQSL и 30 минут в LoTW дискуссия о том что считать началом и концом QSO теряет смысл.

Ещё раз повторяю - <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.

[RZ3DX]

а звать можно сколько угодно, час, два... пока ответит.

Все правильно, особенно когда надо дозваться до DXpedion или до DX-a.
Или каждый раз очищать окна, если тебе не ответили сразу.
Вот интересно, при очистке Time-on сбрасывается или нет?

73