SWL из TL-04

[R3PLN]

Ну вот мы и вернулись к тому, с чего начали...
Понятно, что это проблема хамлога и изрядно самих цифромодемрв. Одни не хотят вменяемый интерфейс наблюдателя, вторые формируют изначально некорректный файло (о чем, кстати, при загрузке на e-qsl имеется чекбокс "это файло неправильное, почините теги").
Так ведь хорошо, что есть желающие и могущие запилить тулзу-конвертер! Я для личных целей вообще сделал парсер, чтобы не грузить серсисы тысячами повторных строк.
Если мы со своей стороны чем-то можем быть полезны - только ЗА руками и ногами!
Поделитесь наработками, дадим фидбек.
Правда, только если на моно или вменяемо пускаемое вайном, тут как бы и нормальные юзеры никсов в наличии...

[R2PU]

Итак , в ADIF загружаемом на hamlog/eQSL (отестил на обоих сервисах):
а) реальный RST c которым Вы принимали станции - тэг <RST_SENT>
б) указание второй станции с которой хэм проводил QSO - тэг <QSLMSG>

На самом деле, во всяком случае для заливки на HAMLOG, как раз в тэг <RST_SENT> нужно указывать SWL, а вот в <rst_rcvd> указывать реальный уровень сигнала, с которым наблюдатель видел ваш сигнал, хотя если честно, здесь можно писать почти что угодно, т.к. в ходе радиообмена уровни сигналов меняются от посылки к посылке. Данный формат уже проверен, залит и получен ПРАВИЛЬНЫЙ результат, в том числе, и подтверждения от HAMов. Программа автоматизированной конвертации файлов WSJT-X совместными усилиями с UA3482SWL и UR1274SWL уже написана и проходит тестирование.

Ходим по кругу (даже в элементарном, не говоря уж о большем).....
Сейчас повторно перепроверил, может поймёте наконец хоть в таком формате :

Видно, да? (ухнута ещё ночь - бо мне чисто по человечески жалко как начитавшихся "рецептов" наблюдателей - так и хэмов которым на hamlog/eQSL сыплятся сотни QSLок от наблюдателей с дефолтными "-10" вместо реальных RST).

Проверяйте ещё раз (желательно с аналогичными скринами применительно к конкретным записям ADIF) - пока Ваше детище не вышло "на широкую дорогу" да окончательно не "засыпало" хэмов наблюдательскими QSLками с дефолтным RST "-10"
+ естественно указание второй станции (чтоб не ходить по кругу читаните мои предыдущие посты)

Всё остальное - чуть позже, при взаимном понимании - естественно продолжим.

P.S. Естественно отправка UA3219SWL-R2PU была только в тестовых целях и по окончании эксперимента потёр записи в журналах и на сервисах - чтоб не обвинили в "раздвоении" личности

Я для личных целей вообще сделал парсер, чтобы не грузить серсисы тысячами повторных строк.

Заинтересовал чесслово, можно подробнее про "грузить серсисы тысячами повторных строк" , что есть лишние строки ?

[UD0XAO]

Всем добрый день! (Хотя у меня уже глубокая ночь)

Вот скриншот моего журнала в HAMLOGе. Записи заносились через adif-файл именно по тому образцу, который я описывал выше.

Подготовленную и направляемую карточку я просматриваю открывая в этом же окне, столбец QSL.
Естественно, я как и Вы прежде чем остановится на данном варианте провел не один тест со своим позывным. К сожалению показать не смогу, я уже их просто удалил, а повторять заново не вижу смысла.
Возможно, не корректно идет отображение в данном окне, ну или в работе самого HAMLOGa. Этого я не могу сказать.
Сегодня специально зарегистрировался на eQSL. Там как раз ВЫ были абсолютно правы - уровень сигнала нужно указывать в
поле <RST_SENT>.
Для себя могу сделать самый простой вывод - чтобы не было путаницы - одно и то же значение уровня можно указывать в обеих полях! На мой взгляд это не критично, т.к. в любом случае HAM не принимал наблюдателя ни с каким уровнем сигнала. А если посмотреть на то что присылают в ответных QSL, то там можно увидеть абсолютно всё что угодно.

