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

[UN5J]

При создании Adif добавил - Used callsign, на первый взгляд, заработало.

Это был первый взгляд, - опять не определяет повторы. Пожалейте простой люд, зачем ему нужна программа, которая после каждого обновления требует настройки?
Сделайте так, чтобы можно было работать в программе, а не заниматься программированием.

[RX3ASP]

пример:я принял R-10--передаю RR73--а в ответ тишина--мои действия???

Вы позывной и рапорт получили? Да. Свой рапорт, подтверждение приёма рапорта и 73 передали? Да.
Делайте что хотите - передавайте CQ, отвечайте кому-то ещё, изучайте RX окно. Если потом пробьются 73, хорошо. Нет, так нет.
А если Вам Антарктика ответит в тот момент, когда ждёте это самое 73? Будете дальше RR73 передавать третьему району?

[US5WE]

пример:я принял R-10--передаю RR73--а в ответ тишина--мои действия???

Записываем в лог, грузим в LoTW и смотрим, подтвердилось или нет.

[R0AX]

а он мои RR73 не получил и пошел дальше,чтоб не мучаться,соответственно в лог не внес и таких примеров гора и не надо стрелы на Антарктиду переводить.Я и смотрю,у нас как 73 передавать,то Антарктида подходит,то какой-то Гондурас

[R0AX]

вот пока писал ,китайцу пришлось три раза RR73 передать,но связь закончилась

[R2EA]

Так есть для этого галочка RRR - самый что ни на есть полный ПРОТОКОЛ!

Забудьте про эти RRR, как страшный сон!
Скоро это станет не нужным и в wsjtx.
Вы видимо забыли, что раньше не было
возможности вызывать сразу рапортом?
А сейчас, я себе даже и не представляю
работу по другому...
Только рапорт и ни каких rrr!
Побалуйтесь с счетчиками-очень хорошая
реализованная задумка.
Я даже и не знаю чьи эти две хотелки,
но помню, что о них тоже мечтал.

На данный момент ни чего существенного
менять в JTDX не нужно. Просто необходимо
отточить и сделать лучше, то что есть.

Правда можно попробовать поиграться с алгоритмом
последовательности при окончании qso с последующим
подбором станции, а не cqингом для ручного режима.

И зачем оно нужно, это "прощальное" 73?

Это неотъемлемая часть qso!!!
Без полученного 73 qso в лог
вносят примерно 10 % коллег.
К ним прибавка от пользователей
Eqsl, которые тоже добавляют
в лог, если помнят свои связи.
В итоге, если от вас не будет 73,
то вам подтвердят 20-25% ваших
RRR - связей.

[US4IRT]

Это был первый взгляд, - опять не определяет повторы.

Владимир, последний раз предлагаю: отправьте мне свой ADIF переделаю на однострочный.

[R1MA]

а он мои RR73 не получил и пошел дальше, чтоб не мучаться, соответственно в лог не внес и таких примеров гора

Например, провожу связь с XE1KIM на 40 метрах (очень нужная связь), обменялись рапортами, получил RR73, передал 73. А он видимо мои 73 не получил, "затоптали" торопыги или QSB. В логе связь не появилась. Так Andy Kim на QRZ.COM прямо и пишет: If you work me on JT65, FT8 and I do not get a 73 from you, the QSO WILL NOT BE LOGGED. Думаю, что ПРОТОКОЛ надо соблюдать. И главное, не мешать корреспонденту завершить QSO, а потом уже звать на свободной частоте...

[R0AX]

Записываем в лог, грузим в LoTW и смотрим, подтвердилось или нет

а зачем вы от DX ждете ответное RRR,дали рапорт и пошли других dx-ов окучивать и ждите на lotw

[UA3DJY]

Понял почему в моих тестах снижается количество декодированных сообщений при ручном выборе большого количества потоков.

