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

[US4IRT]

Если все связи проведены в текущем году, то всё работает корректно

Кажется,это зависит от формата ADIF.Связи залитые из UR5EQF иногда не определяются как В4, а с HB9HQX нормально. "Перезаливка" через него помогла - сейчас все нормально даже трех-летней давности.

[RX4HN]

Кажется,это зависит от формата ADIF.Связи залитые из UR5EQF иногда не определяются как В4, а с HB9HQX нормально. "Перезаливка" через него помогла - сейчас все нормально даже трех-летней давности.

Смотрел форму записи в журнале и JT-9 и JT-65 связей разницы не обнаружил никакой кроме моды. Записи 2015 года один в один с записями 2016. Может влияет время создания файла? Буду смотреть дальше на реальном эфире и без "ковыряния" файла журнала. К сожалению, осталось мало чистых JT-9 связей без дублирования в JT-65, но, как говорится, будем посмотреть - есть явление, должно быть и объяснение ему.

[RX4HN]

Записи 2015 года один в один с записями 2016.

При более пристальном изучении,оказалось, что это не совсем так.
Вот что записано в Log,e:

QSO с UN7DA в моде JT-65 на 20 метрах нет, но JTDX
выдаёт B4, тогда как Alert всё отображает нормально.
Alert работает с файлом WSJT_log.adi.

Записи в WSJTX_log.adi
2015-май-17,02:30,UN7DA,NO00,21.078,JT9,+04,+05
2015-июн-04,06:08,UN7DA,NO00,14.078757,JT9,-07,-09
2016-июл-27,00:00,UN7DA,NO00,7.076728,JT65,-08,-06,,,
2016-авг-20,22:49,UN7DA,NO00,3.576505,JT65,-01,-03,,,
2016-авг-26,23:36,UN7DA,NO00,7.078660,JT9,-04,-12,,,

Некоторые записи оканчиваются по разному:
2015-июн-05,05:56,5P1KZX,JO57,21.078136,JT65,-01,-01
2015-июн-05,14:30,M0GNM,IO91,14.079212,JT9,-24,-20,,
2016-май-26,01:08,4S7AVR,MJ96,14.077569,JT65,-13,-12,,,
На что влияет количество ,,, в строке?

Записи в WSJTX.log
Здесь никакого различия в записи нет.
<call:5>UN7DA <gridsquare:4>NO00 <mode:5>JT9 <rst_sent:3>+04 <rst_rcvd:3>+05 <qso_date:8>20150517 <time_on:4>0228 <band:3>15m <freq:9>21.078000 <station_callsign:4>RX4I <my_gridsquare:6>LO43xc <eor>
<call:5>UN7DA <gridsquare:4>NO00 <mode:3>JT9 <rst_sent:3>-07 <rst_rcvd:3>-09 <qso_date:8>20150604 <time_on:4>0608 <band:3>20m <freq:9>14.078757 <station_callsign:4>RX4I <my_gridsquare:6>LO43xc <eor>
<call:5>UN7DA <gridsquare:4>NO00 <mode:4>JT65 <rst_sent:3>-08 <rst_rcvd:3>-06 <qso_date:8>20160727 <time_on:4>0000 <band:3>40m <freq:8>7.076728 <station_callsign:4>RX4I <my_gridsquare:6>LO43xc <eor>
<call:5>UN7DA <gridsquare:4>NO00 <mode:4>JT65 <rst_sent:3>-01 <rst_rcvd:3>-03 <qso_date:8>20160820 <time_on:4>2249 <band:3>80m <freq:8>3.576505 <station_callsign:4>RX4I <my_gridsquare:6>LO43xc <eor>
<call:5>UN7DA <gridsquare:4>NO00 <mode:3>JT9 <rst_sent:3>-04 <rst_rcvd:3>-12 <qso_date:8>20160826 <time_on:4>2336 <band:3>40m <freq:8>7.078660 <station_callsign:4>RX4I <my_gridsquare:6>LO43xc <eor>
Похоже, что именно количество ,,, в конце строки и приводит к появлению В4 на JT-65 при ранее проведённых связях в JT-9, но почему это не фиксирут Alert?

[UA3DJY]

а как его определишь, только если бы он правда на диапазоне появился то народ по любому начал бы звать, а так никто его не увидел, и не вызывал, и это не раз так получается с другими позывными.

да, и в это время туда прохода у нас не бывает.

Декодеры с подсказкой/согласованным фильтром (должна быть звездочка после декодированного сообщения) обрабатывают позывные из файла CALL3, и в этом случае возможно ложное декодирование которое всегда будет содержать реально существующий позывной.

Декодеры BM/KVASD/SFRSD/FTRSD обрабатывают кодированные символы и вероятность того что они в результате декодирования дадут правильно сформированное сообщение с реально существующим позывным равна почти нулю, за несколько лет в JT65 я такого ни разу не видел.

