LogConv FAQ - Features

Use the GUI app license tool to enable all of LogConv's features.
Q: What file formats does LogConv support?
LogConv currently supports reading ADIF (*.adi), Cabrillo (*.cbr), CT (v 9 & 10) (*.bin), Log EQF (*.eqf) and tr Log (*.dat) files. It write to both ADIF and Cabrillo format. Not all logging programs or file formats support all contests. Refer to the log matrix file for a complete list of which contests are supported in each file format.

Q: How do I tell LogConv what type of file I am converting?
You don't have to. LogConv uses both the suffix of the filename and the actual contents of the file to determine in what format the input file is. Note however, that just because a file you wish to convert has the same suffix as a supported log format does not mean that LogConv will know how to convert it.

Q: What is QSO Normalization?
LogConv reads input logs and tries to make sense of the information contained therein. Many programs do not mark their fields to fully identify what was sent. For example, a program might just mark a grid square received as "RCVD". Some log conversion programs will just create an ADIF file with a field marked <RCVD> and pass the value through but in doing so some potentially valuable information is lost. LogConv knows what information is exchanged in a given contest and can properly mark the data with the correct identifier. So instead of a "<RCVD:1>7" field you'll get a proper ADIF "<ituz:1>7" field.

Click on the extrapolate option on the main dialog to get more data.
Q: What is QSO Extrapolation?
Extrapolation is the process by which LogConv takes a QSO's minimal information and attempts to infer additional information about the station's location. By doing this you can convert logs to ADIF format with more geographic information than the original files LogConv converted. These extra fields can help in awards checking depending upon the software package into which you feed the converted file.

Here's an example QSO without extrapolation in an output ADIF file:
<call:4>K5TR <qso_date:8>20040612 <time_on:6>180400 <band:2>6m <mode:3>SSB <rst_sent:2>59 <rst_rcvd:2>59 <gridsquare:4>em00 <eor>

Here's the same QSO with extrapolation:
<call:4>K5TR <qso_date:8>20040612 <time_on:6>180400 <band:2>6m <mode:3>SSB <rst_sent:2>59 <rst_rcvd:2>59 <state:2>TX <cont:2>NA <gridsquare:4>em00 <cqz:1>4 <ituz:1>7

Note the new fields in bold, the values of which were deduced from the gridsquare alone.

Q: What does the "Generic SRX Field" (-srx) option do? (Introduced in v2.02)
Some logging programs use the ADIF <srx> field to store generic information exchanged in a contest, even though the ADIF specification states that this field is for serial number received only. So you could have file contents that look like this:

<qso_date:8:d>20050108 <time_on:6>180707 <call:5>JA3RL <mode:4>RTTY <band:3>15m <SRX:3>022 <eor>
<qso_date:8:d>20050108 <time_on:6>181620 <call:4>N5XU <mode:4>RTTY <band:3>15m <SRX:2>TX <eor>

Note that one of the records contains a valid serial number and the other non-numeric data. LogConv's SRX option causes the field to be parsed like the "SRX_STRING" field, which is valid for generic contest exchange data. LogConv can then attempt to detect the type of information being received, in this case a serial number in the first QSO and a State in the second.

Q: What does the "Auto Time Increment" (-timeinc) option do? (Introduced in v2.03)
Some logging programs only include hours and minutes in their QSO timestamps and exclude seconds. When importing such files into some programs the order in which QSO's were logged can get shuffled, depending upon how the importing program handles them.

In order to ensure that QSO order is maintained, LogConv includes the auto time increment option, which will add a second to any QSO that matches the previous QSO's timestamp, ensuring the ordering is maintained. For example the following input:

    <qso_date:8:d>20050108 <time_on:4>1807 <call:5>JA3RL <mode:3>SSB <band:3>15m <eor>
    <qso_date:8:d>20050108 <time_on:4>1807 <call:4>N5XU <mode:3>SSB <band:3>15m <eor>
    <qso_date:8:d>20050108 <time_on:4>1807 <call:4>W1AW <mode:3>SSB <band:3>15m <eor>
    <qso_date:8:d>20050108 <time_on:4>1808 <call:6>KA5WSS <mode:3>SSB <band:3>15m <eor>

will show up in the output file with the following timestamps:

    <qso_date:8:d>20050108 <time_on:6>180700 <call:5>JA3RL <mode:3>SSB <band:3>15m <eor>
    <qso_date:8:d>20050108 <time_on:6>180701 <call:4>N5XU <mode:3>SSB <band:3>15m <eor>
    <qso_date:8:d>20050108 <time_on:6>180702 <call:4>W1AW <mode:3>SSB <band:3>15m <eor>
    <qso_date:8:d>20050108 <time_on:6>180800 <call:6>KA5WSS <mode:3>SSB <band:3>15m <eor>