Планировщик задач Windows сначала выделяет ресурсы процессора под количество потоков равное количеству логических ядер и декодер декодирует вычитая в этих потоках все три прохода, после окончания работы декодера в этих потоках планировщик задач Windows выделяет ресурсы под еще не выполненные потоки декодирования и в этих оставшихся потоках тоже декодируются три прохода.

Если вручную выбрать количество потоков декодировании более количества логических ядер то на стыке полос частот потоков работающего и ожидающего с одной из сторон нет вычитания сигналов, поэтому для работающего и ожидающего потоков вероятность декодирования слабого сигнала близкого к границе полосы частот (стыку этих потоков) снижается, в итоге на своем четырехядерном i5 я не могу оценить реальную эффективность декодирования при ручном включении более чем 4-х потоков в декодере.

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

[UA3DJY]

Это был первый взгляд, - опять не определяет повторы. Пожалейте простой люд, зачем ему нужна программа, которая после каждого обновления требует настройки?
Сделайте так, чтобы можно было работать в программе, а не заниматься программированием.

Владимир, пожалуйста мне на почту Ваши файлы JTDX.ini, wsjtx_log.adi и картинку на которой показан сбой определения повтора. Без этой информации мы можем только гадать что у Вас не так.

[UA3DJY]

Забудьте про эти RRR, как страшный сон! Скоро это станет не нужным и в wsjtx.

Три года назад ломали копья насчет использования RR73 в протоколе сообщений QSO в моде JT65 в WSJT-X, тогда команда WSJT наотрез отказывалась добавить возможность использования RR73 в программе и это стало моей первой модификацией софта WSJT-X. Года летят, RRR живо

[RX3ASP]

Забудьте про эти RRR, как страшный сон!
Скоро это станет не нужным и в wsjtx.
Вы видимо забыли, что раньше не было
возможности вызывать сразу рапортом?
А сейчас, я себе даже и не представляю
работу по другому...
Только рапорт и ни каких rrr!
...
И зачем оно нужно, это "прощальное" 73?
Это неотъемлемая часть qso!!!
Без полученного 73 qso в лог
вносят примерно 10 % коллег.
К ним прибавка от пользователей
Eqsl, которые тоже добавляют
в лог, если помнят свои связи.
В итоге, если от вас не будет 73,
то вам подтвердят 20-25% ваших
RRR - связей.

Я не пользую RRR, как впрочем и AutoSeq6-7. Поэтому не очень понимаю, зачем вы столько написали в мой адрес.
RR73 и SkipGrid хорошие вещи, но многим пока непонятны, как Split, FakeIt и др. премудрости. То же самое рано или поздно будет и с "прощальными 73" в режиме RR73

Ради эксперимента, некоторое время не отправлял 73 в ответ на RR73. Конечно, это не было 1000 QSO, но процент не подтвердивших eQSL / LOTW тех, кто получал/не получал от меня 73 примерно одинаков и говорит скорее о медленном темпе загрузки пользователями adif на сервисы.

И ещё раз для любителей "прощальных 73" - WSJT их не требует, поэтому и не зацикливается на RR73

[UA3DJY]

И ещё раз для любителей "прощальных 73" - WSJT их не требует, поэтому и не зацикливается на RR73

Это дефект, вот пример несостоявшегося QSO:

CQ BB1BB OM65
BB1BB AA1AA FN25
AA1AA BB1BB -15
BB1BB AA1AA R-15
AA1AA BB1BB RR73 ... QSO внесено в лог
BB1BB AA1AA R-15
BB1BB AA1AA R-15
BB1BB AA1AA R-15...

[RA3QH]

Конечно протокол есть протокол и его желательно соблюдать....но отправка R-xx уже подразумевает то что рапорт принят...RR73 подтверждает прием рапорта той станцией которую звали(т.е так сказать "хозяин" частоты)...Если она для себя рапорт не приняла то в ответ идет повторно рапорт и в итоге ожидается получение того же R-xx которое повторюсь несет в себе инфо о приеме рапорта корреспондентом... По большому счету в передаче 73 нет никакой необходимости,это просто вежливость,прощание....