=Архив= LogHX: Аппаратный журнал любительской радиостанции, тема №2

[RX4HX]

LogHX - программа аппаратного журнала любительской радиостанции с большими возможностями настройки "под себя".

Вложение 244265


Сайт программы: RX4HX

Помощь по программе: Ссылка --> Начальная страница

Ссылка --> на файл Whatsnew.txt с информацией о последних обновлениях в релизе:

Ссылка --> Актуальные релизы и история изменений.

Канал на Youtube Сергея RD9CX: LogHX

База дипломов - >> Вложение 262565

Уважаемые друзья!
В связи с большой загрузкой по работе отвечать на личные письма и телефонные звонки возможности нет!
Просьба все вопросы и предложения писать на форуме QRZ.RU
Спасибо за понимание!

[R2PU]

Ну раз уж JTDX отправляет сразу на eQSL, стоит это и в логе сделать, раз владельцы eQSL на это не ругаются))) Думаю это решит все проблемы.

Я что то пропустил ? (некоторое время назад RX4HX вроде как говорил что автоотправки на eQSL не будет по принципиальным соображениям ) . Было бы очень неплохо (естественно - с возможностью отключения) )))

Но одинаковое "как округлять и как отправлять (по time on или по time off ) " всё равно не помешает , иначе есть большой риск попасть рано или поздно на апокалипсический сценарий : "среднестатистический хэм решивший выгрузить журналы за несколько лет с ужасом обнаруживает на сервисах сотни и тысячи дублей " (на текущем этапе когда LogHx пишет time_on из time_off JTDX такая вероятность действительно есть).

Так он сейчас и отбрасывает.
Время time off 132750 (пост 3431). при округлении в логе, по правилам округления, должно бы записатся как 13:28
Но там почемуто стоит 13:27, то есть секунды просто отбрасываются.
Или правила округление теперь уже не те, что в былое время. .

Судя по картинкам в моих двух постах выше и по тому что на eQSL везде в формате hh:mm - просто отбрасываются секунды (без округления в сторону ближайшей минуты). Пускай так (простота и единый стандарт иногда дороже правил арифметики ).

Вопрос лишь в том что на скрине в сообщении #3431 отчётливо видно разницу в 4(!) минуты по одному и тому же QSO - тут дело уже не в округлении а в разном подходе - JTDX шлёт на eQSL по time_on , а лог пишет (и шлёт на eQSL) по time_off (причём time_off из wsjtx_log.adi превращается в LogHX3 в time_on) .
Можно я уже не буду скринить adif из LogHX открытый в текстовом редакторе - там именно TIME_ON и никак иначе (совпадающий по времени с time_off в wsjtx_log.adi , на 4х минутах разницы очень хорошо видно).

Бог с ней с арифметикой и правилами округления , можно как то поправить в LogHX3 чтобы time_on соответствовало действительности (бралось из time_on в wsjtx_log.adi) ?
Хотя тут тоже есть подводные камни (например DX который ответил спустя полчаса отправит на eQSL time_off , естественно не совпадёт с нашим time_on ) .... в общем чем дальше тем страшнее ))))).

В идеале бы конечно и time_on и time_off и в JTDX и в LogHX3 (в JTDX уже реализовано в файле лога wsjtx_log.adi есть и то и то) соответствующие друг другу в разных софтах ....
+ возможность проставлением галочек в настройках выбирать по time_on или time_off отправлять на eQSL - тогда бы каждый хэм мог найти для себя приемлимый вариант и не опасаться дублей.

[RX4HX]

по принципиальным

Не по принципиальным, а по просьбе владельцев eQSL.

отбрасываются секунды

Да. Ошибся - именно отбрасывает, потому что то ли LoTW отбрасывает, то ли еще кто... Не помню уже.

разницу в 4(!) минуты по одному и тому же QSO - тут дело уже не в округлении а в разном подходе - JTDX шлёт на eQSL по time_on , а лог пишет (и шлёт на eQSL) по time_off

Вот именно по этому лог шлет только одно время. Разница в eQSL допустима по моему в 30 минут. Лог у меня проверяет соответствие с LoTW/eQSL +/- 30 мин.

[UR5KJK]

Ну раз уж JTDX отправляет сразу на eQSL, стоит это и в логе сделать

В данном конкретном случае это не поможет, так как лог всёравно будет записывать Time off вместо Time on.
Просто надо устранить ошибку трансляции времени с ADIF JTDX в LogHX.

Лог у меня проверяет соответствие с LoTW/eQSL +/- 30 мин.

Разница в eQSL допустима по моему в 30 минут.

Это допустимый разброс времени при синхронизации подтверждений.
Речь идёт о загрузке QSO.
При загрузке на e-QSL выдаётся время, которое записано в логе и
e-QSL не определяет повтор, так как разное время. Даже если разница всего одна минута.

[RX4HX]

бралось из time_on в wsjtx_log.adi

