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

[US5WE]

Я могу привести еще с десяток DX, которые свято следуют протоколу. И с десяток DX, которые не отвечают, если не зовут локатором.

Интересно увидеть список. Мы тут практически всегда рапортом зовем, вот и сегодня TO3Z с первого вызова на 160м на рaпорт ответил.

[UA1OMZ]

Вот он редкий случай, несколько минут назад, когда человек не принял 73 и требует "продолжение банкета", ну дал ему оперативно вручную ещё раз 73 (как писали ради уважения, хотя мог и не давать), ведь связь то у него уже после его первого RRR была в логе. И вот вам вопрос на засыпку - неужели он или кто ли бо другой в здравом уме будет ли удалять из лога QSO если не получит 73??? Думаю, что нет!

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

А вот если бы его повторное RRR(RR73/73) было бы не принято, то ранее при включенном автомате, программа зациклилась бы на повторной передаче ненужного RR73/73, засоряя эфир. Но не теперь в режимах autoseq0 и autoseq1, QSO заканчивается логично без лишних RR73/73, ещё раз спасибо!

[LY3BG]

...PZ5RA один из тех, кто требует абсолютно полного соблюдения протокола.

Но на вызов рапортом реагирует нормально

[R5WM]

Чем дальше в лес, тем больше "феноменов"
К вопросу о рапортах и соблюдении протокола
В итоге плюнул...

Оператор включил режим VHF Contest!

[RJ7M]

Оператор включил режим VHF Contest

Лучше бы ОН голову включил

[UR5LCZ]

У меня была сегодня ситуация с YY7WGA.
Вызвал его - он ответил с рапортом -10, т.е. контакт нормальный.
Я тоже дал рапорт -16.
От него RRR
Я 73 в ответ.
Он мне 73 гонял цикла 3, пока я еще один раз не дал ему 73 уже вручную.
Любой сценарий можно довести до маразма - по 10 раз друг другу гонять "наитеплейшие" 73.
Этот сценарий проведения связи, я думаю, со временем упростится.
Может в ущерб подтверждаемости.
На заре своей радиолюбительской деятельности в телеграфе работал на "клоподаве".
При проведении связи - обязательно приветствие, все данные в обе стороны, завершение.
А сейчас - 5NN и GL или 73 - вот и вся связь, и не только с дэхом.
Очень редко, когда еще что-то.
Так что надо просто подождать.

[UA3DJY]

Вот он редкий случай, несколько минут назад, когда человек не принял 73 и требует "продолжение банкета", ну дал ему оперативно вручную ещё раз 73 (как писали ради уважения, хотя мог и не давать), ведь связь то у него уже после его первого RRR была в логе.

Программа при передаче RRR не заносит связь в лог, только если корреспондент вручную ее внесет.

[UA3DJY]

Игорь, а не по этой причине не видит adif, что в WSJT-X формируется так <station_callsign:6>US4IRT а в логах в основном <OPERATOR:6>US4IRT

Благодарю, фильтр лога в JTDX (если активирован) действительно должен читать позывной с тэга <OPERATOR> если в записи отсутствует тэг <STATION_CALLSIGN>. Ох уж этот ADIF стандарт

[RJ7M]

А сейчас - 5NN и GL или 73 - вот и вся связь, и не только с дэхом.

У меня на UA0ZS есть сертификат американского Rag Chewers Club. Приглашают сами по рекомендации двоих членов. Непременным условием является проведение CW QSO продолжительностью не менее 30 минут. Rag chewers club - Amateur-radio-wiki
Это вам "не здрасьте - до свиданья". А сейчас и без этого зачастую.

[US5WE]

Благодарю, фильтр лога в JTDX (если активирован) действительно должен читать позывной с тэга <OPERATOR> если в записи отсутствует тэг <STATION_CALLSIGN>. Ох уж этот ADIF стандарт

Я очевидно не понимаю сути дискуссии.
В WSJT-X:
<call:6>SM0FGT <gridsquare:4>JO89...
в JTDX:
<call:5>VE3XN <gridsquare:4>EN93...
Cоответственно, можно делать merge логов обоих программ, с последующей загрузкой в LoTW завершая, таким образом, цикл QSO->QSL.

[EU1FQ]

To UA3DJY:
Игорь, Если стоит галочка "Маркеры", то не работает звуковое оповещение по "другим стандартным сообщениям", позывные, которые соответствуют уведомлению, но помечены маркером.
Если же стоит галочка "Выделение других стандартных сообщений", то все нормально. Но тогда автоматом снимается галочка "Маркеры". Это так и задумано, что не работает звуковое оповещение по "другим стандартным сообщениям", если стоит галочка "Маркеры"?

[UR5LCZ]

Игорь!
На будущее, если есть такая возможность, добавить выделение новых префиксов в закладке "Уведомления".

[RA3QH]

Игорь,так все же какой вид должна иметь строка ADIF в логе? После установки версии 132 заметил что JTDX показывает мне меньше QSO чем было,причем значительно....только в FT8 "исчезло" около 1000...Будет ли нормальным для JTDX такой формат
<OPERATOR:5>RA3QH<CALL:6>UA9CGL<QSO_DATE:8>20190306<TIME_ON:4>1047<FRE Q:6>10.136<MODE:3>FT8<RST_SENT:2>01<RST_RCVD:3>-11<NAME:4>Vlad<QTH:12>Ekaterinburg<STATE:5>SV-03<GRIDSQUARE:4>MO06<PFX:4>UA9C<DXCC_PREF:3>UA9<BAND:3>30M<CONT:2>AS<C QZ:2>17<ITUZ:2>30<DXCC:2>15<EOR>

[UA3DJY]

Благодарю, фильтр лога в JTDX (если активирован) действительно должен читать позывной с тэга <OPERATOR> если в записи отсутствует тэг <STATION_CALLSIGN>. Ох уж этот ADIF стандарт

Игорь,так все же какой вид должна иметь строка ADIF в логе? После установки версии 132 заметил что JTDX показывает мне меньше QSO чем было,причем значительно....только в FT8 "исчезло" около 1000...Будет ли нормальным для JTDX такой формат
<OPERATOR:5>RA3QH<CALL:6>UA9CGL<QSO_DATE:8>20190306<TIME_ON:4>1047<FRE Q:6>10.136<MODE:3>FT8<RST_SENT:2>01<RST_RCVD:3>-11<NAME:4>Vlad<QTH:12>Ekaterinburg<STATE:5>SV-03<GRIDSQUARE:4>MO06<PFX:4>UA9C<DXCC_PREF:3>UA9<BAND:3>30M<CONT:2>AS<C QZ:2>17<ITUZ:2>30<DXCC:2>15<EOR>

Замените OPERATOR на STATION_CALLSIGN в текстовом редакторе.

Добавил функционал импорта ADIF лога в формат используемый в JTDX в очередь на исполнение.

[UA3DJY]

Наблюдаю такой сбой под версией VAC 4.60, появляется через некоторое время после нормальной работы, как временное решение придется откатиться на предыдущую версию VAC:

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

Для тех кто дает цифровой поток с железа SDR на JTDX/WSJT-X через VAC, параметр 'Ms per int' позволяет компенсировать набег фреймов и соответственно уход DT:

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