По поводу моей программки, как вы изволили выразится

пока Ваше детище не вышло "на широкую дорогу" да окончательно не "засыпало" хэмов наблюдательскими QSLками с дефолтным RST "-10"

могу Вас успокоить, у меня нет никакого желания её туда - на широкую дорогу - выводить. Программа писалась для себя и ещё для нескольких человек.
Хотя как раз в ней и реализован тот самый механизм защиты HAMов от "засыпания" их тысячами строк:
- в конечный adif попадают только полностью завершенные QSO, а не просто CQ и разного рода безответные попытки установления связи
- кроме того даже среди этих, полностью завершенных связей, проводится дополнительная проверка на повторение (добавление в adif) позывного не ранее чем через какой-то промежуток времени (от 1 дня и больше).

Таким образом, из общего массива в несколько тысяч строк файла all.txt, формируемого WSJT-X, на первом этапе отсева остаётся примерно сотня, ну а после второго этапа - несколько десятков.

В то же время, могу отметить что сами HAMы заливают свои QSO, проведенные в FT8, сотнями (если не тысячами). Понятно, что подтверждение проходит автоматически при условии что и вторая сторона диалога сделает то же самоё. Получается что проблема не в наблюдателях, а в отсутствии на сервисах типа eQSL/HAMLOG и им подобных механизма автоматического подтверждения данных логов, залитых наблюдателями.

С уважением UD0XAO, 73!

[R3PLN]

Я для личных целей вообще сделал парсер, чтобы не грузить серсисы тысячами повторных строк.

Заинтересовал чесслово, можно подробнее про "грузить серсисы тысячами повторных строк" , что есть лишние строки ?

Рома, давай поспокойнее. Хэм не врубится, что от SWL нужен иной формат записей.

WSJTX не умеет выводить записи строго по числам, не умеет делать выборки. Можно только весь лог за всё время загрузить. Надо оно? Не надо. Сделал себе парсер, который запоминает крайнюю прошлую связь и выбирает только свежие, которые я потом и загружаю. вместо 10100 связей с 10000 повторов сервисы получают только 100 свежих.
Но я ж в линуксе живу, придётся сильно переписать =)

[R2PU]

Вот скриншот моего журнала в HAMLOGе. Записи заносились через adif-файл именно по тому образцу, который я описывал выше.

Ну теперь хоть понятно где проблема - Вы возможно просто недопроверили конечный результат (что придёт реальному хэму от реального наблюдателя) на двух разных учётках "наблюдатель"-"хэм".
Ещё раз, что в итоге видит реальный хэм (R2PU) от реального наблюдателя (UA3219SWL):

Ещё раз для начинающих наблюдателей:
в ADIF загружаемом на hamlog/eQSL :
а) <RST_SENT> - реальный RST c которым Вы принимали станцию
б) <QSLMSG> - указание второй станции с которой хэм проводил QSO
в) <RST_RCVD> - указываете три буквы SWL (не надо "0"или тем более "что угодно")

Сегодня специально зарегистрировался на eQSL. Там как раз ВЫ были абсолютно правы - уровень сигнала нужно указывать в
поле <RST_SENT>.

Ну слава ж тебе Попов (или Маркони), хоть что-то удалось наконец донести.
Ни грамма стёба: не радовался так как сейчас - ни когда подтвердил свою 100ю DXCC как наблюдатель (FT8 и такой массовости в DIGI не было ещё и в помине), ни когда подтвердил свою 250ю DXCC + все 40 зон + все 50 штатов как хэм
Расскажем, подскажем, поможем - было бы понимание!