Несколько страниц назад меня убедили что нужно брать time_off. По этому пока ничего менять не буду, потому как разница даже в 4 мин ни на что не влияет. А введение в лог 2-х времени только к путанице приведет.

[UA3LLS]

Алексей, помнится, Вы упоминали в планах подружить лог с Опен Оффис, чтобы пользователи смогли отказаться от не всегда законного использования продукта от МелкоМягких. ..?

[UR5KJK]

меня убедили что нужно брать time_off.

Так почему же при экспорте из лога в ADIF оно получается time on.

[R2PU]

меня убедили что нужно брать time_off.
разница даже в 4 мин ни на что не влияет

Ещё как влияет ...
1) Ровно с момента включения автоотправки в JTDX на eQSL при каждой отправке из LogHX3 на eQSL будут множится дубли (достаточно разницы в минуту - и одно QSO превращается в два , см предыдущие посты) . Свой же коллега радиолюбитель так и будет наступать на эту мину , вон не далее как сегодня опять спрашивали-отвечали как включить в JTDX отправку на eQSL Сколько он наотправляет дублей (десятки ? сотни? тысячи?) пока заметит неладное и как их потом будет вычищать - вот в чём вопрос ....
2) Страшно подумать сколько дублей (сотни или тысячи) получит коллега - хэм вдобавок к выгруженному журналу выгрузивший на еQSL файл wsjtx_log.adi из JTDX (такие рецепты тоже проскакивали в теме JTDX - как вариант восполнить утраченные связи)
3) Реакция некоторых корреспондентов получивших два запроса на одно QSO тоже вполне предсказуема ....
4) time_on в переводе на великий и могучий - время включения (начала QSO) , time_off - время выключения (окончания QSO). Режьте меня - не понимаю кто и зачем убеждал подменить одно время другим (лог пишет время time_on т.е начала связи по времени окончания QSO ). Но теперь я кажется понимаю почему раньше не было проблемы с дублями а теперь она есть ....

ничего менять не буду

Ваше право , мы Вас услышали (лог пишет time_on по time_off т.е времени окончания QSO , т.е фактически подменяет время начала временем окончания) . Теперь хоть понятно что происходит - откуда берутся дубли и почему иной раз время QSO не совпадает с временем указанным корреспондентом . Знание сила !

Так почему же при экспорте из лога в ADIF оно получается time on.

Потому что Алексея убедили превращать time_off в time_on для каждого QSO (как бы так помягче сказать .... по факту лог просто сохраняет\посылает каждый раз недостоверные данные о времени time_on) .....
Теперь хоть понятно откуда посыпались дубли + откуда временами берутся красные крестики в hamlog \ неподтверждённые связи в qrz.com и clublog.org (при том что бэнд\RST\mode совпадают) ....
Равно как и понятно что в случае осложнений надо сразу открывать wsjt_log.adi из папки JTDX и смотреть настоящие time_on и time_off + регулярно проверяться на наличие дублей на eqsl и прочих сервисах (с ужасом припоминаю - в святой уверенности что time_on в журнале и JTDX совпадают - не выгружал ли я файл wsjtx_log на другие сервисы , вроде как не выгружал , тому кто так сделал крайне не завидую ....).

[UR7TT]

НАПОМНЮ

http://forum.qrz.ru/355-loghx-appara...ml#post1421528

[RX4HX]

на eQSL будут множится дубли

Решение этой проблемы я Вам сказал - отправлять или из лога, или из JTDX.

подружить лог с Опен Оффис

Учитывая тот факт, что особо это никому не надо, а работы по разбору формата Опен Офис много - так и отложил это в долгий ящик.

[RX4HX]

колонка Print

Она заменена колой PrintQueue.

[RT5Q]

Связи в лог из JTDX влетают на ура. Указываются и рапорта в Дб. Но после выбора позывного двойным кликом в JTDX позывной в поле ввода на сером фоне.
Где нажать пимпочку.

[UR7TT]

Она заменена колой PrintQueue.

В чем смысл этой колонки? Как ее редактировать? И как отметить QSO в очередь на печать?
Раньше включил колонку принт, пробежался по логу, отметил нужное, оно появилось в заданиях печати, отпечатал, колонку скрыл.
Теперь как?

[4Z5CP]

Выбираем нужные связи пробелом, правый клик мышки :

[RX4HX]

Но после выбора позывного двойным кликом в JTDX позывной в поле ввода на сером фоне.

Причина тут простая: лог определил, что сданным корреспондентом связь уже была RTTY - на бендмапе ведь эта модуляция для частот FT8 указана? Как этого избежать - добавить на бендмап частоты FT8.
Я так понимаю, причина в этом.

[UA9OP]

Связи в лог из JTDX влетают на ура. Указываются и рапорта в Дб. Но после выбора позывного двойным кликом в JTDX позывной в поле ввода на сером фоне.
Где нажать пимпочку.

объясните при мудрость ввода и серый фон....что это значит??