LogConv FAQ - Features
|
Use the GUI app license tool to enable all of LogConv's features. |
Q: What file formats does LogConv support?
A: 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?
A: 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?
A: 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?
A: 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)
A: 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)
A: 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>