Для себя могу сделать самый простой вывод - чтобы не было путаницы - одно и то же значение уровня можно указывать в обеих полях! На мой взгляд это не критично, т.к. в любом случае HAM не принимал наблюдателя ни с каким уровнем сигнала. А если посмотреть на то что присылают в ответных QSL, то там можно увидеть абсолютно всё что угодно.

Критично, в первую очередь для самих же наблюдателей (многие из которых становятся потом хэмами).
Чёткое понимание форматов данных и соблюдение их - залог уверенной и не побоюсь этого слова красивой работы как для наблюдателя так и для хэма.
Тэг <RST_RCVD> в ADIF - наблюдатель указывает три буквы SWL , мир-дружба-взаимопонимание и уважение к человеку придерживающемуся общепринятой системы.
Увидеть на QSL от некоторых хэмов действительно можно что угодно (от их местного времени и даты в неправильном формате - до "10MHz SSB") - но давайте с самого начала работать правильно а не "и так сойдёт" ?

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

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

- в конечный adif попадают только полностью завершенные QSO, а не просто CQ и разного рода безответные попытки установления связи
- кроме того даже среди этих, полностью завершенных связей, проводится дополнительная проверка на повторение (добавление в adif) позывного не ранее чем через какой-то промежуток времени (от 1 дня и больше).
Таким образом, из общего массива в несколько тысяч строк файла all.txt, формируемого WSJT-X, на первом этапе отсева остаётся примерно сотня, ну а после второго этапа - несколько десятков.

Ну в общем приплыли (по аналогии с "робостанциями" клепающими QSO многими тысячами без участия оператора), в первом приближении Ваш алгоритм выглядит примерно так? :
-step1: наблюдатель запускает комп с WSJT-X/JTDX и может уходить по своим делам на энное количество часов/дней
-step2: спустя энное количество часов-дней наблюдатель приходит и "скармливает" софтинке файл all.txt из WSJT-X/JTDX
-step3: умная софтинка "вычленяет" из файла all.txt все принимавшиеся QSO , фильтрует от повторов , создаёт ADIF файл
-step4: наблюдатель заливает ADIF файл на сервисы (eQSL/hamlog)
Охо-хо (это не хорошо и не плохо) , ещё совсем недавно понятие "наблюдатель" трактовалось как живой человек слушающий эфир и в реальном времени самолично "выцепляющий" QSO проводимые хэмами.
SWL = Short Wave Listening , где он теперь тот "слушатель" самолично сидевший за приёмником (ну или "SDR-свистком" в последние годы) , всё свелось к : "включил-ушёл на ....цать часов - через ....цать часов пришёл и скармливай файлы программам" ?
Не осуждаю (нравится-играйте) , просто хочу заметить что в бытность наблюдателем я мало того что получил массу удовольствия - так ещё и дофига чему научился (поэтому "свежеиспечённый" R3PJT и начал сразу выдавать результаты в том же DXинге - а не забивать лог сотнями\тысячами QSO c соседними околотками да европейскими соседями).
Впрочем каждый выбирает сам, нравится играть в "робоSWL"- играйте , как/если надоест - маякнёте, расскажу про DXCC/WAZ/WAS , экспедиции да контесты - и "прицельную" работу живого оператора (ни с чем несравнимое удовольствие + естественно результат).

Рома, давай поспокойнее.

Лёша, я стараюсь (например мой предыдущий пост был мной же почикан примерно впятеро по обьёму).
Но когда человек делающий буквально первые шаги в хэмрадио начинает подавать какие-то советы космического масштаба .......(о это бессмертное из Михаила Афанасьевича) на предмет "неправильных" интерфейсов , функционала , хэлпов в отношении:
WSJT-X ( K1JT кстати обладатель Нобелевской премии)
JTDX ( UA3DJY )
hamlog.online (R4AS)
подаривших десяткам тысяч хэмов со всего мира мира недостижимые раньше возможности + ведущих постоянную многолетнюю титаническую работу по совершенствованию своих продуктов и добавлению всё нового функционала.
То очень трудно не залудить ту цитату из Булгакова целиком (пока получается).
Куда уж ещё спокойней ......

