Hi!
I got 0.9.3 working as I want on my desktop with the latest DXCC-tables and all that. I installed 0.9.6 on my laptop to have a portable log as well. These two versions of CQRLOG does have different opinions on how many DXCC I have worked per band. The totals are the same.
Here's what I've done:
-I export the desktop ADIF to the laptop 0.9.6.
-I "clean up" the log from unknown DXCC:s by filtering DXCC = !. By doing this
I can correct the bugs I know so far, such as 5V7-calls, SX for Greece and a RA3-call that CQRLOG for some reason does not recognice. I only leave the /MM-calls as unknown. The rest is up to CQRLOG to solve.
Now, after rebuilding the stats I have the same number of worked DXCC:s in both machines.
But the laptop says for example 302 worked on 20m while desktop says 303, which is correct. I print both stat-reports in HTML, cut them in to matrix-tables to compare them. There is no difference at all when comparing the statistics DXCC by DXCC and band by band. Something must go wrong in the calculation process...
/Mikael SM6VJA
HI again!
After investigating this a bit more I do change my statement.
The problem was some of the same odd callsigns that have been troubling me before:
-PJ6A was sorted under PJ7 in CQRLOG. I have already corrected this once, I know.
-UO4OH from 1993 was ER (Moldova), CQRLOG wants it to be UN (Khazakstan)
-3D2IO/R was worked as Rotuma Island, CQRLOG wants it to be Fiji
-SV5RDS/J was an JOTA activity on SV5, CQRLOG puts SV on that.
I fully understand that it is impossible to respond correctly to all old and odd callsigns.
That is more or less a problem in every computerized log.
BUT there is a feature that I dont like:
-When I find a QSO that is not the DXCC I worked, I open the QSO in EDIT-mode. Within a second CQRLOG changes the DXCC according to the latest list I guess. There is no warning that this will happen. So if I dont look carefully when opening the QSO for edit, I have changed the DXCC of a QSO without knowing it. For example in the imported CQRLOG-ADIF UO4OH is DXCC Moldova (ER). When imported to a brand new CQRLOG-installation, it overrides what is in the ADIF and I get back my old log-bugs that I already have solved in the imported ADIF.
-Is there a report-file somewhere that shows what has been modified compared to the imported ADIF?
-Is there a way to edit a QSO and mark it with "DONT EVER TOUCH WHATEVER THE NEW DXCC LIST SAYS"?
Best regards,
Mikael SM6VJA
Mikael SM6VJA
There is an update of country files available, which should solve the issues mentioned above, ie. all Rotuma stations signing 3D2**/R are now assigned to Rotuma and all 3D2**/C to Conway Reef. This should help in particular, not all Rotuma and Conway expeditions signing /R or /C respectively.
The Jamboree stations (/J) resolution is another issue. It now works properly for Dodecanese SV5 (and SW5, SX5, SY5, SY5 and J45) as well as for Crete SV9 (and SW9, SX9, SY9, SY9 and J49). The same situation was found with EA6, EA8 and EA9 and all variants of these prefixes. There is a bug which is now fixed. Many thanks for reporting!
Moldova/Moldavia - the prefix date change (UO->ER) is 1993/08/27. This date was changed from previously bad/buggy entry. Also thanks for advice!
PJ6A never was a problem. Remeber that since 0400 UTC, October, 10, 2010 is is a separate DXCC country (see our front page info) however before the dissolution of the Netherland Antilles PJ5 and PJ6 was the same DXCC entity as PJ7.
If you did not get the latest country file set updated via the automated procedure, download it from the 'Country files' section (see the menu) and perform the update manually (follow the help). Don't forget to rebuild your stats!
73, Martin, OK1RR
Hi again!
Thank's for coming back so fast, it wasn't that urgent ;)
For some reason my program did not suggest an automatic update of DXCC-list this time
but I loaded it manually. The problems I mentioned seem to be solved. I still have problems
with a few QSO:s, listed below.
-UA3KM is an "unknown country"
-K3J was for a limited period KH3, but you know that already
-5V7C is listed an "unauthorized operation". BUT I have it confirmed in LoTW and it gives me DXCC-credit there! So I guess ARRL puts OK on that one.
-UO4OH was changed to ER. If the date of change, 1993/08/27 is correct, the operator has not changed his callsign in time. The date of my QSO was 1993/12/27.... so CQRLOG is probably right here.
What I really would like when I import an ADIF is to see in the error-log which QSO:s CQRLOG has changed or will change to fit the DXCC-tables. Or if a report file could be generated after a re-build? Its a bit time consuming to solve this manually every time it happens, even if I get faster every time ;).
Best regards,
Mikael SM6VJA
Mikael SM6VJA
Mikael, I am afraid that your notes are useless unless you provide exact QSO dates. All calls you mentioned have date limited validity and/or country resolution.
The prefixes of former USSR are a nightmare. No official change dates available (from the early 90s), very often we need to observe other "symptoms" like award rules etc. Anyway, there are many unpredictable political influences, just now you may note UF6V stations from Georgia/Abkhasia using the old USSR prefixes etc.
There are also prefix/region changes realized later. Note that before a date (whoch is still unknown) there were no UA3K. Since WW2, there are 5 (FIVE!) principal changes of Soviet/Russian prefixes.
During USSR dissolution, there was no force to prescribe that the prefix must be changed on a particular day. If we introduce an overlap (covering both alternatives) it will lead to many troubles including unpredictable program behaviour. There is no logger providing 100% accuracy in ex-USSR country resolution. A very similar situation may happen in former Yugoslavia.
I cannot exclude that some date limits will be changed in the future. Thus, we need exact QSO dates like you provided with UO4OH.
Hi!
UA3KM has been active until May this year according to DX-cluster. I worked him last year. That call seems to be used mostly in contests. His callsign today seems to be R3KM, probably to get a shorter cs for contest. Anyway, lets leave it, UA3 is workable from here nearly on all bands every day. I understand the problem. As in any system bad input gives bad output. CQRLOG works quite good in with these old callsigns.
5V7C must have been approved by ARRL since LoTW counts it as DXCC credit. But I cant find any approval-info on ARRL website.
Some thoughts:
May be it would be better to limit the callsign rules only to the prefixes for the DXCC-entities that have fuzzy callsign rules that are not followed? After all, CQRLOG cannot react in advance if a new type of callsign suffix suddenly appears.
So, for example, if I work an UA3x, UA3xx or UA3xxx I would like it to be displayed as "Russia UA(eu)" in the program. Always. Not as an "unknown country", because that is not the case.
For 5V7C, it is still DXCC=5V even if appears to be not approved. So "not approved operation" or "unknown suffix" should not mean "#" or "!" in DXCC-column. Unknown prefixes should trig "#" and "!".
Well, that was a highly personal opinion.
Thanks for working so hard with the program, hats off!
Best regards,
Mikael SM6VJA
Mikael SM6VJA
Mikael, the only useful input is the filtered ADIF output from your log. Put an ! into DXCC field and export the result into ADIF. Repeat the same with # in the DXCC field. Email the resulting ADIF files directly to me (martin (at)ok1rr.com ... the (at) is @).
The 'global' rules as you suggested are not fuzzy but very often misleading - you will not receive any "unknown country" identifier but very often a bad result. In most cases, the second most important is the DATE. We must care all variants since 1945 ... BTW what difference is between UA1KAD and UA1KAE?
Stations not approved - generally a valid QSO is with properly licensed station. More, license rules does not allow to QSO any station which is not entitled to work withn amateur radio service. There is not guaranteed that the unapproved station worked on the legitimate basis. DXCC/ARRL is the only institution who cares the proper licenses including landing permissions etc., all papers needed to became legitimate. Another important point is the proper QSLing procedure, some QSL managers sell QSLs or giving blank QSLs away etc. Not valid for DXCC does mean that something is dubious/not verifiable. Such station will be with highest probability rejected from all serious operating events. A particular station must be verified first (Bill Moore, NC1L), then will be removed from the "black list". LoTW is a proof, however it is not verifiable for me unless I also worked the station. Otherwise I can't be responsible for the country data. With my personal apology, 5V7C is not 5V until approved by the DXCC desk.
I agree... I get your point regarding regulations of how to make a proper, valid QSO and what makes it approved and possible to QSL.
But. The basic problem in the statistics view as I see it, is that I can not see that I have worked an entity on a band, that probably WILL be approved as soon as the papers arrive at ARRL. Which may be a question of years, for example 7o0ygf, which took nearly a decade.
If I dont see what "I belive I've worked" in the statistics, I may spend tons of hours infront of the radio again to catch a rare one on the same band that I probably already have worked, just because its invisible to me. So I find it desirable to have not only "worked (X)" and "confirmed (L)(Q)" in the statistics view. A "worked but not approved" -mark would give me the information I need to judge what I have in my log and decide if I want to spend hours and days chasing the new one again. My totally worn out paperlog-DXCC-matrix gives me this answer, while CQRLOG does not. May be an extra statistics mode like "Confirmed and approved by ARRL" where non approved calls are blocked out would do it? I hope you understood my explanation.
5V7C is a good example. It's been worked, confirmed with paper QSL and LoTW but not yet approved by your source, which means it does not exist. Shall I work 5V again? CQRLOG DX-cluster window says YES! It could say "you have worked a 5V that is not yet approved".
At the moment there are no special "!" or "#" in my log, the most is solved or forced to some DXCC. But I plan to re-install all because something has made my LoTW-confirmations in the statistics go bananas. When I do this, old trouble usually show up and I can e-mail you the unknowns and the unapproved.
Best regards,
Mikael SM6VJA
Mikael SM6VJA