The internal prefix lookup engine has been totally redone to support new wildcard matching features. Previously, ? could be used to match any character. Now, in addition, you may specify groups of characters or ranges of characters. For example,

[AZ] matches A or Z. [ABC] or [A-C] matches A, B, or C. [A-CGN-P] matches A, B, C, G, N, O, and P. [0-9] matches any digit. [A-Z] matches any letter.

A new prefix table with all Russian calls down to the Oblast level will be released.

I believe that LOGic is the only thing on the market that can handle the screwey Russian prefix system.


Here is an excerpt from the new Help file:

You may update the prefix table yourself should a new DXCC country be added or other changes in prefix allocation occur. Go to tools/setup/prefix table.

An important thing to remember about the prefix table is that it is not the DXCC list. The DXCC list is what shows up in the DXCC dropdown on the log form and the progress displays. The DXCC list (as well as zones and other entities) are stored in the Lists table (Tools/Setup/List of Valid Values). The Prefix list uses the callsign to look up the DXCC and other info from a callsign.

It is not necessary to have every conceivable prefix or callsign in the prefix table. In fact, the prefix table is not even necessary for tracking DXCC. It just makes it a lot easier. You could delete all of the records out of the prefix table (not recommended!), and still track DXCC. You would just have to manually log the correct DXCC every time. Sometimes it is impossible to tell from the callsign what the DXCC country is. In this case, you have two options. 1. LOG the proper DXCC country manually. 2. Add the callsign to the prefix table before logging the QSO. Some logging programs rely 100% on its prefix table to determine DXCC. LOGic gives you the option to add the call or not. If a call comes along that does not map to the proper DXCC country, you do not have to go fix the Prefix table. Merely select the proper DXCC manually and carry on.

LOGic searches the prefix table by starting with the entire call and searching for a match. If none is found, LOGic removes the last character of the call and tries again, repeating until a match is found. For example, consider the hypothetical call QR0ABC. LOGic first searches using the whole call, then QR0AB, then QR0A, then QR0, then QR, then Q.

There are several features that make entering complex prefix rules easier. The ? may be used in a prefix to wildcard-match any character. For example, K?6 will match KA6A, KB6CC, or even K26A if there were such a call. If you want to match a variety of characters, but not just any character, you may enclose the characters to be considered in square brackets [ ]. For exampe, R2[FK] matches Kalingrad calls -- R2FA, R2KBX for example.

Ranges of characters may be used. For example U[A-I]2 is another Kalingrad prefix. The second letter must be the letter A through I. This would do the same thing: U[ABCDEFGHI]2

[0-9] matches any digit. [A-Z] matches any letter.

Ranges and single characters may be combined. R[ACDFGJ-OQT-Z]2 is another Kalingrad prefix. The second letter must be A, C, D, F, G, J through O, Q, or T through Z.

If the prefix table has two matching prefixes of the same length, one with wildcards and one without, the one without wildcards takes precedence. For example KP4 takes precedence over K?4. This allows KP4AA to match Puerto Rico and not US call area 4.

A prefix entry normally matches the first part of the call. For instance, KG4 matches ANY call starting with a KG4: KG4AA, KG45B, and in fact would match just KG4 if there were such a call. However, following the "prefix" with and underscore character ( _ ) forces the matching call to be the same length as the "prefix". It is typically used to enter complete calls into the prefix table for entities whose DXCC cannot be determined by the prefix alone. For example, North and South cook do not have their own distinct prefix block. Normally when you log an E5 station, you have to manually select North or South Cook for the DXCC. (The current version of the prefix table as of this writing will log S Cook when you enter an E5 call that is not in the prefix table. But the hyphen in the country designator E5-S will alert you to verify the country).

However, if there is a DXpedition to one of the Cooks, and you want spotting to work properly, enter the call followed by an underscore in the prefix list for the appropriate country. For example, entering E51WL_ for N Cook will allow the spot log to correctly identify this call. (What would happen if you forgot the underscore? Probably nothing in this case. Any call starting with E51LW would count as N Cook. E51LW, E51LWA, E51LWB, etc would all count a N Cook).

The underscore may be combined with wildcard prefixes. For example, KG4??_ matches KG4 followed by exactly two characters: KG4XX, but not KG4XXX.

When entering a complete callsign with a portable designator into the prefix table, the _ must be used. For instance, DU2/WN4AZY_ . If you ommitted the underscore, the spot log would extract DU2 from the callsign and use that for the prefix lookup.

Test the prefixes you enter by selecting Get, then enter a callsign. This searches the same way the log screen does.

Note that it is not necessary to have a prefix entry that matches every call entered in LOGic. There is no need to enter every special event call into the prefix table. If a prefix does not exist, DXCC etc will not be automatically logged. However, you should log the DXCC country manually. LOGic will use this for awards progress tracking. LOGic does not use the prefix table for awards tracking. It uses the data entered in the log form only.

Click here for the update