WSJTX не умеет выводить записи строго по числам, не умеет делать выборки. Можно только весь лог за всё время загрузить. Надо оно? Не надо. Сделал себе парсер, который запоминает крайнюю прошлую связь и выбирает только свежие, которые я потом и загружаю. вместо 10100 связей с 10000 повторов сервисы получают только 100 свежих.
Но я ж в линуксе живу, придётся сильно переписать =)

И зачем для этого использовать файл лога из программы WSJT-X - ни разу не являющейся программой аппаратного журнала любительской радиостанции ?
Отработанное, проверенное, и приносящее некислые плоды (стараюсь иногда обновлять https://www.qrz.com/db/R2PU , равно как и можно глянуть на том же хэмлоге по подтверждённому на Р-150-С ) выглядит так:
- step1: проведённое QSO из WSJT-X/JTDX "на лету" идёт в программу аппаратного журнала (кстати совсем не нужно использовать для этого файл wsjtx_log.adi , взаимодействие WSJT-X/JTDX и аппаратного журнала лучше организовать по UDP - тогда QSO по завершении связи автоматом "влетает" в аппаратный журнал).
- step2: выбираем в аппаратном журнале "свежие" , ещё не выгружавшиеся QSO (руками или например через фильтр "Not send QSO").
- step3: Экспортируем выбранные в аппаратном журнале QSO в ADIF файл (для выгрузки на сервисы), или отправляем их на сервисы встроенным функционалом аппаратного журнала.
Всё ....
Великое благо такого принципа - то что "залетевшие" в журнал но ещё не отправленные на сервисы QSO (step1-step2) можно оперативно редактировать в любом мыслимом и потребном варианте , равно как и то что можно выбирать перед step3 массив отправляемого , да и всё равно ж заносить проведённые QSO в аппаратный журнал - так лучше отправлять на сервисы из него (используя всё богатство встроенного функционала).
За линукс не порекомендую в деталях - но под форточки современные аппаратные журналы (тот же LogHX3) имеют все мыслимые и немыслимые варианты для комфортной работы )))).

[UD0XAO]

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

Как раз проблема в том, что я, как пользователь HAMLOGA (или любого другого сервиса) не должен заглядывать куда-то ещё и разгадывать ребусы: "почему у меня в карточке видно одно, а на другой стороне другое". Это и есть - некачественная работа программного обеспечения!
С другой стороны, когда здесь на форуме, такие "метры" дальней радиолюбительской связи, которые всячески восхваляют свои заслуги прошлого,

ни когда подтвердил свою 100ю DXCC как наблюдатель (FT8 и такой массовости в DIGI не было ещё и в помине), ни когда подтвердил свою 250ю DXCC + все 40 зон + все 50 штатов как хэм

а сейчас точно также не брезгуют заносить в тот же HAMLOG "местничковые" QSO, я думаю мне, хоть и с двадцатилетним опытом в радио (а в программировании даже больше) но, как вы считаете

человек делающий буквально первые шаги в хэмрадио начинает подавать какие-то советы космического масштаба

наверное просто нечего делать, ну чтобы не давать никому космических советов и не отнимать вашего "драгоценного" времени.

До встреч в эфире.

[R3PLN]

Рома, я делаю это в стиле Linux:
Step 1: $> export.py

Рома, блин, выключай менторский тон, люди умные любят учиться, но очень не любят, когда их учат

Не просто так сделали агента, например, не находишь? То-то и оно. Нет в никсах журнала, который жрёт костыли в виде клиент-сервер на одной машине, ибо это костыль костыльный. А написать простейший парсер лога может любой уважающий себя линуксоид. Если ещё и в регэкспы уметь, то даже для SWL робота написать как два пальца. Ну как робота... Тот же парсер, ищущий двусторонние наблюдения в общем файле расшифровок. Как один палец, на спор за пиво нашкрябаю левой пяткой.

