EXPORT:
We export all available data in a TL QSO-record except the country number. These numbers are a volontary feature in ADIF anyway and quite difficult to maintain and it takes a very high effort to implement their export. Thus we decided: Before we implement this feature we would like to gain some experience with its efficieny. Unfortunately the country numbers in the ADIF standard do not match those in use in TL for more than 10 years. This creates a queu of follow-on problems as you can imagine.
Please note that ADIF does not include some of the notations as used in TL. Most notations, however, are simular. Unfortunately there is nothing which matches TL's KEYWORD facility as such. In order to at least save the data in there we export the content of the KEYWORD field to what is denoted by "IOTA" in ADIF. This should meet most user's applications in use of this powerful facility. Other user specified keywords which were added to the COMMENT field will be transferred since we export the complete COMMENT field as it is.
Please note: ADIF includes no specification for the 4m-band. This data cannot be transferred in neither direction for this reason. Furthermore, there is no definition for bandpoints, multipliers and other contest items.
You can choose to export whatever you want. The records for export are to be specified by their record numbers within the dialogue.
The file to be exported should have the extension ...ADI. It will be copied into the subdirectory of TL which you specified as FILEDIR in SETUP.
IMPORT:
We import all data TL can cope with and as specified in the ADIF standard. The band assignment is based on what is denoted BAND in ADIF. There is a definition for a volontary FREQUENCY parameter which could be available from a foreign log. This one, however, has no specified band limits which makes it cumbersome for use ( if available at all ).
The file to be imported has to be copied into the subdirectory of TL which you specified as IMPORTDIR in SETUP.
Since country numbers are a volontary feature which one cannot rely on all imported CALL data will be run through the prefix matching procedure in TL. If the prefix is unique: No problem. In case of ambiguous prefixes the operator is prompted for the correct assignment right away. TL searches through CALLS.DAT as well and keeps an eye on the entries there. So if you have this file up to date TL will automatically assign the odd calls and ambiguous calls to the correct DXCC-entry for you. You can choose to press ESC if you are unsure about the origin of an ambiguous call. In this case the record will not be used to update your DXCC standings and marked in the COMMENT-field as an erroneous entry.
Furthermore, this record is transferred into BADLOG.DAT for your attention and close inspection. This helps you to go through the log in TL's review mode ( F6 -> F6 ) and do the necessary corrections on the spot.
The same applies if something went wrong with the import of either the BAND or Mode since these parameters along with the CALL assignment are the absolute minimum in order to make the record valid for processing in TL.
If other parameters are available as import, such as:
CNTY US-county
NAME ..of the operator
QTH ..of the operator
CONTEST_ID ...
STATE US-State
We procede in the following order:
STATE XY is placed in the KEYWORD-field if it is still empty as S-XY.
NAME, QTH and CNTY are transferred into the COMMENT-field if it is still empty. They will then be separated by a blank from each other.
CONTEST_ID is placed in the COMMENT-field if there is space available.
IMPORTANT NOTICE:
You should have made all necessary corrections on the log records BEFORE you start a SORT & REBUILD operation.
COUNTRY.DAT:
Outlook for version 3.22: