Does Martin still get issues regarding the country files? For example, YU4EBL currently unconditionally resolves to Bosnia-Herzegovina (501) from the CallResolution table. I worked YU4EBL many times in the 1980's so for DXCC it is Yugoslavia (296). [It is unfortunate that the DXCC desk uses 296 for Serbia now so it can be confusing for the older Yugoslavia QSOs.] WP2Z, N6KB, KP4US, KL7CQ, and a few others are similar in that they resolve unconditionally to a country but all of my QSOs are confirmed in their original country (e.g., WP2Z resolves to USA - 291 but all my QSOs are confirmed for Virgin Islands - 285).
KA2xxx calls seem to resolve to Japan (339). Only KA2xx calls should resolve to Japan. KA2xxx are USA (291).
There are other issues such as I have DXCC credit for 3V8AA for a 1982 QSO but the tables say no DXCC credit. Trying to keep the tables accurate for acceptable DXCC credit is tough. Some calls (e.g., 3V8BB) are reused many times and some of the uses are acceptable and some are not which could lead to many table entries.
There still others that just seem to resolve incorrectly. For example, CR9BH in 1982 resolved to Madeira Island (256) but should have been to Macao (152 - confirmed and DXCC verified).
73, Larry W6NWS
Many thanks for info. Some problems are known, some not. The new release of country files is in progress and will be available ASAP.
Using CQRLOG 0.9.3 and cty files of 12 July I still see the following mismatches for which I have a QSL and/or LoTW confirmation and in some case DXCC verification:
LoTW DXCC
QSL Verify CQR
Call QSO_DATE DXCC Date DXCC
---------- -------- ---- --------- ----
3D2AM , 19900525, 489, ,Y,N,N, 176
AC3Q/KX6 , 19820320, 168, ,Y,N,N, 291
AL7O , 20001028, 6, ,N,Y,N, 291
AL7O , 20010217, 6, ,N,Y,N, 291
AM92KW , 19921024, 32, ,N,Y,N, 281
CU/DJ9RR , 20021123, 149, ,N,Y,N, 272
CU1UA , 19820911, 272, ,Y,N,N, 149
EG92C , 19921024, 32, ,Y,N,N, 281
FC0FHN , 19791014, 214, 19840101,Y,N,N, 227
FC6FHX , 19810131, 214, ,Y,N,N, 227
FC9UC , 19810530, 214, ,Y,N,N, 227
FC9UC , 19810531, 214, ,Y,N,N, 227
FO/DL5XU , 20010203, 509, ,Y,N,N, 175
FO/DL5XU , 20010204, 509, ,Y,N,N, 175
FO/HA9G , 20060213, 175, ,Y,N,N, 509
FO/HA9G , 20060215, 175, ,Y,N,N, 509
FO0CLA , 20000222, 509, 20030930,Y,N,N, 175
FO0POM , 20001110, 509, ,Y,N,N, 175
FO0POM , 20001110, 509, ,Y,N,N, 175
KH6DX , 19810106, 110, ,Y,N,N, 291
KH7AA , 19830305, 138, ,Y,N,N, 110
KL7KR , 19810204, 291, ,Y,N,N, 6
M1C , 19820313, 278, 19840101,Y,N,N, 223
M1IPA , 19810521, 278, 19840101,Y,N,N, 223
N6YK/V2A , 19820210, 94, ,Y,N,N, 291
PY7PO/0 , 19800922, 56, 19840101,Y,N,N, 253
R0PA , 20040221, 0, ,N,Y,N, 15
U2R , 19811129, 126, ,Y,N,N, 52
UJ8AW , 19801004, 262, ,Y,N,N, 292
UM8DX , 19860525, 135, ,Y,N,N, 292
UP2AW , 19800417, 146, 19840101,Y,N,N, 130
UQ2LL , 19891112, 145, ,Y,N,N, 130
UQ2OI , 19801004, 145, ,Y,N,N, 130
UQ2PM , 19830109, 145, ,Y,N,N, 130
UR2QD , 19801026, 52, ,Y,N,N, 288
UR2ZN , 19791103, 52, 19810615,Y,N,N, 288
UR2ZN , 19801001, 52, ,Y,N,N, 288
UR2ZN , 19801118, 52, ,Y,N,N, 288
UR2ZN , 19801125, 52, ,Y,N,N, 288
UR2ZN , 19810423, 52, ,Y,N,N, 288
US1A , 19900526, 288, ,Y,N,N, 54
VK9LNO , 20060510, 147, ,N,Y,N, 189
ZE1ET , 19810414, 452, 19840101,Y,N,N, 223
ZE2JD , 19810531, 452, ,Y,N,N, 223
ZK1CQ , 19820404, 191, ,Y,N,N, 234
ZK1CQ , 19820407, 191, ,Y,N,N, 234
ZK1CQ , 19820411, 191, ,Y,N,N, 234
ZK1CQ , 19820414, 191, ,Y,N,N, 234
ZK1XP , 19890218, 234, ,N,Y,N, 191
ZM7JS , 19810610, 270, 19840101,Y,N,N, 34
ZM7JS , 19810611, 270, ,Y,N,N, 34
ZM7KD , 19810611, 270, ,Y,N,N, 34
ZM7VU , 19820413, 270, ,Y,N,N, 34
ZM7ZR , 19810610, 270, 19840101,Y,N,N, 34
Note that by US regulation a non-US station operating in the US or one of its possessions must sign in the form OK1RR/W6. I have worked several stations that have not followed this rule (i.e., signed W6/OK1RR) but that is technically incorrect.
The practice of signing style CE9/VP8AEO instead of VP8AEO/CE9 started about 1990 (plus or minus a bit).
The callresolution.tbl has an entry for CE9/VP8AEO. However, the station actually sent VP8AEO/CE9 and the QSL also had VP8AEO/CE9.
VP8AEO/CE9 , 19810307, 241, 19840101,Y,N,N, 13
We discussed the ZL0 once before a few years ago. It is actually a ZL station and not a US station.
ZL0ADZ/KB0 , 19810417, 170, 19840101,Y,N,N, 291
I have a number of other discrepancies for which the country was determined by DX bulletin at the time, contest call resolution files at the time, and/or from contest data received during the contest that I have not included here.
Larry and others,
it seems that I have to write a longer rant about call systems and structures which knowledge helps me to judge which input should be accepted to my country files and which not. My files are now more than 16 years old and in constant development, so I had to study the call systems with all options during the time. It is, of course, not very important. Anyway, I must apply a simple rule: a change/addition/deletion can be accepted if it can be verified from at least two independent sources. If possible, one of them should be the local licensing authority which info is final. As we know, there is no SINGLE source of 100% reliable info, including ARRL DXCC Desk, CEPT authorities etc. Anyway, I can not accept input like "I have QSL so it must be correct". We remember Danny Weil, Don Miller, Romeo Stepanenko etc.
Every input to my country files is a mix of good and valuable facts, rumours, dreams and unverifiable stories. Believe me, if I should accept every input I received within the years, there will be no country files - if I had something, it will be a worthless garbage. BTW it seems reasonable to extend the README in the country files package with the simple rules what is more wanted and what less...
So, we begin with ZL0ADZ/KB0 which is the simplest one. It seems so:
1. ZL0 is reserved for guest operators visiting ZL. It cannot be used outside of the ZL territory, ie. ZL0AAA/8 can be a regular, valid and good ZL8 but ZL0AAA/VK4 is a callsign misuse unless there is a special option for which is the VK authority responsible. Such options are extremely rare, usually the holder of ZL0AAA call will apply for a VK4 call or he will use his regular call from his domestic country which should be slashed with VK4.
2. The official prefix of USA is W. So, a call like ZL4BBB/W0 does not seem suspicious but ZL4BBB/KB0 is a crap at the first look. The ZL0ADZ/KB0 is even worse and I will not accept such input, with apologies (unless the call became known as a good one).
I assume that ZL0ADZ/KB0 was used as an exapmle only on which you want to demonstrate that CQRLOG will "eat" a garbage and resolve it as a valid call sign. So there must be underlined that CQRLOG does not check the validity of a call sign. No other logger does this, also the user is appealed to use his brain, at least sometimes :-) Be sure that any validity check WILL BE NEVER INTRODUCED to CQRLOG, ie. it would be ALWAYS/FEREVER POSSIBLE to enter a bad call which would finally affect the stats. Also I am pretty sure that we ALL have such bad calls in our logs, no matter if computerized or on the paper.
In addition, there should be mentioned two different systems of slashed calls:
1. The "old system". It is still in use in countries which are not direct members of CEPT, ie. they are either not members (not signed the CEPT) or they are associated to the CEPT based on a special arrangement. This applies to the US, so you correctly mentioned that OK1RR/W6 (old system) can be operated and is valid, but W6/OK1RR is bad and should be considered as a call misuse.
2. The CEPT system. It is quite new. The prefix of the country where the operation is done must be the first, the owner's domestic call must be the second, after the slash. This system now applies to nearly all european countries. The initial CEPT schedule prescribes that either /P or /M must be added but the resulting call became very long and useless in contests and pile-up operations so /P or /M is mostly omitted. It is not 100% legal but it is tollerated with closed eyelids. All participants know that it is a bureaucratic measure (the obligatory /P or /M) which was created without any knowledge of ham radio operating basics. So, if I operate from DL, a fully legal call should be DL/OK1RR/P or DL/OK1RR/M. Because of the length I would probably use DL/OK1RR. DL is not rare but when I operate from Iceland I would use call like TF4/OK1RR for sure. Anyway, OK1RR/TF4 would be illegal.
Of course, there are countries without any system, a guest operation is not allowed (T7, HV, 1A etc.). There are also countries with rather ridiculous "system" like China from where I must operate from a club station and use call like BY1PK/OK1RR.
It seems that European publishers of DX bulletins are so tightly bound to the "CEPT system" that they wilfully changing the correctly supplied calls to the CEPT template. It is apparently the case of CE9/VP8AEO which should be VP8AEO/CE9. BTW this bad behaviour affects also QSL manager files. The US guys are biased to the old system but only few can't accomodate the CEPT-like calls. So, the EU guys have to learn a lot!
Resume: CQRLOG must accept BOTH "slashed call systems". There is hardly possible to introduce an additional flag which system is used - for more reasons: it changes in the time (so there would be neccesary to have a date of the adoption of a particular system), also some special options can't be simply covered which will result in a giant, unmaintainable CallResolution.tbl. The two systems are the reason why CQRLOG MUST ACCEPT possible bad calls. There is no other option, my apologies.
--- to be continued ---
As an aside, ugly as it may be, the ZL0ADZ/KB0 call was real and was accepted by the DXCC desk for ZL. It is probably the worst example I have seen of a call. I forget the rationale the operator gave me at the time but I don't think he liked the scheme much either but that was the ZL government call assignment at the time.
I have some odd ones like a W5xxx/1P1. The operator was using /1P1 because he was on Pelican Island (Texas) as I recall. Legal? Nope. I would not expect any call resolution scheme to decipher that one. 1P is an unassigned prefix as I recall.
I can understand your frustration a bit in trying to keep up with the variants in calls. Some are technically incorrect by the rules of the government under which the station is operating. These variants can certainly complicate the decoding rules.
Further complicating things are the fact that a call like FO0xxx may operate from several different DXCC entities in a short period of time such as 3 days in FO, 3 days in FO/A, etc. Short of the callresolution table showing each period at a different DXCC entity there is no good way to resolve it. The ambiguous prefix table does help to point out calls that may need human intervention.
All of the calls in the list in my previous response are real QSOs and calls. All (or nearly all) of calls used to resolve in the yplog days but fail under CQRLOG (I know, different algorithms).
73, Larry W6NWS
Larry, I don't get frustrated. My search for most accurate country files is a never ending biz and now takes simply much longer time than I assumed 16 years ago. The files with accompanying algorithms is a boring, hard "formica style" work but it should be done and I am willing to do this. No reason for crying :-)
Again, the DXCC Desk, LoTW etc. can't be and is not the final authority, with all respect to my many American friends. There are more "country systems" (EWWA, WAE, R-150-S etc.) which should/must be ignored in the same way as both mentioned above. CQRLOG uses the DXCC system because it is most popular and most straightforward. But it is a system only. As I said before, the only authority in the ZL0ADZ/KB0 case can be the NZ licensing authority. You bet that I emailed to many licensing authorities asking to verify a call. The reasons are apparent, anyway I plan to return to this stuff in another part of my talking about calls.
Can you explain the meaning of following lines? I see the call and date as the first two items. The numbers in 489, ,Y,N,N, 176 can be ADIF country numbers but that's all I can read from the line.
LoTW DXCC
QSL Verify CQR
Call QSO_DATE DXCC Date DXCC
---------- -------- ---- --------- ----
3D2AM , 19900525, 489, ,Y,N,N, 176
AC3Q/KX6 , 19820320, 168, ,Y,N,N, 291
BTW your input is very valuable, it helped me many times to solve a bad problem. Anyway if you have (and willing) to offer your whole log for analysis, I can do this. Of course, you can also try it yourself. It will be very interesting to see the unresolved ones (create a filter with an ! as a DXCC country) as well as badly resolved entries.
The HTML messed up the columns on the list. The first two columns are call and QSO date as you thought. The next columns are actual DXCC country number, DXCC verification date if any for the QSL I have, and the last column is the DXCC country number reported by CRLOG.
I did my first attempts at call resolution in the early 1970's using the ITU allocation chart. It worked quite well for "normal" calls (e.g., OK1RR, W6NWS) but did not do as well for other calls. At the time I did not try to identify country regions as much.
Your tables are far more complete and, of necessity, more complex. They contain considerable historical information. It is the historical data that makes it complex. The cty files used by N1MM, CT, and other contesting programs since the mid-1980's are simpler because they only deal with the present - not past call assignments. Those programs still have to deal with odd call formations.
There are many country schemes in existence today. DXCC is probably the most widely used (and maybe the oldest). Your tables still resolve to the DXCC country number and not to a CQ entity for example. The N1MM etc cty files have indications for CQ contest entities that are used for contests that distinguish such entities.
The data I have provided for the mismatches (out of 100K+ QSOs) I see are to help make the tables as accurate as possible. You as owner of the tables will have to decide whether the data is of such importance as to require changes in the tables and/or algorithm changes to accomodate such data. You can, of course, choose to ignore the input for whatever reason suits you.
BTW, the only "!" returns were for /MM stations as would be expected and for a few bad calls also as expected.
I do appreciate the work that you have put into the tables over the years. It is a somewhat thank-less job.
73, Larry W6NWS