И чо это за намёки про роботизированные станции? То есть это получается чуть освободить руки - зло, а отвалить полляма за сдр-траесивер, который ещё и телеграф за тебя читает - типа это православно?
А ты поди сделай бакен из транзистора прошлого тысячелетия

А вот садиться писать такого робота-парсер-логер без понимания основ - реально зло. Это все уже поняли. Давай уже не трать силы и время на переливания из пустого в порожнее, все всё поняли, нам вебинары не нужны

[R2PU]

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

Всю необходимую информацию Вам выдали - сопроводив её подробным описанием базовых принципов и результатами реального тестирования.
Увы так и не увидел в ответ не то что понимания - но хотя бы элементарного TNX.

Это и есть - некачественная работа программного обеспечения!

Которым пользуются десятки тысяч хэмов ....
-Тот же hamlog.online по совокупности реализованного функционала уже не имеет аналогов в мире
-Та же WSJT-X была первой и регулярно обрастает новыми цифровыми модами
- Та же JTDX имеет множество возможностей и постоянно расширяется по функционалу.
Требовать от R4AS, K1JT, UA3DJY срочного исполнения Ваших персональных "хотелок" - не сильно продуктивно и конструктивно , там и без того гигантский труд и постоянная работа по совершенствованию софта.

С другой стороны, когда здесь на форуме, такие "метры" дальней радиолюбительской связи, которые всячески восхваляют свои заслуги прошлого,
а сейчас точно также не брезгуют заносить в тот же HAMLOG "местничковые" QSO, я думаю мне, хоть и с двадцатилетним опытом в радио (а в программировании даже больше) но, как вы считаете
наверное просто нечего делать, ну чтобы не давать никому космических советов и не отнимать вашего "драгоценного" времени.
До встреч в эфире.

Решать Вам.
Со своей стороны могу предложить некоторую "перезагрузку" - и спокойно, не срываясь на личности обьяснить хотя бы базовое:
- почему хэмы зачастую не сильно смотрят на "стаж", но сильно смотрят на то кто чего достиг и смог
- откуда у DXмэнов\контестменов в логе появляются не только DX QSO
- равно как и то что указание своих достижений (на том же qrz.ru у некоторых прямо в подписи) - общепринятая практика.

Рома, блин, выключай менторский тон, люди умные любят учиться, но очень не любят, когда их учат

Лёша, блин не говори за всех.
Когда начинают говорить\писать R2PT (DXCC HR) , RW3PZ (DXCC HR#1 and other) и далее по списку - согласен терпеть от них любой тон и "поучения" - и предпочитаю не гнездить свои теории и критиковать что-то там , а послушать тех кто лучше\больше\сильнее.

Нет в никсах журнала, который жрёт костыли в виде клиент-сервер на одной машине, ибо это костыль костыльный.

CQRLOG for Linux ( """ WSJT-X Logging directly to CQRLOG """" )
EWLog ( """ WSJT-X тоже работает, в настройках самой WSJT нужно включить UDP и в журнале поставить галочку использовать WSJT-X """ )

И чо это за намёки про роботизированные станции?

Моветон цитировать самого себя, но повторюсь (из предыдущего поста): "включил-ушёл на ....цать часов - через ....цать часов пришёл и скармливай файлы программам"
Вот это в моём понимании уже не хэмрадио а что-то другое ..... (IMHO единственное исключение - DX-pedition c их стороны , впрочем там свои "камни" с ARRL , преценденты были)
Хочешь поговорить об этом - давай в другой теме (бо первые "роботы" FT8 появились ещё в 2017м, начиная с SV5DKL и понеслась .... вплоть до SQ9FVE и его "мега супер" WSJT-Z ).

То есть это получается чуть освободить руки - зло, а отвалить полляма за сдр-траесивер, который ещё и телеграф за тебя читает - типа это православно?

Не знаю ни одного полумиллионера для которых наличие декодера CW в покупаемом аппарате было ключевым фактором ))))
Если ты про локальный скиммер - то там совсем другие цели\задачи, да и проводит QSO всё равно живой оператор с ушами-руками а не "автопилот"

