Кажется,это зависит от формата ADIF.Связи залитые из UR5EQF иногда не определяются как В4, а с HB9HQX нормально. "Перезаливка" через него помогла - сейчас все нормально даже трех-летней давности.
Смотрел форму записи в журнале и JT-9 и JT-65 связей разницы не обнаружил никакой кроме моды. Записи 2015 года один в один с записями 2016. Может влияет время создания файла? Буду смотреть дальше на реальном эфире и без "ковыряния" файла журнала. К сожалению, осталось мало чистых JT-9 связей без дублирования в JT-65, но, как говорится, будем посмотреть - есть явление, должно быть и объяснение ему.
При более пристальном изучении,оказалось, что это не совсем так.
Вот что записано в 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?
Декодеры с подсказкой/согласованным фильтром (должна быть звездочка после декодированного сообщения) обрабатывают позывные из файла CALL3, и в этом случае возможно ложное декодирование которое всегда будет содержать реально существующий позывной.
Декодеры BM/KVASD/SFRSD/FTRSD обрабатывают кодированные символы и вероятность того что они в результате декодирования дадут правильно сформированное сообщение с реально существующим позывным равна почти нулю, за несколько лет в JT65 я такого ни разу не видел.
VP9GE сейчас активен в JT65.Цитата:
и ложные какие то вылазят типа 241 -24 0.1 1544 # CQ VP9GE FM72 !Bermuda
а его и не было?
Если Вы создаете базу данных в 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, этот файл не используется ни софтом WSJT-X/JTDX ни софтом JTAlert для функционала B4.Цитата:
Записи в WSJTX_log.adi
2015-май-17,02:30,UN7DA,NO00,21.078,JT9,+04,+05
это содержимое файла wsjtx_log.adi, JTDX v16.5rc3 в реальном времени считывает и использует эту информацию для проверки статуса B4.Цитата:
Записи в WSJTX.log
Здесь никакого различия в записи нет.
<call:5>UN7DA <gridsquare:4>NO00 <mode:5>JT9 <rst_sent:3>+04 <rst_rcvd:3>+05 <qso_date:8>20150517
По логике это,скорее всего CQNA слитно? Это не первый раз такое
Вложение 170060
вот снова станция с -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
и как отличить?
А такое проходили.Цитата:
это уже в проходили
Вложение 170061
E9DX, E9NA, E9AS и тому подобное является результатом модификации протокола JT65 (применено примитивное дополнительное кодирование результат которого является стандартным сообщением), эту модификацию сделал в одной из версий своего софта JT65-HF автор Beat HB9HQX. Просто кто то из операторов еще продолжает использовать эту версию, несовместимую по протоколу JT65 с WSJT-X.
Прошу помощи зала. После обновления программы, не помню какого, появилась бяка.Шум на двух частотах. Вертикальные палочки- это проблема звуковой карты. Пробовал возвращаться на предыдущую версию, тоже самое. Хотя раньше такого не было. На других программах такого нет. Подскажите, что я не так делаю? И еще вопрос. Иногда декодирование происходит на 58 до 03 секунды. Но не все. Часть декодируется сразу а одна какая нибудь позднее.
Спасибо.