Log4OM

Hi all
I just wanted to publicly thank Terry and Daniele for their dedication to solving a specific problem.
Some of my old DXCC records at ARRL have been manually entered (at ARRL) into the LoTW system with extremely poor data, making it useless to update my DXCC statistics.
Some of these even include credits without callsign identification, or wrong dates, etc.

Terry and Daniele have spent countless hours to help me solve this issue (not entirely, but it would have been completely impossible considering the above), so what remained to be adjusted manually by me was minimized.

This is first class support, and again, I want to publicly thank them both.
Keep it up !!

Paul,
Thanks for the kind words, all part of the service.

To answer your question re duplicates, posed on another logging programs google group this week.

The reason you get dupes when importing an FT8 ADIF is because when you log with FT8 using TCP/UDP or JTalert/Gridtracker direct logging to Sqlite the QSO time used is the start time of the QSO, however the FT8 program ADIF file records the end time - So a miss match!

As there is a time difference logging programs consider these to be two different QSO's and you find duplicates in your log!

Log4OM overcome this by providing a 'Duplicates threshold' in the ADIF import window which makes our software ignore any QSO time within the specified time period.

This makes it impossible to import these apparent dupes and easy to eradicate should a user have inadvertently already caused dupes.

BTW this also used to happen with FLdigi but they wisely added a user choice of what time to use

Thank you Paul
We always learn something interesting every day when Terry (and me, a magnitude less than him) is exploring user needs.

Best 73
Lele

Terry and Lele
Many thanks again.
Terry, regarding dupes, they are created by MSHV, which will log everytime a RR73 is sent. So IMHO, I do not think it is a TCP or UDP issue.
Let's say TX7N sends RR73 (and logs) but the other station does not copy , sends the report again, then TX7N will send RR73 again... and log again.
This threshold in Log4OM is a fabulous tool to eliminate these...

Take care !

No it's not a tcp/udp issue they save the correct start time

But MSHV saves it's own ADIF as well and the QSO time recoded in that is the end time

So UDP might correctly save 15:15

But the ADIF records 15:40 perhaps!

So now they can be seen as two separated QSOs when the ADIF is imported