Давай уже не трать силы и время на переливания из пустого в порожнее, все всё поняли, нам вебинары не нужны

Чёт не увидел я понимания в в ответ на конкретное инфо а увидел очередной виток: "софт от R4AS, K1JT, UA3DJY плохой и недоработанный" + несколько "рецептов" (чего стоит только : "вот в <rst_rcvd> указывать реальный уровень сигнала, с которым наблюдатель видел ваш сигнал, хотя если честно, здесь можно писать почти что угодно, т.к. в ходе радиообмена уровни сигналов меняются от посылки к посылке" + "одно и то же значение уровня можно указывать в обеих полях! " ) + изрядно личных выпадов (старался особо не акцентироваться , бо пишуший их местами просто не понимал элементарного).

Я обычно трачу время и силы в расчёте на то что дискуссию прочитает кто-то из тех кто ищет в сети необходимое инфо , сильно не хотелось чтобы начинающие наблюдатели приняли один из тех перлов за руководство к действию.
Тем более что всё просто и оттестено:
Ещё раз для начинающих наблюдателей:
в ADIF загружаемом на hamlog/eQSL :
а) <RST_SENT> - реальный RST c которым Вы принимали станцию
б) <QSLMSG> - указание второй станции с которой хэм проводил QSO
в) <RST_RCVD> - указываете три буквы SWL (не надо "0"или тем более "что угодно")

Если это действительно понятно - тогда да , результат достигнут (не суть какой ценой).

[R2PU]

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

Всю необходимую информацию Вам выдали - сопроводив её подробным описанием базовых принципов и результатами реального тестирования.
Увы так и не увидел в ответ не то что понимания - но хотя бы элементарного TNX.

Это и есть - некачественная работа программного обеспечения!

Которым пользуются десятки тысяч хэмов ....
-Тот же hamlog.online по совокупности реализованного функционала уже не имеет аналогов в мире
-Та же WSJT-X была первой и регулярно обрастает новыми цифровыми модами
- Та же JTDX имеет множество возможностей и постоянно расширяется по функционалу.
Требовать от R4AS, K1JT, UA3DJY срочного исполнения Ваших персональных "хотелок" - не сильно продуктивно и конструктивно , там и без того гигантский труд и постоянная работа по совершенствованию софта.

С другой стороны, когда здесь на форуме, такие "метры" дальней радиолюбительской связи, которые всячески восхваляют свои заслуги прошлого,
а сейчас точно также не брезгуют заносить в тот же HAMLOG "местничковые" QSO, я думаю мне, хоть и с двадцатилетним опытом в радио (а в программировании даже больше) но, как вы считаете
наверное просто нечего делать, ну чтобы не давать никому космических советов и не отнимать вашего "драгоценного" времени.
До встреч в эфире.

Решать Вам.
Со своей стороны могу предложить некоторую "перезагрузку" - и спокойно, не срываясь на личности обьяснить хотя бы базовое:
- почему хэмы зачастую не сильно смотрят на "стаж", но сильно смотрят на то кто чего достиг и смог
- откуда у DXмэнов\контестменов в логе появляются не только DX QSO
- равно как и то что указание своих достижений (на том же qrz.ru у некоторых прямо в подписи) - общепринятая практика.

Рома, блин, выключай менторский тон, люди умные любят учиться, но очень не любят, когда их учат

