One thing that users of both packages will notice is that QSO details appear immediately in this new package where it might have taken a few seconds to change in the original. There are 3 different updates done this way as it ‘thinks’ they are needed. It does some updates as it starts up, not every time though, and that becomes obvious as you see a progress bar appear, increment towards 100% and then disappear. This ‘new’ LogView for WSJT-X was effectively re-started as a new project based on different file techniques, using different update techniques and a single timer to check and process WSJT-X files only at non-critical times.

It actually got messy and occasional errors appeared. The original Log File Viewer software tuned out ok but it did have some issues related mainly to the fact that it required multiple timers to set up the background processes: copying changed files from the source WSJT-X folder, processing them. More mostly-relevant details can be found on the original WSJTXViewer page.īEWARE of warning errors on 60 metres : fix is here ! Please ensure that you read all of the descriptive texts on this page. It all depends on what you actually have.Replaces ‘WSJT-X Log File Viewer’ started 27th March 2018 In some cases it may be a very simple job, in others it will be more work. The difficulty of the task depends on how close the structure of the CSV is to the requirements of ADIF. In some cases ad hoc scripts may be needed but usually it can be done in Access. Faced with a generic CSV file, I’d probably import it into the database and then do any manipulations necessary to coerce it into the structure that my ADIF generator expects. Access has powerful import and export facilities including CSV.

I have a Perl script which will generate ADIF from my logs stored within the database (or whatever subset I want). The way I deal with this issue is to use Microsoft Access as an intermediary. Any CSV to ADIF conversion has to know what it’s dealing with. An amateur radio log in CSV might choose to encode the band as “80m” or “3.5MHz”, for example. It says nothing about how any particular data is to be encoded. CSV itself merely defines the syntax, and even within that there are variations such as whether fields are quoted and whether the first line is used to declare field names. On the other hand CSV is a generic file format used to represent relational data in a textual format.

The ADIF side of it is OK there is a specification of how to represent a log in that format, both syntax and semantics. The problem with your question is that it isn’t really well defined.

Adif to csv conversion