и ложные какие то вылазят типа 241 -24 0.1 1544 # CQ VP9GE FM72 !Bermuda
а его и не было?

VP9GE сейчас активен в JT65.

[UA3DJY]

При более пристальном изучении,оказалось, что это не совсем так.

Alert работает с файлом WSJT_log.adi.

Если Вы создаете базу данных в JTAlert и импортируете в нее связи из wsjtx_log.adi то JTAlert работает со своей базой данных автоматом обновляя ее при занесении новой QSO в лог wsjtx_log.adi в случае когда JTAlert и WSJT-X работают одновременно. Если при использовании WSJT-X софт JTAlert не работает то занесенные в wsjtx_log.adi QSO не попадут в базу данных JTAlert до тех пор пока Вы снова не импортируете в нее wsjtx_log.adi лог.

Записи в WSJTX_log.adi
2015-май-17,02:30,UN7DA,NO00,21.078,JT9,+04,+05

это записи из файла WSJTX.log, этот файл не используется ни софтом WSJT-X/JTDX ни софтом JTAlert для функционала B4.

Записи в WSJTX.log
Здесь никакого различия в записи нет.
<call:5>UN7DA <gridsquare:4>NO00 <mode:5>JT9 <rst_sent:3>+04 <rst_rcvd:3>+05 <qso_date:8>20150517

это содержимое файла wsjtx_log.adi, JTDX v16.5rc3 в реальном времени считывает и использует эту информацию для проверки статуса B4.

[US-E-12]

На что влияет количество ,,, в строке?

Это разделитель. Нажмите LogQSO и заполните все пустые строки (Name, Tx Power, Comments), затем посмотрите файл, между всеми запятыми будет вписана информация.

[UA9OP]

VP9GE сейчас активен в JT65.

согласен если это так, поcмотрим дальше, а еще бывает вызываю к примеру w4uat, он мне не ответил, а через час приходит от него рапорт, это как?
а его в эфире уже давно нет кому отвечать?

[US4IRT]

По логике это,скорее всего CQNA слитно? Это не первый раз такое

[UA9OP]

и ложные какие то вылазят типа 241 -24 0.1 1544 # CQ VP9GE FM72 !Bermuda
а его и не было?
VP9GE сейчас активен в JT65.

вот снова станция с -1 отработала а с ней снова вылезают станции которых в данный момент нет на частоте


1452 -1 -0.3 969 # TU NEWBAND 73

1452 -10 -0.3 1562 # CQ G0CHE IO90 * ~England

1452 -11 -0.3 2531 # CQ DX W0MAF EM29 * ~U.S.A.

1452 -12 -0.3 1345 # CQ DX PY4DK GH51 * ~Brazil

и как отличить?

[UA9OP]

По логике это,скорее всего CQNA слитно? Это не первый раз такое

это уже в проходили

[US-E-12]

это уже в проходили

А такое проходили.

[UA3DJY]

вот снова станция с -1 отработала а с ней снова вылезают станции которых в данный момент нет на частоте


1452 -1 -0.3 969 # TU NEWBAND 73

1452 -10 -0.3 1562 # CQ G0CHE IO90 * ~England

1452 -11 -0.3 2531 # CQ DX W0MAF EM29 * ~U.S.A.

1452 -12 -0.3 1345 # CQ DX PY4DK GH51 * ~Brazil

и как отличить?

Звуковой файл, всегда и при любых проблемах для диагностики как минимум необходим звуковой файл.

Без него могу только гадать, например что это результат нелинейных искажений в приемном тракте.

[UA3DJY]

По логике это,скорее всего CQNA слитно? Это не первый раз такое

E9DX, E9NA, E9AS и тому подобное является результатом модификации протокола JT65 (применено примитивное дополнительное кодирование результат которого является стандартным сообщением), эту модификацию сделал в одной из версий своего софта JT65-HF автор Beat HB9HQX. Просто кто то из операторов еще продолжает использовать эту версию, несовместимую по протоколу JT65 с WSJT-X.

[UA3DJY]

А такое проходили.

Интересна цветовая маркировка этого свободного сообщения, из которой видно что в 16.5rc3 есть небольшой дефект.

[UR6EF]

Прошу помощи зала. После обновления программы, не помню какого, появилась бяка.Шум на двух частотах. Вертикальные палочки- это проблема звуковой карты. Пробовал возвращаться на предыдущую версию, тоже самое. Хотя раньше такого не было. На других программах такого нет. Подскажите, что я не так делаю? И еще вопрос. Иногда декодирование происходит на 58 до 03 секунды. Но не все. Часть декодируется сразу а одна какая нибудь позднее.
Спасибо.