Лёша, блин не говори за всех.
Когда начинают говорить\писать R2PT (DXCC HR) , RW3PZ (DXCC HR#1 and other) и далее по списку - согласен терпеть от них любой тон и "поучения" - и предпочитаю не гнездить свои теории и критиковать что-то там , а послушать тех кто лучше\больше\сильнее.

Нет в никсах журнала, который жрёт костыли в виде клиент-сервер на одной машине, ибо это костыль костыльный.

CQRLOG for Linux ( """ WSJT-X Logging directly to CQRLOG """" )
EWLog ( """ WSJT-X тоже работает, в настройках самой WSJT нужно включить UDP и в журнале поставить галочку использовать WSJT-X """ )
Далее не "менторствую" , бо сам на форточках.

И чо это за намёки про роботизированные станции?

Моветон цитировать самого себя, но повторюсь (из предыдущего поста): "включил-ушёл на ....цать часов - через ....цать часов пришёл и скармливай файлы программам"
Вот это в моём понимании уже не хэмрадио а что-то другое ..... (IMHO единственное исключение - DX-pedition c их стороны , впрочем там свои "камни" с ARRL , преценденты были)
Хочешь поговорить об этом - давай в другой теме (бо первые "роботы" FT8 появились ещё в 2017м, начиная с SV5DKL и понеслась .... вплоть до SQ9FVE и его "мега супер" WSJT-Z ).

То есть это получается чуть освободить руки - зло, а отвалить полляма за сдр-траесивер, который ещё и телеграф за тебя читает - типа это православно?

Не знаю ни одного полумиллионера для которых наличие декодера CW в покупаемом аппарате было ключевым фактором ))))
Если ты про локальный скиммер - то там совсем другие цели\задачи, да и проводит QSO всё равно живой оператор с ушами-руками а не "автопилот"

Давай уже не трать силы и время на переливания из пустого в порожнее, все всё поняли, нам вебинары не нужны

Чёт не увидел я понимания в в ответ на конкретное инфо а увидел очередной виток: "софт от R4AS, K1JT, UA3DJY плохой и недоработанный" + несколько "рецептов" (чего стоит только : "вот в <rst_rcvd> указывать реальный уровень сигнала, с которым наблюдатель видел ваш сигнал, хотя если честно, здесь можно писать почти что угодно, т.к. в ходе радиообмена уровни сигналов меняются от посылки к посылке" + "одно и то же значение уровня можно указывать в обеих полях! " ) + изрядно личных выпадов (старался особо не акцентироваться , бо пишуший их местами просто не понимал элементарного).

Я обычно трачу время и силы в расчёте на то что дискуссию прочитает кто-то из тех кто ищет в сети необходимое инфо , сильно не хотелось чтобы начинающие наблюдатели приняли один из тех перлов за руководство к действию.

Тем более что всё просто и оттестено:
Ещё раз для начинающих наблюдателей:
в ADIF загружаемом на hamlog/eQSL :
а) <RST_SENT> - реальный RST c которым Вы принимали станцию
б) <QSLMSG> - указание второй станции с которой хэм проводил QSO
в) <RST_RCVD> - указываете три буквы SWL (не надо "0"или тем более "что угодно")

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

[R2PU]

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

Всю необходимую информацию Вам выдали - сопроводив её подробным описанием базовых принципов и результатами реального тестирования.
Увы так и не увидел в ответ не то что понимания - но хотя бы элементарного TNX.

Это и есть - некачественная работа программного обеспечения!

Которым пользуются десятки тысяч хэмов ....
-Тот же hamlog.online по совокупности реализованного функционала уже не имеет аналогов в мире
-Та же WSJT-X была первой и регулярно обрастает новыми цифровыми модами
- Та же JTDX имеет множество возможностей и постоянно расширяется по функционалу.
Требовать от R4AS, K1JT, UA3DJY срочного исполнения Ваших персональных "хотелок" - не сильно продуктивно и конструктивно , там и без того гигантский труд и постоянная работа по совершенствованию софта.

С другой стороны, когда здесь на форуме, такие "метры" дальней радиолюбительской связи, которые всячески восхваляют свои заслуги прошлого,
а сейчас точно также не брезгуют заносить в тот же HAMLOG "местничковые" QSO, я думаю мне, хоть и с двадцатилетним опытом в радио (а в программировании даже больше) но, как вы считаете
наверное просто нечего делать, ну чтобы не давать никому космических советов и не отнимать вашего "драгоценного" времени.
До встреч в эфире.

Решать Вам.
Со своей стороны могу предложить некоторую "перезагрузку" - и обьяснить хотя бы базовое:
- почему хэмы зачастую не сильно смотрят на "стаж", но сильно смотрят на то кто чего достиг и смог
- откуда у DXмэнов\контестменов в логе появляются не только DX QSO
- равно как и то что указание своих достижений (на том же qrz.ru у некоторых прямо в подписи) - общепринятая практика.

Рома, блин, выключай менторский тон, люди умные любят учиться, но очень не любят, когда их учат

Лёша, блин не говори за всех.
Когда начинают говорить\писать R2PT (DXCC HR) , RW3PZ (DXCC HR#1 and other) и далее по списку - согласен терпеть от них любой тон и "поучения" - и предпочитаю не гнездить свои теории и критиковать что-то там , а послушать тех кто лучше\больше\сильнее.

Нет в никсах журнала, который жрёт костыли в виде клиент-сервер на одной машине, ибо это костыль костыльный.

CQRLOG for Linux ( """ WSJT-X Logging directly to CQRLOG """" )
EWLog ( """ WSJT-X тоже работает, в настройках самой WSJT нужно включить UDP и в журнале поставить галочку использовать WSJT-X """ )
Далее не "менторствую" , бо сам на форточках.

И чо это за намёки про роботизированные станции?

Моветон цитировать самого себя, но повторюсь (из предыдущего поста): "включил-ушёл на ....цать часов - через ....цать часов пришёл и скармливай файлы программам"
Вот это в моём понимании уже не хэмрадио а что-то другое ..... (IMHO единственное исключение - DX-pedition c их стороны , впрочем там свои "камни" с ARRL , преценденты были)
Хочешь поговорить об этом - давай в другой теме (бо первые "роботы" FT8 появились ещё в 2017м, начиная с SV5DKL и понеслась .... вплоть до SQ9FVE и его "мега супер" WSJT-Z ).

То есть это получается чуть освободить руки - зло, а отвалить полляма за сдр-траесивер, который ещё и телеграф за тебя читает - типа это православно?

Не знаю ни одного полумиллионера для которых наличие декодера CW в покупаемом аппарате было ключевым фактором ))))
Если ты про локальный скиммер - то там совсем другие цели\задачи, да и проводит QSO всё равно живой оператор с ушами-руками а не "автопилот"

Давай уже не трать силы и время на переливания из пустого в порожнее, все всё поняли, нам вебинары не нужны

Чёт не увидел я понимания в в ответ на конкретное инфо а увидел очередной виток: "софт от R4AS, K1JT, UA3DJY плохой и недоработанный" + несколько "рецептов" (чего стоит только : "вот в <rst_rcvd> указывать реальный уровень сигнала, с которым наблюдатель видел ваш сигнал, хотя если честно, здесь можно писать почти что угодно, т.к. в ходе радиообмена уровни сигналов меняются от посылки к посылке" + "одно и то же значение уровня можно указывать в обеих полях! " ) + изрядно личных выпадов (старался особо не акцентироваться , бо пишуший их местами просто не понимал элементарного).

Я обычно трачу время и силы в расчёте на то что дискуссию прочитает кто-то из тех кто ищет в сети необходимое инфо , сильно не хотелось чтобы начинающие наблюдатели приняли один из тех перлов за руководство к действию.

Тем более что всё просто и оттестено:
Ещё раз для начинающих наблюдателей:
в ADIF загружаемом на hamlog/eQSL :
а) <RST_SENT> - реальный RST c которым Вы принимали станцию
б) <QSLMSG> - указание второй станции с которой хэм проводил QSO
в) <RST_RCVD> - указываете три буквы SWL (не надо "0"или тем более "что угодно")

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